Example of the use of the proposed protocol

["Carl Edman" <>]

From: Jason Fosback <>
> "Carl Edman" <>:
> > The server does not tell the client what to draw when and where. 

> > It   tells the client what it sees.  Where it sees nothing because
> > it is behind walls, it does not send map commands.  The client
> > knows for what   areas it has received map commands and it only
> > displays those.  Those   areas which are not mapped in, it can
> > display whatever it wants and it   doesn't need any instructions
> > for it.
> 

> Okay, so the server gives the client exactly what it sees.  Hmmm. 

> So, does the client do an   automatic SHIFT of the map?  Let's forget
> LOS for the moment, and focus on what you're   proposing.  In a
> large, open area (such as Scorn), would you be transmitting the MAP  

> command for all squares, or does the client do this implicit SHIFT? 

> Okay, so now when we   head north from the starting area toward the
> wall, the top area of the sreen in not visible; when   the client
> does the implicit SHIFT, does it automatically assume the new area is
> *outside* the   LOS, consequently leaving the area black?

OK, let me describe this particular example in a little more detail.

[ Carl wants to play crossfire so he fires up his NeXTstep crossfire
  client ]
[ The client automatically logs him in ]

Client->Server: LOGIN NEXTSTEP-CLIENT Carl Carlssupersecretpassword

[ The server checks the password and it matches, then it puts carl on
  the map.  It turns out that the tag of the item which represents
  Carls character on the server is 123.  The server also sets Carls
  LOS set (more on that later) to the empty set. ]

Server->Client: VIEW 123

[ The client sees and remembers this number from now until the next
  VIEW command which probably will not be in this session ]
  

[ The server calculates a new LOS set i.e. the set of all map squares
  which are in the LOS of Carl.  Then it compares that new set with the
  old set.  It sends one MAP command for all the squares in the new
  set which weren't in the old set.  As the old LOS set was empty that
  first map is pretty big. ]
  

S->C: MAP 40 40 floor 41 40 wall 42 40 wall ... 


[ Now the server checks if there are any squares in the old LOS set
  which aren't in the new.  There aren't any so it needn't send any
  UNMAP command ]

[ Next the server sends an ITEM command for every item inside the new
  LOS set which is not inside the old (but as in the beginning the old
  LOS set is empty), it sends a list of all visible items ]
  

S->C: ITEM 123 44 44 1 Carlsimage Carl
           ^    ^  ^ ^  ^          ^
Itemtag ---|    |  | |  |          |
X coordinate ---|  | |  |          |
Y coordinate ------| |  |          |
Quantity ------------|  |          |
Name of image ----------|          |
Name of item ----------------------|

[ In particular the client also receives an ITEM command for the
  viewpoint item (see above).  Now the client knows where the player is 

  and uses the MAP information above to draw the background map around
  the player ]

S->C: ITEM 433 IN 123 1 helmetimage X ray Helmet (worn)

[ The client also receives the list of items inside other open items. 

  This includes items inside the viewpoint item i.e. the players
  inventory.  That last command indicates that the player carries an
  helmet of X ray vision (worn).  The client can use this information
  to draw the inventory window ]

S->C: ITEM ...
      ....

[ More item commands for what else is in view ]

[ Now assume the player wants to move north by a step ]

C->S: MOVE 123 44 45

[ That is just a request by the client.  It does not change the display
  at all ]

[ The server receives the request, decides that the client can move
  north (i.e. no wall, not overburdened) ]
 

S->C: ITEM 123 44 45

[ Note that the server doesn't have to send all the item data.  Only
  the first three fields are mandatory.  The rest need only be sent for
  items which enter the field of view or which change ]

[ When the client receives this description, likely it will shift the
  entire view which may create a black row on top and may shift the
  bottom view out of the image (or it may not if the client is an
  automapping client) ]

[ As soon as the server processed the MOVE command, it also noticed
  that the LOS may have changed.  So it calculates a new LOS set.  It
  compares it with the old LOS set (which this time around is pretty
  big).  If there are any new squares in the new LOS which weren't in
  the old it will send a single MAP command for all of them.  That will
  be pretty small.  The maximum average is 11 (with a 5 square range of
  view).  If there is any obscuration, it will be less.]

S->C: MAP 40 50 wall 41 50 wall 42 50 wall ...

[ As the client receives these commands it updates that black strip on
  top of the screen which it may have. ]

[ Now the same for the squares in the old set which aren't in the new.
  Again this will be pretty small ]
 

S->C: UNMAP 40 40 41 40 ...

[ Finally when the server changes the LOS set it checks whether there
  are any visible items in the new set which weren't in the old (no
  reason to worry about disappearing items -- UNMAP is all the
  information client needs on those).  There may be a small number
  of ITEM commands. ]
  

S->C: ITEM 642 45 50 1 orcimage Orc chieftain
     ...

[ The client displays those items as it receives information about
  them. ]
  

[ Now assume that orc chieftain wants to attack the player.  It moves
  towards the player ]

S->C: ITEM 642 45 49
  

[ Later ]

S->C: ITEM 642 45 48

[ Later ]

S->C: ITEM 642 45 47

[ That's all.  No maps or unmaps or long items for monster movement. 

  Just a single short command every time it happens,  That command is
  generated by the same routine which makes the Orc itself move. 

  Zilch overhead. ]

[ At some later time after the player has dealt with the Orc.  The
  player wants to drop the helmet.  The player is still in square
  (44/45). ]

C->S: MOVE 433 44 45

[ When the server process all that returns is: ]

S->C: ITEM 433 44 45

I hope it is now clearer what the server/client sent when under the  
proposed protocol.

	Carl Edman