nengi Tutorial 1: Authoritative Server Model

The model of network programming we’ll be using with nengi is called the authoritative server model, or sometimes the server authoritative model. What does this mean? Well, we’re talking about games here, so it means that whatever happens in the game is decided by our server side code. “How do players actually affect the game world if the server decides everything?” you may be wondering. And that really is the question at the heart of network programming.

The answer is both simple and complex. I’ll give you the simple answer now, but the complex answer is where we’ll go when we explore varying methods of lag compensation such as clientside prediction and rewound collisions. The simple answer is that the player asks the server, very politely, if it wouldn’t mind changing something about the game.

So let’s talk about the flow of data associated with the server authoritative model, because it has a certain elegant simplicity.

  1. User performs an action
  2. Server receives action, and scrutinizes it
  3. Server changes something about the game world (maybe)
  4. Server sends out the new state of the game world
  5. User sees the effect of their action (maybe)

This is unidirectional. For the user to affect the game world all of these steps are followed in order. This is how we move, shoot, loot, chat, and do anything else in a game with an authoritative server.

Pretty simple right? Let’s talk for a moment about a game that does not treat the game server as the authority.

If we were to hastily convert a single player game to a multiplayer game, we might do so by implementing a connect feature, and then a feature where we send out our player position every frame to anyone we’re connected to. What kind of model is this? Peer to peer. If the game were very simple this might work. If the game has npcs and items and an interactable environment we need to do a lot more to get those working. We’ve got to decide which of the peers is going to actually host the game and be the “authority” on the state (position, hitpoints, etc) of the npcs and everything else. This would be peer to peer where one of the peers is the host or authority (a reasonably common networking model). This is already starting to resemble a true authoritative server model in scope of work, but it still has a lot of problems.

First, the players are sending their positions to the host (or to each other, if true peer to peer). If a hacker feels like modifying their game client, they can have super speed or teleportation. If the game clients handles collisions with the world, well a hacker might just elect not to run the collision code locally and move through solid objects. If the game client handles dealing damage itself, then a hacker will tamper with the logic and gain the ability to instantly kill everyone in the game. If the players’ inventories exist primarily on their own game client, then a hacker can create any piece of gear or amount of wealth. Overall, the game is very vulnerable to hacking. This isn’t a server-authoritative game, it is a client-authoritative game, where the client is a potentially modifiable program being distributed to end users. That means the authority is potentially owned by hackers.

Ultimately, the more we want to reduce hacking, the more we need to head towards an authoritative server model. Even if we want to produce a peer to peer game where the players are allowed mod the game server, we’d still want it server-authoritative. Afterall, what is the point of letting people mod the server code if the game client is the actual authority? Some hacked clients would just run around destroying everything for everyone.

So hopefully that clears up why we would set out to follow an authoritative server model.

Next: nengi Intro 2: State & API Overview