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)

> I can't imagine a game that'd need that much data

I can :)

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.

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.

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.

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.

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.

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.

It's sending inputs that makes preventing cheating easier.

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

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.

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.

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.

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.

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.