GDC Next 2013 - Synching Game States Across Multiple Devices
Download as PPTX, PDF1 like390 views
Saving players' game states across multiple devices can be tricky, especially if you allow offline play. Many games make the user choose between states when play is detected on a different device. Users can easily make mistakes that erase hours of progress. While developing Tunnel Town, we hit upon an elegant solution that can help you deliver a more polished user experience without the hassle of complicated code. The average profitable lifetime of a mobile game is six months. Learn how to architect your servers so they can be reused for multiple projects with a simple approach that scales easily.
More Related Content
Similar to GDC Next 2013 - Synching Game States Across Multiple Devices (20)
Recently uploaded (20)
GDC Next 2013 - Synching Game States Across Multiple Devices
- 1. Syncing Success Managing Online/Offline Game States Across Multiple Devices Dave Geurts and Colter Haycock Software Engineers Smart Bomb Interactive
- 4. Goals: Create mobile game that¡ ? Supports local only mode ? Allows play on multiple devices ? Seamlessly supports online and offline play ? Is non-intrusive when switching devices ? Requires minimal server logic
- 5. Our Recipe 1) Serialized hashed game state 2) Security 3) Server with volatile caching and persistent storage 4) Save state system for online and offline play
- 6. 1) Hashed Game State ¡ñ Serialization - Google Protocol Buffers Pros o Less Server Code
- 8. 1) Hashed Game State: Ingredients ¡ñ Serialization - Google Protocol Buffers Pros o Less Server Code o Fewer Database Schemas to Manage
- 10. 1) Hashed Game State: Ingredients ¡ñ Serialization - Google Protocol Buffers Pros o Less Server Code o Fewer Database Schemas to Manage o Obfuscation
- 12. 1) Hashed Game State: Ingredients ¡ñ Serialization - Google Protocol Buffers Pros o Less Server Code o Fewer Database Schemas to Manage o Obfuscation Cons o Can be difficult for debugging o Will need an External source for Metrics/Analytics ¡ñ Game State versioning
- 14. 1) Hashed Game State: Ingredients ¡ñ Serialization - Google Protocol Buffers Pros o Less Server Code o Fewer Database Schemas to Manage o Obfuscation Cons o Can be difficult for debugging o Will need an External source for Metrics/Analytics ¡ñ Game State versioning ¡ñ Storage friendly character sets
- 15. 2) Security Encryption of Game State ¡ñ Prevent share of save files ¡ñ Client needs to be able to decrypt without talking to server ¡ñ Don¡¯t leave keys/salt in plain text Server Authentication ¡ñ Confirming identity is important! ¡ñ Some systems **cough** Game Center **cough** don¡¯t support server authentication TAKEAWAY: If someone smart wants to hack your game, they will!
- 16. 3) Server w/ Volatile Caching and Persistent Storage Application language that can easily load balance App server needs to be lean! Simple logic to allow easy scaling Pick a database that will shard out of the box Cache layer to let databases breathe!
- 17. 4) Online and Offline Play Problem How do you allow play on multiple devices while supporting online and offline modes?
- 18. Houston, We Have a Problem
- 19. 4) Online / Offline Formula ¡ñ On login, client sends game state + UDID ¡ñ Server responds with game state + UDID of last save it has Client Rules ¡ñ Server UDID == my UDID: use local ¡ñ Server UDID != my UDID: ¡ñ If last save on this device was ONLINE: use server state ¡ñ If last save on this device was OFFLINE: ask user
- 24. 4) Same Time Play Problem: playing on same account on multiple devices at the same time Potential Solutions Don¡¯t Allow Stomping Stomp + Notify
- 25. 4) Same Time Play Solution 1: Don¡¯t Allow ¡ñ Client sends heartbeat to server ¡ñ Client sends ¡°I¡¯m done¡± on pause/quit ¡ñ Server doesn¡¯t allow second device to play Pro 1. No stomping Cons 1. Requires server and client logic 2. Must ping servers frequently
- 26. 4) Same Time Play Solution 2: Stomping ¡ñ Client gets game state from server on login ¡ñ Whoever saves last (closes app) wins Pro 1. No added server or client code Con 1. Stomping SUCKS Users won¡¯t always realize they ¡°stomped¡± their data and might think it¡¯s a bug if they ¡°lost¡± data
- 27. 4) Same Time Play Solution 3: Stomping w/ Notifications ¡ñ Client gets game state from server on login ¡ñ Whoever saves last (closes app) wins ¡ñ Notify users when stomping is detected Pros 1. Users can keep playing 2. Notified if a stomp occurred Cons 1. Stomping still SUCKS 2. Requires extra server/client code
- 28. Hindsight Is Wonderful ¡ñ People barely ever QUIT your app. Almost all ¡°closes¡± are really just pauses ¡ñ Don¡¯t assume your target audience¡¯s hardware! ¡ñ Do research about silly reasons Apple has rejected apps!
- 29. Server Tools Scaling Tools Client Tools
- 30. Contact Information Dave Geurts daveg@smartbombinteractive.com @sims11tz Colter Haycock colter@smartbombinteractive.com @blindgoatia Questions?