[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: peer-peer syncronization
> Francesco Orsenigo wrote:
> 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!
I was thinking about relative simultaneity, wich means that if event A and
event B occour simultaneously for player 1 at, say, 11h45'21"pm they happen
later or before, but simultaneously (togheter!) for player 2 at
11h45'22"pm... If I was crossing the firing line in at the same time my
enemy shot, i should appear fragged on both computers...
I don't get fragged at the same time on two computers, but i get fragged when
the enemy, on each computer, shots...
Well, i guess the fps case is easier, since there are so few MOBs....
> "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."
What a truth...
> If you use UDP, you'd better be sending data that you can definitely
> afford to lose.
Wich means no relative data, only absolute data (where 'relative' means that
depends on the previous data wich must be correct...)
> 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.
Well, it is still good for a small LAN....
> 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.
Yeah, but that's complex....
What about the server just 'routing' timed packets?
-The player gives a command
-The client sends the command to the server
-The server adds the time (in game time) of the execution of the command
(maybe postponed some ticks in the future) and sends it back to ALL clients.
-The clients receive the command and, when the time has come, execute the
command, updating the game.
Drawback: some lag between the command issued and the command executed.
But should fit a RTS game.
> 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!
True... But how can i know how much can i trust an UDP connection?
> 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.
Maybe, but too complex for me alone.
Keeping consistency between TCP and UDP quite scares me...
I must think about it.