41–50 of 100 posts
Earlier quoted context omitted.
Is there any reason that transmitted data would be much larger than player inputs (e.g. keystrokes and mouse movement)?
Typically you send state, not inputs. To prevent cheating.
Earlier quoted context omitted.
It's a ludicrous amount of bandwidth even for a 1,000 player game, and a strong indicator that this developer is doing something very wrong.
It's like someone saying their project repo has 10-20GB of source. (btw game server network data is usually trivially and insanely compressible, far more than text)
For example, if you have n=1000 players, and m=2000 objects, the total number of object state updates that need to be sent out is n x m.
So a 1000 player space game with 1000 players, and 2000 objects (say, 1000 other players and 1000 AI ships...), and you have O(1000 x 2000) = 2,000,000
Compare this with a more typical FPS, let's say, n=32 and m=1000 (let's be generous...).
The amount of bandwidth for that game would be O(32 x 1000) = O(32000).
Given this, it's pretty easy to see how a 1000 player space game would send more bandwidth than a regular 32 player FPS, even if it did use all the standard tricks from first person shooters, eg. snapshots, delta encoding and all that.
There's just more state to send, and in total, roughly O(n^2) bandwidth as player count n increases.
Earlier quoted context omitted.
Typically you send state, not inputs. To prevent cheating.
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.
Earlier quoted context omitted.
It's like someone saying their project repo has 10-20GB of source. (btw game server network data is usually trivially and insanely compressible, far more than text)
Have you considered the O(n x m) issue with player counts? For example, if you have n=1000 players, and m=2000 objects, the total number of object state updates that need to be sent out is n x m. So a 1000 player space game with 1000 players, and 2000 objects (say, 1000 other players and 1000 AI ships...), and you have O(1000 x 2000) = 2,000,000 Compare this with a more typical FPS, let's say, n=32 and m=1000 (let's…
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.
Earlier quoted context omitted.
> I can't imagine a game that'd need that much data I can :)
Maybe instead of leaving drive by comments like this you can explain this to the overwhelming majority of people in this thread who think it's bananas.
Why limit yourself to bandwidth usage designed around the turn of the century?
It's 2026. We can do better :)
There is nothing "democratizing" about hosting your game's servers on AWS. Your game can have zero hosting cost if you just let players host their own servers. Let people play the game they paid for, forever, instead of locking them in to playing on an AWS server then killing the game in a couple of years when it's not profitable anymore.
Although I agree it’s more like subsidising than democratising (and the price will just go back up eventually), the “just let players host it” is overly simplistic. There are tons of reasons to not do that - for example, companies and games that have not embraced modding do not want to be competing with modified/unofficial versions of their own games’ servers (as well as the cheating issue that can bring with it)
Earlier quoted context omitted.
Have you considered the O(n x m) issue with player counts? For example, if you have n=1000 players, and m=2000 objects, the total number of object state updates that need to be sent out is n x m. So a 1000 player space game with 1000 players, and 2000 objects (say, 1000 other players and 1000 AI ships...), and you have O(1000 x 2000) = 2,000,000 Compare this with a more typical FPS, let's say, n=32 and m=1000 (let's…
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…
What if you could have a 1000 player FPS, and it was networked at the same fidelity of a AAA FPS? It would certainly use more bandwidth, but what if?
"This is because my space game sends a lot of bandwidth. 10-20 megabits per-second per-client" What is this game doing that uses so much bandwidth? Pretty sure most games use something like 2mbps.
It's a ludicrous amount of bandwidth even for a 1,000 player game, and a strong indicator that this developer is doing something very wrong.
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.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
It's a ludicrous amount of bandwidth even for a 1,000 player game, and a strong indicator that this developer is doing something very wrong.
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 sma…
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.