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

Lag Compensation

C’est le mécanisme du serveur, et celui dont les erreurs coûtent la vie à un joueur — au profit de celui qui a la pire connexion. Tout ce qui suit sur cette page découle de cette asymétrie.

La question à laquelle répond la compensation de latence (lag compensation) est étroite : qu’a réellement vu le tireur ? Une action peut porter un instant de vue (view time), le tick que l’acteur regardait au moment d’agir, et la plateforme restaure les poses des cibles à ce tick pour juger le tir sur ce qu’il y avait à son écran.

L’instant de vue est une affirmation, pas un fait

Il vient du client : c’est donc une affirmation de l’appelant, traitée comme telle. Deux conséquences :

• La fenêtre de compensation est bornée, et hors de cette fenêtre la plateforme refuse. Elle n’extrapole pas pour rendre service : un refus est une décision que vous voyez, une extrapolation silencieuse en est une que vous ne voyez pas.
• Lire l’état passé d’une cible reste soumis à la visibilité. Interroger un tick passé ne permet pas de contourner Visibility — ce que vous ne pouviez pas voir alors, vous ne pouvez pas le lire maintenant.

Et « le tir n’a pas compté » est un verdict, pas une erreur : une réponse réussie, accompagnée d’une raison lisible par la machine.

Ce qui subit le rollback est déclaré, et ce n’est pas tout

Tout ramener en arrière produit des doubles kills : deux joueurs se tirent dessus, tous deux sont rembobinés à un moment où ils sont vivants, tous deux touchent. Ne rien ramener en arrière annule la compensation de latence elle-même. La frontière entre les deux est une liste déclarée.

Le rembobinage lui-même se fait ici, et non dans les modules rembobinés. L’anneau d’historique restaure les poses du tick contesté, puis on pose à Collision sa question de chevauchement habituelle sur ces poses — le module Collision ne garde aucun historique et rien en lui ne sait ce qu’est un tick de vue. L’anneau lui-même est la piste d’historique de l’entité, pas un second stockage.

La décision se prend sur le passé, l’effet s’applique au présent

La compensation de latence répond à une question sur l’instant de vue du tireur. Les conséquences — dégâts, mort, récompense — s’appliquent à l’état actuel. Ce qui s’est passé entre l’instant de vue et l’instant de la décision n’est ni annulé ni recalculé.

La re-simulation côté serveur n’est pas prévue. Recalculer des conséquences face à une nouvelle vérité exige un point de référence fixe, que l’état en virgule flottante ne nous donne pas. Il reste tout ce sur quoi repose le module : un client qui rejoue ses propres entrées non confirmées (Prédire son propre mouvement), et la compensation de latence comme lecture du passé pour une seule décision. C’est ainsi que fonctionne l’avantage au tireur, en pratique.

Si vous venez d’ailleurs

• La compensation de latence avec avantage au tireur (favour-the-shooter), telle que la livrent la plupart des shooters compétitifs : c’est le même mécanisme, et cette page le décrit.
• Le netcode à rollback complet. Le rembobinage est là ; le rejeu du monde après coup ne l’est pas, et le paragraphe ci-dessus explique pourquoi. Si votre design suppose que les conséquences soient recalculées après coup, c’est cette dépendance qu’il faut soulever avec nous tôt plutôt que de la découvrir tard.

Bon à savoir aussi

• L’implémentation peut être surchargée. Si votre jeu a besoin d’une autre règle de compensation, vous pouvez remplacer la nôtre, et le remplacement déclare lesquelles des déclarations il respecte.
• Il n’y a pas de points d’extension sur le chemin de la prédiction et de la correction. Ils tournent à la fréquence du tick.
• Rien de tout cela ne s’applique en autorité externe. La compensation de latence existe pour les salles (room) que fait tourner la simulation de la plateforme. Quand le tick appartient au serveur de jeu d’un studio ou à un client maître, la compensation revient à celui qui l’exécute — voir Qui exécute le tick.