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.
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.
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.
"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.
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.
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.
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?
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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
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.
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.
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.
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.
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)
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.
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.
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.
"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.
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.
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.
"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.
This is totally correct.
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)
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.
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.
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?
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.
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?
If a normal game sends 2mbps, then 20mbps would be 10 times as many objects.
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.
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.
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.
> 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.
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.
I was going to say this too.
Games don't need to send much data to sync game state across clients
Is there any reason that transmitted data would be much larger than player inputs (e.g. keystrokes and mouse movement)?
Typically you send state, not inputs. To prevent cheating.
It's sending inputs that makes preventing cheating easier.
Some genres of games (like RTS) typically do send inputs instead of state. Cheating is indeed possible.
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.
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.
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.
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).
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.
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.
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.
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
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.
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
Maybe you can just be doing all the standard compression tricks, but still have a 10-20 times larger world? If so, why not?
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.
> I can't imagine a game that'd need that much data
I can :)
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.
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 :)
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.
The speed of light is not just a good idea, it's the law!
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.
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)
[delayed]
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.
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.
https://knockoutcity.com/private-server-edition
Its free, until it’s not
dont know if I can trust amazon anymore.
Do know that you cannot trust Amazon.