You don't really ever stream games in normal situations in the same manner though. The content is mostly rendered client side, why does the server need so much bandwidth?
Let's assume these FPS games send 1mbps - 2mbps per-client (many send less, some send more) but it's a good range to start with.
Now increase the player count from 100 to 1000. The number of objects that needs to be sent from server to client also 10Xs, because you need to send state for each player visible to each client, so that client can actually see the other players moving around. The end result is bandwidth is now approximately 10X what it was before, or 10-20mbps.
To address your question around RTS and inputs. Game developers usually end up using state synchronization methods (sending the positions, rotations etc per-object) instead of relying on input based deterministic methods whatever player counts are high. My personal threshold is around 4 players.
This is the reason FPS games and other higher player count games usually send state instead of just inputs. Because if they were to rely on a deterministic simulation synchronized only by inputs like an RTS, the server would have to wait for input from the the most lagged player before it could step the server simulation forward, and with regular internet jitter, packet loss and so on, as the player count increases it becomes more and more likely that the game will hitch and stutter waiting for these inputs.
So the answer is, bandwidth sent per-client scales with the number of players in the game, and games with higher player counts tend to send state instead of just inputs for the reasons above.
cheers
Would also argue that RTS inputs are different from fps as in general you give commands to units, like go here in move/attack mode, and they do it for you. In fps your inputs control a character directly. So they can use different methods of conveying progress of state. And an fps game can use both methods, like doing deterministic physics for objects. Also don't need to wait for inputs just because its deterministic simulation?
I guess my confusion/frustration comes from this sort of default, "wow, that's a lot of bandwidth, umm I guess somewhere he must be doing something really inefficient" train of thought that I see so many commenters are going through in this thread.
What if it wasn't inefficient. What if what I'm describing is actually using the 10-20mbps and packing in an appropriate amount of game that justifies that amount of bandwidth on top of already doing all the smart compression techniques?
Think of it like this, what if you did all the compression and bandwidth optimization techniques available, and instead of targeting 1-2mbps, you just used the additional bandwidth to fit in more game? More players. Greater object density. A bigger world. More networked objects. Higher tick rate. There are any number of dimensions you can expand along.
Nobody is suggesting "LOL, bandwidth is free now, make the same game, but be lazy and have it take up 10-20mbps! hahah".
The industry doesn't take kindly to the same things over and over, players want novelty. So give it to them!
Good luck with your game though, great if it works, but seems like many large player count games cut corners to simplify things.
I never said anything about scaling numbers without optimization.
If a game is already optimized, and you scale up numbers, the game doesn't suddenly become unoptimized just because n or m increases.
You just have more stuff.
You can fit a lot of game in 2mbit/s with a little bit of work.
And you can fit exactly 10X the game in 20mbps with the same amount of work, plus some AF_XDP magic.
A 6v6 game of Forged Alliance (12 players each moving hundreds of units around, many with simulated projectile weapons) uses 0.3mbps.
Games don't need to send much data to sync game state across clients
Yes, because it's networked via deterministic lockstep and it sends only inputs.
Other games genres like FPS use a different network model and send object state. This means their bandwidth is proportional to how many objects there are in the world (or how many objects are relevant to each player).
I understand that those are big budget games, but there is a lot of room for improvement in 10000 kbps.
OK I'll bite.
Quake 3: Arena supports 32 players. What if it supported 1000 players?
1000/32 = 31.25
theoretical quake 3 but with 1000 players (all visible) would be:
31.25 x 120 kilobits per-second = 3,750 kilobits per-second = 3.75 mbps sent per-client.
now make quake 3 more interesting by putting in 1000 NPCs in to interact with, so 2000 total objects -> double the bandwidth to 7.5 mbps per-client.
fill the rest of the bandwidth with weapon data (one shots), sounds, fx and other random events -> 10mbps is pretty easy to hit, maybe even go over, especially if a lot of stuff is going on in the level.
> Fortnite peaks at ~400 kbps during the initial 100-player drop and goes down from there.
Fortnite has 100 players.
Theoretically, if it supported 1000 players, then you would multiply bandwidth by 10 if all other players were visible, or if you had the 1000 players in the same size world, so on average you would see 10X more players than before with relevancy / culling by distance or LoS.
400 kbps x 10 -> 4000 kbps -> 4 mbps sent per-client.
Now make it more fun and add 1000 NPC characters to the level, 2000 characters per-level total.
8 mbps per-client for theoretical, 1000 player Fortnite w. 1000 NPC characters in the level.
> I understand that those are big budget games, but there is a lot of room for improvement in 10000 kbps.
This is simply not true. It would be really great if you guys would do some light math before making statements like this.
Streaming sounds and FX every single time and never caching is a choice that will lead to 10Mbps, but completely unnecessary. All you "really need" is initial state, the timestamps / inputs of the other players, and reproducible physics.
Do you expect bandwidth sent per-player will:
a) stay the same b) decrease c) increase
?
> Streaming sounds and FX every single time and never caching is a choice that will lead to 10Mbps
Nobody is suggesting streaming sounds and FX like this.
If it helps you, completely ignore my comment about sounds and FX. Focus instead on how the per-player bandwidth has scaled up, eerily close to 10mbps per-client, when you take any of the classic games you mentioned, and scale their player count up to 1000 players and see what happens.
> All you "really need" is initial state, the timestamps / inputs of the other players, and reproducible physics.
Yes, this approach works for low player count games, but as player counts increase the probability that you'll be stuck waiting for the most lagged player to deliver input to the server approaches 1.
So no, this is not all you really need. This approach doesn't work well for high player count games (I wouldn't use it for any game with more than 4 players personally).
I get that the people doing the work know better than people who haven't, I'm open to learning more and can't make any ironclad statements.
Eve Online could do large-scale player battles before 10Mbps connections were available to gamers. And somehow much more efficiently per/player than Q3: Arena. What were they doing that you are not?
When too many ships get close together, the action slows down in "time dilation" (they slow the game down because they cannot keep up in terms of CPU and probably bandwidth as well).
It's a smart design trick that made it possible for them to pull this game off much earlier than it should have been possible.
I'm not doing any of that time dilation and everything plays like an FPS game or action game, just with n=1000 players all the time because it's 2026 and I can send a lot of bandwidth.
Yes, I still have to work really hard to keep server CPU costs, client CPU costs and make all game code || and bandwidth down and optimize it, even to fit in this (seemingly high) bandwidth budget. But it's the right choice for an action game where time dilation is not an option, and all the action happens in one tight space, like in a Star Wars movie when there is a space battle.