Multiplayer tutorial 1: concepts

Favourite 204 favourites
Tutorial written by AshleyOriginally published on 3rd, March 2014 - 4 revisions

Preventing cheating

If the peers told the host where they were and what they were doing in the game, and the host trusted them, peers could cheat. They'd simply need to suddenly send data saying they were the other side of a wall, or that they'd attacked a player they couldn't reach, and so on. To mitigate this, instead the peers only tell the host their inputs, such as which arrow keys they are currently holding down. The host receives this and starts moving that player, and sending data back telling that player where it thinks they are.

The immediate problem with this is that it adds a delay to all the player inputs. If a player presses 'Left' with a latency of 100ms, the host will receive that input 100ms after it was pressed. Then it will take another 100ms for the host's update with the new player position to arrive back. This would mean all the peer's controls feel very laggy, only taking effect after a significant fraction of a second. To resolve this, the peer's local game uses local input prediction.

Local input prediction

Instead, pressing left will send a message to the host saying the input was pressed, then that player's local game starts moving them anyway, without waiting for confirmation from the host! Since the host and the peer are running the same game, they generally match up pretty closely. Then the player gets controls which feel responsive, and they still can't cheat: they are only sending their inputs, and can't pretend to be somewhere else. Even if they hacked their local game, it only serves to disadvantage themselves, since all they can do is show themselves as being in the wrong place compared to the host.

The peer's player will however inevitably drift off the position that the host sees them. There are lots of small errors that can accumulate in network timing, framerate synchronisation, delta-time measurements and so on. The peer is still receiving messages from the host saying where they are, but the messages are delayed. In the previous example, the peer receives their position from the host with a total delay of 200ms. To correct deviations, the multiplayer engine looks at the object history and compares where it was 200ms ago. In other words, corrections are made looking at where the object was in the past, taking in to account the latency to the host. If the object is in the wrong place, the multiplayer engine will gradually move it to compensate. This happens over time to try to make it less noticable. In extreme cases a large and noticable correction will be necessary, but under good network conditions the movement matches up closely and small adjustments are made in a way that are difficult to spot.

Input prediction for peers
It's worth noting this is not limited to positions. The multiplayer engine has the ability to do all this synchronisation with any instance variable, not just X and Y co-ordinates.


Under poor network conditions, there can be obvious effects on gameplay. Gamers commonly refer to these problems as "lag". It can include rough motion (when the 80ms update buffer is empty), jumps or discontinuities in gameplay (when packet loss occurs and the next update significantly change the game state), the player suddenly changing position (when local input prediction encounters a large error), or consequences that appear unfair (usually the result of each player seeing the game with a different delay, and the host making an authoritative decision in favour of one particular peer).

Unfortunately there is no good solution to permanently avoid these problems, other than to find a better quality Internet connection. These problems usually only occur under severe circumstances, such as complete packet loss for a few seconds, or sudden and extreme temporary changes in latency or PDV. In such cases it is almost impossible for the various compensation techniques to cover it up. This is sometimes simply the reality of communication over the Internet.

Share and Copy this Tutorial

You are free to copy, distribute, transmit and adapt this work with correct attribution. Click for more info.


stefanos 3,478 rep

Yeah that's nice :)

Monday, March 03, 2014 at 8:36:42 PM
Vallhalen 3,062 rep


Monday, March 03, 2014 at 8:43:51 PM
Leandrus 5,876 rep


Monday, March 03, 2014 at 8:55:27 PM
SgtConti 4,931 rep

Very interesting, hopefully the beta release comes tomorrow ;)

Monday, March 03, 2014 at 9:02:03 PM
DUTOIT 12.7k rep

Fantastic :)

Monday, March 03, 2014 at 9:05:34 PM
emoaeden 9,699 rep

I can't wait to try this !

Monday, March 03, 2014 at 9:07:53 PM
NeoBiel 4,566 rep

Meu sonho se realizando...

Monday, March 03, 2014 at 9:08:29 PM
albrektv 8,106 rep

Thank you for the lesson that you are waiting for him

Monday, March 03, 2014 at 9:11:31 PM
valdarko 6,297 rep

how it will handle data save, like itens and stuff?

Monday, March 03, 2014 at 9:33:35 PM
Joskin 6,089 rep

Yes ! Thanks a lot !

Monday, March 03, 2014 at 10:23:48 PM
jobel 16.7k rep

I'm very excited to go through this! thanks!

Monday, March 03, 2014 at 10:35:05 PM
DatapawWolf 30.8k rep

I notice this does not address the subject of host cheating. Preventing the clients is nice and all, but, for example, say the host hacks their client, they could now send whatever they want to the peers.

Now you could say that anti-cheating measures and checks could be implemented, but then you could apply that same logic to each client as well.

Thoughts, anyone?

Monday, March 03, 2014 at 11:17:34 PM
popyui 2,344 rep

Me gusta mucho esto y me da una mejor idea de como funcionan mis juegos de mis consolas

Monday, March 03, 2014 at 11:19:48 PM
DatapawWolf 30.8k rep

Also, not to spam, but addressing the "Lag Compensation" techniques. I'm sorry but if a player has a bad connection in a shooter game, too bad for them. Newer games in the Call of Duty series have notoriously infuriating lag comp which is responsible for all sorts of nonsense.

In my opinion it's a technique that is often overused and should not be looked as much as interpolation or other ways of synchronizing between peers.

Monday, March 03, 2014 at 11:29:12 PM
DatapawWolf 30.8k rep

"By default updates are sent 30 times a second"
We will be able to modify this, correct? Or send out updates only when needed? It'd be wasteful to constantly spew out that much data for something like a grid/turn based game, where movement may be as low as 1 grid square per 100ms, or not at all when a player is AFK.

Monday, March 03, 2014 at 11:32:42 PM

Leave a comment

Everyone is welcome to leave their thoughts! Register a new account or login.