Re: cheating

["Carl Edman" <>]

From: Mark Wedel <>
> Where as if LOS is handled on server, only those visible objects need
> to be sent.  The client should buffer that information, so if the
> player moves, only a new row and/or column needs to be drawn.

The updated number of map fields will not necessarily be in a row or a  
column due to LOS.  That is why the proposed MAP command allows you to  
give the location for every square which is newly mapped in.  If it  
turns out that they are frequently enough rows or columns, I'm  
certainly not opposed to making a little optimization which allows the  
transmission of such mapping information without having to give _all_  
the coordinates.

> In general, for most maps, not a lot of objects move in the game
> window at the same time, so the updates shouldn't be that bad.

Absolutely.  And objects which don't move only get a single ITEM  
command when they come into view and then never again.  They are  
essentially free.

> However, what gets more complicated is smart updates.  IF you are
> fighting 20 gnolls, and kill the one in front, and another one
> quickly steps up (and thus, lots of gnolls change position), do you
> necessarily want to re-send the position of all 20 gnolls?  It might
> be much better just to remove one gnoll from the mass.0  However,
> under the current protocol, this would not be possible, as all
> objects are tagged with an ID number, and if this method was used,
> all the ID numbers would be off. But I am not sure how much the ID
> numbers are used for monsters.

This is really not a case worth worrying about for three reasons:

(1) Even sending ITEM commands for all twenty gnolls in the ASCII  
format takes only 580 bytes.  That is compressed down to 137 bytes by  
gzip.  While V.42bis is slightly less effective, it'd have more context  
to work with so you can expect similar results there.  Sending 137  
bytes even over the slowest acceptable link takes 70-140 ms.  That's  
certainly acceptable.  And on an ethernet it'd take merely a fraction  
of a millisecond.

(3) Because of LOS considerations, you wouldn't see all twenty gnolls  
which are in a line anyway further shortening display time.  If the  
gnolls are not all in a line, not all will make a step when you kill  
one.

(3) Due to the bidirectional nature of the proposed protocol even  
during those milliseconds that you get the gnoll updates, you can still  
move and fight.  You want to run away ?  No problem. You continue  
hacking&slashing ?  It is as if the delay hadn't happend.

	Carl Edman