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

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

Eric A. Anderson <eanders+@CMU.EDU> writes:
> Tyler Van Gorder <tvangod@ecst.csuchico.edu> writes:
> > [ use ftp to transfer pixmaps ]
> This is probably not the best idea because some people may not be
> able to setup their machine to do anonymous ftp even if they can run
> a crossfire server on it.  Moreover, automatic ftp isn't really easy.
> Why not just have another program do the transfer?  This is what I
> did in the original crossfire server implementation.  I downloaded
> the font every time you started playing to make sure that people had
> a current font.

Yes, and how endlessly long was the list of bug reports caused by  
people not downloading the proper set of fonts, or not having it in the  
right directory or not having compiled for it ?  The server will be for  
us hackers where we can extend the game.  We will maintain them  
ourselves, so minor problems in stability, system requirements or  
complicated installation really isn't that terrible a problem for the  
server.

The client however should be idiot^H^H^H^H^Hunsophistcated user proof  
if we don't want to be flooded with bug reports.  Also when designing  
the protocol we should make minimal assumptions about what facilities  
are available to the client.  Remember that most potential client  
machines in the world do not have a) X, b) rplay, c) ftp, d) good  
preemptive multi-tasking and e) most importantly competent technical  
support for the installation of games.

I think we can build a good protocol which assumes nothing more of the  
client than that it has a bidirectional 8-bit channel to server with a  
bandwidth of at least 1-2 kBytes/second and round trip time of at most  
100-200 ms.  The class of such machines is vast and the rest can be  
built on top of that basis.

	Carl Edman