Rollback-Netcode: deterministisches Replay und kontrollierte Seiteneffekte

Vorauslaufen, dann korrigieren

Rollback erlaubt es einem Spiel, fortzuschreiten, obwohl einzelne Eingaben der Gegenseite noch unbekannt sind. Erweist sich eine Annahme als falsch, kehrt die Simulation zu einem früheren Zustand zurück und holt mit der korrigierten Eingabe wieder auf. Spielende sollen unmittelbar lokal Rückmeldung erhalten, die Implementierung muss aber darauf ausgelegt sein, Arbeit erneut auszuführen, die scheinbar bereits erledigt war.

Der Replay-Vertrag

Klassisches Rollback, das nur Eingaben austauscht, setzt eine deterministische Simulation voraus: Gleicher Zustand und gleiche Eingaben müssen zum gleichen Ergebnis führen. Dieser Artikel behandelt genau diese Architektur. Varianten, die den Zustand synchronisieren, stellen andere Anforderungen. Die Architekturbeschreibung von SnapNet behandelt Eingabevorhersage, Wiederherstellung und Replay. [1] Die Integrationsschnittstelle von GGPO verlangt Callbacks zum Speichern und Laden des Spielzustands sowie zum Vorrücken um einen Frame; die Verantwortung für den Zustand liegt damit bei der Anwendung. [2]

Durchgerechnetes Beispiel

Ein beispielhafter Client hat Frame 105 abgeschlossen, nachdem er die Eingabe der Gegenseite für Frame 102 vorhergesagt hat. Die tatsächliche Eingabe trifft ein und weicht ab. Der gespeicherte Zustand am Ende von Frame 101 wird wiederhergestellt; anschliessend werden die Frames 102, 103, 104 und 105 mit der korrigierten Eingabe und den jeweils aufbewahrten Eingaben neu simuliert. Das sind vier wiederholte Frames, bevor ein weiterer neuer Frame berechnet wird.

Belegt ein gespeicherter Zustand 256 KiB, kosten 8 solcher Zustände 2048 KiB bzw. 2 MiB, ohne Eingaben, Metadaten und Allokations-Overhead. Dies sind hypothetische Grössen, keine Benchmark-Ergebnisse. Der älteste gespeicherte Zustand begrenzt zudem, wie weit dieser konkrete Puffer zurückgehen kann; beim Zählen ist ausdrücklich festzulegen, ob die Snapshots den Anfang oder das Ende eines Frames darstellen.

Ablauf der Implementierung

Jeder Wert, der das künftige Spielgeschehen beeinflusst, ist zu erfassen: Reihenfolge der Entitätserzeugung, Timer, Zustand des Zufallsgenerators, von Animationen abhängiges Treffer-Timing und eingereihte Befehle. Diese Werte sind reproduzierbar zu serialisieren oder zu rekonstruieren. Weder Systemzeit noch unkontrollierte Abschlussreihenfolge asynchroner Operationen dürfen als verdeckte Eingaben in die Simulation einfliessen.

Dieselbe Eingabeaufzeichnung wird zweimal abgespielt, und die kanonischen Zustands-Hashes werden Frame für Frame verglichen. Beim ersten Unterschied sind die strukturierten Zustandsdifferenzen zu untersuchen, nicht nur die Endposition der Spielfigur. Danach werden erzwungene Rollbacks auch bei einer lokalen Verbindung ausgelöst. Das ungünstigste unterstützte Replay-Fenster ist zusammen mit der gewöhnlichen Render- und Simulationsarbeit zu profilieren.

Seiteneffekte und Grenzen

Vorhergesagten Effekten sind stabile Ereignisidentitäten zuzuweisen. Ein Effekt-Ledger kann nach einem Replay unterscheiden, ob ein Sound bereits abgespielt wurde oder ob es sich um ein neu entdecktes Ereignis handelt. Festzulegen ist, welche Effekte abgebrochen werden können, welche trotz Korrektur zu Ende laufen dürfen und bei welchen unumkehrbaren Ergebnissen auf die Bestätigung gewartet wird. [1]

Determinismus kann durch Gleitkommaverhalten, Iterationsreihenfolge oder fehlenden Zustand verloren gehen. Längere Vorhersagefenster erhöhen die Anfälligkeit für Korrekturen und den Replay-Aufwand. Zu definieren ist, wie die Wiederherstellung abläuft, wenn eine Eingabe älter ist als die aufbewahrte Historie oder das Arbeitsbudget erschöpft ist. Eingabeverzögerung (Input Delay) kann eine bewusst ergänzende Massnahme sein; Rollback beseitigt weder Latenz, noch garantiert es unsichtbare Korrekturen.

Quellen

[1] Netcode architectures: rollback — SnapNet.

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