Multiplayer Game Netcode Explained

Prerequisites: This guide assumes you understand game loops (fixed timestep, variable rendering). If you need a refresher, check out mainloop.js and this detailed explanation by the author.

This article reflects my experience building 2D multiplayer games as a hobby alongside my day job in web development.

Important: Avoid VM-like environments (WSL, Docker Desktop, VirtualBox) for multiplayer game development. These environments have poor clock synchronization, causing severe timing inconsistencies and jitter. Use a native OS installation instead.

Online multiplayer is an illusion.

In a perfect world, players would share a single state instantly. In reality, we are bound by the speed of light, unstable Wi-Fi, congested routers, and cheaters. If we simply sent data back and forth as it happened, the game would be an unplayable, jittery mess.

To create the sensation of a smooth, fair, shared reality, game engines like Valve's Source engine rely on a complex web of techniques: we delay time, we predict the future, and we rewrite the past.

Here's how it works.

1. Tick Rate

The server cannot process inputs continuously. Instead, it simulates time in discrete steps called Ticks¹.

Think of the server not as a video stream, but as a turn-based game played at lightning speed. A standard competitive shooter runs at 60Hz². Every ~16ms, the server wakes up, processes inputs, runs physics, and updates the world.

Time ────────────────────────────────────────────────────►

Server Ticks:   ■───────■───────■───────■───────■
                │ ~16ms │ ~16ms │ ~16ms │ ~16ms │

The tick rate keeps simulation deterministic: Tick 100 always happens before Tick 101, regardless of CPU fluctuations.

2. Snapshots and Update Rates

Even at 60Hz, rendering entities only at their tick positions would look choppy to the human eye. But there's another problem: sending 60 snapshots per second to every connected player gets expensive fast. Imagine a server with 100 players; that's 6,000 snapshots per second.

To save bandwidth, servers send Snapshots³ at a lower rate (typically 20Hz). This compounds the visual problem: simulating at 60Hz but receiving updates at 20Hz makes movement significantly choppier.

Server (60Hz):  ●  ●  ●  ●  ●  ●  ●  ●  ●  ●
Network (20Hz): ●──────────●──────────●───►
                (Missing data in between)

The solution requires rendering in the past.

3. Clock Synchronization

Before interpolation can work smoothly, the client must synchronize its clock with the server. The challenge is that you cannot calculate the clock offset from one-way snapshots alone; you need to know the network latency to account for transmission delay.

The Solution: Piggybacking

Use an "echo" method that piggybacks on existing traffic:

• Client: Includes a timestamp (Date.now()) in every input packet.
• Server: Stores this timestamp and echoes it back in the next snapshot as ackTimestamp.
• Client: When receiving the snapshot, calculates the Round Trip Time (RTT)⁴:

The clock offset is then calculated by subtracting the latency (half the RTT) from the traversal time:

The $\frac{\text{RTT}}{2}$ term assumes symmetric network latency.

Key Insight: Minimum RTT

Do not average samples. Instead, track the lowest RTT seen so far and only update the offset when you find a sample with a lower RTT. The sample with the lowest RTT is the most accurate measurement possible, as it represents the physical distance with the least amount of network congestion or jitter.

Implementation Strategy

Updates should be frequent during the first few seconds (roughly 10-20 ticks) to find that "golden" low-latency packet. After that, stop updating the offset to prevent jitter. Only recalibrate if the connection drops or you detect significant, sustained drift.

Advanced Topics: For competitive shooters or high-frequency trading, methods like Clock Slewing, NTP Stratum Models, or Kalman Filters add unnecessary complexity for browser games.

4. Interpolation

To make movement look smooth as if no one was lagging, the client does not render the most recent snapshot it received. Instead, it renders the world in the past.

By buffering incoming snapshots, the client sets its renderTime behind the server. The interpolation delay is a configured value (typically 100ms) that determines how far back in time to render. The snapshot buffer must be large enough to store snapshots covering this delay:

Where the safety margin (typically 1-2) accounts for network jitter and packet loss. For example, with a 0.1s interpolation delay and 20Hz update rate: ⌈0.1 × 20⌉ + 2 = 4 snapshots. This ensures the client always has two snapshots to interpolate between, plus extras for resilience.

Calculating Render Time

Each frame, the client calculates its current render time:

Where currentServerTime is the client's local time converted to server time using the clock offset. This ensures the client is always rendering 100ms in the past (or whatever delay is configured).

Selecting Snapshots for Interpolation

The client searches its snapshot buffer to find the two snapshots that bracket renderTime:

1. Find the newest snapshot with timestamp $\leq \text{renderTime}$ (the older snapshot)
2. Find the oldest snapshot with timestamp $> \text{renderTime}$ (the newer snapshot)

If both snapshots exist, the client uses interpolation⁵ to mathematically smooth the movement between these two known points:

Snapshots Recv:       S1         S2         S3
Time: ────────────────●──────────●──────────●──────►
                      │          │
Current Render Time:  │     X    │ (100ms behind real time)
                      │    /     │
                      └───/──────┘
               Interpolate smoothly here

The client calculates how far between two snapshots it is rendering, then lerps the position:

Where $t = 0.5$ means exactly halfway between snapshots.

This 100ms delay is why players see enemies where they were, not where they are now. But because the movement is smooth, it feels real-time.

5. Extrapolation

When a packet is lost, the client runs out of snapshots to interpolate between.

We could freeze the entity in place, but that looks jarring. Instead, the engine switches to Extrapolation⁶; the client uses the entity's last known velocity to predict where they should be if they kept moving in a straight line.

Interpolation:      S1 ─────── S2 (Path is known)

Extrapolation:      S2 ─ ─ ─ ─ ─ ─ ► ? (Path is guessed)
                    (Velocity × Time)

This is Dead Reckoning⁷. The formula is simple physics:

If the player turned during the lost packet, the prediction will be wrong and the entity snaps when real data arrives. To prevent extreme warping, engines typically limit extrapolation to ~0.25 seconds before freezing.

6. Client-Side Prediction

If we're rendering other players 100ms in the past, why does local input feel instant?

Because waiting for server confirmation would make controls feel sluggish. The client doesn't wait: when you press a key, it runs its own local physics simulation immediately, applying changes instantly. Simultaneously, it sends that input command to the server:

{ sequenceId: 200, input: 'up', timestamp: 1500 }

The sequence ID allows the server to process inputs in order and acknowledge which commands it has validated.

Client Input Buffer

The client maintains an input buffer (typically implemented as a ring buffer) that serves two purposes:

1. Command Sending: The client runs simulation at the same rate as the server (e.g., 60Hz), but throttles command sending to a lower rate (e.g., 30Hz) to save bandwidth. Each frame, the client stores its input in the buffer. When it's time to send (based on the command send rate), the client batches recent inputs from the buffer and sends them to the server.

2. Reconciliation: When the server sends back a snapshot with lastAcknowledgedSequenceId, the client needs to replay inputs that occurred after that sequence. The same input buffer stores these historical inputs, allowing the client to rewind and replay them during reconciliation.

For simplicity, the buffer can store up to a few seconds worth of inputs:

For example, storing 2 seconds at 60Hz requires 120 commands. This provides enough history for reconciliation while keeping the implementation straightforward.

7. Reconciliation

The client and server usually agree. But sometimes they diverge due to collisions, server-side hit detection, anti-cheat corrections, or unstable network conditions. (If you've built optimistic UIs in single-page applications, this is the same pattern: update immediately, then reconcile with the server's response.)

When the server sends a snapshot, it includes lastAcknowledgedSequenceId; the last input command it processed. The client compares: did my predicted position at that tick match the server's?

If they don't match, a prediction error occurred. The client must accept the server's authority:

The reconciliation process:

1. Rewind: Set client position to server's authoritative position at the acknowledged sequence
2. Replay: Re-run the physics simulation for all unacknowledged inputs (after the acknowledged sequence)
3. Smooth: If the final error is small, smooth the correction over several frames; otherwise snap immediately

This correction process is what players experience as rubber-banding: when the client's prediction diverges from the server's reality, the player's character snaps or smoothly corrects back to the authoritative position.

8. Lag Compensation

Since clients render enemies 100ms in the past, direct hit detection would fail. By the time you click, the enemy has already moved.

The server solves this with Lag Compensation⁸. When a shot command arrives, the server calculates when the client actually fired, then rewinds all players to their positions at that moment:

The server then:

1. Calculate Shot Time: Use the formula above
2. Find History: Search position buffer for $t_{\text{shot}}$
3. Rewind: Move all player hitboxes⁹ to historical positions
4. Raycast:¹⁰ Check for collision
5. Restore: Return players to current positions

This is why players die "behind walls." From the victim's perspective, they're safe. From the shooter's perspective (100ms in the past), the victim was exposed. The server favors the shooter.

9. The Server

While clients predict locally, the server maintains the authoritative¹¹ game state. Each tick, it processes commands from all connected players.

Command Processing

Valve's Source engine uses UDP, so commands can arrive out of order or be lost entirely. The server uses sequence IDs to sort them and discard duplicates. If you're building with WebSockets over TCP, order is guaranteed by the protocol, but you still need sequence IDs for reconciliation.

Important for TCP: Disable Nagle's algorithm with socket.setNoDelay(true). Nagle batches small packets to reduce overhead, but this adds latency which is unacceptable for real-time games.

Each player has an input buffer to handle network unreliability. The buffer size is calculated as:

Where the batch size is how many commands arrive per network update, and the margin (typically 2) accounts for missing packets. For example, if clients send commands at 60Hz but network updates arrive at 20Hz, each batch contains 3 commands, so the total buffer is 3 × 2 = 6 commands.

The server processes one command per player per tick:

1. Get the next command from the buffer (FIFO) based on expected sequence ID
2. If found: apply the command and update lastAcknowledgedSequenceId
3. If not found (packet loss): skip processing for this tick. The player simply doesn't perform that action.

If a movement command is lost, the player stops moving (which is what actually happened from the server's perspective). The client's prediction will handle the visual smoothness, and reconciliation will correct any divergence.

Alternative: You can record the last received command and repeat it when a command is lost. This can feel smoother for continuous inputs like movement, but it can mask input bugs and make debugging harder.

If the buffer overflows (client sending commands faster than the server can process), the server takes only the most recent commands up to the buffer limit. This automatically resyncs the client by discarding stale inputs.

Sending Snapshots

After simulating the tick, the server bundles the world state into a snapshot containing positions, velocities, health, and other entity data. It stamps each snapshot with:

• Timestamp (when this state existed, serverTime)
• ackTimestamp for each player (the echoed client timestamp from their last input, used for clock synchronization)
• lastAcknowledgedSequenceId for each player (the last input command processed)

The server then sends snapshots to all clients at the configured update rate (typically 20Hz), even though it's simulating at a higher tick rate (60Hz). Snapshots are sent at regular intervals, not every tick, to save bandwidth.

10. Optimization

To save more bandwidth and improve performance, apply the following techniques:

Binary Serialization

Replace JSON with binary formats using typed arrays (Float32Array, Uint32Array). This eliminates string parsing and field name overhead, making packets significantly smaller and faster to encode/decode.

Delta Compression

Send only what changed since the last acknowledged snapshot instead of full world state every update. The server tracks the last snapshot each client received and sends diffs. Handle packet loss by falling back to full snapshots when needed.