Live data from Hacker News

The best thing that's ever happened for multiplayer games?

mas-bandwidth.com

81–90 of 100 posts

Re: The best thing that's ever happened for multiplayer games?

#81

Earlier quoted context omitted.

If a normal game sends 2mbps, then 20mbps would be 10 times as many objects.

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.

The space game has 1000 players. Most FPS games today have a maximum of 100 players.

Let's assume these FPS games send 1mbps - 2mbps per-client (many send less, some send more) but it's a good range to start with.

Now increase the player count from 100 to 1000. The number of objects that needs to be sent from server to client also 10Xs, because you need to send state for each player visible to each client, so that client can actually see the other players moving around. The end result is bandwidth is now approximately 10X what it was before, or 10-20mbps.

To address your question around RTS and inputs. Game developers usually end up using state synchronization methods (sending the positions, rotations etc per-object) instead of relying on input based deterministic methods whatever player counts are high. My personal threshold is around 4 players.

This is the reason FPS games and other higher player count games usually send state instead of just inputs. Because if they were to rely on a deterministic simulation synchronized only by inputs like an RTS, the server would have to wait for input from the the most lagged player before it could step the server simulation forward, and with regular internet jitter, packet loss and so on, as the player count increases it becomes more and more likely that the game will hitch and stutter waiting for these inputs.

So the answer is, bandwidth sent per-client scales with the number of players in the game, and games with higher player counts tend to send state instead of just inputs for the reasons above.

cheers

Re: The best thing that's ever happened for multiplayer games?

#82

Earlier quoted context omitted.

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

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

Do you think its just parsing and throwing it away?

Re: The best thing that's ever happened for multiplayer games?

#83
post #46

Earlier quoted context omitted.

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.

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 everybo…

By "player hosted servers", I meant players rent a server box with Hetzner or OVH or a managed server with a provider like Nitrado. Local player hosted servers have never really worked for anything more than LAN.

Re: The best thing that's ever happened for multiplayer games?

#84

Earlier quoted context omitted.

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.

The space game has 1000 players. Most FPS games today have a maximum of 100 players. Let's assume these FPS games send 1mbps - 2mbps per-client (many send less, some send more) but it's a good range to start with. Now increase the player count from 100 to 1000. The number of objects that needs to be sent from server to client also 10Xs, because you need to send state for each player visible to each client, so that cl…

I don't think anyone disagrees that linearly scaling of traffic scales linearly. What they're getting at, why would you still use that rather implementing something more efficient? Like Battlefield games (bf4?) did, using different update rates for nearby and distant players.

Would also argue that RTS inputs are different from fps as in general you give commands to units, like go here in move/attack mode, and they do it for you. In fps your inputs control a character directly. So they can use different methods of conveying progress of state. And an fps game can use both methods, like doing deterministic physics for objects. Also don't need to wait for inputs just because its deterministic simulation?

Re: The best thing that's ever happened for multiplayer games?

#85

Earlier quoted context omitted.

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

Do you think its just parsing and throwing it away?

> Do you think its just parsing and throwing it away?

No. Why would anybody think this?

I'm not talking hypothetically btw. Everything I'm talking here about I have already implemented to production quality. So when I say something like, "so and so is not a big CPU problem when you code it right", I really mean it, because I have actually implemented it and found this to be true.

Re: The best thing that's ever happened for multiplayer games?

#86

Earlier quoted context omitted.

The space game has 1000 players. Most FPS games today have a maximum of 100 players. Let's assume these FPS games send 1mbps - 2mbps per-client (many send less, some send more) but it's a good range to start with. Now increase the player count from 100 to 1000. The number of objects that needs to be sent from server to client also 10Xs, because you need to send state for each player visible to each client, so that cl…

I don't think anyone disagrees that linearly scaling of traffic scales linearly. What they're getting at, why would you still use that rather implementing something more efficient? Like Battlefield games (bf4?) did, using different update rates for nearby and distant players. Would also argue that RTS inputs are different from fps as in general you give commands to units, like go here in move/attack mode, and they do…

> I don't think anyone disagrees that linearly scaling of traffic scales linearly. What they're getting at, why would you still use that rather implementing something more efficient? Like Battlefield games (bf4?) did, using different update rates for nearby and distant players.

I guess my confusion/frustration comes from this sort of default, "wow, that's a lot of bandwidth, umm I guess somewhere he must be doing something really inefficient" train of thought that I see so many commenters are going through in this thread.

What if it wasn't inefficient. What if what I'm describing is actually using the 10-20mbps and packing in an appropriate amount of game that justifies that amount of bandwidth on top of already doing all the smart compression techniques?

Think of it like this, what if you did all the compression and bandwidth optimization techniques available, and instead of targeting 1-2mbps, you just used the additional bandwidth to fit in more game? More players. Greater object density. A bigger world. More networked objects. Higher tick rate. There are any number of dimensions you can expand along.

Nobody is suggesting "LOL, bandwidth is free now, make the same game, but be lazy and have it take up 10-20mbps! hahah".

The industry doesn't take kindly to the same things over and over, players want novelty. So give it to them!

Re: The best thing that's ever happened for multiplayer games?

#87
post #23

Earlier quoted context omitted.

If a normal game sends 2mbps, then 20mbps would be 10 times as many objects.

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.

> A 6v6 game of Forged Alliance (12 players each moving hundreds of units around, many with simulated projectile weapons) uses 0.3mbps.

Yes, because it's networked via deterministic lockstep and it sends only inputs.

Other games genres like FPS use a different network model and send object state. This means their bandwidth is proportional to how many objects there are in the world (or how many objects are relevant to each player).

Re: The best thing that's ever happened for multiplayer games?

#88

Earlier quoted context omitted.

I don't think anyone disagrees that linearly scaling of traffic scales linearly. What they're getting at, why would you still use that rather implementing something more efficient? Like Battlefield games (bf4?) did, using different update rates for nearby and distant players. Would also argue that RTS inputs are different from fps as in general you give commands to units, like go here in move/attack mode, and they do…

> I don't think anyone disagrees that linearly scaling of traffic scales linearly. What they're getting at, why would you still use that rather implementing something more efficient? Like Battlefield games (bf4?) did, using different update rates for nearby and distant players. I guess my confusion/frustration comes from this sort of default, "wow, that's a lot of bandwidth, umm I guess somewhere he must be doing som…

Then its fine, but its not what was described, and I guess that is what people had issues with as just scaling player numbers without optimization wouldn't work great right?

Good luck with your game though, great if it works, but seems like many large player count games cut corners to simplify things.

Re: The best thing that's ever happened for multiplayer games?

#89

Earlier quoted context omitted.

> I don't think anyone disagrees that linearly scaling of traffic scales linearly. What they're getting at, why would you still use that rather implementing something more efficient? Like Battlefield games (bf4?) did, using different update rates for nearby and distant players. I guess my confusion/frustration comes from this sort of default, "wow, that's a lot of bandwidth, umm I guess somewhere he must be doing som…

Then its fine, but its not what was described, and I guess that is what people had issues with as just scaling player numbers without optimization wouldn't work great right? Good luck with your game though, great if it works, but seems like many large player count games cut corners to simplify things.

> Then its fine, but its not what was described, and I guess that is what people had issues with as just scaling player numbers without optimization wouldn't work great right?

I never said anything about scaling numbers without optimization.

If a game is already optimized, and you scale up numbers, the game doesn't suddenly become unoptimized just because n or m increases.

You just have more stuff.

Re: The best thing that's ever happened for multiplayer games?

#90
post #54

Earlier quoted context omitted.

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 th…

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.
Post reply on HN