Deterministisches Netcode erklärt: Prediction, Rollback und Latenzkompensation

Zwei Spieler drücken im selben Augenblick dieselbe Taste. Auf dem Sofa ist das Ergebnis sofort und identisch. Über das Internet müssen diese Eingaben einen Round Trip durch Router, Stau und Physik überstehen. Licht in Glasfaser braucht mehrere zehn Millisekunden, um einen Ozean zu überqueren, und echte Internetpfade fügen oben drauf Warteschlangen und Jitter hinzu. Jedes kompetitive Onlinespiel ist deshalb eine Übung in Täuschung: Spieler glauben zu lassen, ihre Aktionen wirkten sofort, während die Wahrheit noch durch das Netz unterwegs ist.

Zum Weiterlesen: Epic Games setzt bei seinem verschobenen Disney-Shooter auf KI-First · Google startet Playground, eine KI-Plattform, die aus Prompts spielbare Spiele baut.

Das ist die Geschichte der Tricks hinter dieser Illusion (Prediction, deterministische Simulation, Rollback und Latenzkompensation), warum es jeden gibt, was er kostet und warum ein Fighting Game, ein Echtzeit-Strategiespiel und ein Shooter dasselbe Problem auf wirklich unterschiedliche Weise lösen.

Die Randbedingung: Latenz lässt sich nicht vermeiden

Ein vernetztes Spiel hat eine Autorität (meist einen Server), die entscheidet, was real ist. Die Eingabe eines Spielers muss diese Autorität erreichen, verarbeitet werden, und der resultierende Zustand muss zurückkommen. Dieser Round Trip ist der Ping, und er ist nie null.

Bei 60 Bildern pro Sekunde dauert ein Frame 16,7 Millisekunden. Ein völlig normaler Ping von 100 ms umfasst daher etwa sechs Frames zwischen dem Tastendruck und der Reaktion der Welt. Für ein rundenbasiertes Spiel ist das irrelevant. Für ein Fighting Game, in dem ein einzelnes Frame entscheidet, ob eine Combo trifft, oder für einen Arena-Shooter, in dem ein Headshot eine Frage von Graden ist, ist es das ganze Problem.

Spiele greifen es von zwei Seiten an: die Zukunft vorhersagen und später korrigieren, oder die Eingabe des lokalen Spielers verzögern, damit entfernte Spieler Zeit haben aufzuholen. Fast jeder echte Netcode ist eine Mischung aus beidem.

Client-Prediction und Server-Abgleich

Das einfachste Modell (Eingabe senden, auf den Server warten, das Ergebnis zeichnen) fühlt sich kaputt an. Das ursprüngliche Quake funktionierte so, und die Spieler spürten jede Millisekunde davon.

Die Lösung, populär gemacht von QuakeWorld und dokumentiert von Gabriel Gambetta, besteht darin, den Client denselben Bewegungs-Code lokal ausführen zu lassen, sobald eine Taste gedrückt wird, während der Server autoritativ bleibt. Client und Server müssen sich nur über die eigene Figur des Spielers weitgehend einig sein, also sagt der Client diese Figur sofort voraus.

Wenn das Update des Servers eintrifft, überschreibt es nicht einfach die Welt des Clients. Stattdessen sagt es sinngemäß: Hier ist der autoritative Zustand, und hier ist die letzte Eingabesequenznummer, die ich verarbeitet habe. Der Client verwirft die Eingaben, die der Server bereits bestätigt hat, setzt auf den Serverzustand zurück und spielt dann die Eingaben erneut ab, die der Server noch nicht gesehen hat.

# Client, jeder feste Simulations-Tick
inputs = sample_local_input()
send_to_server(tick, inputs)
buffer[tick] = inputs

state = simulate(state, inputs)          # jetzt handeln, nicht warten

# Wenn ein autoritatives Update eintrifft...
on_server_update(server_state, acked_tick):
    state = server_state
    for t in range(acked_tick + 1, current_tick + 1):
        state = simulate(state, buffer[t])   # nicht bestätigte Eingabe erneut abspielen

Dieses erneute Abspielen ist der Kern des Server-Abgleichs. Es hält den Spieler reaktionsfähig und den Server in der Verantwortung. Korrekturen sind selten (derselbe deterministische Bewegungs-Code auf denselben Eingaben stimmt meist überein), und sie werden geglättet statt hart umgesetzt.

Client-Prediction funktioniert am besten, wenn ein Ergebnis überwiegend von der eigenen Eingabe des lokalen Spielers abhängt. Sie kann zum Beispiel nicht vorhersagen, von jemandem erschossen zu werden, den der Spieler nicht sieht; diese Art von Ereignis kommt als Korrektur vom Server.

Determinismus, Festkomma-Arithmetik und Lockstep

Eine andere Familie von Spielen sagt überhaupt nichts voraus. Sie sendet nur Eingaben und lässt jede Maschine die exakt gleiche Simulation ausführen. Wenn der Startzustand identisch ist und die Eingaben identisch sind, bleiben die Ergebnisse für immer identisch. Das ist das Lockstep-Modell, beschrieben im klassischen Age-of-Empires-Paper "1500 Archers on a 28.8".

Lockstep beruht auf Determinismus: Für einen gegebenen Spielzustand und eine gegebene Menge von Eingaben muss das Weiterschalten um einen Tick auf jeder Maschine dasselbe Ergebnis liefern.

Gleitkomma-Arithmetik (der Standard in den meisten Engines) ist für grundlegende Operationen IEEE-754-konform, aber nicht garantiert bit-für-bit reproduzierbar über verschiedene CPUs, Compiler, Optimierungseinstellungen oder sogar Debug- und Release-Builds hinweg. Glenn Fiedlers Überblick zum Gleitkomma-Determinismus sammelt die Leidensgeschichten: transzendente Funktionen, die sich zwischen AMD und Intel unterscheiden, Engines, die die FPU-Präzision und den Rundungsmodus beim Start festnageln, und Projekte, die Gleitkomma vollständig aus dem Gameplay verbannen.

Die robuste Antwort ist Festkomma-Arithmetik: Zahlen, die als skalierte Ganzzahlen gespeichert werden, etwa ein Q16.16-Layout mit 16 Bits für den ganzzahligen Teil und 16 für den Bruchteil. Festkomma hat weniger Wertebereich und kann langsamer sein als native Floats, rundet aber vorhersagbar und liefert überall identische Ergebnisse. Auch Zufallszahlengeneratoren müssen deterministisch sein, identisch geseedet und im Gleichschritt weitergeschaltet, damit jeder Tick dieselben Würfe bekommt. Spiele tauschen routinemäßig Zustands-Checksummen aus, um eine Desynchronisation zu erkennen, sobald sie beginnt.

Determinismus ist nicht umsonst, und er ist zerbrechlich. Jede versteckte Abhängigkeit von Iterationsreihenfolge, Threading oder einem Physik-Solver von Drittanbietern kann ihn brechen. Aber er erkauft etwas Mächtiges: Weil nur Eingaben übertragen werden, bleibt die Bandbreite auch bei Tausenden Einheiten klein.

Eingabeverzögerung: die einfachste ehrliche Lösung

Der direkteste Weg, mit Latenz umzugehen, ist zu warten. Input-Delay tastet die Eingabe des lokalen Spielers ab und hält sie ein paar Frames lang fest, bevor simuliert wird, sodass entfernte Eingaben Zeit haben anzukommen. Input-Delay ist trivial korrekt und braucht keine Prediction, aber die Verzögerung ist real und der Spieler spürt sie.

GGPO, das wegweisende Rollback-SDK, behandelt Input-Delay als einstellbaren Regler statt als feste Kosten. Der Entwicklerleitfaden schlägt vor, die Anzahl verzögerter Frames anhand der Verbindung zu wählen, und warnt, dass eine zu kurze Verzögerung längere Rollbacks und sichtbarere Glitches erzeugt. Verzögerung und Prediction sind Ergänzungen, keine Rivalen.

Rollback: den anderen Spieler vorhersagen

Rollback-Netcode ist Client-Prediction, angewandt auf alle, nicht nur auf einen selbst. Jeder Client simuliert sofort die Eingabe des lokalen Spielers und errät die Eingabe des entfernten Spielers anhand dessen, was dieser kürzlich getan hat. Er führt das Frame sofort aus, statt zu warten. Wenn die echte entfernte Eingabe schließlich eintrifft, vergleicht der Client sie mit der Vermutung. Stimmen sie überein, passiert nichts. Weichen sie ab, spult der Client zum letzten bestätigten Zustand zurück, setzt die korrekte Eingabe ein und simuliert jedes Frame bis zur Gegenwart neu, meist in einem Bruchteil eines Frames, weit schneller als Echtzeit.

Die GGPO-Dokumentation beschreibt das Ziel schlicht: Das Design soll Spielern die „Illusion eines latenzfreien Netzwerks" geben, damit Timing, Reaktionen und Muskelgedächtnis, die offline aufgebaut wurden, online Bestand haben. Das SDK entstand 2009 und machte Rollback in Fighting Games populär; sein Autor Tony Cannon erklärte den Ansatz im Magazin Game Developer.

Rollback stellt harte technische Anforderungen an eine Engine:

• Die Spielsimulation muss deterministisch und serialisierbar sein, man muss den vollständigen Spielzustand speichern und wiederherstellen können.
• Sie muss ein Frame weiterschalten können, ohne es zu rendern, weil Rollback viele verborgene Frames auf einmal ausführen kann.
• Simulation muss von Darstellung getrennt sein, damit Effekte und Geräusche, die während eines Rollbacks entstehen, bis zum sichtbaren Frame aufgeschoben werden können.
• Sie muss auf einem festen Zeitschritt laufen, damit eine variable Tickrate das erneute Abspielen nicht verzerrt.

Das Slippi-Projekt der Melee-Community ist eine bekannte Demonstration: Rollback wurde nachträglich in ein GameCube-Spiel von 2001 eingebaut, das in einem Emulator läuft, und ließ Spieler über Distanz antreten, ohne die Eingabeverzögerung, die verzögerungsbasiertes Netplay erforderte.

Rollback ist nicht unsichtbar. War eine Vorhersage falsch, kann die Korrektur ein kurzes Springen oder einen „Teleport" auf dem Bildschirm verursachen. Spiele justieren dies mit einer kleinen Menge Input-Delay und indem sie begrenzen, wie weit im Voraus sie spekulieren. In Overwatch beschrieb Blizzards Timothy Ford, wie sogar Projektile vorhergesagt werden, damit Raketen sofort wirken, mit der Akzeptanz, dass eine falsch vorhergesagte Rakete gelegentlich zu verschwinden scheint.

Latenzkompensation: den Server zurückspulen

Shooter machen den Server meist autoritativ und weigern sich, Clients zu vertrauen, was gut für die Sicherheit ist, aber ein neues Problem schafft. Um Jitter zu glätten, rendern Clients andere Spieler leicht in der Vergangenheit. Wenn man auf das zielt und feuert, was man sieht, zielt man auf das, wo die Welt des Servers war.

Latenzkompensation löst das, indem der Server die Welt auf den Moment zurückspult, in dem die Eingabe des Schützen erzeugt wurde. Er speichert eine kurze Historie der Position und Hitboxen jedes Spielers und versetzt bei einem Schuss die anderen Spieler dorthin zurück, wo der Client des Schützen sie sah, und prüft den Treffer dort. Deshalb wird Latenzkompensation oft als serverseitiges Zurückspulen bezeichnet.

Valves Source-Engine machte die Technik populär, und ihre Dokumentation und ihr Quellcode zeigen, wie der Server einen früheren Tick innerhalb eines begrenzten Fensters rekonstruiert. Riot beschreibt dasselbe Design für VALORANT: „Wenn der Server hört, dass du einen Schuss abgegeben hast, muss er den Weltzustand darauf zurückspulen, was du beim Abdrücken gesehen hast, um genau zu bestimmen, ob dein Schuss getroffen hat", erklärte das Unternehmen.

Der Nebeneffekt ist real und umstritten. Das Zurückspulen bevorzugt den Schützen, was eine genreweite Asymmetrie formt, die als Peeker's Advantage bekannt ist: Ein Angreifer, der um eine Ecke kommt, kann einen Verteidiger sehen und beschießen, bevor dem Client des Verteidigers mitgeteilt wurde, dass der Angreifer sich bewegt hat. Weil die Sicht des Verteidigers auf den Angreifer selbst verzögert ist, bekommt der aggressive Spieler ein Fenster zusätzlicher Reaktionszeit. Spiele begrenzen das Rückspulfenster, damit ein Spieler mit sehr hohem Ping nicht jemanden töten kann, der bereits in Deckung gegangen ist, und sie justieren Tickrate und Routing, um das Fenster zu verkleinern statt zu beseitigen.

Deterministischer Lockstep sendet nur Eingaben und vertraut darauf, dass jede Maschine zum selben Ergebnis kommt. Server-autoritative Shooter vertrauen niemandem und bezahlen dafür mit einer zurückgespulten Welt.

Tickrate und Snapshot-Interpolation

Die Tickrate eines Servers gibt an, wie oft pro Sekunde er die Simulation weiterschaltet. Ein 64-Tick-Server simuliert alle 15,6 ms, ein 128-Tick-Server alle 7,8 ms. Höhere Raten machen Trefferregistrierung und Bewegung frischer, aber die Kosten sind linear: Riot-Ingenieure schrieben, dass ein 128-Tick-Frame innerhalb von 7,8 ms andernfalls einen ganzen CPU-Kern pro Match verbrauchte, was sie zwang, auf ein Budget von wenigen Millisekunden herunterzuoptimieren, damit mehrere Spiele einen Host teilen konnten.

Clients simulieren selten die ganze Welt selbst. Sie empfangen Snapshots des Serverzustands und rendern eine glatte Annäherung. Snapshot-Interpolation, wie Fiedler sie beschreibt, puffert eingehende Snapshots für eine kurze Verzögerung und interpoliert zwischen den beiden jüngsten, wobei sie ein wenig zusätzliche Latenz gegen Glätte eintauscht. Der Puffer muss tief genug sein, dass der Verlust ein oder zwei Pakete keinen Ruckler verursacht; Fiedlers Faustregel ist etwa das Dreifache des Paketintervalls, danach durch eine höhere Senderate verringert. Extrapolation (das Vorausraten, wenn ein Snapshot zu spät kommt) wird sparsam eingesetzt, weil Physik und Kollisionen Vermutungen schnell falsch machen.

Dieselbe Spannung erscheint in Shootern als Command-Buffering. Der Server hält eine kleine Warteschlange der Bewegungen eines Clients, damit er sie glatt abspielen kann, statt im Namen des Clients vorherzusagen. Riot dokumentierte den Balanceakt: Zu wenig Pufferung, und der Server sagt Bewegungen voraus und erteilt Korrekturen; zu viel, und das Spiel fühlt sich wie hoher Ping an. Die Simulation läuft auf einem festen Zeitschritt, entkoppelt von der Render-Bildrate, sodass ein Client mit 30 fps und ein Server mit 128 Hz trotzdem dieselbe Uhr weiterschalten.

P2P, autoritative Server und warum Genres auseinandergehen

Die Topologie, die ein Spiel wählt, formt alles andere.

• Peer-to-Peer-Lockstep (klassisches RTS): Jeder Spieler sendet Befehle an jeden anderen, und jede Maschine simuliert dieselbe Welt. Es braucht keine dedizierten Server und nutzt sehr wenig Bandbreite, läuft aber nur so schnell wie der langsamste Spieler, erfordert direkte Verbindungen, die Firewalls oft blockieren, und gibt jedem Client den vollständigen Spielzustand, was Betrug leicht macht, indem Informationen gelesen werden, die der Spieler nicht sehen sollte.
• Rollback-Peer-to-Peer (Fighting Games): Zwei Spieler tauschen Eingaben aus, und jeder simuliert beide Figuren lokal. Ein kleiner, vollständig sichtbarer Zustand macht Determinismus und Serialisierung handhabbar, und Informationslecks fallen weniger ins Gewicht, wenn das ganze Match ohnehin auf dem Bildschirm ist.
• Autoritatives Client-Server (die meisten Shooter): Ein Server besitzt die Wahrheit; Clients sagen nur ihre eigenen Aktionen voraus und rendern alle anderen aus Server-Snapshots. Es widersteht Betrug, gleicht unterschiedliche Hardware aus und skaliert auf viele Spieler, auf Kosten von Servern, Bandbreite und Infrastruktur.

Das Sicherheits-Dilemma

Server-Autorität ist die stärkste Anti-Cheat-Position: Ein gehackter Client kann sich selbst belügen, aber die Welt des Servers ist das, was andere Spieler erleben. Deshalb zentralisieren kompetitive Shooter die Autorität und sind bereit, dafür mit Latenz zu bezahlen.

Aber Latenzkompensation schafft ihre eigene Angriffsfläche. Weil der Server der gemeldeten Sicht des Clients für die Trefferregistrierung vertraut, kann ein Spieler absichtlich Latenz erzeugen oder vortäuschen, um seinen Peeker's Advantage zu vergrößern, eine Praxis, die als Lag-Switching oder Lag-Abuse bekannt ist. Grenzen für das Rückspulfenster und dafür, wie weit die Position eines Spielers zurückgespult werden darf, sind die Standardverteidigung, ebenso wie asymmetrische Verbindungen als verdächtig zu behandeln.

Deterministischer Lockstep hat eine subtilere Sicherheitsgeschichte. Weil jeder Client zum selben Ergebnis kommen muss, kann jede Abweichung erkannt werden, und eine manipulierte Simulation fällt auf, wenn ihre Checksumme nicht übereinstimmt. Das macht es schwer, die Regeln zu hacken. Es tut nichts, um Informationsbetrug zu stoppen, weil der vollständige Spielzustand (einschließlich der Gegnerpositionen) bereits auf dem Client liegt.

Vorbehalte und offene Probleme

Rollback und Prediction sind keine Allheilmittel. Sie verlangen billige Zustandsserialisierung und eine Simulation, die viele Frames schneller als Echtzeit ausführen kann; eine schwere Physiksimulation mit einem langsamen Solver ist möglicherweise schlicht nicht in der Lage, schnell genug neu zu simulieren. Determinismus lässt sich leicht versehentlich brechen und ist teuer, über Plattformen und Compiler hinweg aufrechtzuerhalten. Latenzkompensation tauscht Fairness gegen Gefühl und bevorzugt immer denjenigen, der schießt.

Es gibt auch ein Messproblem. Spieler machen „Lag" für Ruckler verantwortlich, die durch ihre eigene Bildrate, durch den Server oder durch Jitter verursacht werden, und diese haben unterschiedliche Lösungen. Teams instrumentieren zunehmend all das (Tick-Timing, Puffertiefe, Round-Trip-Zeit und Jitter) und legen es den Spielern offen, damit die Diagnose kein Rätselraten ist.

Worauf man achten sollte

Drei Trends werden dieses Feld wahrscheinlich weiter prägen. Erstens mischen mehr Spiele Modelle: server-autoritative Simulationen mit Rollback-Techniken darin, statt sich für eine Philosophie zu entscheiden. Zweitens reift die Engine-Unterstützung, da deterministische Festkomma-Bibliotheken und Rollback-Tooling für kleinere Teams verfügbar werden, die Netcode nicht von Grund auf bauen können. Drittens wird die Latenz selbst auf der Infrastrukturebene angegriffen, durch privates Routing und regionale Serverplatzierung, weil die billigste Millisekunde die ist, die nie versteckt werden muss.

Der rote Faden ist, dass guter Netcode eine Reihe bewusster Kompromisse ist, nicht ein einzelner Algorithmus. Prediction erkauft Reaktionsfähigkeit, indem sie Korrekturen riskiert. Determinismus erkauft winzige Bandbreite, indem er Perfektion verlangt. Latenzkompensation erkauft fair wirkende Schüsse, indem sie die Zeit zurückspult. Zu verstehen, welchen Preis ein Spiel zu zahlen bereit ist, ist der schnellste Weg zu verstehen, warum es sich online so anfühlt, wie es sich anfühlt.