Captain strike backend post-mortem
Download as PPTX, PDF1 like273 views
The document outlines the architecture and design principles of a mobile game, 'Captain Strike', released on September 4, 2014, which has amassed over 20 million downloads. It details backend structures utilizing MongoDB for data management and Redis for caching, along with various game mechanics such as quests, events, and user profile management. Key lessons learned include optimizing connection protocols, minimizing request numbers, and tracking critical user data for improved game performance.
Captain strike backend post-mortem
- 1. Captain Strike Release Date: 9-4-2014 Platform: IOS, Android Total Download: 20M+ Peak DAU: 30k Peak CCU: 3k
- 2. Game Loop • Action Phrases • Activities - Buy and Upgrade items - Lottery - Quest, Event, Achievement - Leaderboard competition - …….
- 4. Backend Architecture Database Cache API Services Room Controller Room Room Room Room Server1 Server2
- 5. Databases • MongoDB - NoSQL with dynamic query - Good performance on big data - Predefine index on Schemaless data • Redis - Blazing fast - Store rapidly changing data and caching recently query
- 6. API Services • HTTPS - The security capabilities of SSL/TLS to standard HTTP communications - Easy to develop and deploy • Python - Widely used general-purpose, high-level programming language - Multi Platform - A huge number of frameworks and modules
- 7. Game Room • Standalone Application - Standalone process under managed of Room Controller • Forwarder - Synchronize player game ‘s world with others • Referee - Watches a game closely to ensure that the rules are adhered.
- 8. Room Life Circle • Load Configuration • Waiting for match start Initializing • Game Logic Processing • Synchronize game world and collecting data Playing • Calculating score • Update User Profile via API Service Scoring
- 11. Design Principles • Client just a “Display Screen” • Online configuration • Focusing on active user
- 12. Authenticate • Token base authentication. - API Service generate an opaque string that identifies a user ( Token ) - User must provide Token to API Service when make request to server - Token have a lifetime of about an 4 hours
- 13. User Profile • Client Read-only – Client don’t have authorize to change/modify user profile – User send action to server. Server check valid and update user profile according to that action Ex: Client: “Buy a gun id=10” Server: Check money, level, …. Perform transaction and update user profile
- 14. Quests and Events • Action and Target ID – Quest is an accumulate number of Action and TargetID. Quest Complete when acc number equal or greater than requirements – Each Quest/Event has their own requirement to activated • Competition Rewards – Competition rewards do not automatically delivery to user. User should call API to check and receive it after login complete
- 16. Connection • Minimize long live connections • Transmit data as quickly as possible Using UDP instead of TCP for real-time multiplayer • Be careful with packet loss • Ping is not constant!
- 17. Request/Response • Minimize number or request to limit the impact of ping Ex: Instead of send 3 api ( /getprofile, /getemail, /getconfig ) We can combine them together using Batch API • Not all requests can be processed in parallel!
- 18. Online Parameters • Online parameters are very important. It can help you balance/configuration your game without update your application • Use DNS instead of IP address for server URL • Using Cache to improve server performance
- 19. Tracking System • Always track critical information ( User purchase, User Profile change, … ) • Pay attention to your tracking record design • Analyze data to understand your audiences
- 20. Q&A Thank you for your time!