Authoritative Game Servers in .io Games

Authoritative Game Servers

A key concept of developing .io games today is the authoritative game server. But what is that exactly?In general, this means that the game server is what all players report to, and the players have no say in what actually happens in the game. Lets go over some of the main concepts that govern this.

Player Input

Instead of the player sending their position, as many rookie .io game devs make the mistake of doing, the player should send their input (eg. WASD keys, space bar, etc.). Then, the server decides what to do with this input. In this way, the player has no way of faking their position, because the server is in total control of what the player's position is. This is the trick that prevents any sort of speed or teleportation hacking on .io game. This has the drawback that the server has to do all the work in calculating key physics, but it also means the player cannot hack these key mechanics of the game.

Interpolation and Prediction

Since the server then has to send the position back to the player, the player has to wait slightly for the server to respond before it moves the player sprite to the next position. This can make for some laggy, delayed gameplay. One trick to handle this is that the client already knows what input they put in, so they know generally what direction and speed they should move. This is called prediction, because the client can move before it recieves the information from the server. If the client is incorrect, however, the server will take over and there will be a jump back to a different position. I do not use prediction, because that sort of thing can cause more jittery annoyance than good in games. What I do use is interpolation. What this does is it makes the player move along a smooth path to the next position.

Server Broadcasting

Sending all the data for all the players would be wasteful for an otherwise efficient server. Therefore, broadcasting data is customized to each player. Authoritative servers usually only send the client nearby objects relative to their position. This means there is less data to send, it is all relevant to the client, and there is no chance that the other player can hack with additional information (since they won't have that info!). Usually, this process is accomplished by culling, or cutting off any objects besides those within the viewable rectangle of the player.

Lag Prevention

One problem with this model is that it means the server needs to be doing all of the game collisions and computations. It can prevent cheating, but it can also get laggy when the server is doing too much. Therefore, it is sometimes beneficial to give the client slightly more information than they need. Your client implementation should not use it to help the player benefit. If a hacker is crafty, they can figure out how to use it to their advantage, but the information should not be vital to the game. For example, if you do not want to compute whether a nearby player is actually visible to another player on the server, simply send that player to the client and the client will compute it instead. Of course, hackers could exploit this by figuring out where that player is anyway. That is what is usually happening when you have game hacks that can detect the outlines of other players.

Want to learn more? Join the Cavegame.io Discord to chat!