What Is Netcode in Games? Prediction, Rollback, and Authoritative Servers

A plain glossary of the techniques that make online games feel instant, who holds authority in a match, and the game backend that netcode alone does not cover.

What is netcode in games?

Netcode in games is the networking code that keeps every player’s view of an online match in agreement, fast enough that the match feels live. It decides what each machine sends, who decides the truth, and how each client hides the delay before that truth arrives.

Every online game has netcode, even when players never notice it. They notice when it fails: a shot that clearly hit but did not count, a character that snaps back after running forward, or an opponent who teleports across the screen.

The core problem is latency. A message between two players can take tens to hundreds of milliseconds, and some messages arrive late or not at all. Netcode cannot make the network faster. It can only decide who is in charge, what to show while waiting, and how to correct mistakes without the player feeling them. For the transport side (TCP, UDP, and snapshots), our game networking tutorial covers the basics.

Server authoritative vs client authoritative (and peer to peer)

Before any technique, netcode answers one question: whose version of the match is true?

• Server authoritative. A server runs the match. Clients send inputs, the server applies them, and it broadcasts the result. Clients are, in effect, privileged spectators of a world the server owns.
• Client authoritative. Each client decides its own state and tells the others. A server may relay messages, but it does not check them. This is simpler and faster, but a modified client can claim anything.
• Peer to peer. Players connect directly, and one of them often acts as host. Authority sits on a player’s device.

Server authoritative vs client authoritative is mostly a question of cheat risk. If a dishonest client would ruin the game for others, the server needs to own the truth. If players are trusted, as in a casual co-op match, relayed messages are often enough. Our guide to which multiplayer architecture fits a live game walks through that choice in detail.

How does an authoritative game server work?

An authoritative game server runs the simulation for a match on a fixed tick, a regular step where it reads inputs, updates the world, and sends out the new state. Here is one tick in a shooter:

1. Clients send inputs. A player presses fire and moves left. The client sends those inputs, not the result.
2. The server validates them. It checks the move is legal, the weapon has ammo, and the timing makes sense.
3. The server simulates. It moves players, resolves the shot, and applies damage.
4. The server broadcasts state. Every client receives the new positions and outcomes.
5. Clients render. Each client draws the authoritative state, smoothing it with the techniques below.

The tick rate is configurable and depends on the genre. A fast shooter needs frequent updates. An active turn-based card battle can run far fewer, and a slow asynchronous game can stop its loop between turns.

The cost of server authority is the round trip. If the client waited for the server before showing every action, a fast game would feel sluggish. That is the problem the rest of the netcode toolbox solves.

Netcode glossary: the techniques that hide latency

Client-side prediction vs rollback vs server authority

These terms are often compared, but they solve different parts of the problem. Server authority decides who owns the truth. Prediction and rollback decide what the player sees before the truth arrives.

Client-side prediction and reconciliation. Your client moves your character the instant you press a key, then keeps a list of inputs the server has not confirmed. When the server’s state arrives, the client resets its own character to that state and immediately replays the unconfirmed inputs on top, all before the next frame is drawn. If the guess was right, nothing visible happens. If it was wrong, the character corrects, which players feel as rubber-banding. This pairs naturally with an authoritative server, which is why most shooters and action games use it.

Lag compensation. Prediction makes your own movement feel instant, but other players are drawn slightly in the past. When you shoot, the server rewinds hitboxes to where targets were on your screen, so a shot that looked on target counts. The trade-off is that players can occasionally be hit just after reaching cover. Valve’s write-up of Source multiplayer networking is the classic reference for prediction, interpolation, and lag compensation together.

Rollback. Each client runs the whole game locally and guesses what the remote player will do, usually by repeating their last input. When the real input arrives and differs, the client rewinds to that frame and re-simulates every frame since then with the correct input, all inside one rendered frame, so the player only sees the corrected result. Rollback needs a deterministic simulation that can save and restore state quickly. Most rollback setups also add a small, fixed input delay of a frame or two, so fewer guesses turn out wrong. Fighting games made it famous because one-on-one matches with frame-precise timing suffer most from input delay. The open-source GGPO library, released under the MIT license in 2019, is the reference implementation many fighting games point to.

Deterministic lockstep. Clients exchange only inputs, and every machine runs the same simulation in the same order. It keeps bandwidth tiny even with thousands of units, which is why strategy games use it. The catch is that the match runs at the pace of the slowest connection, and any non-determinism makes the clients drift apart.

Listen server vs dedicated server

A listen server is a player’s machine that hosts the match while that player also plays. It costs the studio nothing in servers, but the host has zero latency, the match depends on the host’s connection, and a host who quits forces a migration or ends the game. A dedicated game server is a machine that only runs the match, with no player on it. It is fair to every player, easier to protect, and the natural home for an authoritative simulation, at the cost of hosting and operating a fleet.

Competitive and cheat-sensitive games almost always move to dedicated servers. Dedicated game server hosting brings its own work: placing servers near players, starting and stopping them as demand changes, and handing players from matchmaking into the right server.

Netcode is not your whole game backend

Netcode covers the live match. Everything before and after it belongs to a game backend, and that layer outlives every match.

This split is why studios treat authoritative real-time play and the persistent game backend as two layers that talk to each other. The match server reports the result, and the backend records it, updates rankings, grants rewards, and puts players into the next match. Keeping them separate also lets each layer scale on its own, which our game backend scalability best practices covers. For a full build walkthrough, see how to make an online multiplayer game.

Where Nakama fits

Nakama is our open-source game backend, and it covers both layers.

For the match, Nakama supports authoritative multiplayer and relayed multiplayer, so you choose server authoritative multiplayer or client-relayed play per game mode. In authoritative matches, you write match handler code that runs on the server at a fixed, configurable tick rate. Each tick, the match loop receives every message that arrived since the last tick, so validation happens in one place before state is broadcast. Real-time traffic runs over WebSockets or rUDP.

For games that run physics in a headless engine build, Nakama’s session-based multiplayer uses a fleet manager to start dedicated game servers from the matchmaker and report results back. Wildlight took this path for Highguard: Nakama handles matchmaking and player accounts on a dedicated Heroic Cloud private instance, and Amazon GameLift runs the game servers through our Nakama-GameLift integration.

Around the match, Nakama provides accounts, matchmaking, storage, leaderboards, tournaments, and social features in the same backend. For publishers and larger studios, Heroic Cloud runs Nakama as a managed service with dedicated resources, so your team focuses on netcode and content rather than operating the backend. Smaller teams start on the same open-source core and keep it as they grow.