Your multiplayer game is not leaking bandwidth. The costs you are seeing are the correct costs for what your engine is doing. Understanding why they are high is the first step to changing them.
Bandwidth is a hard limit, not a performance metric
Most game performance problems have a fix: optimize the shader, cull the draw calls, pool the allocations. Bandwidth works differently. It is not a variable that responds to an optimization pass. It is a hard constraint on what you can simulate and what your business model can support. Every networked entity, every additional player, every physics object consumes a fixed slice of your budget. When you hit the ceiling, you cannot add complexity without a larger bill, a smaller player count, or both.
What you are paying for
A 3D transform is position, rotation, and scale: nine floats at four bytes each. Uncompressed, that is 36 bytes per entity per update.
Very few developers ships a game with that, nor any networking framework or engine. Every serious multiplayer system applies compression before data touches the wire. Bit packing reduces float precision to what the game truely requires. Delta compression sends only what changed since the last tick. Quantization represents values in fewer bits. Batching amortizes header costs across multiple updates. These are well-understood techniques, and Photon Fusion, Netcode for GameObjects, Mirror, and Coherence all implement some version of them.
After compression, a 3D transform update costs roughly between 12 and 20 bytes. Game structure can allow this to be optimized further, but that requires more time and effort that is not going into the core game. Many developers just stick with the baseline.
If you are using a standard multiplayer engine or framework and wondering why your bandwidth bill is high, you are most likely not misconfigured. You are paying the industry baseline, and the industry baseline is expensive at scale.
How player count multiplies the cost
Bandwidth scales with three variables: players, tick rate, and the number of entities each player needs to track. Those variables multiply each other.
For a dedicated server model, take 50 players in a zone at 20 Hz. Each player receives position updates for the other 49 players. At 20 bytes per transform, each player receives 49 * 20 bytes = 980 bytes per tick. At 20 Hz, that is 19,600 bytes per second. Across all 50 players, the server is sending roughly 960 KB per second for movement alone. Run that 24/7 and it adds up fast.
For client-hosted or peer-to-peer topologies, the situation is worse. Each client sends to every other client, so connections scale with n*(n-1). Four players require 12 update streams per tick. Eight players require 56: a 4.67x increase for a 2x increase in players. P2P does not eliminate bandwidth costs. It redistributes them to your players and imposes a hard ceiling on viable player counts.
The monthly math for a persistent online game
For a mid-scale game averaging 500 concurrent players, using the per-player estimate from our kazap.io analysis: a player slot at standard compression uses roughly 36 GB of egress per month. At 500 average CCU, that is 18 TB of outbound transfer per month.
On AWS, data transfer out from US East starts at $0.09/GB for the first 10 TB and $0.085/GB for the next 40 TB. The bandwidth bill for that workload is approximately $1,580 per month. Five game servers running 24/7 add another $600. Total: roughly $2,180 per month.
Compute costs are relatively stable. They scale with what your CPU is doing. Bandwidth costs scale directly with players times bytes per player per second times seconds per month. If your game doubles in size, the bandwidth line doubles. If your tick rate doubles, so does the bandwidth line. Compute does not behave the same way.
Going below the baseline
If 12-20 bytes per transform is what standard engines deliver, going lower means building custom data models. You write serialization code tuned to your specific game state. You test it against edge cases. You maintain it as the game evolves. Custom serialization is a category of bugs that is particularly hard to diagnose in production: the symptoms show up as desync, jitter, or visual corruption, and the root cause is bytes that do not mean what the deserializer expects.
For competitive games running at 60 Hz or higher, the baseline multiplies with tick rate. For persistent online worlds, the baseline accumulates with server uptime. In both cases, getting below the baseline matters enough that studios invest significant engineering time to do it. Most of that time is not glamorous: it is protocol debugging in production, edge case handling, and keeping serialization code in sync with a changing game.
What Reactor does differently
Reactor builds data models from the actual state of your game and optimizes automatically. The developer does not write serialization code. Reactor observes what is in the scene, what is changing, and what the range of values is, and generates the most efficient representation it can. That process is ongoing: the model updates as the game state changes.
Real results from games built on Reactor:
- Kazap.io: approximately 0.5 bytes per transform
- Braains2: under 1 byte per transform, running 100 players and 150 physics objects at 30 Hz, with the entire server using 35 kbps. The full case study is here.
- Ruins demo: frequently under 1 byte per transform despite active physics destruction throughout the session
In a controlled comparison against Photon Fusion 2 and Netcode for GameObjects, Reactor used 9.5 times less bandwidth on transform data. The full methodology and scene configuration are available on GitHub if you want to run it yourself.
Applied to the monthly cost example above: at 6x wire bandwidth reduction across a full game session (accounting for protocol overhead), the $1,580 AWS egress line drops to about $263. Compute stays the same. Total falls from $2,180 to $863 per month, or about $15,800 per year.
The question is not whether bandwidth is a problem at scale. It is. The question is whether you solve it with serialization engineering or with a different foundation.
Reactor is free to develop locally and free to self-host up to 32 CCU. Get started here.