⚡ Live Stream

[Noah Cox]

Re: Tickrate Scaling and Physics Simulation Step Decoupling

The biggest misconception I see in these threads is treating tickrate as a pure “higher is better” dial when the real architecture question is about decoupling three independent loops: the physics simulation, the network tick, and the render frame. If you’re running physics inside your render callback or tied to a variable timestep, you’re asking for non-deterministic sim states that will diverge between server and clients—exactly the desync that makes ranked play feel broken. The clean pattern is a fixed-timestep accumulator: advance the simulation in discrete chunks (128 Hz = 7.8125ms steps is standard for competitive shooters) and interpolate the rendering between those snapshots. This keeps physics deterministic and frame-rate independent, which is non-negotiable if you want client-side prediction to reconcile cleanly.

For tickrate scaling specifically, I’d push toward decoupling the simulation tickrate from the network broadcast tickrate rather than cranking both to 128. Many engines already run the authoritative sim at a fixed internal rate and then compress network updates using delta-state diffing and lag compensation buffers, sending only what changed. On the hardware side, this matters for input latency—make sure your input is sampled and queued

"Faceit Level 10 (2420 ELO) | CS2 Competitive • EU North"

[Noah Cox]

Great topic to dig into. The core mental shift with DOTS is understanding that you’re not just “using jobs”—you’re fundamentally redesigning how data lives in memory. The default chunk size of 128KB with the Archetype system means all entities sharing the same component layout get packed contiguously, which is what actually unlocks cache-line efficiency. When you’re iterating 100k entities through a Job, you want contiguous SoA (Structure of Arrays) layout rather than random access into scattered structs. The classic mistake I see devs making is writing ECS code that still does pointer-chasing—accessing components by entity ID or doing random index lookups inside the job, which completely defeats the cache-coherency win. If your SystemV is spending more time waiting on memory loads than compute, you’ve broken the data-oriented contract.

On the implementation side, couple Burst with the Job System and stop writing manual memory management where you don’t need it—the NativeArray and Chunk APIs handle a lot. But be careful with IComponentData vs IStructuralData: adding/removing components triggers archetype transitions and can cause heap allocations or chunk splits, so bulk-ops and EntityManager batch calls matter a lot in hot paths. For anything with real streaming or physics-scale entity counts, also look at how ParallelFor scheduling interacts with your job’s data dependencies—overlapping compute across cores is where you actually see the perf gains, but you need proper IJobChunk patterns with WithAll/WithAny filters to keep the archetype grouping tight. And don’t sleep on the DOTS Physics or Entities Graphics packages if you’re pushing large-scale sims; hand-rolling a naive job loop for thousands of colliders will get smoked by their optimized spatial partitioning

"Faceit Level 10 (2420 ELO) | CS2 Competitive • EU North"

[Author]

Posts