When only “go here” is exchanged and each side computes the path itself, even a small difference in the calculation sends a character or monster down a different path until it gets pulled back into place.
Why With click-to-move and monster chasing, only the destination is sent and the client computes the path on its own → Effect Differences in terrain data, collisions with other characters, or calculation order make it move along a different path from the server’s → On screen Monsters walk through walls and then snap to another spot, clicked characters change direction as if sliding
Primary owner Game team (Server development) · Also Game team (Client development)
Game team action items
Server: send the path’s intermediate points (waypoints) as well, sync positions periodically. Client: converge smoothly when positions diverge, use the same terrain data as the server.
On the graph
Random spikes · Position correction count and distance per entity
Where to look
Per entity, the difference between the position the server sent and the position the client computed, with the coordinates of corrections plotted on the map. Periodically comparing checksums of both sides’ path results or positions pinpoints when they started to diverge
Confirmed if
Corrections cluster at specific terrain (ledges, narrow passages, slopes) or crowded spots and repeat at the same place even for players with normal network metrics
Ruled out if
Corrections happen only when loss or jitter spikes, regardless of place: connection problem. A single monster jumping on several players’ screens at once: check whether a slow client has control of the monster
Check with
Game server or client logs and metrics
Learn more
This approach is one reason click-to-move and tab-target games are less sensitive to ping. The trade-off is that nothing guarantees both sides get the same result, so a mechanism that syncs positions now and then is essential. Floating-point results can differ slightly depending on CPU type, compiler, and optimization settings (including debug versus release builds). In designs that exchange only inputs and assume both sides compute identical results, such as lockstep and rollback, these tiny differences can accumulate until the game state on the two screens splits apart (desync).
Sources
Deterministic LockstepGaffer On Games Even if deterministic on the same machine, floating-point results can differ across compilers, OSes, and CPUs
State SynchronizationGaffer On Games Sending state along with inputs keeps both sides in sync without perfect determinism
Peeking into VALORANT's NetcodeRiot Games Packet loss, or two characters trying to move to the same spot, makes server and client simulations diverge and need correction
Floating Point DeterminismGaffer On Games The same floating-point code can give different results depending on compiler, CPU architecture, and debug or release build; includes a case where AMD and Intel CPUs returned slightly different values from transcendental functions
/fp (Specify floating-point behavior)Microsoft /fp:fast may reorder or combine floating-point operations and give results different from other /fp settings, and operations fused with FMA can also differ from a separate multiply and add