Re: client/server once again

[Mark Wedel <master@rahul.net>]

quinet@montefiore.ulg.ac.be (Raphael Quinet) writes (portions removed)
>* The client sends all commands issued by the user directly to the server,
>  with almost no preprocessing (i.e. "move north", "eat food", "apply ...").
>
It does have to be decided how the server responds to these commands.
Does it send like an OK command, in which the client then updates the
proper information (food, hp, inventory, etc), or instead, does it
just send what information changes)

The first has the advantage that the client needs to know about all
the effects (how much food an item is worth, and what it does).  But it also
means less information needs to be trasmitted. (note, since the server
still keeps track of information, the worst a rogue client can do is
just display inaccurate information.)

>* The server periodically sends the following information to every client:
>  - the current player position
>  - modifications to the map, other players positions, monster positions
>  - each time a new area of the map is entered, the server sends a map chunk
>   (say, 10x10 or 30x30) to the client, with all the objects in it
>  - the modifications to the inventory or player status
>
Map buffering may or may not be useful.  IT really depends on how much
the map changes.  If XPM is being used, sending it the floor is probably
a good idea, since that won't change.

 But if you have lots of monsters moving around, or a lot of things
dieing and leaving items, buffering a portion of the map may have no use.

 IT also goes back to up above.  IF you actually send what objects are on
the map, then you also need the client to know about all the archetypes.

 You could just send the entire map area where the person is (which
I think is 49 (7x7) squares?).  If you figure two bytes per square
(either using font position, or some number scheme that gets handshaked
at start time), this is not very much.  Then for each scroll. a command
could be sent like:

Scroll map right;
map faces (series of numbers)

 where the map faces is the new row or column to actually draw.  Obviosly,
more compact commands would need to be used. (perhaps all commands/
identifiers are just two byte sequences or something.)  Likewise, you could
have a map update command, that just updates a specfic square.

>* The client may handle the Line Of Sight algorithm.  If one wants to cheat
>  (using a drone, for example), he could do this even if the server only
>  sends the visible bits to the client.  This would only require a slightly
>  more complex algorithm, but won't prevent nasty guys from doing it.  So,
>  why not do the LOS on the client side?  This would free more processing
>  power on the server.
>
Depending on map buffering, line of sight may or may not be done on
the client side.

>* We can have several clients, using different display techniques.  We could
>  even have a 3D-client (if you have ever played DOOM on a PC, you know what
>  I'm talking about).  This may be silly, but why not?
>

As said, there is certainly nothing preventing multiple clients.  Could
use different toolkits or layouts, and different graphics or whatever,
depending on each persons taste.  There is certainly no reason that there
can only be one client program.  And if the client runs so that it
does not have extra knowledge (which I think is really desirable), then
this makes life easier (compared to if official binaries with RSA keys
are needed for each client and OS/archictecture.

>I could start working on that as soon as 0.90.2 is stable.  Any comments?
>
>

 I think client server will be a great addition.

 All comments above are just thoughts and comments.  In no way am I saying
that this needs to be the official way the clients act.

--Mark