Re: cheating

["Rupert G. Goldie" <>]

"Carl Edman" <>:

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

It is worth worrying about for several reasons:

1) You can easily get way more than 20 monsters. Worst case is 120 in an empty
area full of monsters. 40-50 wouldn't be an unreasonable number to expect.

2) LOS isn't relevant in a mostly open area. The gnolls don't have to be in a 
line. If they are in a mass and you kill one lots will move.

3) Without synchronisation people will scream, so your bi-directional pipe 
doesn't buy you much. If you can make 3 moves while only one screen update 
occurs you are going to find yourself in big trouble, usually when you can
least handle it.

4) When there are lots of monsters there will probably also be lots of spells
flying about. As a cone move across the screen do you want to update every
object each time ? 

5) With all those spells monsters will be dying and dropping items.

6) This situation (confronting a horde of monsters) is the time you least want 
to be hit by latency. I would much rather have latency when I examine an object
then when I'm fighting a large number of spell casting monsters.


Rupert
(Despite flooding my mailbox Carl, you have generated a valuable discussion
on the client/server issues)