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

["Carl Edman" <>]

Tyler Van Gorder <> writes:
> ok..here is a thought: When a client connects: ask the user if they
> want to download the "standard library" of pixmaps. If yes, then
> automate an ftp process to download the crossfire.pix files that will
> be standard to all servers. Then  additionally ask if they want to
> download the pixmap files that our specific to that server. If these
> files get time stamps...then the user can be made aware that changes
> to those pixmap files have changed. From the last time they
> downloaded them. Thus, what you have done is after the initial
> downloading of the files...the client side has all pixmaps. Second,
> if you spawn an external ftp process to do the downloading....then
> the server does not have to worry about sending pixmaps to the
> client. Let ftp deal with it. :>
 

Oh please don't !  That both _requires_ the client to have a working  
anonymous ftp which many potential clients (like PCs and Macs) don't  
have _and_ it imposes a large startup cost on slow connections (which  
is after all, what we are concerned with here).  


No, the ideal protocol would work something like this:

Server -> client
map 1 2 floor
map 1 3 floor
map 1 4 firewall

[ Client notices the name 'firewall'.  Checks its cache (either on disk  
or in memory) and find it has no image associated with the name  
'firewall' ]

Client -> Server
send firewall

Server -> Client
transmit firewall 567
.... 567 bytes of arbitrary 8-bit binary ....

[ Client converts the binary image into whatever the locally preferred   
format is (possibly adjusting colors and resolution to the local  
preference) and (if that is its policy) caches the result ]

a.s.o.

The server never sends any image or sound to the client unless the  
client specifically asks for it.  On the other hand, if the client asks  
for it the server will send immediately as often as the client asks for  
it.  That means that clients can decide on their own caching policies.   
Clients short on hard disk space but long on bandwidth, can only cache  
binaries in memory for a limited time within each session.  Other  
clients will always save all binaries and never delete them.  Yet other  
clients may choose to delete binaries which haven't been used for a  
number of weeks.  All that is up to the client and the server doesn't  
care.

For animation I think the best solution is to have animated images  
contain several "subimages" and instructions on how quickly they should  
be flipped through.  As soon as the client has the animated image, the  
server never again has to worry about animations.

I'm working on a draft of a possible crossfire protocol.  I've there  
interest, I can post it in a few days.

	Carl Edman