Netcode

How a game keeps two or more machines agreeing about the same world over a link that loses packets and delivers the rest late. It is the largest architectural commitment an engine forces on a project, and the choice is made at the beginning because two of the three options demand properties the simulation must have had all along.

Three families

Lockstep. Everyone runs the same simulation and exchanges only inputs; a frame advances when all inputs for it have arrived. Cheap on bandwidth regardless of how much is happening on screen, which is why RTS games still use it. game-networking-fiedler puts it plainly: the state is "simply too large to exchange between players." The cost is that one slow peer stalls everyone, which is what killed it for action games once play moved off the LAN.

Rollback. Lockstep without the waiting: predict the remote input, run the frame now, and when the real input contradicts the prediction, restore the last agreed state and re-simulate every frame since. ggpo is the reference implementation, and its three requirements are the price: a fully deterministic simulation, a fully serializable game state, and the ability to save, load and step a frame without rendering it.

Client-server with prediction and state sync. One authoritative server; clients predict their own actions immediately and correct when the server disagrees, and either receive state snapshots to interpolate between (Unreal, Halo) or inputs to replay. Everything since QuakeWorld in the action-game line works this way.

Why it is an engine decision, not a feature

Rollback and lockstep both require determinism: the same state plus the same inputs must produce an identical state on every machine, every frame. That is a property of the whole simulation, and almost nothing in a general-purpose engine guarantees it by default — floating-point differences across compilers and CPUs, an unsynchronised random source, physics that varies with frame timing, or gameplay code that reads something the renderer owns will each break it, silently, until two machines diverge in a match.

Serializability is the same kind of demand: every piece of state that affects the outcome has to be capturable and restorable in a frame's budget, which constrains how gameplay objects are allowed to be written. Retro-fitting either onto a shipped codebase is the expensive path, and it is the reason the netcode question sits alongside the language and rendering questions when an engine is picked rather than after.

Client-server with prediction relaxes determinism — the server is the tiebreaker — and pays for it in bandwidth and in the class of bugs where a client's prediction visibly snaps back.

What each engine supplies (2026-08-25)

The three stacks are now paged from their own documentation: unreal-replication, unity-netcode-gameobjects, godot-multiplayer-api. All three implement the third family above — client-server with an authoritative side — and none ships lockstep or rollback, which is consistent with the determinism argument in the section below: a general-purpose engine cannot promise what those two require.

Two things fall out of reading them side by side. Unity is the only one that makes the topology a choice, and it is candid that the cheaper option is the one that is easier to cheat against. And the engines differ most in what they automate when bandwidth runs out: Unreal names four mechanisms for deciding what a player does not receive, and neither of the other two documents an equivalent — a gap in the reading, not necessarily in the engines.

Coverage edge 5's remaining half is closed. What is still missing is any measurement: three architectural accounts, no numbers, and nobody comparing the three under load.