This document summarizes the key details of the mobile game "Captain Strike", including its release date, download numbers, gameplay loops, backend architecture, database usage, API services, room management, authentication process, user profiles, quests/events, and lessons learned. The backend uses MongoDB and Redis databases, Python API services, and distributes game rooms across multiple servers managed by a room controller. Authentication uses token-based authentication. User profiles are read-only on the client. Quests and events track action counts on the server. Connection handling, request batching, online parameters, and tracking systems were important lessons learned.

1. Captain Strike
Release Date: 9-4-2014
Platform: IOS, Android
Total Download: 2M+
Peak DAU: 30k
Peak CCU: 3k

2. Game Loop
• Action Phrases • Activities
- Buy and Upgrade items
- Lottery
- Quest, Event, Achievement
- Leaderboard competition
- …….

3. Part 1
Backend Architecture

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

9. Distributed Room
Database
Cache
API Services
Room
Controller
Room
Room
Room
Room
Server1 Server2

10. Part 2
Working Flow

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

15. Part 3
Lessons Learned

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!