Rubberbanding
Rubberbanding is the visible snap-back that happens when the server corrects a client's mispredicted position.
,
Desync is not lag
The two get used interchangeably and they are different failures.
Lag is delay: everything you see is correct, just late. Desync is disagreement: what you see is wrong, and acting on it produces outcomes that feel arbitrary. You shoot someone who is already gone, or you round a corner and die to a player you never saw.
This distinction matters because it changes what you fix. A player on 15 ms can desync badly from a determinism bug. A player on 120 ms can stay perfectly in sync with sound prediction and reconciliation. Chasing ping when the cause is code wastes a sprint.
In Practices - Insights from Edgegap's Blog
Article's key insights
Desync is a disagreement, not a delay: Lag means information arrives late. Desync means two machines hold different versions of the same world, which is a separate failure with separate fixes.
There are two distinct kinds: Replication desync, where an authoritative server corrects a client that guessed wrong, and determinism desync, where peer simulations diverge and the session stops outright.
Rubberbanding has two levers: How often the client mispredicts, which latency drives, and how visible each correction is, which netcode drives. Pull either one and players see less of it.
Tick rate is neither lever: Raising it does not make predictions more accurate, and on a connection already dropping packets it makes the artifacts worse.
"A desync has occurred" is a checksum failing: Lockstep games compare state hashes every turn, so one divergent float or one unsynchronized random call ends the session.
The four things that actually cause it
Unstable tick rate. The server updates match state a fixed number of times per second. When CPU contention causes that rate to drop or fluctuate, clients receive state less often and predict further ahead on staler information. Instability hurts more than a low-but-steady rate — a server that runs 60 Hz, then 44 Hz, then 60 Hz produces worse desync than one that holds 30 Hz consistently, because prediction cannot calibrate against a moving target.
Latency and jitter. High round-trip time means predictions run on older information. Variable round-trip time is worse: the client cannot settle on a correction rhythm, so it over- and under-shoots in turn.
Non-deterministic simulation. In lockstep architectures, every client runs the same simulation and trusts it to produce identical results. Floating-point differences between platforms, uninitialized values, or anything reading wall-clock time will diverge, and the divergence compounds silently until it is visible. This is the cause that low ping does not protect you from at all.
Clock misalignment. When server and client disagree about what time it is, every time-based calculation — ability cooldowns, projectile travel, buff duration — resolves differently on each side.
Why packet loss makes it worse, not just slower
A dropped state update is not a delayed state update. Under UDP the client does not wait for it; it continues predicting from the last state it has. Each lost packet extends the window in which the client is extrapolating unverified, and the correction when the next update lands is correspondingly larger and more visible. This is the mechanism behind most rubberband
What fixes it, in order of leverage
Layer | Fix | What it addresses |
|---|---|---|
Architecture | An authoritative server as the single source of truth | Removes the class of desync where two clients each believe they are right |
Client | Prediction with server reconciliation | Keeps input responsive while letting the server win every disagreement |
Client | Interpolation of remote entities | Smooths the visible motion of other players between updates |
Server | Lag compensation — rewinding to the shooter's view | Makes hit registration fair across different latencies |
Code | Deterministic simulation, fixed-point where needed | The only fix for lockstep divergence |
Infrastructure | Consistent tick rate, servers near players, headroom | Eliminates the infrastructure-side causes entirely |
A word from our sponsor (ourselves!)
Most lag comes from distance, not from code. Edgegap's Edge Cloud is a distributed network with up to 615+ locations available on demand, so each match runs at the best available location for its players. Independent replays of live studio traffic measured a 58% drop in average round-trip time compared with public cloud.
The order matters. Teams reliably spend time on the last row when their problem is in the fourth, or on the fourth when their problem is in the sixth. Instrument before you optimize: log server tick times and client correction magnitudes, and you will know within a day which layer you are actually in.
Edgegap's Take (just our opinion, take it with a grain of salt!)
Edgegap's Take
"Most studios we talk to arrive convinced they have a netcode problem, and roughly half of them have a capacity problem wearing a netcode costume. Servers packed too densely contend for CPU, tick rate becomes erratic under load, and prediction has nothing stable to calibrate against. The tell is that it only shows up at peak concurrency. Before you rewrite your prediction layer, plot your server tick times against your player count. If the two correlate, the fix is headroom, not code… and that is a much cheaper afternoon."
,
