| ▲ | mvdtnz 8 hours 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. |
|
| ▲ | 10000truths 8 hours ago | parent | next [-] |
| 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 8 hours ago | parent | next [-] | | "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 8 hours ago | parent [-] | | 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 8 hours ago | parent | prev | next [-] | | 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 7 hours ago | parent [-] | | 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 8 hours ago | parent | prev | next [-] | | It does not scale quadratically per client though, and the number given is per client. | | |
| ▲ | gafferongames 7 hours ago | parent [-] | | 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. |
| |
| ▲ | 8 hours ago | parent | prev [-] | | [deleted] |
|
|
| ▲ | avaer 8 hours ago | parent | prev [-] |
| 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 8 hours ago | parent [-] | | 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 8 hours ago | parent [-] | | 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 8 hours ago | parent [-] | | 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 8 hours ago | parent [-] | | 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 7 hours ago | parent [-] | | The number of players per-Fortnite server is 100 players. The number of players per-Battlefield server is 64 players. | | |
|
|
|
|
|
