Compensating for network conditions
To minimise bandwidth and packet loss, by default the multiplayer engine transmits data up to 30 times a second. Games typically render at 60 frames per second, so this means data is only sent approximately every other frame.
Compensating for peers
Peers will be receiving data from the host indicating object data, such as their positions. If they simply directly displayed what was received, object movements would appear choppy as they only get updated every other frame. They would also move irregularly, with the updates subject to PDV and packet loss.
To improve the gameplay experience, the multiplayer engine interpolates between updates for values like X and Y co-ordinates. In the case of positions, it will linearly interpolate between updates. For example if data is coming in every other frame, then the frame which does not receive an update will use a value half way between the two updates either side. This makes the motion smooth again without needing any more data.
However when rendering an interpolated frame, it does not know what the next value is yet, because that will arrive in the future! Instead of using a time machine, the multiplayer engine solves this by adding an artificial extra delay of 80ms for the peers. This means the multiplayer engine can know about the next few updates ahead of what it is currently rendering. Even if the next update is missing due to packet loss, it may be able to use the next update after that to interpolate towards. Even if poor network conditions mean there are no updates for 80ms, the engine can keep extrapolating from the direction of the previous two updates. This however is just guesswork, and the object might jump if the next update shows the object has in fact gone somewhere else.
The multiplayer engine allows you to use three possible interpolation modes for values: linear (such as for object positions), angular (such as for object angles), and none (for data that should not be interpolated, like a boolean indicating if a laser is on or not).
Latency variations
It should be noted that the latency can change. For example a routing device somewhere may become overloaded, and the data between two players suddenly gets re-routed down a different path which is slower; or perhaps a new faster path becomes available. Latencies sometimes also gradually improve in the first minute or so after connecting, as the devices along the connection route gradually optimise the connection and figure out the fastest possible path. The latency is constantly re-measured to detect such variations.
If the latency decreases, the multiplayer engine temporarily runs the game in a very slight fast-forward so it reduces how far behind you are seeing the game. On the other hand, if the latency increases it very slightly runs the game in slow-motion and increases how far behind you are seeing the game. This is necessary to avoid the choppy, irregular movement that occurs when the 80ms delay no longer covers any updates. These adaptations should happen slowly enough to be imperceptible, but it helps ensure the best possible experience even if the connection quality varies during the game.
Compensating for the host
The host has the authoritative version of the game. They have zero latency, since there is no need to transmit data to themselves. In other words, the host is participating in the "real" game, and the peers are doing their best to render the same game with delayed and possibly irregular updates from the host. The host has a slight gameplay advantage as a result.
You might think that the host would need to interpolate between updates of the object positions received from peers. This actually does not happen, because the peers should not tell the host where they are. In fact, the host should tell the peers where they are. The reason for this is covered in the next section.