Asynchronous Multiplayer on Mobile Network
- 1. ASYNCHRONOUS MULTIPLAYER: AUTHORATIVE SERVER ON SLOW NETWORK Ivan Dolgushin Game developer at Appturn
- 2. Maze Mash
- 3. Maze Mash
- 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.
- 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
- 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