Rembobinage côté serveur pour la détection de touches avec compensation de latence

Quel instant le joueur a-t-il visé ?

Une cible distante affichée sur un client représente un état antérieur du monde. Lorsqu'une attaque parvient au serveur, ne tester que la position actuelle de la cible peut donner un résultat différent de ce que le joueur voyait. Le rembobinage côté serveur (server rewind) répond à ce problème de timing par un test de touche sur l'historique ; il n'autorise pas un client à déclarer des dégâts.

Un historique, sous autorité bornée

Riot décrit un rembobinage de l'état des cibles vers l'instant vu par le tireur, avec une limite de rembobinage pour préserver l'équité. [1] L'implémentation de Valve conserve l'historique des joueurs, vérifie le timing, tient compte du délai d'interpolation et restaure l'état modifié temporairement une fois la compensation effectuée. [2] La politique exacte dépend du jeu ; un test de touche historique n'a pas besoin de rejouer toute la simulation.

Exemple détaillé

Supposons un serveur fictif qui reçoit un tir à 12.000 s et valide l'instant vu par le tireur à 11.880 s. Le rembobinage demandé est de 120 ms, ce qui reste dans la limite de 200 ms choisie pour ce jeu. Aucun de ces deux chiffres n'est une valeur par défaut d'un moteur.

L'historique contient les positions du centre de la cible 2.0 m à 11.875 s et 2.5 m à 11.900 s. Pour un segment où l'interpolation linéaire est autorisée, la fraction vaut (11.880 - 11.875) / (11.900 - 11.875) = 0.2, ce qui donne 2.1 m. Il faut alors tester le tir validé contre la géométrie de touche historique à cet instant, puis appliquer le résultat accepté selon les règles de jeu autoritatives actuelles.

Si une téléportation sépare ces deux échantillons, l'interpolation inventerait des positions qui n'ont jamais existé. Il faut alors marquer cette discontinuité et appliquer à la place une politique explicite de rejet ou d'échantillonnage.

Démarche d'implémentation

Définissez le périmètre du rembobinage : joueurs, hitboxes animées, portes mobiles ou autres éléments occultants pertinents. Combiner une cible historique avec un couvert à l'état présent peut produire des résultats qu'aucun des deux participants n'a vus ; choisissez la règle voulue et documentez-la.

Validez la séquence de l'attaque, les bornes de timing, l'éligibilité de l'arme, les munitions et l'origine plausible du tir. N'acceptez pas des horodatages arbitraires fournis par le client comme des demandes d'historique faisant foi. Stockez assez de données de pose pour reconstruire la représentation de touche retenue, y compris une identité liée au cycle de vie, afin qu'une entité recyclée n'hérite pas de l'historique d'une autre cible.

Privilégiez, lorsque c'est possible, des requêtes historiques isolées. Si des objets du monde actif sont déplacés temporairement, garantissez leur restauration quel que soit le chemin de sortie, et empêchez toute autre logique de jeu d'observer ce monde temporaire.

Équité et diagnostic

De plus grandes fenêtres d'historique acceptent des vues plus anciennes, mais allongent la durée pendant laquelle un défenseur peut encore être touché après s'être mis en sécurité en apparence. Des fenêtres plus petites rejettent davantage d'attaques retardées. Ce compromis ne peut pas être supprimé par une comptabilité parfaite.

Enregistrez les instants demandé et accepté, la disponibilité de l'historique, le motif de rejet et la géométrie testée. Testez les latences inégales, les pics de latence, les couverts mobiles, la réapparition et les horodatages aux limites. Expliquez le retour de touche de façon cohérente avec la politique retenue, plutôt que de promettre que l'image de chaque client représente un présent unique et partagé.

Sources

[1] Peeking into VALORANT's netcode — Riot Games.

[2] Source SDK lag compensation — Valve.