Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mas-bandwidth.com

Post reply on HN
Print view View original

71–80 of 100 posts

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

#71

Post by [deleted] »

gafferongames wrote: post #69
frollogaston wrote: post #65

Earlier quoted context omitted.

My question and its followups have all been reasonable and non-assuming. I was interested in some more details, but not anymore, best of luck.

This thread absolutely has not been full of reasonable and non-assuming questions. 1. "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" 2. "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" 3. "overwhelming majority of people…

[deleted]

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

#72

Post by gafferongames »

gafferongames wrote: post #66
frollogaston wrote: post #52

Earlier quoted context omitted.

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.

The number of players per-Fortnite server is 100 players. The number of players per-Battlefield server is 64 players.

Furthermore, Fortnite "Cannot support more than 100 players" according to Tim Sweeney. https://www.gamespot.com/articles/fortnite-cannot-support-mo...

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

#73

Post by gafferongames »

axus wrote: post #40
gafferongames wrote: post #11

Earlier quoted context omitted.

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.

> At the absolute worst, a room full of 32-players in Quake 3: Arena would be sending 120 kilobits per second to each player.

OK I'll bite.

Quake 3: Arena supports 32 players. What if it supported 1000 players?

1000/32 = 31.25

theoretical quake 3 but with 1000 players (all visible) would be:

31.25 x 120 kilobits per-second = 3,750 kilobits per-second = 3.75 mbps sent per-client.

now make quake 3 more interesting by putting in 1000 NPCs in to interact with, so 2000 total objects -> double the bandwidth to 7.5 mbps per-client.

fill the rest of the bandwidth with weapon data (one shots), sounds, fx and other random events -> 10mbps is pretty easy to hit, maybe even go over, especially if a lot of stuff is going on in the level.

> Fortnite peaks at ~400 kbps during the initial 100-player drop and goes down from there.

Fortnite has 100 players.

Theoretically, if it supported 1000 players, then you would multiply bandwidth by 10 if all other players were visible, or if you had the 1000 players in the same size world, so on average you would see 10X more players than before with relevancy / culling by distance or LoS.

400 kbps x 10 -> 4000 kbps -> 4 mbps sent per-client.

Now make it more fun and add 1000 NPC characters to the level, 2000 characters per-level total.

8 mbps per-client for theoretical, 1000 player Fortnite w. 1000 NPC characters in the level.

> I understand that those are big budget games, but there is a lot of room for improvement in 10000 kbps.

This is simply not true. It would be really great if you guys would do some light math before making statements like this.

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

#74

Post by axus »

gafferongames wrote: post #73
axus wrote: post #40

Earlier quoted context omitted.

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.

> At the absolute worst, a room full of 32-players in Quake 3: Arena would be sending 120 kilobits per second to each player. OK I'll bite. Quake 3: Arena supports 32 players. What if it supported 1000 players? 1000/32 = 31.25 theoretical quake 3 but with 1000 players (all visible) would be: 31.25 x 120 kilobits per-second = 3,750 kilobits per-second = 3.75 mbps sent per-client. now make quake 3 more interesting by p…

Why are all 1000 players visible to each other at once? The numbers I quoted were worst case, not a baseline.

Streaming sounds and FX every single time and never caching is a choice that will lead to 10Mbps, but completely unnecessary. All you "really need" is initial state, the timestamps / inputs of the other players, and reproducible physics.

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

#75

Post by thunderfork »

gafferongames wrote: post #70
gafferongames wrote: post #64

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.

20 megabits per-second is 2.5 megabytes per second. Do you really think PCs have difficulty processing 2.5 megabytes of data per-second in 2026?

Taking 2.5 megabytes per second of compressed new state information, uncompressing it, and applying it (across the "thousands and thousands of networked entities", etc, that keep being talked about) to the game state? All the memory thrash that implies, along with the knock-on effects (animation updates, yadda yadda)?

Yeah, that has a performance cost.

Will this impact a big-money gaming rig? Probably not? Will it run good on the Steam Deck? Probably not.

Generally, in a game loop, all this stuff is going to be single-threaded and blocking, right? It's mutating the game state, that's the classic why-games-suck-at-thriving-on-many-small-cores problem. So your performance capacity ends up being tighter than you might think relative to other "ingest data" tasks.

Let's say your game's networking runs at 30 ticks a second, and you've done a great job in uncoupling rendering from the game loop, so you're lucky enough to not have to worry about that. You still only have 30ms, on a single thread, to handle networking (likely no special kernel-skipping stuff on clients!), unpack, apply and propagate your changes, and also do your local game loop stuff. If you miss that interval once, the game starts to fall behind and feel bad to play.

Now, you could say "lower the tick rate", but then you'd need less data, too, and your game gets less responsive (fine for some games, not for others)

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

#76

Post by thunderfork »

gafferongames wrote: post #69
frollogaston wrote: post #65

Earlier quoted context omitted.

My question and its followups have all been reasonable and non-assuming. I was interested in some more details, but not anymore, best of luck.

This thread absolutely has not been full of reasonable and non-assuming questions. 1. "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" 2. "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" 3. "overwhelming majority of people…

The person you're replying to isn't me (the person you're quoting above), but to be clear:

I'm not trying to be insulting, here, it's just kind of a bizarre, eyebrow-raising thing to see. There's a reason you're not seeing any AAA games doing this, y'know?

If you're doing something that's really unusual, you're going to have people going "this is really unusual".

Please don't take this the wrong way - this is sincere, well-intentioned advice: have you ever watched Shark Tank? The best people on there can still give a good pitch when their ideas are challenged.

The games industry - and especially the multiplayer games space - are brutal, and players are going to be way more critical, way more rudely, than anyone on HN.

It would benefit you and your game greatly to practice selling your idea in the face of criticism and doubt.

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

#77

Post by gafferongames »

thunderfork wrote: post #75
gafferongames wrote: post #70

Earlier quoted context omitted.

20 megabits per-second is 2.5 megabytes per second. Do you really think PCs have difficulty processing 2.5 megabytes of data per-second in 2026?

Taking 2.5 megabytes per second of compressed new state information, uncompressing it, and applying it (across the "thousands and thousands of networked entities", etc, that keep being talked about) to the game state? All the memory thrash that implies, along with the knock-on effects (animation updates, yadda yadda)? Yeah, that has a performance cost. Will this impact a big-money gaming rig? Probably not? Will it ru…

> Will this impact a big-money gaming rig? Probably not? Will it run good on the Steam Deck? Probably not.

Runs fine on steam deck. Runs fine old on 10 year old PC. It's really not that expensive, if you code it correctly (which means data oriented programming, programming in a cache aware way and going wide for everything to distribute load when possible).

But this is how modern games are coded anyway. See ECS/DOTS for Unity and so on. Based on similar techniques we've been using for a decade+ on game consoles.

> Generally, in a game loop, all this stuff is going to be single-threaded and blocking, right?

No. Once you go above 100 players you usually to go wide for pretty much everything across multiple threads, even on the client. But obviously on the server, you go really wide.

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

#78

Post by gafferongames »

thunderfork wrote: post #76
gafferongames wrote: post #69

Earlier quoted context omitted.

This thread absolutely has not been full of reasonable and non-assuming questions. 1. "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" 2. "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" 3. "overwhelming majority of people…

The person you're replying to isn't me (the person you're quoting above), but to be clear: I'm not trying to be insulting, here, it's just kind of a bizarre, eyebrow-raising thing to see. There's a reason you're not seeing any AAA games doing this, y'know? If you're doing something that's really unusual, you're going to have people going "this is really unusual". Please don't take this the wrong way - this is sincere…

Hey, I want to make something really clear to you. I'm a professional game developer and I write netcode for AAA games for a living. I wrote large parts of the netcode for Titanfall 2 and Apex Legends.

> There's a reason you're not seeing any AAA games doing this, y'know?

Yes, it's because bandwidth used to be really expensive (both in bare metal and cloud) and now in many cases it's less so, and in some cases totally free (AWS GameLift). This is big news that is relevant to other professional multiplayer game developers, the readers of my website https://mas-bandwidth.com

It's also because most game developers don't have the skills (or time) to write completely custom netcode for their game, so they are limited to existing solutions which tend to max out around 100 players for historical reasons.

> It would benefit you and your game greatly to practice selling your idea in the face of criticism and doubt.

But I'm not here to sell my idea to you. I'm just a professional game developer who wrote an article about how free egress bandwidth for game servers in AWS is big news for multiplayer games, with some basic analysis about what it might cause in the game industry moving forward.

Take it or leave it man.

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

#79

Post by [deleted] »

axus wrote: post #74
gafferongames wrote: post #73

Earlier quoted context omitted.

> At the absolute worst, a room full of 32-players in Quake 3: Arena would be sending 120 kilobits per second to each player. OK I'll bite. Quake 3: Arena supports 32 players. What if it supported 1000 players? 1000/32 = 31.25 theoretical quake 3 but with 1000 players (all visible) would be: 31.25 x 120 kilobits per-second = 3,750 kilobits per-second = 3.75 mbps sent per-client. now make quake 3 more interesting by p…

Why are all 1000 players visible to each other at once? The numbers I quoted were worst case, not a baseline. Streaming sounds and FX every single time and never caching is a choice that will lead to 10Mbps, but completely unnecessary. All you "really need" is initial state, the timestamps / inputs of the other players, and reproducible physics.

[deleted]

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

#80

Post by gafferongames »

axus wrote: post #74
gafferongames wrote: post #73

Earlier quoted context omitted.

> At the absolute worst, a room full of 32-players in Quake 3: Arena would be sending 120 kilobits per second to each player. OK I'll bite. Quake 3: Arena supports 32 players. What if it supported 1000 players? 1000/32 = 31.25 theoretical quake 3 but with 1000 players (all visible) would be: 31.25 x 120 kilobits per-second = 3,750 kilobits per-second = 3.75 mbps sent per-client. now make quake 3 more interesting by p…

Why are all 1000 players visible to each other at once? The numbers I quoted were worst case, not a baseline. Streaming sounds and FX every single time and never caching is a choice that will lead to 10Mbps, but completely unnecessary. All you "really need" is initial state, the timestamps / inputs of the other players, and reproducible physics.

I really want to just stop here and ask you what you expect will happen if you take a multiplayer game with n players and increase it to have 10 times the player count (10n).

Do you expect bandwidth sent per-player will:

a) stay the same b) decrease c) increase

?

> Streaming sounds and FX every single time and never caching is a choice that will lead to 10Mbps

Nobody is suggesting streaming sounds and FX like this.

If it helps you, completely ignore my comment about sounds and FX. Focus instead on how the per-player bandwidth has scaled up, eerily close to 10mbps per-client, when you take any of the classic games you mentioned, and scale their player count up to 1000 players and see what happens.

> All you "really need" is initial state, the timestamps / inputs of the other players, and reproducible physics.

Yes, this approach works for low player count games, but as player counts increase the probability that you'll be stuck waiting for the most lagged player to deliver input to the server approaches 1.

So no, this is not all you really need. This approach doesn't work well for high player count games (I wouldn't use it for any game with more than 4 players personally).

Post reply on HN