Re: Misc notes/thoughts.

["Kristofer M. Bosland" <krisb@seattleu.edu>]

On Mon, 11 Dec 1995, Michael B. Martin wrote:

> 
> I agree with this.  I think the greatest feature of crossfire is its
> multi-player ability, and adding clients for non-UN*X OS's could help
> add a *lot* of new players (hopefully not appearing overnight, though,
> so those people running servers would have a chance to upgrade the
> memory on their machines ;).  To this end it would seem to make sense
> to have a well-defined client-server model (the server code being
> maintained in C or C++, say) with the clients relatively easily
> recodable in whatever language you want (having read the propaganda on
> Sun's Web site, Java does indeed sound like a good option for a
> crossfire client).
> 
	I was thinking of Tcl/Tk, which has also been recently ported to
WinDoze, and the Mac.  Does Java have a working interpreter on these
platforms, or are they in the works?

> Now, I admit to knowing practically nothing about how the current
> client/server stuff works.  However, IMHO, the client should handle
> the game window(s), including keeping a list of the players inventory
> and position.  When there is an input event (key, mouse, etc.), the
> event gets processed by the client and is forwarded to the server if
> appropriate.  The client should be in charge of managing map/item

	The Client should handle all X stuff, including all X type
Binaries (i.e. XPM, AU), Windows, and Events.  The Client/Server
interaction should be moderately readable text, and asynchronous.  The
Server Should reference Display Items (such as
pix/humans/players/barbarian) and the Client can render them as
appropriate (Fonts, XPM, Animation).  Should sounds be separate, or part
of the "Image" of an Object?  The later may lead to invisible objects to
provide environmental sounds.
	I also think that the Server should give the Client ids for each
object, and these can be refered to during intercationn (so that each one
does not completely need to be redescribed).  I.e. object77 moves north 1,
or object77 moves to 22,16.  I think that you could get alot of
functionality with a minimum of bandwidth this way.  Occasional
resynchronization may be needed if things start to get lossy.  I think
that a scheme like this would be aided by a move to a more complete and
hierarchical command line interface (i.e. run northeast, or step
northeast).  This may make some common commands longer, but this could be
fixed by implementing aliases on the client end.

[Big Snip]
> 
> -Michael


						-Kris Bosland
						 krisb@seattleu.edu