Update, 26–27 October 2026. The model below is an archived study. The newer campaign compares sixteen pairs of runs with a feature active or unused, across Ironworks and Highlands. Differences between those encounters cannot be added together to predict a supported player count. Compare the newer measurements.
Giving four players bows is a different network workload from giving everyone a bow. The number of people watching those actions matters too, because the server has to send them information. I wanted the match planner to account for that, so I started with a deliberately limited experiment on Ironworks.
The study used fixed runner, archer and shadow-runner classes, with 8–12 players, 0–4 bow holders and 0–4 shadow holders. Each primary run allowed 15 seconds to warm up, then measured 60 seconds of activity. The actions followed a declared schedule. The result would be an estimate for those conditions, not a price that could be attached to a bow in every match.
Learning from the runs the model missed
The first campaign contained 33 runs. In two of its six final evaluation runs, the model underestimated the server's outgoing traffic, by as much as 4,104 bytes per second. Its estimates passed for the other three resources: server receive, the busiest client's receive traffic and the busiest client's send traffic. That still left the complete model failing its check.
I added a term for directed player pairs: N × (N − 1), where N is the player count. It counts each player's possible relationship with every other player, capturing a part of the workload that grows as both the population and its audience grow.
Before collecting more data, I declared nine new runs. The previous final samples became development data; I no longer treated them as an independent test. Six of the new runs used configurations and random seeds the model had not seen, giving the revision a fresh evaluation.
The revised estimates, including their allowance for observed variation, covered all six fresh runs across all four traffic resources. The game's native evaluator reproduced the exported model for all 14 measured configurations. Together, the two completed campaigns contained 42 clean runs, with no retries or detected interference from builds running during measurement.
Why one extra archer costs more in a larger match
Within this scheduled workload, the fitted increase in server outgoing traffic for one additional active bow holder was approximately 1,086.29 × player count bytes per second. That works out to 8.69 kB/s with eight players, and 13.04 kB/s with twelve. The same extra archer has more viewers in the larger match.
The corresponding fitted contribution for one additional active shadow holder was 183.67 + 112.54 × player count bytes per second. Both formulas describe the tested class behavior and action schedule. They do not isolate a universal causal cost of possessing or using either weapon.
The website's archived cost lab stays within the measured bounds and labels estimates between measured configurations as interpolation. I do not extend this fit to 64 players, or use it to invent costs for rail, stars, shrapnel, melee, nets or chi-jumps. Processor time, memory, traffic bursts and unmeasured equipment remain unresolved. A host can use the study to inspect this particular loadout tradeoff; it cannot establish that a whole server is ready for a given player count.