Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: client/server once again



++---- 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. 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.

+---
| 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. 

Rough idea for protocol:

OP CODE 0XXX - map update
=======================
First byte:
  0000YYYY - update line YYYY (relative to viewport) (limits display to 15 lines...)
Second byte:
  XXXXLLLL - update begins at position XXXX and continues LLLL positions
LLLL sequences:
  0XXXXXXX XXXXXXXX - bottommost object is XXXXXXXXXXXXXXX (max 32768 object, hmm)
  zero or more of these:
    1XXXXXXX XXXXXXXX - XXXXXXXXXXXXXXX is on top of previous object

OP CODE 1XXX - character update
=============================
First byte:
  0001XXXX - change stat XXXX
    0000 - X
    0001 - Y
    0010 - speed
    0011 - weapon speed
    etc.
Second byte:
  YYYYYYYY - relative (-128 to 127) for coordinates, some other scheme
             for speed. Might put Str Con etc. here.

OP CODE 2000 - object name (sent when the player steps onto the object or similar,
==========================  not when it comes into view!)
First byte:
  0002000 - update object names
Second byte:
  XXXXXXX - update so many objects
XXXXXXXX sequences:
  0XXXXXXX XXXXXXXX - object number XXXXXXXXXXXXXXX
  NUL-terminated string - if necessary with a double NUL
 OR
  1XXXXXXX XXXXXXXX - object number XXXXXXXXXXXXXXX
  0YYYYYYY YYYYYYYY - same string as object YYYYYYYYYYYYYYY

OP CODE 2001 - object animations
================================
[similar to 2000]

OP CODE 20FF - forget object
============================

[...]

OP CODE FFFF - go ahead
=======================
The client should not update its display until it receives a go
ahead. This way, the server can theoretically send several "change
stat X" - may be needed for teleports etc.


I'd better stop, this is just off the top of my head. I believe
someone mentioned he was working on a draft for a protocol?

| 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.

Well, with my above approach, the client is told that object 323 and
432 have the same animation sequence or name. I gather that is close
enough.

+---
| You could just send the entire map area where the person is (which I
| think is 49 (7x7) squares?).  [...] Then for each scroll. a command
| could be sent like [...] where the map faces is the new row or
| column to actually draw.  [...]  Likewise, you could have a map
| update command, that just updates a specfic square.
+---

That's a lot of special cases. (it's currently 11x11, btw - Frank was
going to change that to 13x13)

+---
| 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.


Kjetil T.