[gameprogrammer] Re: FPS with distributed servers
- From: Ryan Hanlon <ryanh@xxxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Fri, 04 Mar 2005 10:11:51 -0800
David Olofson wrote:
>Between network packets, the nodes are basically just running local
>games with some objects (other human players) being driven by
>extrapolated data from the other nodes. When new information arrives,
>nodes adjust affected parts of their game state as needed
>
>But *how*, exactly?
>
>Well, one way might be to keep a "running snapshot" of the game state,
>corresponding to the reception time of the last packet from each
>node. Whenever you get a packet of events from another node, you load
>that node's running snapshot into the engine, add the new events to
>your "player input database", and then fast forward to the current
>time, replacing snapshots newer than the one you reloaded as you go.
>
>Obviously, this requires a rather lightweight game state and game
>logic and/or some nice lazy evaluation logic to avoid doing much
>about objects you can't see anyway. I suspect it might be both easier
>and more effective to pass incremental game state updates around
>instead, so you can just correct your state, rather than rolling back
>and re-running the game logic. That will probably require much more
>bandwidth, but with some smart filtering (ie send only data that may
>accually matter to each node) and compression, it shouldn't be an
>issue.
>
>
>
Another thing that helps here is something I used in a game I was
working on sometime last year. I shelved that one eventually because it
just didn't seem like it would be fun enough to justify the work I had
left, but the game was basically a real-time, online space-faring RPG
where the server did pretty much all the work, and the clients pretty
much only displayed what they were told. The idea was to make it so
that clients could be modified in just about any way, but wouldn't be
able to cheat at the game.
To help deal with the issue of updating the game state smoothly, I
stored all variables that updated rapidly in a structure that included a
value, the time it was set, a velocity, sometimes acceleration, and
sometimes a max and min value. Then for all updates, the server would
send each variable with a current value, the current rate of change, and
for some things, the current acceleration (rate of rate of change). The
client would use the rates of change to interpolate smoothly between
updates. This had the nice effect of allowing me to send updates much
less frequently and still see very little skipping and jumps in object
placements.
The one problem I didn't have a very nice solution for was input
latency. I had only done testing on my local network at that stage, but
even on that network, it was very difficult to keep the client and
server close to agreement while inputs were coming in.
Ryan
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
Other related posts:
