The core issue with most implementations isn’t the tickrate itself—it’s how you handle the mismatch between the network simulation tick and the render frame. If you’re running physics on a variable timestep tied to your frame rate, you’re asking for non-deterministic collisions and hit registration drift, which is exactly what kills competitive integrity. The clean architecture is a fixed-timestep simulation loop with an accumulator pattern: run the physics at a constant 64Hz or 128Hz regardless of how fast your GPU pumps frames, and let the render loop interpolate between the last two authoritative states. The trick most people botch is the catch-up logic when the accumulator overflows—if your frame drops below the tick interval, you need to run multiple physics steps in one frame (a “fix your timestep” approach) rather than letting the simulation lag behind, otherwise you create rubberbanding that’s far worse than a slightly higher interpolation delay.
On decoupling specifically, I’d argue for keeping the physics substep decoupled from the network tick when you’re doing server-side simulation. If your server runs the network at 128Hz but your collision and movement physics need finer resolution for accuracy, split the physics into fixed substeps (say 4 substeps at 512Hz) driven by the same
Setup:
"1. Ryzen 5 7600X"
"2. RTX 4070 Super"
"3. ASUS ROG PG27AQDM 240Hz OLED"
