Oh shit and I forgot NAT issues. Depending on NAT, some players simply cannot host a game (without a relay server), no matter what they do.
709 karma · joined November 26, 2014
* 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 everybody's connection gets really bad for 60 seconds.
* At least in the USA, internet connections are highly asymmetric. It's getting better now, but 10-20 years ago, the vast majority of players would only have enough bandwidth to send and receive one client's worth of bandwidth, and would not be able to upload bandwidth for all players, especially as player counts increased.
* Cheating. The player hosting the server on their machine (if a PC) could modify code and/or memory to cheat.
* Lag switching / network shaping. The player hosting the server could time out, lag out or ruin the experience for a player they don't like.
* Host advantage. The final one is that the player hosting the server has zero lag, so has a huge advantage over other players.
For a competitive game at least, it's much better in 2026 to host your servers somewhere secure, or to have player hosted servers in a secure provider that doesn't let players do any of the things above.
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.
A larger more detailed world with a higher player count, networked using quake style netcode techniques ala. Counterstrike, Titanfall, Apex Legends with snapshots and delta compression, client side prediction and lag compensation.
In short, FPS netcode scaled up to 1000 players, but applied to a space game, not an FPS, because the world doesn't need another FPS right now...
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.
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?
Why limit yourself to bandwidth usage designed around the turn of the century?
It's 2026. We can do better :)
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.
And you can fit exactly 10X the game in 20mbps with the same amount of work, plus some AF_XDP magic.
I can :)
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.
And yet, everything I wrote in the article is true.
Obviously, nobody actually spent that. At scale people would negotiate better deals.
The reason why this is a big deal is that now small games, or studios who launch their first game and don't have any real clout yet can get a really good deal from AWS by default.
I think this will result in most new games electing to host in AWS Gamelift by default, due to the difficulty of procuring enough bare metal at launch on favorable terms
For example, working out how much bare metal and in which locations to order? It's really difficult to work out when you are launching a game and you don't know how successful the game will be.
Now studios can just scale elastically up/down at launch, find out their base load and maybe bare metal can beat it, or maybe not, but AWS is competitive now with bare metal for games, and easier to spin up and adjust your fleet, vs. old-school purchase by the month and 30 days notice to shut down bare metal :)
Point taken. I'll just ask the AI to make me a really fun AAA multiplayer game next time I work on one.
Using this technology to build anything remotely serious, OR EVEN GAMES, is wildly stupid.