The best thing that's ever happened for multiplayer games?(mas-bandwidth.com) |
The best thing that's ever happened for multiplayer games?(mas-bandwidth.com) |
What is this game doing that uses so much bandwidth? Pretty sure most games use something like 2mbps.
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.
(btw game server network data is usually trivially and insanely compressible, far more than text)
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 assure that parsing 20 megabits per-second worth of packets on a client is not a significant CPU cost for the client.
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.
I understand that those are big budget games, but there is a lot of room for improvement in 10000 kbps.
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
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.
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.
I can :)
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.
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?
Why limit yourself to bandwidth usage designed around the turn of the century?
It's 2026. We can do better :)
But I've already told you. A larger more detailed world, with a higher player count. In doing so, it just happens to cost more bandwidth, even if you do use all the bandwidth compression techniques that are used in AAA FPS (I've worked on several).
Please stop assuming I'm an idiot. The article is about the free egress bandwidth deal, which is a cool thing for games, and will save a lot of money for new game developers launching games. It's not about my space game.