Update, 26–27 October 2026. The byte counts below belong to the 20–21 October compact-wire work. The build at this update uses wire protocol 37, the shared network message format, with PicoQUIC as the default transport implementation and CUBIC controlling how its sending rate responds to congestion. See the current implementation and dated archives.
Looking through the traffic, I kept finding information that did not need to be sent again. A suit does not change with every movement update. A bow action does not need all the fields used by a rail shot. An input field that contains its default value can often be represented more briefly.
I tackled those cases separately, with correctness checks for each. Fewer bytes would not help if losing a packet made the next message impossible to understand, or if a new player joining a reused slot changed the appearance of an arrow already in flight.
Sending appearance when it changes
I moved appearance into a reliably delivered roster, tied to the particular player occupying a slot, and locked the chosen look for the round. A new preference takes effect next round. Disconnecting ends that occupant identity, so someone joining the same slot is still a different person as far as existing events are concerned.
A score update can then leave out the name and appearance the viewer already has. A newly connected viewer still receives the complete starting information. Shots and projectiles also retain the appearance data they need after their owner leaves; an old arrow must not borrow the next occupant's look.
For input and combat messages, I used short indicators for fields at their exact default values and smaller records for each kind of action. Actions can share identity information from the message carrying them, but only after that enclosing message has been validated. A bow release or cancellation still refers to the draw it belongs to. Rail and melee actions still carry the view information needed to check the attack. Aim precision and timing deadlines stayed unchanged.
Measuring the bytes saved
The archived comparison used 32 clients on Ironworks: an original 20-second sample and three later samples of 20 seconds each, compared as traffic rates. The server's outgoing game-data payload, added across all clients, fell from about 4.249 MB/s to 2.842 MB/s, or 33.1%. This is the application's data; the extra bytes used to transport it are counted separately.
That reduction applies to this workload. It does not establish a matching reduction in processor use or latency, or a matching increase in player capacity. Compact encoding can itself take work to produce and decode. The later 64-player limit came from separate tests on physical machines.
The useful change was to send information at the point it was needed. Clients already have the models, trails and sounds, so server-confirmed events can tell them what happened without repeatedly sending the details of how it looks. The traffic breakdown preserves the categories and historical measurements behind the comparison.