Two papers presented at GDC 2001 still explain most of what goes wrong in multiplayer games twenty-five years later. Yahn W. Bernier, then a developer at Valve, published Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization, describing how Half-Life hid network delay behind prediction and server-side lag compensation. Paul Bettner and Mark Terrano, then at Ensemble Studios, published 1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond, describing how a real-time strategy game kept thousands of units synchronized over a dial-up modem, and what happened when it did not.

Between them, those two papers describe two entirely different failure modes. Players and developers now call both of them by the same word: desync.

Knowing which one you have is most of the work, because the fixes do not overlap.

What Is Desync in a Multiplayer Game?

Desync, short for desynchronization, is when two machines in the same session disagree about the state of the game world. Your client believes you are standing behind a wall. The server believes you are still in the doorway. Both are internally consistent. Only one of them is authoritative.

The symptoms are familiar to anyone who plays online. Shots that pass through a player who was clearly in the crosshair. Damage taken a full second after reaching cover. A character that slides back three meters for no visible reason. A door that opens, closes, and opens again. In turn-based and simulation games, the symptom is blunter: the game stops and tells you a desync has occurred.

Those look like different bugs. Underneath, they are the same class of problem showing up in two very different network architectures.

Desync vs Lag: What Is the Difference?

Lag is a timing problem. Information arrives late, but everyone eventually agrees on what happened. A 200ms ping game that never desyncs is sluggish and perfectly consistent.

Desync is a correctness problem. Machines have arrived at different answers, and without intervention they will keep diverging.

Lag is slow. Desync is wrong.

The two are related, because latency is one of the conditions that makes divergence more likely, but they are not interchangeable. You can desync at 20ms ping because of a floating-point bug, and you can play at 150ms ping with no desync at all.

Replication Desync: When the Server Overrules the Client

Most action games, shooters and battle royales use an authoritative server. The server owns the real game state, clients send inputs, and the server sends back the truth.

Waiting for a round trip before your character moves feels terrible. That approach is what SnapNet's documentation calls input delay, where clients "send their inputs to the server and then, when they receive the simulation results from the server, they show those results to the player." It is simple and it never mispredicts. It also ties your game's responsiveness directly to every player's ping.

So most fast-paced games predict instead. As Gabriel Gambetta describes it in his Fast-Paced Multiplayer series, "we can send the inputs to the server and immediately process them on the client, that is, we predict what the game state will be after the server has processed the inputs."

When the guess matches what the server later confirms, the player sees nothing at all. Prediction is invisible when it works.

When the guess does not match, the server's version wins, and the client has to be dragged into agreement. That is replication desync, and the player sees it as a correction.

Bernier's paper covers the other half of the same trade. Because every client renders a slightly delayed view of the world, the server rewinds its own history to evaluate a shot against what the shooter actually saw. That technique is what makes hit registration feel fair to the person pulling the trigger. It is also why the person being shot sometimes dies after they believe they reached cover. The disagreement there is not a malfunction. It is a deliberate choice about whose view to honor.

Why Does Rubberbanding Happen?

Rubberbanding is the visible form of a misprediction being corrected. Gambetta's description of the raw behavior is exact: the character "moved two squares to the right, stood there for 50 ms, jumped one square to the left, stood there for 100 ms, and jumped one square to the right."

SnapNet's core concepts documentation puts the tradeoff plainly: "visual artifacts and glitches can arise when the client mispredicts simulation results," and they commonly "manifest as objects teleporting or spontaneously appearing/disappearing."

Which means rubberbanding is never the root problem. It is the output of two inputs multiplied together: how often the client guesses wrong, and how badly each wrong guess shows on screen. Latency, jitter and packet loss drive the first. Netcode drives the second. Both are real levers, and a team that only knows about one of them will spend months on the wrong work.

Lever One: Cut the Latency

Prediction error scales with round-trip time. Every millisecond between a client and its server is another frame the client advances on its own, with no confirmation, on nothing but its own guess.

At a 60 Hz simulation rate, a client 30ms from its server runs about two frames ahead of the truth. At 180ms it runs about eleven. Same code, same engine, same player. Five times the exposure.

That ratio is why a game with mediocre netcode can feel acceptable at 50ms and fall apart at 150ms. The corrections were always happening. At close range they were small enough that interpolation absorbed them before anyone noticed. Stretch the gap and the same corrections become visible snaps. Packet loss and jitter compound it, since a lost input packet means the server advances without the player's action entirely.

So the cheapest fix available to most studios involves no code at all. Put the server closer. Deploying into 615+ locations rather than a handful of large regions is what produces an average 58% latency reduction and sub-50ms connections for 78% of the playerbase. A team that halves its median round trip has roughly halved the size of the problem its netcode has to solve, without shipping a patch. The full argument for that approach is in For True Latency Reduction, the Only Answer Is More Locations.

Why Raising Tick Rate Is the Wrong Infrastructure Lever

Studios reaching for an infrastructure fix usually reach for tick rate first. It is the wrong one.

Tick rate determines how often the server resolves and broadcasts the world. Raising it gives you finer temporal resolution, which genuinely matters for hit registration precision. It does nothing for prediction accuracy, because accuracy depends on your simulation code and on which inputs reached the server, not on how often the server talks.

What it does reliably is increase message volume. A player rubberbanding because their connection drops packets now receives twice as many packets to drop. The corrections arrive more often and the artifacts get worse.

Tick rate is a precision and cost decision, which we broke down in Game Server Tick Rate Explained. Latency is the infrastructure lever that moves desync. Tick rate is not.

Lever Two: Fix the Netcode

Lower latency shrinks the problem. It never removes it, because even at 20ms the client is still guessing, and a game that ships without prediction feels laggy on a LAN. Four mechanisms do the rest of the work.

Client-side prediction runs the simulation locally the instant the player presses a key, so input feels immediate regardless of ping. Everything else is built on top of it.

Rollback handles the moment the server's authoritative state arrives and disagrees. Rather than snapping to the new state and discarding everything since, the client rewinds to the last confirmed frame.

Resimulation replays the intervening frames from that confirmed state forward, applying the inputs the player has made in the meantime. SnapNet describes the sequence as "rolling back the client's simulation to the results from frame 1, resimulating frames 2 and 3, and then finally simulating the new frame." Done well, most corrections resolve without the player seeing anything, because the replayed result lands close to where they already were.

Presentation smoothing handles what survives that. Keeping cosmetic code separate from simulation code means a corrected position can be interpolated visually across a few frames instead of teleporting. SnapNet's split between simulation and presentation exists for this: gameplay code may run several times per rendered frame, while "any logic that is cosmetic only and does not affect the simulation can still be run only once per frame."

There is a fifth consideration that explains why some corrections land harder than others. An input does not stay equally authoritative forever. From the moment a player presses a key, the precision of that input decays as it crosses the network and as the player keeps issuing new ones on top of it. A shot fired 20ms ago is a strong claim about the world. The same shot, still unconfirmed 200ms later while the player has already strafed, turned and fired twice more, is a much weaker one. Reconciliation that treats both with equal confidence will either over-correct recent inputs or stubbornly defend stale ones.

All of this costs CPU. Reconciliation, as SnapNet notes, "incurs a heavy CPU cost," since a single rendered frame may require rewinding and replaying several simulation frames. For teams weighing input delay against rollback before committing, we compared the two directly in How to Mitigate Latency in Multiplayer Games: Input Delay vs Rollback.

Neither lever substitutes for the other. Good netcode at 200ms still produces visible corrections. Perfect routing behind a game with no prediction still feels unresponsive. Studios that ship smooth multiplayer pull both.

Determinism Desync: Why "A Desync Has Occurred"

The second family works nothing like the first, and it accounts for the loudest complaints on the internet right now.

Strategy games, 4X titles, grand strategy sims, sports titles and a lot of co-op games do not stream world state at all. They use lockstep. Every machine runs the same simulation, and the only thing sent over the wire is player input. Bettner and Terrano used this to move 1,500 units across a 28.8k modem, which streaming positional data could never have done.

The catch is absolute. Every machine must compute bit-identical results, forever. To verify that, lockstep games checksum their state on a schedule and compare. A mismatch cannot be repaired by asking for a resend, because there is no authoritative copy to resend. So the game stops and reports the error.

That is what "a desync has occurred" means. A checksum comparison failed.

Bettner and Terrano documented how fragile that is. "A deer slightly out of alignment when the random map was created would forage slightly differently," they wrote, "and minutes later a villager would path a tiny bit off, or miss with his spear and take home no meat." The core difficulty, in their words: "very subtle differences would multiply over time."

Their team checksummed aggressively and still lost ground. "As much as we check-summed the world, the objects, the pathfinding, targeting and every other system, it seemed that there was always one more thing that slipped just under the radar."

The usual culprits have not changed since 2001. Floating-point math that rounds differently across CPU architectures, compilers or platforms. Random number generators consumed a different number of times on different machines, a problem the authors called out directly, noting that "programmers were not used to having to write code that used the same number of calls to random within the simulation." Uninitialized memory. Container iteration order. Mod or patch version mismatches between players, which is why modded grand strategy sessions desync so reliably.

Neither lever from the previous sections applies here. Cutting latency does nothing, because nothing was lost in transit. Better prediction does nothing, because there is nothing to predict. The two machines did different math, and a session at 15ms ping breaks exactly as readily as one at 150ms. If your game reports desync as a hard error rather than a stutter, the fix is in the simulation and nowhere else.

Does a Dedicated Server Eliminate Desync?

Yes, and for a more fundamental reason than most teams expect.

The obvious part is recovery. When a client's state drifts from the truth, an authoritative server can stop sending deltas, which is the usual efficient approach of transmitting only what changed since the last tick, and instead push the full state with instructions to treat it as canonical. The client's divergent copy is simply overwritten. That costs bandwidth, which is exactly why you send deltas the rest of the time, but it turns an unrecoverable session into a momentary hitch.

The less obvious part is architectural. Lockstep desyncs are unrecoverable precisely because no machine has the standing to overrule the others. Put a dedicated authoritative server in the middle and that condition disappears. There is a source of truth by construction, so the failure mode that ends a Civilization session cannot arise in the same way.

Peer-to-peer and host-migration architectures give up both properties. Every client becomes a potential source of truth, the host's machine performance becomes everyone's problem, and a migration mid-match hands authority to a machine that may be in worse shape than the one that left. We broke down the tradeoffs between these models in Authoritative Servers, Relays, Peer-to-Peer.

A dedicated server does not make prediction unnecessary, and it does not shorten the distance to your players on its own. What it gives you is a state you own, can instrument, and can forcibly correct.

One Clarification: "Desync" Also Means an Exploit

The word carries a third meaning that is worth knowing before you triage a pile of player reports.

In competitive shooter communities it is usually shorthand for lag compensation artifacts. Rainbow Six Siege is the standing example, where analysis of the game's netcode found low ping players losing exchanges to high ping players even from cover, along with mismatches in which direction an opponent was actually facing. That is replication desync, described by players in their own vocabulary.

Elsewhere it means a deliberate cheat. In October 2025, the Roblox developer loleris reported a "desync" exploit spreading across games on the official Developer Forum, in which an exploiter's position updates still reached the server but stopped replicating to other clients. The result, as the thread put it, is that "the server sees you as in the ring, but all other clients see you as somewhere far away," which makes the player effectively invisible and unhittable. Roblox staff confirmed they could reproduce it and shipped a fix.

Same word, opposite intent. A thread complaining about desync may be describing your netcode, or someone abusing it.

—

This article draws on and cites Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization by Yahn W. Bernier (GDC 2001), 1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond by Paul Bettner and Mark Terrano (GDC 2001, published on Game Developer), the Fast-Paced Multiplayer series by Gabriel Gambetta, and SnapNet's core concepts documentation by High Horse Entertainment. All rights in the original content are owned by their respective owners.