[gameprogrammer] Re: FPS with distributed servers
- From: David Olofson <david@xxxxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Fri, 4 Mar 2005 15:29:22 +0100
On Friday 04 March 2005 14.37, Brian Barrett wrote:
[...]
> the other option is if the Random number generators are seeded
> *exactly* such that each machine will produce the same numbers, the
> game treats the networked players as additional input, such that all
> the "server" does is rout the packets containing what input each
> player pressed to each individual machine and allows the user to
> issue server commands.
I've been thinking of doing something that with Kobo Deluxe, which has
"exact" (integer based) fixed rate logic with a custom pseudo-RNG
anyway.
The problem is that what you describe above is only part of the
solution. It would work, but only with very low ping. High ping would
not only cause lag (ie the other players may not be where they seem
to be, because what you see is based on extrapolated positions based
on the last few "frames" from the server), but would also add lag to
your input, since it'll have to go through some sync point, rather
than directly to the local engine. Thus, you quickly lose the whole
advantage with running a local server.
What I have in mind is to (ab)use the local engine as a prediction
filter on steroids. It can't do much about other players (just the
usual assuming they're still doing whatever they were doing the last
time we heard from them), but it *can* predict the actions of NPCs
and the game environment with 100% accuracy, except in situations
where the actions of other players affect things.
That is, as long as you're fighting NPCs, you have 0 ping (you're
fighting your own computer), and your local server is the authority
for the area you're in. Likewise for all other players.
When two or more players are in the same general area, the
servers/clients - lets call them nodes - will have to decide who
controls what. The easiest way would be to just say that the player
who's closest to an object or NPC gets to decide what that NPC
*actually* does, in case the nodes disagree.
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.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
Other related posts:
