Tell me more ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.
up vote 2 down vote favorite

I'm developing a multiplayer game through Gamecenter in unity with prime31 plugin. This is how I sync the clocks of the two players (right now there will only be 2 player in one match), and I wanted to now if it's ok:

This is done one time at the start of the match.

  • I have device A and device B.

  • Device A resets it's game clock to 0.0f.

  • A sends a reliable message to B saying that A has reset it's game clock.

  • B recieves the message and resets his game clock as well and sends a message to A saying he has also reseted the clock.

  • A recieves the message and does the following.

float delayAtoB = getCurrentTime() / 2;  
setGameClock(delayAtoB);

delayAtoB is actually this the time it took to get to B, so right now the two devices have the same clock. It works ok, but I wanted some opinions because I'm not sure if it's the best way and some exceptions might ocur..

share|improve this question
1  
Possible duplicate: gamedev.stackexchange.com/questions/18766/… – Trevor Powell Jan 17 at 20:09

2 Answers

up vote 2 down vote accepted

What you've described is correct and commonplace. Ping times can vary widely though, so to get a more accurate result you can repeat the process a few times and take the average ping time as described on wikipedia.

share|improve this answer
But I just simply set the device A clock back so it syncs with the other due to the delay. Why would I want to do more pings and get the average? Setting the clock A exactly the delay time will make the 2 devices sync, I don't know if I'm missing something. This is a one-time thing i do before everything, then the clocks will update on their own deivces independantly. – marcg11 Jan 17 at 19:48
Right now, you are taking the first RTT (round trip time) as law and using that for the rest of the game. RTTs can vary quite a lot depending on a variety of factors, the first one could be 100ms, then 75ms, then 80ms and so forth. Depending on your game, and the connection, you may not notice any discrepancies using the first RTT as law. But if you do notice problems, taking the average of a few RTTs will be a better approximation of the expected RTTs and will get the clocks as close the same as possible. – John McDonald Jan 17 at 20:18
up vote 1 down vote

You actually want unreliable messages not reliable ones. The reason is that if a retransmission occurs then your timings can be significantly out. Just repeat the unreliable process until it works.

There's a standard protocol for doing this called NTP which may be of some interest, although it may be overkill for a game.

share|improve this answer
You don't need the clocks to be perfectly in sync, but the closer they are together (within reason), the better. The clock that's behind will have less time to get a packet to the clock that's ahead. Eg: If it took 50ms to send the reset packet server->client, and let's say 100ms from client->server because a packet was dropped, then the server would see a RTT of 150ms, and the clocks at T0 would look like: Server = 75ms, Client = 50ms. Messages from server->client will have 25ms of extra time to arrive, while messages from client->server will have 25ms less time to arrive. – John McDonald Jan 18 at 15:53

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.