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

[Tyler Van Gorder <>]

> 
> Carl Edman () wrote:
> > Mark Wedel <> writes:
> > > I don't think all images and sounds should be referred to by name
> > > when the client is actually playing.
> > > 
> [stuff deleted]
> > 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.
> > 
> First note: remember that you never need to send the binary data for the
> sounds.  The rplay daemon will fetch the sound files from the nearest RPTP
> server if they aren't available locally.  So you only need to send the
> filenames.  But the pictures are another problem: if a client doesn't have
> the pixmap for one object, it will have to get it from the CrossFire server.
> 
> There are two solutions if we want to save bandwidth:
> - when the client connects to a server, the server sends all filenames (images
>   and sounds) to the client, along with their id numbers.  Then, each time a
>   sound or image has to be used, its id number (2 or 4 bytes) is sent instead
>   of its name.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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. :>
 
Tyler.