Hacker News Reader

Comment by 10000truths | Hacker News Reader

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.

View on HN

"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.

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.

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.

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.

Why would you wait for inputs on server? That's a stupid idea. You can rollback on the server when mis-predicted inputs arrive late.

You are correct. You can do that. Then the real cost becomes the extra CPU cost of the rollback. Better not be CPU bound with that physics simulation, because you might need to roll back a whole second worth of physics in less than 1/60th of a second of real-time.

It does not scale quadratically per client though, and the number given is per client.

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.

Again, this games claims to send 10-20mbps per client. The quadratic part would be the full outgoing from the server, those numbers are not the full outgoing. The full outgoing is claimed to be 10-20 *gigabits* per second.

Having 10 times the data from 10 times the players is not quadratic.

> Again, this games claims to send 10-20mbps per client. The quadratic part would be the full outgoing from the server, those numbers are not the full outgoing. The full outgoing is claimed to be 10-20 gigabits per second.

Per-client bandwidth -> O(n), where n is the number of players. 10 - 20mbps for this game per-client. Let's say n=1000. O(n) because each client needs to receive state for n other players (yes, each client also receives state for its own local player too)

Total bandwidth sent from server -> O(n*n), where n is the number of players. Since the server sends 10-20mbps per-client, and there are 1000 clients the total bandwidth sent from the server is 1000 * 10-20mbps -> 10-20gbps.

Where the quadratic comes in: When you increase from n=100 to n=1000, per-client bandwidth increases by only 10X, but total bandwidth increases by 10*10=100X O(n*n), because packets are now being sent to 10X the clients, but ALSO and the bandwidth sent per-client is 10X (because each client now has 10X players it needs to receive state for).

Thus quadratic. FIN.

This is getting tiring, so I'm only going to try to clarify one more time and I'm not going to bother replying again.

We agree that the total bandwidth is quadratic. However, that was NOT THE DISCUSSION. It is irrelevant to the discussion because it was NOT THE DISCUSSION.

I'm specifically, replying to the comment up thread that brought up the 10-20mbps number from your article, which then got replied to calling it quadratic. This 10-20mbps number is the PER CLIENT bandwidth. I am not talking about the 10-20gbps number. The PER CLIENT bandwidth is not quadratic, since it scales linearly per player.

Thus, the PER CLIENT bandwidth is not quadratic. FIN.

Also:

It should have read like this:

Let's say typical games send 1-2 megabits per-second *per-client* 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)"

It's correct elsewhere. Sorry it did not include the per-client in the mention above in this thread. I can see this is what threw you off.

Reply on news.ycombinator.com