7 ms·

"This is because my space game sends a lot of bandwidth. 10-20 megabits per-second per-client" What is this game doing that uses so much bandwidth? Pretty sure

"This is because my space game sends a lot of bandwidth. 10-20 megabits per-second per-client" What is this game doing that uses so much bandwidth? Pretty sure most games use something like 2mbps.

gafferongames 4mo ago
Higher player counts and more detailed worlds? It's 2026 and we regularly watch 4k video streams @ 25mbps. Seems like games should be able to get away with sending this amount of bandwidth too for a higher fidelity experience.
- JohnMakin 4mo ago
  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?
  - gafferongames 4mo ago
    If a normal game sends 2mbps, then 20mbps would be 10 times as many objects.
    - frollogaston 4mo ago
      That's what I'm asking, seems like this isn't a normal game, but what specifically about it makes the bandwidth requirement so high? I know RTSes send inputs instead of state, but that has its own drawbacks.
      - gafferongames 4mo ago
        The space game has 1000 players. Most FPS games today have a maximum of 100 players. 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
        Hikikomori 4mo ago
        I don't think anyone disagrees that linearly scaling of traffic scales linearly. What they're getting at, why would you still use that rather implementing something more efficient? Like Battlefield games (bf4?) did, using different update rates for nearby and distant players. 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?
        gafferongames 4mo ago
        > I don't think anyone disagrees that linearly scaling of traffic scales linearly. What they're getting at, why would you still use that rather implementing something more efficient? Like Battlefield games (bf4?) did, using different update rates for nearby and distant players. 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!
        Hikikomori 4mo ago
        Then its fine, but its not what was described, and I guess that is what people had issues with as just scaling player numbers without optimization wouldn't work great right? Good luck with your game though, great if it works, but seems like many large player count games cut corners to simplify things.
    - thunderfork 4mo ago
      If you're using stream compression, 20mbps would likely be a lot more than 10 times as many objects (and you shouldn't be serializing the whole state every update, and... yadda yadda) You can fit a lot of game in 2mbit/s with a little bit of work.
      - gafferongames 4mo ago
        > 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.
    - mvdtnz 4mo ago
      Even 2mbps would be on the extremely high side. I doubt many mainstream games, if any, use this kind of bandwidth. Excluding games that stream video of course. A 6v6 game of Forged Alliance (12 players each moving hundreds of units around, many with simulated projectile weapons) uses 0.3mbps.
      - bluefirebrand 4mo ago
        I was going to say this too. Games don't need to send much data to sync game state across clients
      - gafferongames 4mo ago
        > A 6v6 game of Forged Alliance (12 players each moving hundreds of units around, many with simulated projectile weapons) uses 0.3mbps. 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).
    - axus 4mo ago
      At the absolute worst, a room full of 32-players in Quake 3: Arena would be sending 120 kilobits per second to each player. Fortnite peaks at ~400 kbps during the initial 100-player drop and goes down from there. I understand that those are big budget games, but there is a lot of room for improvement in 10000 kbps.
      - gafferongames 4mo ago
        > At the absolute worst, a room full of 32-players in Quake 3: Arena would be sending 120 kilobits per second to each player. 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.
        axus 4mo ago
        Why are all 1000 players visible to each other at once? The numbers I quoted were worst case, not a baseline. 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.
  - deleted 4mo ago
    [deleted]
- thunderfork 4mo ago
  Game data and video data have very different constraints. Depends on the nature of the game, of course, but with jitter and all that, video can just run a buffer and manage network conditions (more) trivially, but a game needs things to be a lot tighter to avoid gameplay-impacting desync
  - deleted 4mo ago
    [deleted]
  - gafferongames 4mo ago
    It's true plus you cannot just send a snapshot of 100 kilobytes or so from server to client with 1500 byte MTU with regular IPv4 packet fragmentation and reassembly due to packet loss amplification effects.
- xnx 4mo ago
  Is there any reason that transmitted data would be much larger than player inputs (e.g. keystrokes and mouse movement)?
  - kridsdale1 4mo ago
    Typically you send state, not inputs. To prevent cheating.
    - LoganDark 4mo ago
      Huh? If the server trusts the client to send state then the client could potentially send invalid or unfair state. If the client merely sends inputs then it can't just decide to manipulate the state that way.
      - frollogaston 4mo ago
        He means the server sends state to the clients, rather than sending other clients' inputs (or just P2P if no server). There are games that send inputs, which means if it's a game of limited information, clients know more than they should.
        LoganDark 4mo ago
        Ah, I get it now. I actually know a game that sends inputs (I commented elsewhere in the thread, the game is Cosmoteer). But yes, most games I'm aware of send state.
    - seba_dos1 4mo ago
      It's sending inputs that makes preventing cheating easier.
    - frollogaston 4mo ago
      Some genres of games (like RTS) typically do send inputs instead of state. Cheating is indeed possible.
thunderfork 4mo ago
Yeah, this strikes me as strange. If you're sending that much data constantly, you're either syncing too much stuff too often, or you're not using compression when you should be (shout-out to Oodle) Something that this article doesn't mention that's going to be a big constraint: each of your clients parsing 20mbps of updates is going to have a performance impact on those clients. At the end of the day, you can only "democratize" while you have players, and performance constraints on end users aren't getting any looser
- gafferongames 4mo ago
  Maybe you can just be doing all the standard compression tricks, but still have a 10-20 times larger world? If so, why not?
  - thunderfork 4mo ago
    Client performance characteristics? Speaking very broadly... I can't imagine a game that'd need that much data unless it involved a lot of streaming assets (audio, video, etc) or really, really naive netcode.
    - gafferongames 4mo ago
      > I can't imagine a game that'd need that much data I can :)
      - mvdtnz 4mo ago
        Maybe instead of leaving drive by comments like this you can explain this to the overwhelming majority of people in this thread who think it's bananas.
        gafferongames 4mo ago
        Nobody has answered my question, which is if you can use more bandwidth, and in doing so supports a larger, more detailed world, then why not? Why limit yourself to bandwidth usage designed around the turn of the century? It's 2026. We can do better :)
mvdtnz 4mo ago
It's a ludicrous amount of bandwidth even for a 1,000 player game, and a strong indicator that this developer is doing something very wrong.
- avaer 4mo ago
  It's like someone saying their project repo has 10-20GB of source. (btw game server network data is usually trivially and insanely compressible, far more than text)
  - gafferongames 4mo ago
    Have you considered the O(n x m) issue with player counts? For example, if you have n=1000 players, and m=2000 objects, the total number of object state updates that need to be sent out is n x m. So a 1000 player space game with 1000 players, and 2000 objects (say, 1000 other players and 1000 AI ships...), and you have O(1000 x 2000) = 2,000,000 Compare this with a more typical FPS, let's say, n=32 and m=1000 (let's be generous...). The amount of bandwidth for that game would be O(32 x 1000) = O(32000). Given this, it's pretty easy to see how a 1000 player space game would send more bandwidth than a regular 32 player FPS, even if it did use all the standard tricks from first person shooters, eg. snapshots, delta encoding and all that. There's just more state to send, and in total, roughly O(n^2) bandwidth as player count n increases.
    - frollogaston 4mo ago
      There are already plenty of 1000-player games with 2000 objects that use a lot less bandwidth than this, usually because a lot of the object tracking is left to the clients while the server shares some form of player input. I'm not saying there's no possible reason to use 20mbps, just asking what it's for. Is the space game avoiding sending player inputs for anticheat reasons? How is the server updating the client on the objects' state? I will say though, 20mbps of game bandwidth is different from video bandwidth. I'm guessing you require low latency too. And it'd be a lot for the clients to deal with, even the deserialization by itself.

"This is because my space game sends a lot of bandwidth. 10-20 megabits per-second per-client" What is this game doing that uses so much bandwidth? Pretty sure most games use something like 2mbps.

gafferongames 4mo ago

Higher player counts and more detailed worlds? It's 2026 and we regularly watch 4k video streams @ 25mbps. Seems like games should be able to get away with sending this amount of bandwidth too for a higher fidelity experience.

JohnMakin 4mo ago
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?
- gafferongames 4mo ago
  If a normal game sends 2mbps, then 20mbps would be 10 times as many objects.
  - frollogaston 4mo ago
    That's what I'm asking, seems like this isn't a normal game, but what specifically about it makes the bandwidth requirement so high? I know RTSes send inputs instead of state, but that has its own drawbacks.
    - gafferongames 4mo ago
      The space game has 1000 players. Most FPS games today have a maximum of 100 players. 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
      - Hikikomori 4mo ago
        I don't think anyone disagrees that linearly scaling of traffic scales linearly. What they're getting at, why would you still use that rather implementing something more efficient? Like Battlefield games (bf4?) did, using different update rates for nearby and distant players. 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?
        gafferongames 4mo ago
        > I don't think anyone disagrees that linearly scaling of traffic scales linearly. What they're getting at, why would you still use that rather implementing something more efficient? Like Battlefield games (bf4?) did, using different update rates for nearby and distant players. 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!
        Hikikomori 4mo ago
        Then its fine, but its not what was described, and I guess that is what people had issues with as just scaling player numbers without optimization wouldn't work great right? Good luck with your game though, great if it works, but seems like many large player count games cut corners to simplify things.
  - thunderfork 4mo ago
    If you're using stream compression, 20mbps would likely be a lot more than 10 times as many objects (and you shouldn't be serializing the whole state every update, and... yadda yadda) You can fit a lot of game in 2mbit/s with a little bit of work.
    - gafferongames 4mo ago
      > 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.
  - mvdtnz 4mo ago
    Even 2mbps would be on the extremely high side. I doubt many mainstream games, if any, use this kind of bandwidth. Excluding games that stream video of course. A 6v6 game of Forged Alliance (12 players each moving hundreds of units around, many with simulated projectile weapons) uses 0.3mbps.
    - bluefirebrand 4mo ago
      I was going to say this too. Games don't need to send much data to sync game state across clients
    - gafferongames 4mo ago
      > A 6v6 game of Forged Alliance (12 players each moving hundreds of units around, many with simulated projectile weapons) uses 0.3mbps. 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).
  - axus 4mo ago
    At the absolute worst, a room full of 32-players in Quake 3: Arena would be sending 120 kilobits per second to each player. Fortnite peaks at ~400 kbps during the initial 100-player drop and goes down from there. I understand that those are big budget games, but there is a lot of room for improvement in 10000 kbps.
    - gafferongames 4mo ago
      > At the absolute worst, a room full of 32-players in Quake 3: Arena would be sending 120 kilobits per second to each player. 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.
      - axus 4mo ago
        Why are all 1000 players visible to each other at once? The numbers I quoted were worst case, not a baseline. 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.
- deleted 4mo ago
  [deleted]
thunderfork 4mo ago
Game data and video data have very different constraints. Depends on the nature of the game, of course, but with jitter and all that, video can just run a buffer and manage network conditions (more) trivially, but a game needs things to be a lot tighter to avoid gameplay-impacting desync
- deleted 4mo ago
  [deleted]
- gafferongames 4mo ago
  It's true plus you cannot just send a snapshot of 100 kilobytes or so from server to client with 1500 byte MTU with regular IPv4 packet fragmentation and reassembly due to packet loss amplification effects.
xnx 4mo ago
Is there any reason that transmitted data would be much larger than player inputs (e.g. keystrokes and mouse movement)?
- kridsdale1 4mo ago
  Typically you send state, not inputs. To prevent cheating.
  - LoganDark 4mo ago
    Huh? If the server trusts the client to send state then the client could potentially send invalid or unfair state. If the client merely sends inputs then it can't just decide to manipulate the state that way.
    - frollogaston 4mo ago
      He means the server sends state to the clients, rather than sending other clients' inputs (or just P2P if no server). There are games that send inputs, which means if it's a game of limited information, clients know more than they should.
      - LoganDark 4mo ago
        Ah, I get it now. I actually know a game that sends inputs (I commented elsewhere in the thread, the game is Cosmoteer). But yes, most games I'm aware of send state.
  - seba_dos1 4mo ago
    It's sending inputs that makes preventing cheating easier.
  - frollogaston 4mo ago
    Some genres of games (like RTS) typically do send inputs instead of state. Cheating is indeed possible.

thunderfork 4mo ago

Yeah, this strikes me as strange. If you're sending that much data constantly, you're either syncing too much stuff too often, or you're not using compression when you should be (shout-out to Oodle) Something that this article doesn't mention that's going to be a big constraint: each of your clients parsing 20mbps of updates is going to have a performance impact on those clients. At the end of the day, you can only "democratize" while you have players, and performance constraints on end users aren't getting any looser

gafferongames 4mo ago
Maybe you can just be doing all the standard compression tricks, but still have a 10-20 times larger world? If so, why not?
- thunderfork 4mo ago
  Client performance characteristics? Speaking very broadly... I can't imagine a game that'd need that much data unless it involved a lot of streaming assets (audio, video, etc) or really, really naive netcode.
  - gafferongames 4mo ago
    > I can't imagine a game that'd need that much data I can :)
    - mvdtnz 4mo ago
      Maybe instead of leaving drive by comments like this you can explain this to the overwhelming majority of people in this thread who think it's bananas.
      - gafferongames 4mo ago
        Nobody has answered my question, which is if you can use more bandwidth, and in doing so supports a larger, more detailed world, then why not? Why limit yourself to bandwidth usage designed around the turn of the century? It's 2026. We can do better :)

mvdtnz 4mo ago

It's a ludicrous amount of bandwidth even for a 1,000 player game, and a strong indicator that this developer is doing something very wrong.

avaer 4mo ago
It's like someone saying their project repo has 10-20GB of source. (btw game server network data is usually trivially and insanely compressible, far more than text)
- gafferongames 4mo ago
  Have you considered the O(n x m) issue with player counts? For example, if you have n=1000 players, and m=2000 objects, the total number of object state updates that need to be sent out is n x m. So a 1000 player space game with 1000 players, and 2000 objects (say, 1000 other players and 1000 AI ships...), and you have O(1000 x 2000) = 2,000,000 Compare this with a more typical FPS, let's say, n=32 and m=1000 (let's be generous...). The amount of bandwidth for that game would be O(32 x 1000) = O(32000). Given this, it's pretty easy to see how a 1000 player space game would send more bandwidth than a regular 32 player FPS, even if it did use all the standard tricks from first person shooters, eg. snapshots, delta encoding and all that. There's just more state to send, and in total, roughly O(n^2) bandwidth as player count n increases.
  - frollogaston 4mo ago
    There are already plenty of 1000-player games with 2000 objects that use a lot less bandwidth than this, usually because a lot of the object tracking is left to the clients while the server shares some form of player input. I'm not saying there's no possible reason to use 20mbps, just asking what it's for. Is the space game avoiding sending player inputs for anticheat reasons? How is the server updating the client on the objects' state? I will say though, 20mbps of game bandwidth is different from video bandwidth. I'm guessing you require low latency too. And it'd be a lot for the clients to deal with, even the deserialization by itself.