I expect Amazon to change their pricing once they've established a foothold and makes me a bit wary to adopting it. Their other offerings are simply far too expensive which you will naturally reach out for.
dieselgate · 2026-06-30 20:51:07 UTC
Do know that you cannot trust Amazon.
frollogaston · 2026-06-30 22:20:09 UTC
I can trust Amazon in general. Just not going to assume that something that costs them a lot will remain free for me to use.
gafferongames · 2026-06-30 22:42:00 UTC
Maybe it doesn't cost them a lot, actually.
fivetenpen · 2026-06-30 20:56:15 UTC
Its free, until it’s not
iammjm · 2026-06-30 21:02:30 UTC
Would this also mean lower latency between two locations? One interesting case for me would be lowering latency in StarCraft: Brood War, which is cursed by having 90% of its player base in South Korea, with the rest of us foreigners spread all over the world.
gafferongames · 2026-06-30 21:03:34 UTC
The speed of light is not just a good idea, it's the law!
frollogaston · 2026-06-30 21:03:40 UTC
"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 · 2026-06-30 21:10:04 UTC
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 · 2026-06-30 21:13:15 UTC
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 · 2026-06-30 21:15:40 UTC
If a normal game sends 2mbps, then 20mbps would be 10 times as many objects.
frollogaston · 2026-06-30 21:32:57 UTC
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.
thunderfork · 2026-06-30 21:34:28 UTC
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 · 2026-06-30 21:42:58 UTC
> 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 · 2026-06-30 21:38:14 UTC
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 · 2026-06-30 21:46:16 UTC
I was going to say this too.
Games don't need to send much data to sync game state across clients
axus · 2026-06-30 21:47:57 UTC
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 · 2026-07-01 03:58:29 UTC
> 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 · 2026-07-01 04:55:38 UTC
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.
gafferongames · 2026-07-01 06:35:16 UTC
I really want to just stop here and ask you what you expect will happen if you take a multiplayer game with n players and increase it to have 10 times the player count (10n).
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 for high player count games (I wouldn't use it for any game with more than 4 players personally).
thunderfork · 2026-06-30 21:20:10 UTC
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
gafferongames · 2026-06-30 21:44:32 UTC
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 · 2026-06-30 21:31:50 UTC
Is there any reason that transmitted data would be much larger than player inputs (e.g. keystrokes and mouse movement)?
kridsdale1 · 2026-06-30 21:37:08 UTC
Typically you send state, not inputs. To prevent cheating.
LoganDark · 2026-06-30 21:43:41 UTC
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 · 2026-06-30 21:50:19 UTC
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 · 2026-06-30 22:04:55 UTC
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 · 2026-06-30 21:44:38 UTC
It's sending inputs that makes preventing cheating easier.
frollogaston · 2026-06-30 21:48:58 UTC
Some genres of games (like RTS) typically do send inputs instead of state. Cheating is indeed possible.
gafferongames · 2026-06-30 22:28:04 UTC
Cheating in the sense of breaking fog of war, because the client has to actually have the whole game state in memory due to deterministic synchronization. Yes.
gafferongames · 2026-06-30 21:38:43 UTC
Some games are networked deterministically, so that you can send only the inputs, and the game plays out exactly the same way (down to a checksum matching for all game state in memory across all players).
The problem is that as player counts increase, the chance that any one player is late delivering inputs to the server (or to other players, if peer-to-peer) approaches 100%.
A deterministic simulation cannot stay deterministic, unless it has the correct inputs for all players, so the game has to pause and wait for inputs for all players before stepping the authoritative game state forward.
This is why high player count games like MMOs are not usually networked deterministically.
frollogaston · 2026-06-30 21:44:27 UTC
Haha of course it's Age of Empires. The lag was insane because out of 8 players, there'd always be that one guy. AoE2 also had bugs with determinism, causing games to sometimes end because one person went out of sync. Even the HD remake had those issues. The even later DE remake seems to have fixed it, but it still depends on this really finicky math library that doesn't work exactly right in Wine/Proton.
LoganDark · 2026-06-30 21:46:20 UTC
Oh hey! I sometimes play a game called Cosmoteer that has deterministic lockstep multiplayer. That means in multiplayer every game has to synchronize on the exact same tick, receive all inputs from all other players and apply them on their exact same ticks, etc. The entire session is bottlenecked by the slowest player's machine. But it's very cool.
If any player desynchronizes, their state has to be erased and then completely re-sent from scratch so that they can start processing inputs correctly again.
thunderfork · 2026-06-30 21:25:38 UTC
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 · 2026-06-30 21:30:18 UTC
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 · 2026-06-30 21:37:02 UTC
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 · 2026-06-30 21:41:51 UTC
> I can't imagine a game that'd need that much data
I can :)
mvdtnz · 2026-06-30 21:45:20 UTC
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 · 2026-06-30 21:56:30 UTC
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 · 2026-06-30 22:08:57 UTC
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 · 2026-06-30 22:24:56 UTC
> 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 · 2026-06-30 22:51:23 UTC
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 · 2026-06-30 23:22:35 UTC
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.
thunderfork · 2026-07-01 05:40:23 UTC
The person you're replying to isn't me (the person you're quoting above), but to be clear:
I'm not trying to be insulting, here, it's just kind of a bizarre, eyebrow-raising thing to see. There's a reason you're not seeing any AAA games doing this, y'know?
If you're doing something that's really unusual, you're going to have people going "this is really unusual".
Please don't take this the wrong way - this is sincere, well-intentioned advice: have you ever watched Shark Tank? The best people on there can still give a good pitch when their ideas are challenged.
The games industry - and especially the multiplayer games space - are brutal, and players are going to be way more critical, way more rudely, than anyone on HN.
It would benefit you and your game greatly to practice selling your idea in the face of criticism and doubt.
gafferongames · 2026-07-01 06:18:37 UTC
Hey, I want to make something really clear to you. I'm a professional game developer and I write netcode for AAA games for a living. I wrote large parts of the netcode for Titanfall 2 and Apex Legends.
> There's a reason you're not seeing any AAA games doing this, y'know?
Yes, it's because bandwidth used to be really expensive (both in bare metal and cloud) and now in many cases it's less so, and in some cases totally free (AWS GameLift). This is big news that is relevant to other professional multiplayer game developers, the readers of my website https://mas-bandwidth.com
> It would benefit you and your game greatly to practice selling your idea in the face of criticism and doubt.
But I'm not here to sell my idea to you. I'm just a professional game developer who wrote an article about how free egress bandwidth for game servers in AWS is big news for multiplayer games, with some basic analysis about what it might cause in the game industry moving forward.
Take it or leave it man.
gafferongames · 2026-06-30 22:49:56 UTC
> 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 · 2026-06-30 23:37:24 UTC
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 · 2026-07-01 05:33:32 UTC
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 · 2026-07-01 05:59:41 UTC
> 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 decades 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.
mvdtnz · 2026-06-30 21:36:28 UTC
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 · 2026-06-30 21:44:08 UTC
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 · 2026-06-30 21:50:16 UTC
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 · 2026-06-30 21:54:12 UTC
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.
gafferongames · 2026-06-30 22:00:41 UTC
Yes, but how many games truly support 1000 players at the same quality level and fidelity of a AAA FPS? I can't think of any, even Eve: Online has time dilation and starts to chug when the action gets too intense.
What if you could have a 1000 player FPS, and it was networked at the same fidelity of a AAA FPS? It would certainly use more bandwidth, but what if?
frollogaston · 2026-06-30 22:08:37 UTC
The largest player count FPSes I can think of are Battlefield and Fortnite. I don't think the bandwidth is the constraint on those, even if you really wanted to have 1000 people shooting at each other in the same spot.
gafferongames · 2026-06-30 22:52:05 UTC
The number of players per-Fortnite server is 100 players.
The number of players per-Battlefield server is 64 players.
It's not as ludicrous as you think, for two reasons:
1. Bandwidth requirements scale quadratically with player count, since the state of each player needs to be broadcast to every player. You can optimize this with clever tricks like server-side occlusion culling, but that's heavily dependent on your specific game's mechanics, and it still doesn't address the worst case scenario of lots of players clustering in a small visible area.
2. Players are not the only entity that need to be synced. Every server-side entity affecting a client needs to have its state broadcast to that client. A dynamically destructible environment that physically interacts with players is a perfect example of this - launch a rocket at a building, compute the Voronoi fractures server-side based on impact location, sync thousands of pieces of flying concrete debris (each with its own rigid body) across all players.
frollogaston · 2026-06-30 22:05:40 UTC
"Every server-side entity affecting a client needs to have its state broadcast to that client" is true, but you're presuming all those entities are going to be server-side, which in most cases they're not.
Yes I can imagine if you put all the state on the server and broadcast all that to the clients, you can easily use 20mbps for a massive game, more like 200mbps. Would also imagine it'd be insanely laggy, and not because of the bandwidth itself. At that point you're probably better off just streaming the video, cause at least clients can uh "parse" that quickly.
gafferongames · 2026-06-30 22:12:11 UTC
A typical quake style FPS netcode like Counterstrike, Apex Legends, Titanfall etc. would have all gameplay affecting objects (bullets, missiles props whatever...) as server side entities.
On the client these entities are usually interpolated, except the local player character, which has client-side prediction (eg. optimistic execution with rollback to apply server corrections to maintain server authority).
So it's not at all unusual to suggest that all gameplay affecting objects would be server-side. In this network model, that is the default approach.
The exception would be for entirely cosmetic FX or cosmetic debris objects that don't push back on the player.
Stevvo · 2026-06-30 22:09:41 UTC
2. Is an absurd example. That is not how you do networked physics in 2026. You use jolt for cross-platform determinism with rollback, replicating only inputs.
gafferongames · 2026-06-30 22:31:42 UTC
Deterministic cross-platform networking with jolt is fine and good, but there are multiple ways to network a game, and even to do networked physics in 2026.
I hope your game world is small, and your player count is low, otherwise: 1) your server will be waiting for inputs from the most lagged player, 2) you will become entirely CPU bound on the client performing all this rollback.
Approaches that don't suffer from these two problems send state, yes they send a lot more bandwidth, but they scale better as the number of players n increases.
xboxnolifes · 2026-06-30 22:18:53 UTC
It does not scale quadratically per client though, and the number given is per client.
gafferongames · 2026-06-30 23:06:53 UTC
Let's say typical games send 1-2 megabits per-second for first person shooters with 100 players or less (in some cases it's more, some cases it's less, but let's assume this is at least reasonable to do in 2026)
Now you have a game with 1000 players.
That's 10 times the number of objects in the world (players have to be sent to other players, assuming you can see all the other players because they are right near you.)
Now this game sends 10-20megabits per-second.
It's just math. More players --> more bandwidth.
Stevvo · 2026-06-30 21:05:32 UTC
There is nothing "democratizing" about hosting your game's servers on AWS.
Your game can have zero hosting cost if you just let players host their own servers. Let people play the game they paid for, forever, instead of locking them in to playing on an AWS server then killing the game in a couple of years when it's not profitable anymore.
dwroberts · 2026-06-30 21:39:45 UTC
Although I agree it’s more like subsidising than democratising (and the price will just go back up eventually), the “just let players host it” is overly simplistic.
There are tons of reasons to not do that - for example, companies and games that have not embraced modding do not want to be competing with modified/unofficial versions of their own games’ servers (as well as the cheating issue that can bring with it)
gafferongames · 2026-06-30 21:41:16 UTC
Companies like https://nitrado.com host community servers cheaply and support mods. Sort of a nice half-way in between truly player hosted servers (where somebody could quit mid-game, or even cheat the game), and dedicated servers run only by the devs.
Stevvo · 2026-06-30 22:00:36 UTC
I don't know if any of those "tons of reasons" are actually valid; checking the top 10 multiplayer games on Steam by player count all of them allow player hosted servers.
gafferongames · 2026-06-30 22:36:58 UTC
Well, I can give several reasons why player hosted servers (like on their own machines) can be a bad idea:
* If the server player quits, the game is over, or the game developer has to implement host migration, which generally sucks. Game developers would prefer to spend this money and time making the game more fun instead.
* If the server player cooks a burrito in the microwave and is playing over wifi, maybe everybody's connection gets really bad for 60 seconds.
* At least in the USA, internet connections are highly asymmetric. It's getting better now, but 10-20 years ago, the vast majority of players would only have enough bandwidth to send and receive one client's worth of bandwidth, and would not be able to upload bandwidth for all players, especially as player counts increased.
* Cheating. The player hosting the server on their machine (if a PC) could modify code and/or memory to cheat.
* Lag switching / network shaping. The player hosting the server could time out, lag out or ruin the experience for a player they don't like.
* Host advantage. The final one is that the player hosting the server has zero lag, so has a huge advantage over other players.
For a competitive game at least, it's much better in 2026 to host your servers somewhere secure, or to have player hosted servers in a secure provider that doesn't let players do any of the things above.
gafferongames · 2026-06-30 22:41:34 UTC
Oh shit and I forgot NAT issues. Depending on NAT, some players simply cannot host a game (without a relay server), no matter what they do.
gafferongames · 2026-06-30 21:39:50 UTC
Hosting in AWS (or anywhere else) doesn't preclude you from doing the right thing and releasing your server binary or even source code after you shut your game down. For example, Knockout City by Velan Studios did exactly this.
Give me self host code any day. This feels like the bait and switch AWS likes to pull. Would rather rely on the server in my dresser drawer than AWS for as much as I possibly can.
simianwords · 2026-06-30 21:45:46 UTC
this is painting a caricaturist view of AWS. they have been more or less stable with their prices and features. Their prices have mostly gone down ime. I have so far seen zero bait and switches and mostly things working as usual.
Comments
What is this game doing that uses so much bandwidth? Pretty sure most games use something like 2mbps.
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
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 for high player count games (I wouldn't use it for any game with more than 4 players personally).
For example many RTSs are networked this way. They can have thousands or tens of thousands of units, but send only inputs. The classic article on this being 1500 archers on a 28k modem: https://zoo.cs.yale.edu/classes/cs538/readings/papers/terran...
The problem is that as player counts increase, the chance that any one player is late delivering inputs to the server (or to other players, if peer-to-peer) approaches 100%.
A deterministic simulation cannot stay deterministic, unless it has the correct inputs for all players, so the game has to pause and wait for inputs for all players before stepping the authoritative game state forward.
This is why high player count games like MMOs are not usually networked deterministically.
If any player desynchronizes, their state has to be erased and then completely re-sent from scratch so that they can start processing inputs correctly again.
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
I can :)
Why limit yourself to bandwidth usage designed around the turn of the century?
It's 2026. We can do better :)
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...
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.
I'm not trying to be insulting, here, it's just kind of a bizarre, eyebrow-raising thing to see. There's a reason you're not seeing any AAA games doing this, y'know?
If you're doing something that's really unusual, you're going to have people going "this is really unusual".
Please don't take this the wrong way - this is sincere, well-intentioned advice: have you ever watched Shark Tank? The best people on there can still give a good pitch when their ideas are challenged.
The games industry - and especially the multiplayer games space - are brutal, and players are going to be way more critical, way more rudely, than anyone on HN.
It would benefit you and your game greatly to practice selling your idea in the face of criticism and doubt.
> There's a reason you're not seeing any AAA games doing this, y'know?
Yes, it's because bandwidth used to be really expensive (both in bare metal and cloud) and now in many cases it's less so, and in some cases totally free (AWS GameLift). This is big news that is relevant to other professional multiplayer game developers, the readers of my website https://mas-bandwidth.com
> It would benefit you and your game greatly to practice selling your idea in the face of criticism and doubt.
But I'm not here to sell my idea to you. I'm just a professional game developer who wrote an article about how free egress bandwidth for game servers in AWS is big news for multiplayer games, with some basic analysis about what it might cause in the game industry moving forward.
Take it or leave it man.
I can assure you that parsing 20 megabits per-second worth of packets on a client is not a significant CPU cost.
Do you really think PCs have difficulty processing 2.5 megabytes of data per-second in 2026?
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)
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 decades 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.
(btw game server network data is usually trivially and insanely compressible, far more than text)
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.
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.
What if you could have a 1000 player FPS, and it was networked at the same fidelity of a AAA FPS? It would certainly use more bandwidth, but what if?
The number of players per-Battlefield server is 64 players.
1. Bandwidth requirements scale quadratically with player count, since the state of each player needs to be broadcast to every player. You can optimize this with clever tricks like server-side occlusion culling, but that's heavily dependent on your specific game's mechanics, and it still doesn't address the worst case scenario of lots of players clustering in a small visible area.
2. Players are not the only entity that need to be synced. Every server-side entity affecting a client needs to have its state broadcast to that client. A dynamically destructible environment that physically interacts with players is a perfect example of this - launch a rocket at a building, compute the Voronoi fractures server-side based on impact location, sync thousands of pieces of flying concrete debris (each with its own rigid body) across all players.
Yes I can imagine if you put all the state on the server and broadcast all that to the clients, you can easily use 20mbps for a massive game, more like 200mbps. Would also imagine it'd be insanely laggy, and not because of the bandwidth itself. At that point you're probably better off just streaming the video, cause at least clients can uh "parse" that quickly.
On the client these entities are usually interpolated, except the local player character, which has client-side prediction (eg. optimistic execution with rollback to apply server corrections to maintain server authority).
So it's not at all unusual to suggest that all gameplay affecting objects would be server-side. In this network model, that is the default approach.
The exception would be for entirely cosmetic FX or cosmetic debris objects that don't push back on the player.
I hope your game world is small, and your player count is low, otherwise: 1) your server will be waiting for inputs from the most lagged player, 2) you will become entirely CPU bound on the client performing all this rollback.
Approaches that don't suffer from these two problems send state, yes they send a lot more bandwidth, but they scale better as the number of players n increases.
Now you have a game with 1000 players.
That's 10 times the number of objects in the world (players have to be sent to other players, assuming you can see all the other players because they are right near you.)
Now this game sends 10-20megabits per-second.
It's just math. More players --> more bandwidth.
Your game can have zero hosting cost if you just let players host their own servers. Let people play the game they paid for, forever, instead of locking them in to playing on an AWS server then killing the game in a couple of years when it's not profitable anymore.
There are tons of reasons to not do that - for example, companies and games that have not embraced modding do not want to be competing with modified/unofficial versions of their own games’ servers (as well as the cheating issue that can bring with it)
* If the server player quits, the game is over, or the game developer has to implement host migration, which generally sucks. Game developers would prefer to spend this money and time making the game more fun instead.
* If the server player cooks a burrito in the microwave and is playing over wifi, maybe everybody's connection gets really bad for 60 seconds.
* At least in the USA, internet connections are highly asymmetric. It's getting better now, but 10-20 years ago, the vast majority of players would only have enough bandwidth to send and receive one client's worth of bandwidth, and would not be able to upload bandwidth for all players, especially as player counts increased.
* Cheating. The player hosting the server on their machine (if a PC) could modify code and/or memory to cheat.
* Lag switching / network shaping. The player hosting the server could time out, lag out or ruin the experience for a player they don't like.
* Host advantage. The final one is that the player hosting the server has zero lag, so has a huge advantage over other players.
For a competitive game at least, it's much better in 2026 to host your servers somewhere secure, or to have player hosted servers in a secure provider that doesn't let players do any of the things above.
https://knockoutcity.com/private-server-edition