Cette page n’est pas encore traduite : la version anglaise est affichée.

Prediction & Lag Compensation

Prédire vers l’avant, compenser vers l’arrière, sur des données qui portent l’instant réel de chaque événement. Le client réagit instantanément, le serveur garde raison, et les tirs sont jugés dans la chronologie du tireur.

Quand l’utiliser

• L’entrée doit paraître instantanée malgré la latence, tandis que le serveur continue de faire autorité : prédire vers l’avant, réconcilier en cas de divergence.
• Les tirs doivent être jugés dans la chronologie du tireur : ResolveAt ramène les hitboxes au tick de vue annoncé.
• Les arcs de visée et les marqueurs d’impact doivent correspondre au résultat : le client et le serveur calculent la même Trajectory.
• Les champs critiques pour le jeu ne doivent jamais subir de rollback : déclarez ce qui se prédit et ce qui attend le serveur.
• L’effet élastique (rubber-banding) demande du réglage : fenêtres et tolérances par entité, télémétrie des erreurs de prédiction.
• Inutile quand la latence ne gêne pas. Les jeux au tour par tour ou lents tournent très bien avec de simples deltas de Data & Subscriptions.

Qui fait quoi

En bref

Le mot recouvre trois mécanismes distincts, avec des autorités et des modes de défaillance différents, et chacun a son article :

Quatre presets, et « no prediction » en fait partie.

Les jeux au tour par tour, les jeux de stratégie et la plupart des titres mobiles n’ont besoin d’aucune prédiction ; la déclarer indique au client d’afficher l’état tel qu’il est au lieu de deviner.

Le module ne possède ni modèle de mouvement, ni table de réactions, ni géométrie, ni fenêtre d’historique à lui. Ils appartiennent respectivement à Locomotion, Collision, Map et Entity. La prédiction les applique plus tôt ou les lit à rebours ; elle n’en déclare jamais une seconde copie.

[Entity("tank")]
[Prediction(ForwardTicks = 8, MaxRewindTicks = 64)]
public class Tank
{
    [Sync, Predicted] public Vector3 Position;                        // rolls back and replays
    [Sync, Predicted] public Vector3 Velocity;

    [Stat(Max = 100), AuthoritativeOnly] public Stat Hp;   // never predicted
}

@Entity('tank')
@Prediction({ forwardTicks: 8, maxRewindTicks: 64 })
export class Tank {
  @Sync() @Predicted() position!: Vector3;                    // rolls back and replays
  @Sync() @Predicted() velocity!: Vector3;

  @Stat({ max: 100 }) @AuthoritativeOnly() hp: Stat;   // never predicted
}

@entity("tank")
@prediction(forward_ticks=8, max_rewind_ticks=64)
class Tank:
    position: Vector3 = sync(predicted=True)                  # rolls back and replays
    velocity: Vector3 = sync(predicted=True)

    hp = stat(max=100, authoritative_only=True)   # never predicted

UCLASS(PSEntity = "tank", PSPrediction = (ForwardTicks = 8, MaxRewindTicks = 64))
class UTank : public UObject
{
    GENERATED_BODY()

    UPROPERTY(PSSync = (Predicted = "true")) FVector3f Position;   // rolls back and replays
    UPROPERTY(PSSync = (Predicted = "true")) FVector3f Velocity;

    UPROPERTY(PSStat = (Max = 100, AuthoritativeOnly = "true")) FPSStat Hp;   // never predicted
};
// declarations compile into the same pushed model — playserv push from the UE project or CI

[Entity("tank")]
[Prediction(ForwardTicks = 8, MaxRewindTicks = 64)]
public class Tank
{
    [Sync, Predicted] public Vector3 Position;                        // rolls back and replays
    [Sync, Predicted] public Vector3 Velocity;

    [Stat(Max = 100), AuthoritativeOnly] public Stat Hp;   // never predicted
}

La résolution avec compensation de latence (lag compensation) répond à la question « où était chacun au moment de ce tir » :

[After(Projectiles.HitReported)]
public static void Validate(HitReport hit) =>
    hit.ResolveAt(hit.ShooterViewTick);    // rewinds hitboxes, sub-tick interpolated

export const validate = after(Projectiles.hitReported, (hit: HitReport) =>
  hit.resolveAt(hit.shooterViewTick));    // rewinds hitboxes, sub-tick interpolated

@after(projectiles.hit_reported)
def validate(hit: HitReport):
    hit.resolve_at(hit.shooter_view_tick)    # rewinds hitboxes, sub-tick interpolated

La prévision de trajectoire est partagée par le serveur et le client (arcs de visée, marqueurs d’impact). C’est une opération de ce module, extrapolée contre les obstacles de la carte (map) : les deux côtés tracent le même arc à partir des mêmes entrées.

var arc = room.Prediction.Trajectory(from, velocity, steps: 30);   // collision-aware

const arc = room.prediction.trajectory(from, velocity, { steps: 30 });   // collision-aware

arc = room.prediction.trajectory(origin, velocity, steps=30)   # collision-aware

// collision-aware: the arc the platform itself would walk
Room->Prediction->Trajectories->Get(LaunchPosition, LaunchVelocity, /*Steps*/ 30,
    TPSOnResult<FPSTrajectory>::CreateWeakLambda(this, [this](const TPSResult<FPSTrajectory>& Result)
    {
        if (!Result.HasValue()) { return; }
        DrawArc(Result.Value());
    }));
// co_await support ships later: a built-in SDK coroutine wrapper that respects Unreal's GC and threading.

var arc = room.Prediction.Trajectory(from, velocity, steps: 30);   // collision-aware

Le modèle

La prédictibilité se déclare sur un aspect — et un aspect modifié uniquement par l’autorité, selon des règles que le client n’a pas, ne peut pas être marqué prédictible : c’est un échec de validation au déploiement, pas une surprise au runtime.

Ce qui se déclare.

Ce qui est rembobiné, et ce qui ne l’est volontairement pas.

client tick:  apply input locally (predict) → buffer it → send, tick-stamped
server tick:  step the same movement model → authoritative state → delta out
client recv:  authoritative state for tick T → if divergence beyond tolerance:
              rewind to T → replay buffered inputs T+1..now → smooth

Seuls les champs déclarés prédits subissent un rollback ; une petite dérive est lissée, une vraie divergence rembobine et rejoue.

Erreurs

• Un instant de vue hors de la fenêtre est un conflit : envoyez-en un actuel.
• Une requête d’historique hors de la fenêtre est, de même, un conflit.
• Deux défauts de déclaration sont détectés au déploiement : une fenêtre de compensation plus grande que le tampon d’historique, et un aspect marqué prédictible alors que le client n’a pas les règles pour le prédire. Aucun des deux ne peut atteindre un match en cours.
• Deux situations ne sont pas des erreurs, et toutes deux sont observables. Un tampon d’entrées plein suspend la prédiction jusqu’à confirmation au lieu d’écarter des entrées en silence ; et une divergence au-delà du seuil signifie que l’état de l’autorité est accepté tel quel : c’est la correction déclarée, pas une panne.

Limites

Les chiffres arriveront avec le chapitre sur les limites de la plateforme ; ce qui se passe à chaque plafond est déjà fixé.

• La fenêtre de compensation : au-delà, un refus, jamais une extrapolation.
• La fenêtre d’extrapolation pour les autres : l’entité est marquée périmée et l’extrapolation s’arrête.
• Le tampon des entrées non confirmées : la prédiction est suspendue jusqu’à confirmation ; les entrées ne sont jamais écartées en silence.
• La profondeur d’historique pour un rembobinage : au moins égale à la fenêtre de compensation, vérifiée au déploiement.
• La fréquence des actions portant un instant de vue : une limitation de débit, avec une échéance.
• Entités prédites simultanément par client : au-delà du plafond, la prédiction n’a pas lieu, et c’est une dégradation déclarée, pas un refus.