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:

1. Clients send commands
2. Server collects them
3. 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)

1. Client predicts ahead
2. Server sends authoritative correction
3. 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.