Skip to content
This repository has been archived by the owner on Jul 27, 2019. It is now read-only.

Authoritative Server Foundations

João Borks edited this page Mar 18, 2018 · 9 revisions

Why do I need an authoritative server?

Because humans. People will cheat on your game and try to make fun of it, leaving the other players uncomfortable and probably annoyed. You have probably been there before, or maybe you were the cheater! In order to prevent this type of behavior on a multiplayer game, the server must be have control over players' actions, then all players can experience a more balanced gameplay. Still there will be other ways of hacking, but on the client-side such as seeing the others through walls, auto aiming, and these sort of things. Those can be treated in a different way and will not be covered on this (as authoritative server is a hell of a huge thing itself).

How does it work?

Basically, whatever action that happens from the client-side, must first be sent to the server and then the server acknowledges this action sending a response. That's it, that is the authoritative server concept. Ideally, every client should only control what the player is going to control, like the player character. All other stuff should be controlled by the server, like AI entities, interactive objects, etc. So again, in short, the authoritative server concept is:

Client Input > Server Acknowledge > Server Response > Client Update

Patience

It sounds easy and simple, right? Yeah right, but we need to remember there is a little bit of lag because of the network. We need some extra stuff to make it work seamlessly. Right now with this implementation, we would notice a delay between when we input something and when it actually executes, which would probably make it unplayable or pretty much not enjoyable in common scenarios. That's where the other concepts come to aid! To help balance the experience with an authoritative server we have: client-side prediction, server reconciliation, entity interpolation and lag compensation.

I'll give a quick explanation of each one, and then we can expand on their specific pages. Client-side Prediction acts exactly on this delay we just talked about. Once the client inputs an action, it gets immediately executed as a prediction of the result. Then once the server responds, the client performs a Server Reconciliation, to confirm the prediction and make corrections if needed. That works pretty well when you have a client and a server only. When adding another client we need to get it running smoothly as well, but considering we are receiving only a few updates per second compared to the regular game update. Therefore we need to perform Entity Interpolation to smoothly display the observed client movement and actions between the sync updates. By doing this, the observed clients are displayed in the past relative to their own time. Finally, as a design choice we may implement Lag Compensation, which basically allows the server to simulate the moment that a client made an input to detect a hit, as the observed client is displayed in the past. The server in this case will need to rollback a few ticks to perform the detection.

I think that's good for the authoritative server, you probably get it. I guess you're ready to move on to the next page :D

🏠Home | ⏮ Framework Progression | [⏭ Server Component]

Clone this wiki locally