Designing a real-time multiplayer mobile game touches more disciplines than almost any other mobile system design question — location services, real-time networking, AR, anti-cheat, server architecture, battery, and the operational realities of a game with millions of concurrent players.
Functional requirements
- Real-time location-based gameplay
- Encounter creatures/items in the world
- Battle other players or NPCs
- Chat / friends
- Persistence — inventory, levels, achievements
- AR experience (camera-overlay rendering)
Non-functional
- Sub-200ms input-to-screen for actions
- Battery: 1 hour of gameplay should drain ~15-25%
- Resilient to network drops
- Anti-cheat — server-authoritative for important actions
Architecture
Three main systems: client, game session, persistence.
Server-authoritative actions
Anything that affects gameplay state must be server-authoritative. Catching a Pokemon, completing a battle, leveling up — the server decides. The client requests, the server validates and confirms.
Why: cheaters can modify the client. If the client reports “I caught 100 legendaries,” the server should reject this without server-side validation.
Real-time location
Sample GPS every 1–3 seconds during gameplay. Push to server. Server maintains the player’s session state and broadcasts visible game events to the player based on their geolocation (s2 cell-based partitioning).
Spawn logic
Server determines what creatures spawn where, when, and to whom. Client receives a list of nearby spawns; renders them on the map. Spawn data is server-authoritative — clients cannot wish creatures into existence.
Battle protocol
For real-time battles between players:
- Both clients connect to the same game session server
- Inputs sent to server with sequence numbers and timestamps
- Server simulates the battle deterministically
- Outcomes broadcast back to both clients
- Clients render with prediction + correction (rollback netcode for fairness)
AR rendering
iOS: ARKit places the creature in the camera feed using world tracking. Android: ARCore equivalent.
For lower-end devices, fall back to a 2D overlay over the camera feed without full 3D world tracking.
Anti-cheat
- Server-authoritative everything important
- Detect impossible movement (teleporting, flying speeds)
- Detect spoofed locations (mock GPS detection on Android, jailbreak detection on iOS)
- Behavioral analytics on the backend (catch rates, walking speeds, distance traveled)
- Shadow ban or warn for first offenses; full ban for repeated
Battery
- GPS at moderate accuracy when stationary; high accuracy only when moving
- Camera for AR is the biggest battery hog — disable when not actively encountering
- Disconnect from session server when game minimized for >30 seconds
Persistence
Player state in a sharded database (DynamoDB, Spanner, or sharded MySQL). Inventory, achievements, friends. Hot-state cached in Redis for low-latency reads during gameplay.
Frequently Asked Questions
How do you handle a player who loses connection mid-battle?
Pause the battle for ~30 seconds awaiting reconnect. If reconnect fails, AI takes over the player’s side or the battle is forfeit (depending on game design). Server logs are authoritative.
Why is Pokemon Go server load spiky?
Special events (Community Day) concentrate millions of players in narrow time windows. Capacity must be 10–20x baseline, and the architecture must shard across regions to handle it.
How do you detect GPS spoofing?
Inconsistent location/sensor readings (GPS says you are walking but accelerometer says you are stationary), impossible velocities, or location-modification API detection.