In this part of the written version of our webinar, we will discuss (server) authority in more detail. You can also watch the section on this subject in the recording of our webinar above, it will automatically start at the correct section. Please remember to accept all cookies, otherwise the video might not show up for you.
Let me first explain what I mean by authority. Authority refers to the decisions you make during game development in terms of what actions, logic, and verification you run on your server process. If running any process at all. It also refers to what actions, logic, and verification you trust to run purely on the client. This in effect, has a tremendous impact on your future hosting costs, and in my opinion, should always be taken into consideration to prevent surprises at a later stage.
Historically a lot of games used a peer-to-peer (P2P) model with no server in between. The problem with peer-to-peer is that connectivity problems rise exponentially the more players you have participating in a single session. Secondly, the only verification in place, is from one client (usually the “host”) towards the other clients, leading to a sub-optimal scenario in terms of latency (host advantage), security, and cheats. And thirdly, assuming all players can connect to the host, the upload bandwidth that is available becomes a critical factor for an enjoyable player experience.
Companies realized that while a peer-to-peer setup, with no burden on hosting costs, is not a sustainable model if you wish to earn more revenue from your game after release, as the player experience varies wildly, not exactly helps in driving sales. You need to take some control over the online experience of the player.
So, what are the options; if you have a game where most of your logic and actions can be trusted to be done by the client (or between clients in a match)? You could simply go for a server build that acts as nothing more than what we call a hole puncher, or NAT (network address translation) punch-through.
A NAT punch-through is extremely lightweight; you can run many of them on a single machine and VM. It is only used as a point in the middle for all players to connect to, so they can connect with each other. So, although there are bandwidth costs, the infrastructure cost can be minimized. If future needs arise for server-side verification, you can opt to add it part by part.
The more server-side needs of your game, the heavier this server instance needs to be, and thus, the higher the cost per player of your game. For example, a famous game with cars still uses a relatively lightweight instance, but already has more logic added to it than the NAT punch-through model I described before.
Shooters were the reason server instances were created in game hosting at all, think of Unreal Tournament 99, Starsiege Tribes, Counter-Strike, Quake etc; The reason for that is that you want your server to verify and be in control over who shoots and moves where. You also want it to control who gets hit and who does not. If the server is working on hitbox calculations, map data, positioning, it starts to become quite a process.
Now imagine you’re not dealing with a 4 vs 4, or 8 vs 8, but 64 vs 64 or 99 player battle royale maps; this should make clear what it does with the requirements of the server application. The heaviest server builds we’ve seen are games that are MMO-Like games with stored/shared progression, lots of loot drops, very large maps with many players’ interactions in the same area. This results in a lot of server-side processing and as a result, requires dedicated hardware setups.
These games are an example where the focus has been on server authority; we don’t trust the client for the majority of things because it impacts player experience, cheating, gameplay, and thus impacts revenue, while also costing more to host later on.
However, you should also ask the question ‘Do we really need this to be server-side verified?’ and “Isn’t there a smarter way to do this or to use fewer resources?” with every game feature. This way you can ensure your hosting costs don’t go over the top compared to your planned income.
One real-life example is a well-known knight-fighting game. This game was released using a peer-to-peer model, even though there were a lot of plans for a live game with future content. As the number of players who can participate in a single match is not large, peer-to-peer seems like something which could work. However, in today’s world, there is simply too much interference and unpredictability on the consumer (clients) side. Badly configured routes not supporting UPNP, random firewalls, IPv6 translations… there were a lot of reasons why two clients are not able to directly talk to each other.
The game’s online experience at launch was troubled by resyncs, disconnected matches, bad matchmaking. In short, the player experience was not optimal. This was recognized and shortly after the game moved from a peer-to-peer model to one which uses tiny VM’s with a simple NAT punch-through and some server logic. This greatly improved the player experience, and since then it has turned into a successful live game.
While developing your game, you should seriously consider what type of server authority you want for your game. For most live-games, I would not recommend a simple peer-to-peer model since it can heavily affect the player experience and potential income of your game.