Netcode à rollback : rejeu déterministe et effets de bord maîtrisés

Anticiper, puis corriger

Le rollback permet à un jeu d'avancer alors que certaines entrées distantes ne sont pas encore connues. Lorsqu'une hypothèse se révèle fausse, la simulation revient à un état antérieur et rattrape son retard avec les entrées corrigées. Le joueur doit obtenir une réponse locale immédiate, mais l'implémentation doit pouvoir revenir sur un travail qui semblait déjà accompli.

Le contrat de rejeu

Le rollback classique, fondé uniquement sur les entrées, exige une simulation déterministe à partir du même état et des mêmes entrées ; cet article porte sur cette architecture. Les variantes qui synchronisent l'état ont d'autres exigences. L'explication de l'architecture par SnapNet couvre la prédiction des entrées, la restauration et le rejeu. [1] L'interface d'intégration de GGPO exige des callbacks de sauvegarde/chargement de l'état du jeu et d'avancement d'une frame, ce qui fait de la propriété de l'état une responsabilité de l'application. [2]

Exemple détaillé

Prenons un client fictif qui a terminé la frame 105 après avoir prédit l'entrée distante de la frame 102. L'entrée réelle arrive et diffère de la prédiction. On restaure l'état sauvegardé à la fin de la frame 101, puis on simule les frames 102, 103, 104 et 105 avec l'entrée corrigée et les entrées conservées pour chaque frame. Cela fait quatre frames rejouées avant toute nouvelle frame.

Si un état sauvegardé occupe 256 KiB, conserver 8 états de ce type coûte 2048 KiB, soit 2 MiB, sans compter les entrées, les métadonnées ni le surcoût d'allocation. Ces tailles sont hypothétiques et ne proviennent pas d'un benchmark. L'état sauvegardé le plus ancien borne aussi la profondeur de restauration de ce tampon précis ; lors du décompte, indiquez explicitement si les snapshots correspondent au début ou à la fin des frames.

Démarche d'implémentation

Recensez toutes les valeurs qui influent sur le gameplay futur : ordre de création des entités, timers, état du générateur aléatoire, timing des coups dépendant des animations et commandes en file d'attente. Sérialisez-les ou reconstruisez-les de façon reproductible. N'utilisez ni l'heure réelle ni l'ordre de complétion d'opérations asynchrones non contrôlées comme entrées cachées de la simulation.

Rejouez deux fois le même enregistrement d'entrées et comparez, frame par frame, des hashes d'état canoniques. Au premier écart, examinez les différences structurées de l'état plutôt que la seule position finale du personnage. Provoquez ensuite des rollbacks forcés, même sur une connexion locale. Profilez la fenêtre de rejeu la plus défavorable prise en charge, conjointement avec le travail ordinaire de rendu et de simulation.

Effets de bord et limites

Donnez aux effets prédits des identités d'événement stables. Un registre d'effets permet de distinguer un son déjà joué d'un événement nouvellement découvert après le rejeu. Décidez quels effets peuvent être annulés, lesquels peuvent aller à leur terme malgré une correction, et quels résultats irréversibles attendent une confirmation. [1]

Le déterminisme peut être mis en défaut par le comportement des flottants, l'ordre d'itération ou un état manquant. Des fenêtres de prédiction plus longues augmentent l'exposition aux corrections et le volume de rejeu. Définissez la reprise à adopter lorsqu'une entrée est plus ancienne que l'historique conservé ou que le budget de calcul est épuisé. Le délai d'entrée peut être un levier complémentaire délibéré ; le rollback ne supprime pas la latence et ne garantit pas des corrections invisibles.

Sources

[1] Netcode architectures: rollback — SnapNet.

[2] GGPO integration interface — Tony Cannon and GGPO contributors.