Re: cheating & LOS

["Carl Edman" <cedman@cedman.remote.Princeton.EDU>]

Phillipe Brown writes:
> >>>>[From Carl Edman]
>     

>     From: Philip Brown <philb@soda.berkeley.edu>:
>     

>     > asynchronous updates WASTE bandwidth, because they generate
>     > many many more packets than would otherwise be sent.
>     

>     Can you please give one single common game situation in which an
>     async   protocol (as proposed and explained in the example I
>     posted) will cost   "many" more commands than if used
>     synchroneously ?
> 

>  _packets_, I said, packets.  With the emphasis being that for every
> command you send, you send 40 bytes of header.

Ah, yes, some people packets/commands interchangably but that is a  
different matter.  Sending updates asynchroneously probably will tend  
to increase the number of packets.  However, that is not as bad as it  
sounds as the increased TCP/IP packets will mostly occur when the  
connection is idle in any case.  The largest amounts of data (which  
need all the bandwidth they can get) are generated when the LOS set  
changes which requires both MAPs, UNMAPs and ITEMs for the new items.   
That will still be just one packet for all of them.

>     > 2) it preserves a concept of relative "speed" between
>     >    monsters/players/etc nicely
>     

>     That is certainly a concept worth preserving.  How it relates to
>     the   fact that you have to do things synchroneously I do not
>     see.  

>     

> Lemme put it another way. What's your completely new way of doing
> things in the server that will make asynchronous updating work, and
> are you going to do the programming for it?

Yes.  My last major project (a native port of Emacs 19 to NeXTstep) is  
just winding down.  I'm perfectly willing to invest the number of  
necessary hours to change the server so that full advantage of the  
client/server concept is taken.

>     > 3) It equalizes play between fast-update and medium-update
>     > players.
>     

>     Do you mean to say that you deliberately add unnecessary latency
>     to   fast connections to punish those players ?  I don't think
>     that is a   virtue.
> 

> What are you complaining about? There's no need to change the current
> schema. There is going to have to be a maximum frame rate that is
> practical to support. Fast clients will not get any benefit from
> getting their frame updates a piece at a time. They still cannot move
> any faster than the specified frame rate.

I'm not quite sure why you insist on mixing up something real inside  
the game world (like movement rate) with something which is just part  
of the mechanics like when data gets sent to the client.  _Of_course_  
movement rate has to be independent from the network bandwidth and I  
can see absolutely no reason why the two should even be related. 


Also, I think that talking about "frame rate" in crossfire like in a  
flight simulator is somewhat misleading.  In a flight simulator you  
have a continuous change of the world and the faster you can draw the  
better.  In crossfire on the other hand, everything in the world  
happens in a discrete fashion and if nothing happens the frame should  
not be redrawn at all.  A better perfomance measure in my opinion is  
average "latency" i.e. the average amount of time it takes for some  
change in the state of the world to actually become visible to the  
user.

> Fast connections get extra info on each update. But they don't get
> any extra updates. To do otherwise is unfair to midrange connections
>
> Note that the other hand, mid-speed conenctions will find a serious
> detriment from having updates a bit at a time. You've got to work
> with the framework of IP communication. The more fragmented your data
> for updates, the worse real-time response will be.

If we can get anywhere close to having the minimum specification I  
suggested a while ago (1-2 kBytes/sec bandwidth, 100-200 ms roundtrip  
time) and I'm confident that we can get close and think there is a good  
chance that we can actually make that spec, there is no reason to worry  
about mid-speed connections.  If the game is playable at 1-2  
kBytes/sec, you won't even be able to feel the difference between a  
midrange connection which is more than 10x faster (like cross-country  
internet) or a high speed connection which is more than 100x faster  
(like a local ethernet).
     

>     I promise that I do try to be open to your suggestions and
>     criticisms and am sure that they will improve the protocol.  But
>     please do also try yourself to be open to the idea that the
>     client/server protocol may change things for the better and more
>     rational and that should be its goal and not a slavish
>     replication of _exactly_ the way the current X client looks and
>     works.
> 

> I was one of the first, if not the first, to push for a switch to a
> client/server model.

At times I got the impression that you were completely opposed to  
client/server and liked things just fine the way they were.  I'm glad  
that that's not the reality.

> However, we are dealing with very large code here. Things will go a
> lot smoother if you don't get fired up about re-writing everything in
> sight. Just the conversion from current to client/server model is
> going to be a horrendously long task, and involve many may hours of
> tuning things. Attempting to re-write significantly many other things
> will screw things up by a factor of 10 or more. If you realy want to
> do that, you'd be better off organising people to write a game from
> scratch. I'm quite serious about this, and most other experienced
> programmers will agree with me.

I agree with you about the size of this project.  Client/Server done  
right will involve large amounts of programming by people who know what  
they are doing.  The question is whether we just want to add another  
layer of code atop the current code, or if we want to take advantage of  
the opportunity which client/server offers to actually simplify and  
rationalize things which touch on it.  The former may require slightly  
less work in the short run, but in the long run it is certainly more  
efficient to clean up several interrelating problems at once.  I  
believe that if we do client/server right, the total server code size  
will actually shrink compared to what we have now and maintenance will  
become much easier.

	Carl Edman