Update, 26–27 October 2026. The follow-up makes PicoQUIC the default transport with CUBIC managing congestion, stores state in growing pages of memory, waits for network work to become ready, and separates recovery rules for different message lifetimes. The latest capacity campaign also fixes an input grant tied to an outdated generation. The measurements below belong to the earlier Quiche investigation. Read the subsequent networking work and current tests.
A server can finish a simulation tick—one step of the game—quickly while clients still see an older version of the fight. Tests with 64 players using stars heavily brought that difference into focus. The server's own processing time did not tell me whether fresh information had reached a player.
Stars produce frequent records about their projectiles. Those records need to remain available until the receiver acknowledges them. Movement updates have a different need: they become stale quickly and have a freshness deadline. If the delivery path gets busy, a client can keep receiving packets without assembling and accepting a fresh, complete scene.
Following the record all the way to the client
I separated the stages in the investigation. First the authoritative simulation hands a record to the input/output worker. The transport must then accept it, its frame parts must reach the client, and the client must assemble and accept the scene. Success at an early stage does not show that the later stages completed.
Controlled tests reproduced retries catching up with original records that were still queued. They also showed records awaiting reliable delivery delaying fresh movement frames. Those tests established mechanisms to investigate, without proving that one counter or weapon explained the entire live problem.
Limiting how much work happens at once
The accepted changes stage at most 256 records and handle delivery in four fair rounds before returning to the transport. An index lets receipt retries find active, unacknowledged records without searching inactive history. I also removed unnecessary sizing work when preparing the world update for a client.
An alternative used eight rounds and 512 staged records. I rejected it after its matched run showed worse waits at the slow end of weapon feedback. A larger batch was not automatically a better one.
A separate investigation into the native network adapter found that an old cached wake-up time could delay a packet already ready to send. The corrected adapter repeatedly passed fixed-clock tests that the original failed. That was a useful regression check, but the LAN campaigns used Quiche, not PicoQUIC. They therefore did not measure a PicoQUIC LAN speedup from the adapter fix.
Keeping the results that went both ways
Five further paired comparisons ran the original and revised builds under recorded desktop load. Changes in the worst client's weapon feedback went in both directions. I kept those results because a better result in one run, or an improved median, would otherwise hide clients whose longer waits had worsened.
These were short observations on a local network, with machine activity recorded. They did not qualify Internet play, long sessions or a higher population. The game remained capped at 64 players including bots. The netcode page explains the delivery architecture and retains the dated studies so the improvement and its limits can be inspected together.