Desync
Desync (short for desynchronisation) is when the game state on a player’s client diverges from the server’s authoritative state. The player sees one thing; the server knows something different. That divergence shows up as phantom hits, invisible players, characters teleporting, rubberbanding, or actions that look successful on-screen but fail on the server.
Common causes
- Tick rate inconsistency — If the server’s tick rate drops due to CPU contention, state updates arrive less often. Clients interpolate between stale data and accumulate drift.
- High or variable latency — Large or fluctuating ping means the client’s predictions are based on old information, increasing the chance of divergence.
- Determinism bugs — In lockstep architectures (common in RTS games), any floating-point rounding difference between client and server accumulates into visible desync over time.
- Clock drift — If the server and client clocks diverge, time-based calculations (movement speed, cooldowns, projectile travel) produce different results.
Infrastructure vs. game code
Desync has both infrastructure and code-level causes. Infrastructure-side desyncs come from inconsistent server performance (tick rate drops, CPU jitter from noisy neighbours) and network issues (packet loss, routing changes, DDoS). Code-level desyncs come from non-deterministic simulation, incorrect reconciliation, or floating-point inconsistencies.
How to reduce desync
You attack it from both sides:
- Server-side (code): keep the server authoritative, use client-side prediction with server reconciliation, and make the simulation deterministic where it must be (lockstep games).
- Network (code): apply lag compensation and interpolation so brief latency spikes don’t immediately diverge the view.
- Infrastructure: run a consistent, high tick rate on hardware that doesn’t sag under load, place servers close to players to cut latency, and use stable, well-peered networking. Reliable infrastructure eliminates the infrastructure-side causes entirely — the server sends updates at a predictable rate and clients receive them reliably, so the only desync left to chase is in your own code.
Frequently asked questions
What does desync mean? Desync (desynchronisation) means a player’s client and the game server no longer agree on the state of the game. The result is visible inconsistencies — phantom hits, teleporting players, or actions that succeed on screen but fail on the server.
What causes desync? Inconsistent server tick rate, high or fluctuating latency, non-deterministic simulation code, and clock drift between client and server. Causes split into infrastructure-side (server performance, networking) and code-side (simulation, reconciliation).
How do you fix desync? Keep the server authoritative with client-side prediction and reconciliation, apply lag compensation, and run consistent tick rates on stable, low-latency infrastructure. Fixing infrastructure-side causes leaves only code-side desync to debug.
Is desync the same as lag? No. Lag is delay between you and the server. Desync is disagreement about game state. Lag can cause desync, but a low-ping player can still desync from a determinism bug, and a high-ping player can stay in sync with good prediction and reconciliation.