Source: https://shadowfrag.com/blog/measuring-the-price-of-a-bow/

# A weapon does not have one network price

By the SHADOWFRAG developer · Research · Oct 21, 2026 · 3 min read

My first model underestimated outgoing traffic in two final runs. I revised it to account for player-to-player traffic and checked it against new configurations.

[Jade Deck, captured in SHADOWFRAG's Vulkan renderer](https://shadowfrag.com/_astro/jade-deck.CiDi263J.png)

Actual engine render · Development build · 22 October 2026

**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](https://shadowfrag.com/glossary/#term-shogun-highlands). Differences between those encounters cannot be added together to predict a supported player count. [Compare the newer measurements](https://shadowfrag.com/netcode/#encounters).

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](https://shadowfrag.com/glossary/#term-data-rate-units)**. 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](https://shadowfrag.com/glossary/#term-seed) 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](https://shadowfrag.com/glossary/#term-data-rate-units)**. That works out to **8.69 [kB/s](https://shadowfrag.com/glossary/#term-data-rate-units) with eight players**, and **13.04 [kB/s](https://shadowfrag.com/glossary/#term-data-rate-units) 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](https://shadowfrag.com/glossary/#term-data-rate-units)**. 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](https://shadowfrag.com/netcode/#cost-archive) stays within the measured bounds and labels estimates between measured configurations as [interpolation](https://shadowfrag.com/glossary/#term-interpolation-model). I do not extend this fit to 64 players, or use it to invent costs for rail, stars, [shrapnel](https://shadowfrag.com/glossary/#term-shrapnel), [melee](https://shadowfrag.com/glossary/#term-melee), nets or [chi-jumps](https://shadowfrag.com/glossary/#term-chi-jump). [Processor time](https://shadowfrag.com/glossary/#term-cpu), memory, traffic bursts and unmeasured equipment remain unresolved. A host can use the study to inspect this particular [loadout](https://shadowfrag.com/glossary/#term-loadout) tradeoff; it cannot establish that a whole server is ready for a given player count.

[Back to blog](https://shadowfrag.com/blog/)[Browse the glossary](https://shadowfrag.com/glossary/)

## Request an _invite code._

SHADOWFRAG is opening by invitation. Request a code and receive development updates. [Shadow Council](https://shadowfrag.com/glossary/#term-shadow-council) contributors receive priority when invitations begin.

Enable JavaScript to request an invite code and confirm your email address.

Email confirmation required. Codes will be issued later; a request does not guarantee access. Unsubscribe at any time. [Privacy](https://shadowfrag.com/privacy/)

Confirm your email to join the invitation list. Codes will be issued in a future round; a request does not guarantee access. Unsubscribe at any time.

Anyone can request a code. For [Shadow Council](https://shadowfrag.com/shadow-council/) priority, introduce yourself on Discord with your role, experience, region and time zone. Include examples of your maps or content if you have them.

[Join Discord](https://discord.gg/EHj7rZDNj)