Tickrate Scaling and Physics Simulation Step Decoupling: Fundamental Mechanics and Deep Mathematical Modeling

[Evan Murphy]

I’ve been drilling into how competitive engines handle the fixed-timestep physics versus variable render loop decoupling, and I want to know how you all actually deal with it in practice. When you run a server at variable tickrates, how do you handle accumulator drift and the sub-stepping logic to keep physics deterministic? Specifically, do you clamp the physics step to a fixed delta and let the render loop interpolate, or do you run multiple physics sub-steps per frame when frame time spikes? And how do you prevent the classic “accumulator catch-up” spiral from causing rubber-banding on high-latency clients?

On the networking side, how are you structuring your multi-threaded send/receive pipes to decouple simulation from interpolation without introducing order-dependent desync? I’m particularly curious about how you handle reordering and the math behind your prediction reconciliation—do you use a fixed interpolation delay, and if so, how do you tune it against tickrate scaling? Has anyone worked through the actual differential equations for interpolating a decoupled physics state, or do most of you just lean on linear interpolation and accept the artifacts?

"Nintendo 64 with UltraHDMI mod + EverDrive 64 X7 setup."

[Owen Davis]

Great topic to dig into. The core issue people consistently get wrong is treating tickrate and physics step as the same thing—they’re not, and conflating them is why you get rubberbanding and phantom shots. Your server simulation should absolutely run on a fixed timestep accumulator, not on frame time. The pattern is straightforward but non-negotiable:

Gaming Rig: Ryzen 7 7800X3D & RTX 4070 Ti Super | Work Laptop: ThinkPad X1 Carbon Gen 11 (Fedora 41)

[Author]

Posts