Each player sees a local picture. A server keeps the shared state. Move a character, add delay, then break a connection to see how those pictures come apart and meet again.
Published
A knows the accepted positions.
The move has not reached authority.
B waits for the server’s update.
The useful distinctionResponsive to your input and agreed with everyone else are separate jobs.
Each message leg uses the selected delay. Manual reading time between steps is extra. This model uses a fixed delay, explicit snapshots and one coordinate per player; it omits continuous physics, packet loss, interpolation, authentication and offline input replay.
Go deeper: how it works ↓01 · Prediction
A waiting-for-server-only design makes every action wait for a round trip. Here A draws a predicted move immediately. That improves the local response, while B still needs an update. Prediction is a temporary estimate of what the server will accept.
02 · Authority
The server applies the rule and records an accepted position. Try the closed gate: the local estimate reaches cell 8, but the server stops A at cell 5. This deliberately simple rule creates a visible disagreement. A real game must choose which decisions each system owns.
03 · Correction
A snapshot is a description of the shared state at a point in time. When it arrives, A replaces its estimate and B learns where A is. The clear path confirms prediction; the closed gate corrects it. A fuller system can soften visual corrections or replay pending inputs. This model replaces the position directly.
04 · Recovery
A disconnected screen still has a picture, but it can be old. B moves while A is away. Rejoining restores the connection first; A is current only after a new snapshot arrives. Here the client fetches a fresh snapshot without replaying offline moves. Real systems need explicit rules for identity, missed actions, authority and stale messages.
Building Somewhere Together made these distinctions useful to me. Its source uses Three.js for 3D rendering, Rapier for physics and Cloudflare Durable Objects for room authority. This teaching model runs locally with simple grid positions. It does not execute those engines, reproduce the game’s protocol or measure its performance.
The responsibilities differ: Three.js draws the world; Rapier simulates physics. Cloudflare’s Durable Objects WebSocket example shows how one object can coordinate connected clients. Those tools still need game-specific rules for accepting movement and recovering state.
For an implementation example from a different engine, Unity documents client prediction and separating anticipated values from authoritative values, including smoothing and recalculation. This illustration implements only the smaller sequence shown above.
A convincing connected demo answers only part of that list. Review delay and recovery alongside the happy path.