Interpolation vs. Prediction

For each entity, developers must choose whether it will be interpolated or predicted by players on their local machine. The right choice depends on a number of factors including the game’s genre, its usage of physics, the target player count, and the intended gameplay behavior and purpose of the entity.

Interpolated Entities

When an entity is not predicted, clients smoothly interpolate its state between updates received from the server. Since the entity is always interpolating to the most recent update received, the entity’s state will generally be slightly behind it in time. SnapNet automatically adjusts to network conditions as they change such that entities reach their most recent update just as new data is arriving from the server. This provides smooth motion while keeping latency as low as possible.

Advantages

• Minimal CPU cost: No client-side logic is executed for the entity other than simple interpolation.

• Accurate and smooth motion: Entities only travel through known good states sent by the server i.e., no warping or misprediction artifacts (see below).

• Server-rewindable: It is possible to perform backwards reconciliation on interpolated entities, allowing highly accurate hit detection for genres like shooters.

Disadvantages

• Immutable on clients: State can only be changed by the server. Any change resulting from local player input won’t be reflected until after more than a full packet round-trip time. This is because the client must send its input to the server, and then the server must send back the modified state of the entity before it can be displayed. For this reason, interpolation is generally not a good choice for entities that are driven by local player input.

• Out of sync with predicted entities: Because the state of interpolated entities are earlier than the latest received server update, while the state of predicted entities are later, interpolation can present a problem for game mechanics that require alignment with predicted entities. For example, consider a ball in a sports game—if you are controlling a predicted character and trying to align yourself with an interpolated ball you may position yourself at the correct position too late. For many gameplay mechanics—especially in the fighting and sports genres—this can make interpolation a deal-breaker.

Predicted Entities

When an entity is predicted, clients take the latest state of that entity as received from the server and then simulate it forward in time using the same logic that the server does. It is called prediction because the client is only making its best guess as to the future state of that entity. Because SnapNet is server-authoritative, the client won’t know the true state for sure until it arrives from the server. Exactly how far ahead the client simulates relative to the latest received state is determined by the project’s input delay and prediction settings.

Additionally, some entities require the input of their owning player in order to simulate correctly. For example, a player’s character in a third-person shooter probably requires that player’s input to know what direction to move next. Conversely, a rocket fired by that player probably does not. SnapNet allows this to be configured per-entity at run-time and will ensure that clients always have the subset of player inputs required for prediction. During prediction, the input for remote players—since their future input cannot be known—will always be identical to their most recent input state. In practice, this simple approximation for remote inputs leads to both the least mispredictions and the most forgivable corrections. One way to think about this is that it’s better to show a player doing something late than to show them doing something they never actually did.

Advantages

• Responsive: Actions performed by a local player can be applied to the entity right away. This is why it is generally recommended to predict entities that are directly controlled by local players, but it can even increase responsiveness for certain actions related to remotely controlled characters too. For example, if you press a button to activate an ability that stuns another player and disables their input, you will be able to see that state change and its consequences take effect immediately if you are predicting the other character forward in time.

• In sync with other predicted entities: In contrast to both of interpolation’s disadvantages above, predicted entities can be modified by the client simulation and are in sync from a timeline point of view with other predicted entities. Consider a game mechanic where a character controlled by one player can pick up and throw a character controlled by another. It is challenging to implement such a mechanic if both characters aren’t predicted. This is why prediction is generally favored over interpolation for certain genres where these types of interactions are common—like fighting and sports games.

Disadvantages

• Increased CPU cost: Because the client needs to perform rollback, reconciliation, and prediction, entities use much more CPU time if they are predicted.

• Misprediction: Divergence typically occurs when a remote player’s input is mispredicted, i.e., it was assumed to stay constant but actually changed. The longer the time horizon of prediction, the more likely it is that an input was mispredicted, and the further the game has diverged from the ground truth since then. A typical worst-case misprediction involves the player moving at their highest speed in one direction and then suddenly moving in the opposite direction e.g., holding the left thumbstick on the gamepad full-tilt in one direction and then instantly going full-tilt in the opposite direction. When this occurs, the rollback and reconciliation process pops the entity back into the correct state. Depending on how the game developer chooses to smooth over this discontinuity, this typically results in visual popping, teleporting, and/or rubber-banding. There are a number of strategies to mitigate these artifacts but they can never be completely eliminated when predicting entities driven by remote inputs. On the other hand, predicting entities driven by local player input is much safer and can typically be done over a much longer time horizon without significant artifacts since inputs are generally known.

• No server-rewind: It is not possible to perform perfect lag compensation for things like bullet traces against entities that are predicted. When the client predicts the simulation correctly, lag compensation isn’t necessary because players see opponents in the same place the server will see them. However, if the client mispredicts, the server has no way to validate where the client had predicted them to be. This can be a problem in genres like shooters where hit detection is often the number one priority.

General Guidance

Although there are exceptions to every rule, there are a couple of genre-specific recommendations that are generally good defaults:

• Fighting/Sports: We recommend all players predict all entities by default.
• Shooters: We recommend local players only predict entities they own/control while interpolating most others. However, you may want all players to predict projectiles that are deterministic once fired, like rockets, so they can be dodged effectively.