Higher player counts and more detailed worlds? It's 2026 and we regularly watch 4k video streams @ 25mbps. Seems like games should be able to get away with sending this amount of bandwidth too for a higher fidelity experience.

▲

JohnMakin 9 hours ago | parent | next [-]

You don't really ever stream games in normal situations in the same manner though. The content is mostly rendered client side, why does the server need so much bandwidth?

▲

8 hours ago | parent | next [-]

[deleted]

▲

gafferongames 9 hours ago | parent | prev [-]

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

▲

axus 8 hours ago | parent | next [-]

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.

▲

gafferongames 2 hours ago | parent [-]

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

	▲	axus an hour ago \| parent [-]
		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.

▲

frollogaston 8 hours ago | parent | prev | next [-]

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.

▲

mvdtnz 8 hours ago | parent | prev | next [-]

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.

	▲	bluefirebrand 8 hours ago \| parent [-]
		I was going to say this too. Games don't need to send much data to sync game state across clients

▲

thunderfork 8 hours ago | parent | prev [-]

If you're using stream compression, 20mbps would likely be a lot more than 10 times as many objects (and you shouldn't be serializing the whole state every update, and... yadda yadda)

You can fit a lot of game in 2mbit/s with a little bit of work.

	▲	gafferongames 8 hours ago \| parent [-]
		> 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.

▲

xnx 8 hours ago | parent | prev | next [-]

Is there any reason that transmitted data would be much larger than player inputs (e.g. keystrokes and mouse movement)?

▲

gafferongames 8 hours ago | parent | next [-]

Some games are networked deterministically, so that you can send only the inputs, and the game plays out exactly the same way (down to a checksum matching for all game state in memory across all players).

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.

	▲	frollogaston 8 hours ago \| parent \| next [-]
		Haha of course it's Age of Empires. The lag was insane because out of 8 players, there'd always be that one guy. AoE2 also had bugs with determinism, causing games to sometimes end because one person went out of sync. Even the HD remake had those issues. The even later DE remake seems to have fixed it, but it still depends on this really finicky math library that doesn't work exactly right in Wine/Proton.
	▲	LoganDark 8 hours ago \| parent \| prev [-]
		Oh hey! I sometimes play a game called Cosmoteer that has deterministic lockstep multiplayer. That means in multiplayer every game has to synchronize on the exact same tick, receive all inputs from all other players and apply them on their exact same ticks, etc. The entire session is bottlenecked by the slowest player's machine. But it's very cool. 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.

▲

kridsdale1 8 hours ago | parent | prev [-]

Typically you send state, not inputs. To prevent cheating.

▲

seba_dos1 8 hours ago | parent | next [-]

It's sending inputs that makes preventing cheating easier.

▲

frollogaston 8 hours ago | parent | prev | next [-]

Some genres of games (like RTS) typically do send inputs instead of state. Cheating is indeed possible.

	▲	gafferongames 7 hours ago \| parent [-]
		Cheating in the sense of breaking fog of war, because the client has to actually have the whole game state in memory due to deterministic synchronization. Yes.

▲

LoganDark 8 hours ago | parent | prev [-]

Huh? If the server trusts the client to send state then the client could potentially send invalid or unfair state. If the client merely sends inputs then it can't just decide to manipulate the state that way.

▲

frollogaston 8 hours ago | parent [-]

He means the server sends state to the clients, rather than sending other clients' inputs (or just P2P if no server). There are games that send inputs, which means if it's a game of limited information, clients know more than they should.

	▲	LoganDark 8 hours ago \| parent [-]
		Ah, I get it now. I actually know a game that sends inputs (I commented elsewhere in the thread, the game is Cosmoteer). But yes, most games I'm aware of send state.

▲

thunderfork 8 hours ago | parent | prev [-]

Game data and video data have very different constraints. Depends on the nature of the game, of course, but with jitter and all that, video can just run a buffer and manage network conditions (more) trivially, but a game needs things to be a lot tighter to avoid gameplay-impacting desync

	▲	8 hours ago \| parent \| next [-]
		[deleted]
	▲	gafferongames 8 hours ago \| parent \| prev [-]
		It's true plus you cannot just send a snapshot of 100 kilobytes or so from server to client with 1500 byte MTU with regular IPv4 packet fragmentation and reassembly due to packet loss amplification effects.