You fire a perfectly aimed shot, the kill feed says nothing, and a half second later your screen goes gray because the other player swears they were already behind a wall. That argument, repeated millions of times across every online match ever played, comes down to netcode. Netcode is the collection of techniques a game uses to keep many players in sync across an unreliable internet connection, and it quietly decides whether a multiplayer game feels crisp or feels like wrestling a ghost. Understanding how netcode works explains most of the frustration, and most of the magic, behind playing with other people.
Table of Contents
- What Is Netcode?
- The Core Problem: Speed of Light vs Your Reflexes
- Client-Server vs Peer-to-Peer
- Tick Rate: How Often the Server Thinks
- Delay-Based vs Rollback Netcode
- Client Prediction and Server Reconciliation
- Lag Compensation and Rewinding Time
- Why Netcode Feels Bad Even on Fast Internet
- Frequently Asked Questions
What Is Netcode?
Netcode is an informal umbrella term for everything a multiplayer game does to share its state across the network. There is no single line of code labeled “netcode” inside a game. It is the combination of how positions get sent, how often updates happen, how the game hides delay, and how it resolves disagreements when two machines see different things. Players use the word the way someone might say “the engine,” meaning a whole system rather than one part.
The job sounds simple. Each player presses buttons, those inputs change the game world, and everyone needs to see the same world at roughly the same time. The trouble is that the players are not in the same room. They are scattered across cities and continents, connected by cables, routers, and wireless signals that introduce delay, drop packets, and never behave exactly the same twice. Good netcode hides all of that mess so well that you forget it exists. Bad netcode makes you feel every millimeter of the distance between you and your opponent.
The Core Problem: Speed of Light vs Your Reflexes
Information cannot travel faster than light, and on real networks it travels much slower because of the hops between routers. A signal from a player in London to a server in Frankfurt and back might take 30 milliseconds. From London to a server in Virginia, it might take 90. That round trip time is called latency, or ping, and it is the enemy at the center of every netcode design decision.
Ninety milliseconds does not sound like much, until you remember that a fast game runs at 60 frames per second, which means a new frame appears every 16 milliseconds. By the time your opponent’s movement reaches you, they have already moved for several frames. If a game simply waited for confirmed data before showing anything, every action would feel sluggish and delayed. So netcode does not wait. It guesses, corrects, and rewinds, all in the background, fast enough that you rarely notice.
This is the same kind of clever engineering that shows up all over game development. The way a game fakes a believable world out of limited resources is its own art form, similar in spirit to how procedural generation builds entire worlds from a single seed. Netcode fakes a shared reality. Procedural generation fakes a vast one. Both are illusions held together by math.
Client-Server vs Peer-to-Peer
Before a game can sync anything, it has to decide who is in charge. Two main models answer that question, and the choice shapes everything else about the netcode.
Client-Server
In the client-server model, one authoritative machine, the server, holds the real version of the game. Every player, called a client, sends inputs to the server. The server runs the simulation, decides what actually happened, and sends the results back. If your client thinks you hit someone but the server disagrees, the server wins. This model is the standard for competitive shooters and battle royales because it is much harder to cheat against a server that does not trust anyone. The downside is cost. Studios have to run and pay for that fleet of servers.
Peer-to-Peer
In peer-to-peer, the players connect directly to each other with no central authority. This is common in fighting games and many older console titles because it avoids server costs and can produce very low latency between two nearby players. The catch is trust and stability. If one player has a bad connection, everyone suffers, and without an authoritative referee, cheating and desync become harder to prevent. Sometimes one player acts as a host, which is a hybrid that brings some of the server benefits along with the awkward problem of host advantage and host migration when that player quits.
Tick Rate: How Often the Server Thinks
A server does not run continuously in the way a single-player game might. It updates the world in discrete steps called ticks. Tick rate is how many of these updates happen per second, measured in hertz. A 64-tick server processes the world about 64 times a second, updating roughly every 15.6 milliseconds. A 128-tick server doubles that, updating every 7.8 milliseconds.
Higher tick rates mean the server checks for new inputs more often, which improves how accurately it registers hits and movement. A shot that lands between two slow ticks might be processed a frame late, which is enough to feel wrong in a fast duel. This is why competitive players obsess over tick rate and complain loudly when a popular shooter ships with a lower one. The tradeoff is server load. Every extra tick multiplies the calculations the server has to do per second across thousands of matches, which costs money and engineering effort.
Tick rate is separate from your frame rate, even though both are measured in hertz. Your screen might render at 144 frames per second while the server only ticks at 64. The game smooths over the gap by interpolating, drawing in-between positions so movement looks fluid even when fresh data arrives less often.
Delay-Based vs Rollback Netcode
Fighting games made one specific netcode debate famous, and it splits cleanly into two philosophies for handling the unavoidable delay between players.
Delay-Based Netcode
Delay-based netcode adds a buffer. The game waits a few frames before showing any input, long enough for both players’ inputs to arrive over the network. Because both sides wait the same amount, the game stays perfectly in sync. The problem is that everything feels slightly heavy, like your character has a half thought before acting. When the connection hiccups and an input does not arrive in time, the whole game freezes for everyone until it catches up. On a bad connection, delay-based netcode turns into a slideshow.
Rollback Netcode
Rollback netcode takes the opposite bet. Instead of waiting, it assumes the other player will keep doing what they were doing and shows your inputs instantly. When the real inputs arrive and turn out different from the guess, the game quietly rewinds to the moment of disagreement, replays the correct version in a single frame, and snaps to the right state. Done well, this feels nearly as responsive as offline play. The visible cost is the occasional teleport when a guess was wrong, but most players prefer a tiny visual stutter over constant input delay. Rollback has become the gold standard for fighting games, and its arrival in a beloved older title is often bigger news than any balance patch.
Client Prediction and Server Reconciliation
Shooters and other fast client-server games use a related trick called client-side prediction. When you press forward, your client moves you immediately without waiting for the server to confirm. It predicts what the server will decide, because most of the time the prediction is correct. You walk in a straight line, the server agrees, and nobody notices anything happened behind the scenes.
When the prediction is wrong, server reconciliation steps in. Maybe an explosion knocked you sideways on the server, or another player blocked your path. The server sends back the authoritative position, your client notices the mismatch, and it corrects. If the correction is small, you never see it. If it is large, you get the dreaded rubber-band effect, where your character snaps backward to where the server thinks you really are. That rubber band is not a bug. It is the system honestly admitting that your client guessed wrong and the server had the final say.
The same hidden-machinery mindset runs through the history of game design generally. Old hardware forced developers into similar tricks just to make a game run at all, the kind of constraint-driven cleverness behind how cartridge saves squeezed memory out of tiny batteries. Netcode is that same hacker spirit applied to the network instead of the chip.
Lag Compensation and Rewinding Time
Here is where netcode gets genuinely strange. Imagine you see an enemy standing still and you shoot them dead center. On your screen, it is a clean hit. But because of your latency, by the time your shot reaches the server, that enemy has already moved. Without help, the server would say you missed, because on the server the target was no longer there.
Lag compensation fixes this by rewinding. The server keeps a short history of where everyone was during the last fraction of a second. When your shot arrives, the server checks your latency, rewinds the world to the moment you actually fired on your screen, and judges the hit against that older snapshot. If the target was in your crosshair back then, it counts.
This is brilliant and infuriating at the same time. It rewards the shooter, which feels fair when you are aiming, but it produces the classic “I died behind a wall” complaint. From your perspective you reached cover safely. From the shooter’s perspective, and the server’s rewound version, you were still exposed when their bullet left the barrel. Both players are technically right, which is the whole tragedy of online play in one moment. Lag compensation simply chooses to favor the person pulling the trigger.
Why Netcode Feels Bad Even on Fast Internet
People blame their internet speed for netcode problems, but bandwidth is rarely the issue. A multiplayer game sends tiny packets of position and input data, far less than streaming a video. What matters is latency, packet loss, and jitter. Latency is the delay, packet loss is when data vanishes entirely, and jitter is when latency keeps changing, so the game cannot predict consistently. A gigabit connection with high jitter feels worse than a modest connection that stays steady.
Distance also matters more than people expect. Physics sets a hard floor on how fast a signal crosses an ocean, so playing on a far-away server adds latency that no upgrade can erase. This is why server location and matchmaking region affect feel so much. Two players in the same country on the same server can have a great match, while the same players routed to a distant data center feel like they are fighting underwater.
Then there is the simple fact that netcode is a series of educated guesses. Every prediction, every rewind, every interpolation is the game making a reasonable assumption and hoping reality agrees. Most of the time it does. The moments it does not are the ones you remember, because they are jarring by design. The system only becomes visible when it fails, which means we tend to notice netcode exactly when it is working its hardest.
None of this is unique to one genre. The same disagreements over fairness and feel show up everywhere players compete, from the frame-perfect tricks documented across speedrunning categories and glitches to the design language that defines whole genres, like the precise rules that make a soulslike feel like a soulslike. Multiplayer just adds the extra wrinkle of doing it all across a wire while a server referees.
Frequently Asked Questions
Is netcode the same as ping?
No. Ping, or latency, is the measured delay between your machine and the server. Netcode is the set of techniques a game uses to deal with that delay. Two games can have identical ping and feel completely different depending on how good their netcode is.
Why is rollback netcode considered better for fighting games?
Rollback shows your inputs instantly and corrects in the background, so the game stays responsive even on imperfect connections. Delay-based netcode keeps everyone in sync by waiting, which feels heavier and stutters badly when packets are late. Fighting games depend on frame-perfect timing, so the responsiveness of rollback wins.
Can good netcode fix a bad internet connection?
It can hide a lot, but not everything. Netcode masks latency through prediction and lag compensation, yet packet loss and high jitter give it bad data to work with. If your connection is unstable, even excellent netcode will produce visible corrections and rubber-banding.
Why do I keep dying behind walls?
That is lag compensation favoring the shooter. The server rewinds time to when the attacker fired on their screen, and at that moment you were still exposed, even though you reached cover on your own screen. Both views are valid, and the system chose the shooter’s.
Does a higher tick rate always mean better gameplay?
Higher tick rates improve hit registration and responsiveness, but they cost more server power and do not fix latency or packet loss. A high tick rate paired with poor lag compensation can still feel worse than a lower tick rate built on solid netcode fundamentals.
Conclusion
Netcode is the invisible referee of online play, juggling prediction, rewinding, and authority to make distant players share one world. When it works, multiplayer feels effortless and you never think about it. When it fails, you get rubber-banding, phantom deaths, and arguments that never end. The next time you die behind a wall, you will at least know exactly which clever trick just betrayed you. For more on the engineering behind the games we love, browse the rest of the indie classics and design deep dives on the blog.
🐾 Visit the Pudgy Cat Shop for prints and cat-approved goodies, or find our illustrated books on Amazon.
Leave a Reply