4 ms·

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 w

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 3mo 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 3mo 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 3mo ago
    > I can't imagine a game that'd need that much data I can :)
    - mvdtnz 3mo 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 3mo 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 :)
        frollogaston 3mo ago
        The article already started off saying the bandwidth itself was a problem due to egress costs, but that's not the only issue. Thunderfork already answered what else is wrong with it. Now if you're the author, can you tell me what the space game does?
        gafferongames 3mo ago
        > Now if you're the author, can you tell me what the space game does? A larger more detailed world with a higher player count, networked using quake style netcode techniques ala. Counterstrike, Titanfall, Apex Legends with snapshots and delta compression, client side prediction and lag compensation. In short, FPS netcode scaled up to 1000 players, but applied to a space game, not an FPS, because the world doesn't need another FPS right now...
        frollogaston 3mo ago
        My question and its followups have all been reasonable and non-assuming. I was interested in some more details, but not anymore, best of luck.
        gafferongames 3mo ago
        This thread absolutely has not been full of reasonable and non-assuming questions. 1. "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" 2. "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" 3. "overwhelming majority of people in this thread who think it's bananas." Sorry folks, but if you want to have a positive discussion with me about game netcode this is not the way to do it.
        deleted 3mo ago
        [deleted]
        thunderfork 3mo ago
gafferongames 3mo ago
> 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. I can assure you that parsing 20 megabits per-second worth of packets on a client is not a significant CPU cost.
- gafferongames 3mo ago
  20 megabits per-second is 2.5 megabytes per second. Do you really think PCs have difficulty processing 2.5 megabytes of data per-second in 2026?
  - thunderfork 3mo ago
    Taking 2.5 megabytes per second of compressed new state information, uncompressing it, and applying it (across the "thousands and thousands of networked entities", etc, that keep being talked about) to the game state? All the memory thrash that implies, along with the knock-on effects (animation updates, yadda yadda)? Yeah, that has a performance cost. Will this impact a big-money gaming rig? Probably not? Will it run good on the Steam Deck? Probably not. Generally, in a game loop, all this stuff is going to be single-threaded and blocking, right? It's mutating the game state, that's the classic why-games-suck-at-thriving-on-many-small-cores problem. So your performance capacity ends up being tighter than you might think relative to other "ingest data" tasks. Let's say your game's networking runs at 30 ticks a second, and you've done a great job in uncoupling rendering from the game loop, so you're lucky enough to not have to worry about that. You still only have 30ms, on a single thread, to handle networking (likely no special kernel-skipping stuff on clients!), unpack, apply and propagate your changes, and also do your local game loop stuff. If you miss that interval once, the game starts to fall behind and feel bad to play. Now, you could say "lower the tick rate", but then you'd need less data, too, and your game gets less responsive (fine for some games, not for others)
    - gafferongames 3mo ago
      > Will this impact a big-money gaming rig? Probably not? Will it run good on the Steam Deck? Probably not. Runs fine on steam deck. Runs fine old on 10 year old PC. It's really not that expensive, if you code it correctly (which means data oriented programming, programming in a cache aware way and going wide for everything to distribute load when possible). But this is how modern games are coded anyway. See ECS/DOTS for Unity and so on. Based on similar techniques we've been using for a decade+ on game consoles. > Generally, in a game loop, all this stuff is going to be single-threaded and blocking, right? No. Once you go above 100 players you usually to go wide for pretty much everything across multiple threads, even on the client. But obviously on the server, you go really wide.

gafferongames 3mo 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 3mo 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 3mo ago
  > I can't imagine a game that'd need that much data I can :)
  - mvdtnz 3mo 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 3mo 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 :)
      - frollogaston 3mo ago
        The article already started off saying the bandwidth itself was a problem due to egress costs, but that's not the only issue. Thunderfork already answered what else is wrong with it. Now if you're the author, can you tell me what the space game does?
      - gafferongames 3mo ago
        > Now if you're the author, can you tell me what the space game does? A larger more detailed world with a higher player count, networked using quake style netcode techniques ala. Counterstrike, Titanfall, Apex Legends with snapshots and delta compression, client side prediction and lag compensation. In short, FPS netcode scaled up to 1000 players, but applied to a space game, not an FPS, because the world doesn't need another FPS right now...
        frollogaston 3mo ago
        My question and its followups have all been reasonable and non-assuming. I was interested in some more details, but not anymore, best of luck.
        gafferongames 3mo ago
        This thread absolutely has not been full of reasonable and non-assuming questions. 1. "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" 2. "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" 3. "overwhelming majority of people in this thread who think it's bananas." Sorry folks, but if you want to have a positive discussion with me about game netcode this is not the way to do it.
        deleted 3mo ago
        [deleted]
        thunderfork 3mo ago

gafferongames 3mo ago

> 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. I can assure you that parsing 20 megabits per-second worth of packets on a client is not a significant CPU cost.

gafferongames 3mo ago
20 megabits per-second is 2.5 megabytes per second. Do you really think PCs have difficulty processing 2.5 megabytes of data per-second in 2026?
- thunderfork 3mo ago
  Taking 2.5 megabytes per second of compressed new state information, uncompressing it, and applying it (across the "thousands and thousands of networked entities", etc, that keep being talked about) to the game state? All the memory thrash that implies, along with the knock-on effects (animation updates, yadda yadda)? Yeah, that has a performance cost. Will this impact a big-money gaming rig? Probably not? Will it run good on the Steam Deck? Probably not. Generally, in a game loop, all this stuff is going to be single-threaded and blocking, right? It's mutating the game state, that's the classic why-games-suck-at-thriving-on-many-small-cores problem. So your performance capacity ends up being tighter than you might think relative to other "ingest data" tasks. Let's say your game's networking runs at 30 ticks a second, and you've done a great job in uncoupling rendering from the game loop, so you're lucky enough to not have to worry about that. You still only have 30ms, on a single thread, to handle networking (likely no special kernel-skipping stuff on clients!), unpack, apply and propagate your changes, and also do your local game loop stuff. If you miss that interval once, the game starts to fall behind and feel bad to play. Now, you could say "lower the tick rate", but then you'd need less data, too, and your game gets less responsive (fine for some games, not for others)
  - gafferongames 3mo ago
    > Will this impact a big-money gaming rig? Probably not? Will it run good on the Steam Deck? Probably not. Runs fine on steam deck. Runs fine old on 10 year old PC. It's really not that expensive, if you code it correctly (which means data oriented programming, programming in a cache aware way and going wide for everything to distribute load when possible). But this is how modern games are coded anyway. See ECS/DOTS for Unity and so on. Based on similar techniques we've been using for a decade+ on game consoles. > Generally, in a game loop, all this stuff is going to be single-threaded and blocking, right? No. Once you go above 100 players you usually to go wide for pretty much everything across multiple threads, even on the client. But obviously on the server, you go really wide.