1
\$\begingroup\$

I am trying to synchronize two devices so that they can start the game at the same time.

The mechanism that I've thought about is that I would use the phones' time and set the intervals at, for example, ten seconds each. Then, when the start button is clicked, it will start the game on the beginning of the next interval. So, as long as the start buttons on both devices are clicked in a short time frame of each other, the game should start at the same time.

For the game, near perfect synchronization is important.

Will this work? I am assuming that every phone receives a timestamp from a single source, so that internal clocks are at the same time.

If that doesn't work, what is an alternative/better solution to offline multi-device synchronization?

\$\endgroup\$
  • \$\begingroup\$ What platform are you on? You should not synchronize the two devices with their own time but connect them somehow to each other and send a message to start the game. \$\endgroup\$ – Nino Handler Mar 27 '17 at 20:21
  • \$\begingroup\$ Android (android studio), with hopes of making it cross platform. \$\endgroup\$ – Ethan Watson Mar 27 '17 at 20:23
  • \$\begingroup\$ Use Bluetooth, Nearby, Wifi Direct to connect the devices \$\endgroup\$ – Nino Handler Mar 27 '17 at 20:25
  • \$\begingroup\$ Why are those better methods than the one I mentioned? Just curious \$\endgroup\$ – Ethan Watson Mar 27 '17 at 20:31
  • \$\begingroup\$ I only need them to start at the same time, not be linked in any other way. \$\endgroup\$ – Ethan Watson Mar 27 '17 at 20:31
2
\$\begingroup\$

The best resource on how to do all kinds of synchronization of advanced physical simulations over unreliable networks in games is the excellent blog posts/articles of Mr. Glenn Fiedler.

You can find it here, and the spesific article you want is here. Search for the topic "Measuring Round Trip Time" in that article.

To summarize (copied verbatim):

  1. For each packet we send, we add an entry to a queue containing the sequence number of the packet and the time it was sent.
  2. Each time we receive an ack, we look up this entry and note the difference in local time between the time we receive the ack, and the time we sent the packet. This is the RTT time for that packet.
  3. Because the arrival of packets varies with network jitter, we need to smooth this value to provide something meaningful, so each time we obtain a new RTT we move a percentage of the distance between our current RTT and the packet RTT. 10% seems to work well for me in practice. This is called an exponentially smoothed moving average, and it has the effect of smoothing out noise in the RTT with a low pass filter.
  4. To ensure that the sent queue doesn’t grow forever, we discard packets once they have exceeded some maximum expected RTT. As discussed in the previous section on reliability, it is exceptionally likely that any packet not acked within a second was lost, so one second is a good value for this maximum RTT.
| improve this answer | |
\$\endgroup\$
0
\$\begingroup\$

The delay of an internet network packet is usually < 100 ms. For a single action like you describe, this difference is usually too short to be noticed.

In comparison, the clock in 2 different phones on 2 different operators is rarely more than 2 minutes (120'000 ms) apart, if you account for time zones correctly.

If you can't - or don't want to - use the internet, you could use wifi direct or bluetooth.

If you don't want to use these either: Do your devices have microphones? If you're up for the challenge, you can have a "beep" based activation, where the game starts as soon as the second device hears the first device beep.

A possibly easier solution is to simply have 2 users press the start button at the same time, with audible feedback so they know the other user started at the same time. That way they would be within 200 ms of each other.

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy