Combat that feels the same at 150 ping as it does at 0.

The parry window here is 120 ms wide, which is roughly a tight-but-fair window in a melee game. Ping is treated as symmetric, so the client-to-server trip is half the number on the slider. Nothing else is simulated: no jitter, no packet loss, no tick quantisation. All three make the naive lane worse, not better.

What it demonstrates is one thing only: with a fixed window, the naive lane's judgement point drifts by ping / 2 while the rewind lane's does not. That is the whole argument, and it is the same argument the shipped system makes.

Per-instance. Each unit is a rigged model on the server with its own animator, humanoid-style movement, its own target search and its own replicated state, about 0.12 ms of server step time each once movement, animation state and replication bookkeeping are counted, plus an n² term for target searching without a spatial partition. Against a 16.6 ms frame that ceiling lands at ~130 units.

Headless ECS. No instances on the server at all: flat component arrays stepped by a handful of systems, target search through a grid, and state sent to clients as an event log rather than n property updates per frame. About 0.0025 ms per unit plus a fixed 0.8 ms per tick that doesn't grow with the army, so ~6,300 units in the same frame.

Bandwidth, which the chart doesn't show. A per-instance CFrame plus state costs 40–50 bytes per unit per replication tick, which passes a normal player's downstream budget somewhere between 50 and 100 units, usually before the CPU does. Delta-encoded batched state at 6–8 bytes per unit, with distant units aggregated, keeps thousands inside the same budget.

Where the numbers come from. These are calculated from known per-unit costs rather than recorded from a live test place, which is what the model tag means. The ratio is the claim: one approach has a ceiling in the low hundreds, the other doesn't hit one at the scales this game runs at.

Per-gate cost. Roughly 0.0025 ms to read a gate's inputs, evaluate it and write its output in Luau: a table lookup, a couple of comparisons and a store. Polling pays that for every gate on the board, 60 times a second, no matter what the circuit is doing: 15% of the frame at 1,000 gates, 60% at 4,000, past the whole frame at 8,000.

Changed fraction. On a clocked SAP-2 running a program, the gates whose inputs actually change on a given tick are the ones on the active path: a bus write, a register latch, a handful of decode lines. That's the ~0.6% figure used here. Idle circuits go to nearly zero; a deliberately pathological board with a clock wired into everything converges back toward the polling line, and that's the honest limit of the claim.

Frame budget. 16.6 ms per step at 60 Hz, and the chart shows tick cost as a share of it. Polling's share is set by how big your circuit is; event-driven's share is set by how much of it is doing anything. These are calculated from per-gate cost rather than recorded from a live test place, which is what the model tag means.