No Subject

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

That's correct.

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

No.  Not unless they decide to start dancing around in circles.   
Killing one monster opens up one space.  Only a monster further away  
will walk into it (no point for a monster which is already next to  
you).  That opens up one space further away from you.  One monster will  
walk into from even further away, a.s.o.  until the edge of the  
visibile area i.e. five or six monsters.  That is the maximum number  
which can gain in proximity by your killing one monster.

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

No, _with_ sync they will scream.  Or rather they will throw away the  
protocol over slow lines in disgust when being killed the Nth time  
because they were frozen.  There is absolutely nothing more frustrating  
than being unable to act.  Only a bi-directional protocol will prevent  
that (and use all of the limited available bandwidth instead of only  
half of it like synchronized protocol).  


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


You don't update "each object every time".  You only update an object  
when it changes or enters the LOS after being outside the LOS.  That  
happens fairly rarely.  Yes, when you fight a dozen dragons and they  
all breath at you at the same time you'll have a real problem over a  
slow link.  Of course that problem is only half as big as that which  
you would have in a simple 'graphical' protocol which some here have  
supported which not only has to send drawing commands for all the  
fireball components (much like the proposed protocol does), but also  
has to painstakingly sending _redrawing_ commands for everything below  
the dragon breath after it disappears (something which the proposed  
protocol doesn't have to do).  But still, I'm open to suggestions for a  
special non-item-based command to describe dragon breath and the like.  


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

No big deal.  Monster dies and three or four item commands are sent.   
That's all.  And in contrast to the graphical protocol ideas, we don't  
have to send redrawing commands every time a monster walks over some of  
those 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.

Well, then isn't it fortunate that the same protocol which serves you  
best in one situation also does the best in the other (in addition to  
having real conceptual integrity) ?

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

Thank you.  You see, I have to.  There are all these people saying all  
these wrong things and somebody has to spread the TRUTH. :-)  I just  
sometimes wish they'd beat up on each other instead of all of them on  
me.

	Carl Edman