Date: Fri, 07 Apr 1995 00:29:04 -0700 From: "Jordan K. Hubbard" <jkh@freefall.cdrom.com> To: Stephen Hocking <sysseh@devetir.qld.gov.au> Cc: hackers@FreeBSD.org Subject: Re: Hack Request #1: Doom Seed Message-ID: <25099.797239744@freefall.cdrom.com> In-Reply-To: Your message of "Fri, 07 Apr 95 04:38:54 GMT." <199504070438.EAA09973@netfl15a.devetir.qld.gov.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> For each player, a client would exist that spoke to the server > using a well defined protocol. This protocol would cover the types of > objects that were visible, their orientation, distance, xyz co-ords and the > textures that they were made up of, and the health of the player. This in > turn would allow one the freedom to create various clients that could > display in the way they best saw fit - polygon shapes for X terminals, > textured bitmaps for local connections with shared memory, line drawings for > monochrome X terminals. One could even create clients for the various PC Bleah. :-) Why not just have a tokenized, interpreted language that's platform independant and have the server download the object visualization code to the client! The object then runs its self-display code and requests that the client "draw" it through a generic drawing API provided for all objects to use. The actually client is free to draw the best representation it can of what the object requests - the object doesn't get to make any assumptions about how it really looks. > The monsters could also be modelled as objects with processes of their > own, connecting to the server. One could have fun defining a language that > described the behaiviour of each monster, usually in response to various > classes of events (sighting a player, attacked by something, random > movements). Monster is just a slightly more complex object, again running locally. Believe me, any model where you have a central server running the world bogs down VERY quickly. You want to do what "Hot Java" does and have the clients distribute the problem themselves. Unlike Hot Java, of course, your objects would probabably represent full threads that didn't just go away on a connection dropping but would assume that the central server would either get back to them or keep a connection open for continuous updates. Make the object<->server messaging API class oriented so that messages can propagate up the inheiritance chain until until somebody who knows how to deal with them is found. Thus you can use your clients & server for creating anything from a multiplayer space opera to to a world economics simulator. All most intriguing.. Ah the things one could do if one had infinite amounts of time! :-) > handled by netaudio, but talking to the device direct would be fine. The > server would also have to calculate what you could hear and what stereo > position/volume it would be. Careful - I would do that also with a preemptable thread. You want to be able to halt currently playing sounds in their tracks when new ones come along or the whole thing doesn't sound "synced" enough. Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25099.797239744>