Multiplayer Game Netcode

Written by Backbone Tutorials Team

Last updated: June 2026 · 8 min read

A game played by two people on one keyboard stays in sync for free. The moment those players sit at different computers, everything changes: messages take time to arrive, each player sees a slightly different version of the game, and someone has to decide what really happened. Netcode is the set of techniques that solve this. This article explains the authoritative server model, client prediction, and reconciliation, the foundations of networked multiplayer, framed purely as engineering.

It extends the local multiplayer Pong demo and shares its core problems with the interactive web cluster.

The core problem

Networked games fight a single unavoidable fact: information takes time to travel.

Latency changes everything

When two machines are involved, a player action reaches the other side tens or hundreds of milliseconds later. In that gap, both players are acting on slightly outdated views of the game. If each machine simply trusted its own version, the two would drift apart and disagree about the score, positions, and who won. Every netcode technique exists to manage this gap, the same latency challenge covered in latency and reconciliation.

An authoritative server

The first decision is who gets the final say about the game state.

One source of truth

The standard answer is an authoritative server: one machine, usually the server, holds the true game state, and clients send their inputs to it rather than deciding outcomes themselves. The server resolves everything and tells clients the result. This prevents disagreement and, importantly, makes cheating far harder, since a client cannot simply declare itself the winner. It is the single source of truth idea applied across a network, connected to multiplayer state synchronization.

Client prediction

Waiting for the server before showing your own move would feel awful.

Acting before confirmation

If a client waited for the server to confirm every move, controls would feel laggy by the round trip time. Client prediction fixes this: the client applies your input immediately, predicting what the server will decide, so your own character responds at once. The prediction is almost always right, because you know your own input, so play feels instant while the server still has the final say. This is the game version of the optimistic update.

Server reconciliation

Occasionally the prediction and the server disagree, and that must be resolved.

Correcting a wrong guess

When the server result arrives and differs from what the client predicted, the client reconciles: it accepts the server state as truth and replays any inputs made since, so the correction is applied without losing recent actions. Done well this is invisible; done badly it shows as a rubber band snap. Reconciliation is what keeps prediction honest, and it mirrors the conflict handling in realtime data synchronization.

Showing other players

You can predict your own moves, but not what other players will do.

Interpolation between updates

Other players arrive as a series of position updates from the server, spaced apart in time. Drawing them only when an update lands would look jerky, so games interpolate, smoothly moving a remote player between its last known positions. This trades a little added delay for smooth motion, and the transport carrying these updates is usually a WebSocket.

Common pitfalls

Netcode is famously subtle, with a few defining traps.

What usually goes wrong

The most common is trusting the client, which both desynchronizes play and invites cheating; keep the server authoritative. The second is no prediction, which makes controls feel sluggish on any real connection. The third is a harsh reconciliation that snaps objects visibly instead of correcting smoothly. Start from the working local version and add the network layer once the game logic is solid.

Read next: the Game Development hub, or explore the Interactive Web cluster.