Re: client/server once again

[quinet@montefiore.ulg.ac.be (Raphael Quinet)]

> From: Kjetil Torgrim Homme <kjetilho@ifi.uio.no>
> 
> ++---- Raphael Quinet:
> || The client sends all commands issued by the user directly to the server,
> || with almost no preprocessing (i.e. "move north", "eat food", "apply ...").
> ++--- Mark Wendel:
> | 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 latter should be sufficient.  [...]

Yes.  If the server keeps on sending information to the client, there's no
need to acknowledge every command.  If the client (in fine, the user) wants to
see if a particular request has been executed, he will see it in the next data
stream.

Remember the debate about TCP vs UDP?  Once again, here is the problem of
ACK vs no ACK.  Whichever of the two protocols is used (even a combination of
the two is possible), I think we don't need any kind of "OK command".  If a
packet is lost (low probability), the user will try his command again, that's
all.  Notice: this is only true for the "client to server" side of the
protocol.  Imagine a packet loss when the server sends a "map update packet"
to the client...  We probably need TCP or acknowledged UDP in this case.

> You _can_ get synchronization
> problems, though. Ie. the player can do
> 
>    <apply scroll of enchant weapon>
>    <apply scroll of enchant armour>
>    It glows briefly.
>    <apply scroll of weapon>
>    The scroll turns to dust, nothing happened.
>    Your weapon is already enchanted.
> 
> You get my drift? I don't think this is a real problem for the
> players, though.
>
If the client has two separate windows, one for the command input and the other
for all output, most users won't see the drift...  ;-)

Now I have one suggestion, that could be implemented in the current version
of CrossFire: if a scroll has been identified, the user should receive the
message "The scroll of <this or that> turns to dust".  This won't solve the
drift problem, but this could help anyway, even in the current version.

> +---
> | 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.
> +---
> 
> Obviously, if you just send whatever the player should be able to see
> (ie. do the LOS in the server), you will never send more data if you
> allow the client to buffer data. OK, this is not totally true - the
> protocol will be more complicated. 
> 
Map buffering is a must if a server is going to handle dozens (hundreds?) of
clients accross the Internet.  If something can be done that will reduce the
bandwidth needed without creating security holes in the game (read: ways of
cheating), then do it!

> Rough idea for protocol:
> [... edited out - read Kjetil's message for more info.]

If a player is moving through a sparse map, most of the information sent by
the server will be position updates.  If he is moving along a diagonal line,
two packets will be needed for each movement (update X, update Y).  

I see three ways of dealing with this:
- Use Ketjil's character update packet, but with a bit mask for the stats
  instead of a number.  The server could the send several stats updates in a
  single packet.
- Use "block transfer" techniques: several map/stats/animations updates may
  be chained in a single block, together with the "go ahead" signal, which
  will be sent in a single "send" or "write" call.
- Use a special packet for position updates (both X and Y).

My preference goes to the second technique: this will be more efficient in
terms of network traffic.

There should also be some packets to give special information to the client,
like the current map size, the number of known objects/archetypes (depends on
what kind of information is sent to the client), etc.

Another thing: the object name and other info should be sent as soon as the
object comes into view, because you can examine an object that is not close
to the player.  Here, I make the assumption that the client handles the
"examine" command by itself.  If this is not the case (i.e. the client sends
the request to the server, which responds with all the info), then forget this
remark.

> +---
> | Depending on map buffering, line of sight may or may not be done on
> | the client side.
> +---
> 
> I vote _no_ - I do not want precompiled clients, and I do not want
> clients to effectively give players helmets of X-ray vision just like
> that.
> 
Well, maybe you're right.  But computing the LOS eats a fair amount of
processing power in the server.  This is not a problem if there are only a few
clients on one server, but what will happen if there are 50 players in the
same game?  But I don't like precompiled clients either...

-Raphael