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

["Carl Edman" <>]

I've been reading this thread for some time and as I've thought about  
the issues involved in writing such a game for more years than I care  
to admit and have actually written a working prototype (or two or three  
or ... you get the idea) of such a game, please allow me to make a few  
points of varying signficance and generality in no particular order  
which this discussion has brought to mind.

1.  Do all possible processing on the client.  There are at least two  
reasons for that.  First of all, the client is very likely to be less  
loaded than the server when there several players, so this is a  
performance win.  It will also allow a higher maximum number of  
simultaneous players and you are more likely to find a willing and  
stable server when you don't put quite so high demands on its hardware.   
The second is that client side processing allows users to extensively  
and efficiently customize clients to their own preferences and local  
requirements.

2.  In an ideal world this would mean doing all LOS calculations on the  
client (as a matter of fact, that is what my last prototype did).   
Unfortunately that will allow players to cheat in an undetectable  
fashion.  In particular as maps become more and more complex and  
oriented towards puzzle solving and more and more users play and  
compete on the same server, such cheating becomes increasingly  
unacceptable.  So LOS has to be done on the server.  And, yes, I've  
seen the approaches which have been taken to beat this.  They don't  
work.  They will be broken and they have been broken.  


3.  A corollary to 1. is that you should communicate with the client on  
a high level.  That means that the client sends the server complete  
commands describing one action.  The server sends the client a  
description of what the player would perceive.  How commands get  
entered into the client or how the world is described to the player  
should be matters which are left completely to the client.  That is by  
no means should the server concern itself about such matters, as mouse  
clicks, graphics resolution, simple keystrokes, display size and the  
like of the client.  Functionality like that of 'bind' in crossfire  
0.90.4 should be purely implemented on the client size.

4.  I believe that 3. is best accomplished by sending ASCII commands  
between client and server.  Not only does this completely avoid the  
byte ordering problem, it also makes building and improving the  
interface very much simpler.  As new commands are added to the server,  
players will always be able to just type them in (just as they do the  
rarer commands today) until the client is upgraded to produce them.  
Also as new 'descriptions' are created by the server which some clients  
don't yet understand they can always just be printed out as text on the  
client side (again, until it is upgraded).  The efficiency gained by  
binary communication between client and server over a well-designed and  
unforgiving (after all it expects its input to be generated by a  
computer program) command parser is drowned out completely all the  
other computation which a crossfire server has to do.

5.  Remember that an increasingly large part of the net is connected  
with relatively low bandwidth such as 57.6 kBps leased lines or even  
14.4 kBps SLIP lines.  There is no fundamental reason via a game like  
crossfire shouldn't run perfectly fine via connections like this if the  
designers of the protocol just take a little care.  In particular it is  
very important to allow for various persistent caching policies on the  
client side.  The server should always refer to pictures and sounds by  
name (or possibly persistent unique integers).  For example, it might  
send the command 'disp 15 -34 vampire' to tell the client that the  
player sees a vampire a coordinate (15,-34).  Then it would be up to  
the client to request a vampire image from the server (if it doesn't  
already have one) via a command like 'send vampire'.  Pictures and  
sounds, BTW, should (in contradiction to 4.) be sent in a binary  
format.  Just make sure that it is very simple and not too machine  
specific.  If a client prefers a particular format, it can always  
convert the sent binary to that preferred format upon receipt and cache  
it in that format.

6.  Not all the world is an X terminal.  Please remember that when you  
design the protocol.  Sure you want to design something which is  
implemented relatively easily under X, but there is also NeXTstep and  
even more importantly Macs and Windows.  Much as many of us may dislike  
these GUIs don't forget that they are the vast majority of the  
installed hardware in the world and a significant fraction of the  
Internet.  You won't even have to write those clients yourself.  The  
user base for these systems is so huge that it will not be at all hard  
finding someone who'll love to do it for you (and won't even hate  
himself for it in the morning) as long as you don't make it completely  
impossible by silly protocol design.  Much of the phenomenal success of  
the World Wide Web/Mosaic can be traced back to the fact that nice Mac  
and Windows interfaces are available.  If you can be as open about how  
you design your protocol as the W3 people were, you might very well end  
up not just writing another ultima clone which a couple of us here on  
the net play, but create something which in a few years can give Origin  
a real run for their money in terms of popularity.

BTW, much as I'd personally love to get involved more actively in  
writing the crossfire client/server, I've too little time in the  
foreseeable future to do the kind of job which this task deserves.   
However, if there is a NeXTstep client to be written, I demand the  
first shot at it. :-)  Also, I could write a curses style client if  
that is possible and there is a demand.  Finally, I'm also happy to  
discuss the above points in more detail.

	Carl Edman