Re: client server part 1

[Mark Wedel <master@rahul.net>]

 In terms of doing something like:
MAP wood_floor 1,1 2,2 3,3, 4,4 (etc)

 IT does reduce bandwidth, but does increase complexity on the server.
It then means that the server needs to group all the wood_floor
requests together, then the next item, and so forth.  Not as much
hard to do, but will take cpu time on the server side.

 Only new data is sent.  The client keeps track of data from tick to
tick.  If a person is standing in the middle of town, and there are
no other characters/monsters around, then there is no data being
transmitted from the server to the client - or at least not map data.  The
map is constant, so there is nothing to send.

 This is convenient in that the client then always has all the information
it needs for redraws.

 I would also say that at least for the first version, just keep it
relatively simple and actually write it.  WE can then look at how
efficient it is (in both bandwidth and cpu usage), and then add/change
things in future version to improve on these areas.

I would much rather have a reasonably easy yet complete protocol and
actually get a first version sometime soon (by end oof year?), instead of
having a super protocol that takes another year for it to get complete
and working.

 Using absolute/relative coordinates is a minor issue.  But I think
that absolute will make things easier for tracking down bugs - you can
tehn look at the data being sent and compare it with the data in the
server and make sure it is correct.  RElative becomes a little more difficult,
because you then have to check and see where the player is.

 (Back to some old messages):

VIEW really isn't needed once what the player object is is established.
But it does give a nice future hook for things like 'magic eye'.  Just
send a magic eye object, and set the view to that object.  Then the player
can look through that.

 I think my revised ITEM command is fairly good.  Note that the name
field will contains things like magical, cursed, +1, etc.  So the
client then does whatever appropriate based on this information.
The client is never really sent information unless the player should
know it also.

color changes in object:  This is not supported.  Two main reasons - it
does take more bandwidth, and is only useful for color displays
that are using font/bitmaps.  There is no easy way to change color in
XPMN images.  With a bit of work, you could probably modify all the
xpm images to have aliased colors, and change those.  But right now,
only change the prodminat foreground and background colors are suported
in maps and the archetype file.  If future support for additional colors
in object is added, then the protocol can also be updated.

 Also, at least in low bandwidth situation, it is a fairly good assumption
that compression will be happening.  So while reducing the size of
requests in human format can be noticable, after compresion, the
results may not be significant.

 --MArk