[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: peer-peer syncronization
Francesco Orsenigo wrote:
How can syncronize a game (ie: make two simultaneous events appear
simultaneous to all users) in a peer-peer system, using UDP?
This is an extremely hard thing to do - in fact, over the Internet it's
probably impossible. Most commercial games give up on every single one
of those goals!
(TCP would be slow, and i'd like to avoid the complexity of a client-server
system).
The Client-server mechanism is by far the easiest to implement I think.
There is a mantra in the world of networking which says something like:
"When you use UDP, you soon discover it's limitations - then you try to
work around them by adding error correction, timeouts, retransmits and
packet reordering. Pretty soon you've implemented something thats both
flakier and slower than TCP."
If you use UDP, you'd better be sending data that you can definitely
afford to lose.
The technique would be for each peer to send just the info about commands
given by the player, along with the game time when the command itself is
issued, but this may easily lead to unconsistencies between peers.
A more robust way would be for each peer to send, each game tick, a message
with a "I'm ready for next game cycle, no command" to each other peer, OR a
"I'm ready and the player issued the XYZ command"... But this is
EachPlayer*EachOtherPlayer*EachGameTick... too many "each"... the network
load would be too high even for a 5fps game.... or not?
For sure. The problem is that you'd presumably be waiting for the responses
from all other machines before anyone could start the next iteration. This
slows everyone down to the speed of the slowest machine. If one player with
a modem and a 233MHz machine joins the game from behind a firewall in China,
people with 2GHz machines and T1 lines will be reduced to the same low speed.
In order to remove that constraint, you have to blow away the idea of keeping
everyone perfectly synchronised - and once you are in an asynchronous situation,
you've lost perfect simultaneity.
Once you take away that, the current state of each machine will gradually drift
away from the others and pretty soon, chaos will reign.
That's why it's nice to have a server who can maintain the 'true' state of the
game. Then the other machines can get somewhat away from that state for short
periods and be 'corrected' when the server gets around to telling them what's
truly going on.
Remember too that if you're going to use UDP, you'll be losing packets all over
the place. If everyone is waiting on everyone else - then one lost packet will
stop the game...so in practice, you'd need some kind of time-out to allow lost
packets to be retransmitted. That would be workable in an asynchronous situation - but
in a synchronous environment, everyone has to stall whenever anyone else loses a
packet...that's not going to be much fun!
Any ideas?
The way to do things (IMHO) is to divide events in the world into things
that happen just once (opening a door, picking up an object, killing something)
and events that happen continuously (moving the player, moving bullets, etc).
The one-time events go via TCP - they may take longer but they'll definitely
get there. Continuous events go via UDP and their positions are extrapolated
on the clients to make them look like they happen smoothly.
The server maintains the true state of the world - and sends it to all the
clients as often as network bandwidth permits. If things get out of sync,
there may be a momentary glitch - but the next update from the server will
fix it.
So - if a character is moving along, it may be that the UDP packet describing
where he is gets lost - either going to the server or coming back
from it - but since everyone is 'guessing' where he's most likely to be next,
a lost packet will only mean that he travels in a straight line for 200ms or
so when he should have speeded up, slowed down or turned slightly. Either way,
the error will soon be corrected and you'll see only a tiny jump in position.
If that person is shot though - that information goes via TCP - so he'll definitely
exit the game...although perhaps not at exactly the right screen coordinate.
Is there any documentation about doing such things?
I havn't seen one single place where this has been talked about.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@airmail.net> WorkEmail: <sjbaker@link.com>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----