Game Server Development Series — Part 5: State Synchronization

Leeting Yan

Real-time multiplayer games must constantly keep each player’s view of the world in sync with the authoritative game server.
This is one of the hardest challenges in networked game development because:

  • Networks introduce latency
  • Packets get lost or delayed
  • Input arrival times differ
  • Players have unpredictable connections
  • Tick rates differ between client and server
  • Bandwidth is limited (especially mobile)

State synchronization (“netcode”) is the art of making every player experience smooth, fair, and consistent gameplay, despite these constraints.

This chapter introduces the fundamental techniques used in modern multiplayer games.

1. Why Synchronization Is Hard

The server always holds the “real” world state.

But clients can experience:

  • 100ms to 300ms latency
  • Out-of-order packets
  • Packet loss
  • Network jitter

If the server simply sent “exact state every tick” and clients only rendered that, players would see:

  • Jittery movement
  • Rubber-banding
  • Delayed inputs
  • Stuttering
  • Invisible hits
  • Unresponsive controls

Therefore:
Clients must mask latency while remaining consistent with the server.

This is achieved through prediction, interpolation, and reconciliation.

2. Three Main Approaches to State Synchronization

There are three major families of synchronization strategies used in the industry:

  1. Full Snapshots
  2. Delta Compression
  3. Hybrid (Snapshot + Delta) ← most common

Let’s examine each.

3. Full Snapshots

A full snapshot means the server sends the entire world state:

  • Every player’s position
  • Every velocity
  • Every object state
  • All projectiles
  • All effects

Used in:

  • Very small worlds
  • Low-player-count games
  • Early prototypes
  • High bandwidth LAN games

Advantages

  • Simple to implement
  • Stateless (clients don’t need history)
  • Easy for debugging and replay

Disadvantages

  • Extremely bandwidth-heavy
  • Doesn’t scale to many players or objects
  • Frequent redundant data

This technique is rarely used alone in modern games.

4. Delta Updates (Most Common Approach)

A delta update includes only what changed since the previous tick.

For example:

  • Only send new positions
  • Only send players who moved
  • Only send projectiles that spawned or updated
  • Only send changed health values

This dramatically reduces bandwidth.

Advantages

  • Much more efficient
  • Ideal for moderately large worlds or 10–100 players
  • Works well with interpolation

Disadvantages

  • Requires tracking last-known state
  • Clients must store history
  • More complex logic

Almost all modern shooters (Valorant, Apex, Overwatch), MOBAs, and mobile real-time games use delta updates.

5. Hybrid System (Snapshots + Deltas)

The server sends:

  • Full snapshot every X seconds (e.g., every 1–2 seconds)
  • Delta updates every tick (e.g., 20–60 times per second)

This allows clients to:

  • Correct drift
  • Recover from packet loss
  • Stay close to authoritative state

This is the industry standard approach.

6. Client-Side Prediction

Prediction means the client guesses the result of the user’s input before hearing back from the server.

Example:

  • Player presses “move forward”
  • The client immediately moves the player forward
  • The server eventually confirms the movement

This prevents “input lag.”

Used in:

  • FPS movement
  • MOBA ability activation
  • Racing games
  • Fighting games (combined with rollback)

Prediction is essential for responsive gameplay.

7. Interpolation (Smoothing Other Players)

Because updates arrive intermittently, clients cannot render states directly as they arrive.
Instead, they interpolate between past states to produce smooth motion.

Process:

  1. Store snapshots from server with timestamps.
  2. Render the world a small amount “in the past” (typically 50–100ms).
  3. Interpolate positions of objects using two known states.

Interpolation turns jerky network updates into smooth animation.

Used in almost every real-time multiplayer game.

8. Extrapolation (Limited Prediction for Other Entities)

If you don’t receive an update:

  • Assume object continues moving
  • Cap prediction distance

Used when:

  • Network jitter is high
  • Player movement is continuous
  • Objects follow predictable trajectories

Extrapolation should be used carefully to avoid visible errors.

9. Reconciliation (Fixing Divergence from Prediction)

When the server sends authoritative state, the client must:

  1. Compare server state to predicted state
  2. Roll back to server state
  3. Reapply unsent inputs

This prevents long-term drift.

Used heavily in:

  • FPS
  • High-speed games
  • Peer-state synchronization games

This is why clients save recent input history.

10. Rollback Netcode (High-Level Overview)

Rollback is a special form of reconciliation used in:

  • Fighting games
  • 1v1 action games
  • Games with strict timing

Flow:

  1. Client predicts the future
  2. Server sends authoritative updates
  3. If predictions were wrong → rollback to correct state
  4. Re-run simulation of missed frames

This provides near-zero-latency feel, even with 100–200ms ping.

11. Choosing the Right Sync Strategy

Here is a quick guideline:

Turn-Based Games

  • No need for prediction
  • No interpolation
  • Use WebSocket or TCP
  • State changes are discrete

Casual Real-Time (Mobile Multiplayer, Co-op)

  • 10–20 ticks
  • Delta updates
  • Basic interpolation
  • Optional simple prediction

Competitive Real-Time (FPS, MOBA, eSports)

  • 30–60 ticks
  • Delta updates + input prediction
  • Reconciliation
  • Interpolation
  • Lag compensation
  • Optional rollback for precise actions

Large-Scale MMO / SLG

  • Event-driven or low-frequency snapshots
  • Region-based sync
  • No fast real-time movement

12. A Complete Sync Pipeline (Industry Standard)

Putting it all together:

  1. Client sends input commands (move, shoot, ability).
  2. Client predicts locally.
  3. Server simulates authoritative state.
  4. Server sends delta updates each tick.
  5. Client interpolates/extrapolates other players.
  6. Client reconciles mistakes using server updates.
  7. Full snapshots repair long-term drift.
  8. Rollback handles ultra-low-latency scenarios.

This pipeline keeps games smooth, fair, and responsive.

13. Common Pitfalls and How to Avoid Them

1. Rubberbanding

Cause: incorrect reconciliation or high latency
Fix: smoother interpolation, better rollback logic

2. Warping

Cause: large corrections
Fix: limit correction speed, interpolate corrections over multiple frames

3. Jittery Movement

Cause: uneven packet timing
Fix: client render interpolation buffer (50–100ms)

4. Teleporting or “popping”

Cause: unreliable extrapolation
Fix: clamp predictions

5. Desync

Cause: non-deterministic code
Fix: remove randomness or use fixed-point math

14. Summary

In this chapter, you learned:

  • The core techniques of real-time synchronization
  • How snapshots and deltas differ
  • Why prediction and interpolation are essential
  • How reconciliation and rollback keep clients in sync
  • How to pick the right model for your game
  • Common issues and solutions

State synchronization is one of the most challenging and rewarding parts of game server development.
Mastering it allows you to build smooth, responsive multiplayer experiences that feel great even with imperfect networks.