Re: A few thoughts on client/server in multi-player games

["Carl Edman" <cedman@cedman.remote.Princeton.EDU>]

Mark Wedel <master@rahul.net> writes:
> I don't think all images and sounds should be referred to by name
> when the client is actually playing.
> 

> Doing some handshaking at startup to agree on integer values for each
> image/sound to use when the game is running seems like a very
> reasonable and fast way to do it.  Whether these integers are passed
> as binary values (probably 2 bytes), or ascci characters (probably 4
> characters, but could be 5 some day) might be less relevant.

But haven't we learned from the old map numbering scheme what happens  
with fixed numbering schemes when several independent groups work on  
the code ?  *Please* let us avoid that pitfall in the client/server  
design.

> I personally don't see the need of the client to be extremly
> efficient in how it sends to the server as really important.  I doubt
> the client will be sending a lot of data.  However, how the server
> sends to the client is much more important.  But it also depends on
> what information the client knows.

I agree completely.  Remember that every TCP/IP packet (and UDP/IP is  
not much better) has 40 bytes overhead.  Most single commands sent  
using either ASCII or binary in either direction will be completely  
swamped by that in any case.  The only exception will be the actual  
contents of sounds and images and they will be transferred by an agreed  
upon, simple binary standard in any case.  Given that we agree on that,  
why not use ASCII to send commands and descriptions either way given  
all the advantages I listed in my other recent post on this subject ?

> For example, if the client knows about the entire map, either all
> that stuff needs to be stored on the client end (which would be
> really unsecure, and not especially feasible for those sites that add
> new archetypes and maps), or that information needs to be sent down
> the wire.

I agree.  And because different sites will extend the server in various  
ways, using ASCII 'commands' (what the client sends to the server) and  
'descriptions' (what the server sends to the client with the exception  
of the contents of images/sounds which are a little different) is much  
better because it is less likely to lead to name space conflicts.

> Depending on many factors, sending an entire map with
> various object information may not be any better than sending small
> pieces as required.

Absolutely.  That is one of the arguments I make for why server-side  
LOS is not really inefficient, in particular for people with slow  
links.

	Carl Edman