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

[(Raphael Quinet)]

> Kjetil Torgrim Homme () wrote:
> 
> +---
> | BTW, how do you want to translate a map to ASCII?
> 
> Err, that's the native format of a map. But it's a mute point anyway,
> since whole maps shouldn't be sent. It's unnecessary, and if you do
> that, the cheater will know the magical effects of items, or what
> magic words guards respond to, or ...
> 
Well, I should have made things clear.  Sorry if this wasn't the case.  What
I meant is: the server has its internal copy of the map; when it sends a part
of the map to the client (if the LOS computation is done by the server), it
will have to send the list of objects, floor textures, etc.  Inside the
server, everything is in binary form (cross-refs, id numbers, flags, etc.),
except for the objects names.  So what I wanted to say is: it would be stupid
and time-consuming to translate all that to ASCII in the server, then do the
reverse translation in the client.

I feel that the server should send the list of objects to the client, not
only the pictures, because the client will then be able to do more processing
if it knows the list of animations for each object (given by the server when
the client connects).  Also, when the player asks for the description of an
object, the client will be able to do it without asking anything to the server.
And finally, this would open the way for a new improvement: some clients could
display their own pixmaps for some objects.  Why not?  If I want to write a
client that uses 64x64 pixmaps...  :-)

Of course, the server won't send all its internal info about each object.
It should only send what is directly available to the player.

> I find Carl Edman's views very convincing. A two-digit number can be
> transferred in less space than a 32-bit binary number. You don't have
> to name the protocol commands "transfer_this_list_of_images_please",
> "TMI" will do :-)
> 
Sure, but what about command #7, where the "7" is stored in a single char?

We don't need to use 32-bit numbers.  We could use single chars when the
value is small (int8), and two chars for greater values (int16), using
32-bit ints only for huge values.

I already hear you say: "but you will need to translate all numbers, so why
don't you use ASCII instead?".  Simple: binary data consumes fewer bytes
than ASCII data, and casting a char to an int is much faster than using
atoi/itoa/sprintf/sscanf, etc...

-Raphael