From: jason_watkins@...
Date: 2005-04-17T17:14:41+09:00
Subject: Re: What's beyond Rails?

>>>
Maybe you know more about this than I do, but how much data does a FPS
have to send out and receive, anyway?
<<<

Well, the theoretical limit is always just input itself. Mose skew is
often within single byte values, but even if you bumped it up to 16bit
in x,y you're at 4 bits per sample. Within the sample we might have an
upper bound of 10 key up/down events, so figure something like 16 bytes
per input timeslice. The server can simply act as a relay for this
data.

So the lower limit is something like 16 * numplayers * hz. In other
words, you pay more for UPD packet headers.

For reason of cheat protection, few games use this model however (chris
taylor is the only person I know who's a real big fan of it).

It's more common for games to instead simulate on the server and then
stream the state onto the client. The quake engines themsevles went
back and forth on the details of this, but eventually settled on simply
streaming serially id'd state deltas from the server which the client
acknowledges. The server stores a sync point for each client, and
journals the simulation state from the point of last acknowledgement.
Each client can have it's own rate, and the server sends a cummulative
update from the sync point to the current server state. The real cost
of this model is memory, which is why quake3 won't scale to 100's of
players. There's also disadvantages to it's failure mode: the size of a
future packet grows as packets are dropped. But, a client can get back
in sync with a single such packet, so it proves itself fairly robust.

If you read the literature, you can see the quake3 model + the client
extrapolation code is very close to a well known optimistic discrete
event simulation algorithm (timewarp).

Interestingly, in the many models the guy I know has played with, one
that works the best is instead bucketing state slices to be the same
for all clients, and echos the previous state with each state it sends.
Ie sending A, AB, BC, CD. Single packet drops are almost never noticed.
Loss of sync greater than a single slice are handled out of band by the
same code that handles a player jumping into the middle of a simulation
state. It's far less memory demanding, so it scales quite well, and in
practice ends up being quite competative with the quake3 model.

It's been a while since I looked at the actual rates, but you I do
recall that when I'd lock up counterstrike to send input at 60hz and
request server frames at 60hz it'd end up at around 2kbyte/sec download
nominal, with bursts up to mabye 6kbyte/sec in rare moments. Input
upload is always miniscule.