This document discusses synchronization techniques for multiplayer games. It begins by distinguishing between synchronous and asynchronous games. For asynchronous games, it recommends using an authoritative server model with remote procedure calls and regular state comparisons. It then discusses challenges with real-time games, such as network latency, and proposes solutions like input caching, prediction, and state synchronization to address latency issues. The document notes pros and cons of the predictive approach, such as increased processing but ability to work on a wide range of network qualities.

1. ASYNCHRONOUS MULTIPLAYER:
AUTHORATIVE SERVER
ON SLOW NETWORK
Ivan Dolgushin
Game developer at Appturn

2. Maze Mash

3. Maze Mash

4. Time-keeping in games

5. Synchronous and asynchronous
If the attainment of a win
as a part of a loop
depends on the actions
of more than one player,
•that loop is synchronous;
•if not, it is asynchronous.

6. Step 1: Turn-based games
Synchronization:
• once a turn (on commit);
• network latency does not matter;
• race conditions do matter.

7. Remote Procedure Call (RPC)
Send action, reliably, with turn number.
Return nothing on success.

8. Parallel simulation
Client Server

9. Compare world states regularly:
as check-sum or any other way
De-synchronization

10. Checksum failure strategies:
• Stop the game
• Take client world as correct one
• Take server world as correct one

11. Step 2: Real-time games
Turn-base ->
-> timed turn-base ->
-> time per turn < 1/30 sec
-> real-time game ^_^

12. Synchronizability requirements:
• “Fixed” update time-step
• “Fixed” call order in the update-frame
• “Fixed” data types
• “Fixed” math
• “Predictable” randomness

13. Network latency

14. Re-synchronization strategies:
• Logical state synchronization
• Lerp visuals in several frames

15. Step 3: Predictive RT
When the game turn duration is way shorter than network
latency, the network messages never gets to the remote in
time
Server
Client
A
A
B
B
C
C

16. Time shift
Server
Client
A
A
B
B
C
CLTNCY

17. Jitter
Server
Client
A
A
B
B
C
CLTNCY

18. Input caching
Server
Client
A B C
LTNCYJB
QUEUE
A B C
AB C
|0
|0 |100
|100

19. State synchronization
Server
Client
A B C
LTNCYJB
QUEUE
A B C
AB C
|0
|0 |100
|100
? ?

20. PREDICTION
PREDICTION
Prediction
Server
Client A B C
LTNCYJB
QUEUE
A B C
AB C
|0
|0 |100
|100
QUEUE A B C

21. PREDICTION
PREDICTION
Timestamps
Server
Client A B C
LTNCYJB
QUEUE
A B C
AB C
|0
|0 |100
|100
QUEUE A B C

22. Prediction issues
• Make sure your logic is “prediction-aware”.
No irreversible actions should be done, e.g. object should
not be actually destroyed a while after their “visual death”.
• Make sure your FX logic is “prediction-aware”.
Some action may happen several times in one frame just
because of prediction.

23. Pros and Cons
Pros:
• is working on a wide range of
network qualities
• load depends on actual
prediction duration (low load
on low-latency networks)
• high security
• moderate server load
• almost out-of-the-box replays
Cons:
• prediction requires relatively
large amount processing time
(a bunch of “frame” amounts)
• load depends on actual
prediction duration (high load
on high-latency networks)
• does not work for synchronous
multiplayer games
• quite hard to implement
• horribly hard to debug
• require predictable and
synchronizable random
numbers

24. Thank you!
Ivan Dolgushin
Game developer at Appturn
ivand@appturn.com