Update, 26–27 October 2026. The later capacity study keeps the game's configured limit at 64. Three clean Highlands free-for-all runs with 128 research clients established a result for those local-network conditions. Dense tests at higher counts did not establish a larger general limit. Read the new capacity results.

I could connect 80 clients, but that did not settle whether the game should offer an 80-player setting. The more useful question was how long those clients waited to hear the results of their actions. The physical-machine tests showed a clear difference between completing a run and keeping those delays under control.

A native Windows server ran the authoritative simulation, with a separate Linux machine generating the clients. In the 64-client baseline, the highest client p99 for action results was 33.023 ms. P99 is the 99th percentile: for that client, 99% of measured actions received a result within that time, while the slowest 1% could take longer. The report calls this weapon-disposition time. It is measured by automated test clients, not from a person's physical mouse click to an image on a monitor.

At 80 clients with mixed equipment, the run completed but the worst client's action-result p99 rose to 71.609 ms. Another measure, raw scene-age p99, reached 211.967 ms. Scene age estimates how old the delivered world state is; it answers a different question from how quickly a shot receives a result. Both made the larger run less convincing as a basis for a supported setting.

Trying a different equipment mix

I then assigned 40 clients melee and shadow grenades, and 40 bows and shrapnel. The equipment stayed assigned correctly and the intended holders were present. Scene-age p99 improved to 157.695 ms, but the worst client's action-result p99 worsened again, to 88.424 ms.

That did not identify a single weapon as the cause. Changing equipment also changes which actions occur, how many viewers need their results and when the server does the work. The fresher scene updates did not erase the longer waits for action results, and the comparison could not isolate a weapon's individual cost.

Applying one limit throughout the game

I set the product limit to 64 total players, including bots, in Play, the match planner, server startup and player admission. Ordinary saved settings above the limit are reduced to 64. Imported class scenarios are rejected if they exceed it: silently changing their class quotas would change the scenario the author supplied.

Boundary checks and a short native interface test cover that policy. Choosing a larger map does not raise the limit. Nor does finding an archived stress test with more clients.

These results came from a development build on a private local network. Broader combinations at lower player counts and Internet qualification were deferred. The limit can be revisited with stronger evidence, but the recorded 80-client runs did not justify changing it. The netcode evidence retains both the 64-client baseline and those follow-ups.

A plan you can inspect

A retained native match-builder image shows the map, equipment and population settings together. Its archive date identifies the retained image file; the article explains the scope of the host testing.

SHADOWFRAG match builder with map, objective, equipment policy and a limit of 64 players including bots.
Match builder

The match builder exposes the rules and the current limit of 64 total players, including bots, in one place.

Original PNG

Still-image archive dates come from retained image file timestamps in Los Angeles time. An earlier-dated article may include later builds; each image is dated separately. Images are genuine engine or native-editor output. Download sources, transforms and SHA-256 hashes.

Back to blogBrowse the glossary