Lagger Compensation

rough draft

There's always a player who can barely run the game. Perhaps their internet connection has a lot of packetloss, or their computer is generally laggy and freezes frequently. But thanks to clientside prediction and rewind our game feels playable. While enhacing the accessibility of a game is an accomplishment, it comes with some downsides. These downsides don't affect the lagger themselves, but affect other player's view of the lagger.

Laggy movement compensation

To mitigate players skipping or teleporting, we create two entities for each player. One entity is moved directly via commands. The second entity is programmed to *smoothly* follow the first entity. Voila no more laggy movement!

If the smoothed entity and the raw entity diverge by too much, then we must rubberband the laggy entity.

To make it so that the player can be attacked fairly, we make sure our server-side collision logic checks for hits against the smoothed version of the entity.

Laggy shot compensation (or other commands)

The historian returns us past state at our request - there's nothing automagic about it. At the time that we request the past state we can put a cap on how far back we go (for example 250 ms) and this will precisely control the degree to which laggy players deal damage to other players who have already reached cover. We can even perform this query twice with different limits, one for PvP and another for PvE (lag comp is great in PvE).