Game Server Development Series — Part 4: The Game Loop
Bingrong Yan
All real-time multiplayer games—from shooters to MOBAs—depend on one core mechanism:
the game loop, also known as the simulation loop.
The game loop is the server’s “heartbeat.”
It controls how often:
- Player inputs are processed
- The world updates
- Physics and collisions resolve
- Timers and cooldowns advance
- NPCs and AI behave
- State is broadcast to players
Understanding the game loop is essential for building fair, predictable, real-time gameplay.
1. What Is a Game Loop?
A game loop is a repeating cycle that advances the simulation one step at a time.
Each cycle is called a tick.
Most game servers run at:
- 10 ticks/sec (slow SLG/strategy)
- 20 ticks/sec (battle royale, mobile MOBA)
- 30 ticks/sec (common action/FPS)
- 60 ticks/sec (competitive FPS)
- 120+ ticks/sec (very high-end FPS / fighter prototypes)
Higher tick = more responsiveness but more CPU cost.
2. The Game Loop Cycle
A general tick cycle looks like this:
flowchart TB
A[Receive Player Inputs] --> B[Validate & Normalize Inputs]
B --> C[Update World State]
C --> D[Resolve Physics & Collisions]
D --> E[Run AI & NPC Logic]
E --> F[Trigger Events (skills, bullets, effects)]
F --> G[Generate State Snapshot/Delta]
G --> H[Broadcast to Players]
Each tick advances the world by a fixed slice of time, e.g. 1/30th of a second.
3. Fixed vs Variable Ticks
There are two common loop styles.
3.1 Fixed Tick Rate
The server runs at a predictable interval:
- Every 50ms (20 ticks/sec)
- Every 33.33ms (30 ticks/sec)
- Every 16.67ms (60 ticks/sec)
✔ Pros:
- Predictable
- Deterministic
- Easy for rollbacks
- Easy for client-side interpolation
✘ Cons:
- CPU usage is constant
- Needs optimization to avoid missing tick deadlines
3.2 Variable Tick Rate
The loop uses the exact real-time delta and adjusts each simulation step.
✔ Pros:
- Efficient
- Great for slow/turn-based games
✘ Cons:
- Harder to reproduce deterministically
- Can cause jittery physics
4. A Basic Game Loop (Pseudocode)
Here is a basic fixed-tick loop in pseudocode:
func startGameLoop() {
tickRate := time.Second / 30 // 30 ticks/sec
ticker := time.NewTicker(tickRate)
for range ticker.C {
inputs := drainInputQueue()
validated := validate(inputs)
updateWorld(validated)
collisions()
runAI()
events()
state := generateDelta()
broadcast(state)
}
}
This loop drives a real-time match server.
5. Input Processing
Players send input packets:
- Movement
- Ability activations
- Aim/rotation
- “Use item”
- “Fire weapon”
The server must:
- Validate them
- Order them
- Reject impossible actions
- Apply them to the authoritative simulation
5.1 Input Pipeline Diagram
sequenceDiagram
Client->>Server: Input (move + aim)
Server->>Server: Timestamp + sequence handling
Server->>Server: Validate input
Server->>Sim: Apply input to game state
6. State Update & Physics
After inputs are applied, the server updates:
- Positions
- Velocities
- Collisions
- Projectiles
- Hitboxes
- Environment interactions
Physics updates usually follow a pattern like:
flowchart LR
ApplyForces --> IntegrateVelocity --> ApplyGravity --> CollisionDetection --> CollisionResponse
The server enforces all rules to ensure fairness.
7. Event Processing (Skills, Bullets, Triggers)
Most games have a system for long-running or delayed effects:
- Bullets & projectiles
- Explosions
- Buffs/debuffs
- Cooldowns
- Timers
- AoE effects
- Animation timing events
Events can be:
- Time-based
- Distance-based
- Collision-based
- Conditional (HP < 30%, trigger ability)
These run inside the tick loop or in parallel systems.
8. Snapshot, Delta, or Hybrid State Sync
The server must send updates to clients so they can render the latest state.
There are three major sync models:
8.1 Full Snapshot
Sends entire world state periodically.
✔ Easy
✘ Very bandwidth-heavy
8.2 Delta Updates
Sends only what changed since last tick.
✔ Efficient
✔ Used by modern games
✘ Requires careful diffing logic
8.3 Hybrid Model (Most Common)
Example:
- Snapshots every 1–2 seconds
- Deltas every tick
- Important events sent immediately
9. Determinism — The Key to Replays & Rollback
A simulation is deterministic if:
Given the same inputs and initial state, it produces the same result every time.
Determinism is essential for:
- Rollback netcode (fighting games)
- Lockstep RTS (StarCraft, AoE)
- Replays / spectator mode
- Cheating prevention
- Debugging with time-travel
9.1 Deterministic Simulation Requirements
- Fixed tick rate
- No floating-point randomness (use int math or fixed-point)
- No time-based randomness
- Inputs processed in strict order
- Identical sequence of operations on all machines
10. Rollback vs Lockstep — Two Classic Models
Used in different genres.
10.1 Lockstep (RTS Games)
Each tick:
- Clients send commands
- Server collects them
- Server applies them all at once
Pros:
- Highly deterministic
- Tiny bandwidth
Cons:
- Slow reaction to lag
- Poor for action games
10.2 Rollback (Fighting Games)
- Client predicts ahead
- Server sends authoritative correction
- Client rewinds and reapplies correct inputs
Pros:
- Extremely responsive
- Ideal for 1v1 action
Cons:
- Complex to implement
11. Putting It All Together — Full Game Loop Diagram
flowchart TB
A[Receive Inputs] --> B[Validate Inputs]
B --> C[Apply to Simulation]
C --> D[Physics & Collisions]
D --> E[AI & NPC Logic]
E --> F[Process Events]
F --> G[Generate Snapshot/Delta]
G --> H[Broadcast to Clients]
H --> A
The loop repeats every tick, driving real-time game logic forward.
12. Summary
In this chapter you learned:
- What a game loop is
- How tick rates affect simulation
- Difference between fixed and variable tick loops
- How inputs, physics, and events are processed
- Snapshot vs delta updates
- Why determinism matters
- Basic rollback and lockstep models
The game loop is the foundation of real-time multiplayer game logic.
All future systems—movement, combat, physics, netcode—depend on it.