Client-Prediction und Reconciliation mit einem autoritativen Server

Reaktionsschnelligkeit bei serverseitiger Autorität

Wenn jede Bewegung erst nach einem Round Trip zum Server angezeigt wird, wirkt die lokale Steuerung verzögert. Mit Prediction setzt der Client Eingaben sofort um, während der Server weiterhin den gültigen Spielzustand festlegt. Schwierig ist es, eine verspätete Antwort so einzuarbeiten, dass neuere Eingaben nicht verworfen und keine Eingabe doppelt angewendet wird.

Den bestätigten Zeitpunkt abgleichen

Eingaben nummerieren und unbestätigte Commands aufbewahren. Bei einem autoritativen Update den zugehörigen Zustand wiederherstellen und die übrigen Commands der Reihe nach erneut abspielen. [1] Das Serverergebnis ist mit der Prediction für genau diesen bestätigten Zeitpunkt zu vergleichen, nicht mit der späteren Gegenwart des Clients. Valves Prediction-Implementierung führt ausdrücklich einen Fehlervergleich auf dem bestätigten Zustand durch. [2]

Durchgerechnetes Beispiel

In einem veranschaulichenden eindimensionalen Controller hat der Client die Commands 101, 102 und 103 vorhergesagt. Ein Server-Update bestätigt 101 an der Position 5.0 m; der Client hatte nach diesem Command 5.1 m vorhergesagt. Die Commands 102 und 103 bewegen im wiederhergestellten Zustand jeweils um 0.2 m.

Die Command-Historie bis einschliesslich 101 verwerfen, 5.0 m wiederherstellen und 102, dann 103 erneut abspielen. Die abgeglichene Gegenwart beträgt dann 5.4 m, die bisherige vorhergesagte Gegenwart war 5.5 m. Die relevante Korrektur beträgt -0.1 m; ein blosses Zurücksetzen auf 5.0 m würde zudem zwei noch ausstehende Bewegungen löschen.

Für die Darstellung kann ein separater visueller Offset von der alten Darstellung zur korrigierten Simulationsposition abklingen. Kollisionen und die weitere Prediction müssen dagegen sofort den korrigierten Zustand verwenden. Ein Teleport ist als ausdrückliche Unstetigkeit zu behandeln und nicht durch dazwischenliegende Wände hindurch zu glätten.

Ablauf der Umsetzung

Genau definieren, was ein Input-Command bedeutet: Tick, Dauer, Tasten und alle quantisierten Werte. Bewegungsregeln möglichst gemeinsam nutzen und den gesamten für das erneute Abspielen nötigen Zustand einbeziehen, etwa Geschwindigkeit, Bewegungsmodus und Cooldowns. Die Position allein reicht unter Umständen nicht, um das nächste Ergebnis zu rekonstruieren.

Erneut abgespielte Effekte müssen erkennbar sein, damit wiederholte Prediction Audio, Partikel oder Transaktionen nicht dupliziert. Der Server prüft den Verlauf der Commands und die Spielregeln; eine plausible Position vom Client entgegenzunehmen, ist nicht dasselbe wie die Simulation gültiger Eingaben. Die gespeicherte Historie ist zu begrenzen, und es ist festzulegen, wie vorzugehen ist, wenn ein Update älter ist als der verfügbare Zustand.

Grenzen und Validierung

Prediction kann nicht jede Aktion anderer Spieler und nicht jedes neu sichtbare Hindernis kennen. Häufige Korrekturen können auf abweichende Zeitschritte, unvollständigen Replay-Zustand, unterschiedliche Geometrie oder echte Unsicherheit hinweisen. Korrekturhäufigkeit, Korrekturgrösse, Alter der Commands und Replay-Kosten sind getrennt zu messen.

Verlust, Duplikate, vertauschte Updates, bewegliche Plattformen und Eingaben während des Respawns sind zu testen. Veraltete autoritative Updates sind gemäss der Reihenfolge des Protokolls abzulehnen. Die visuelle Glättung sollte erst abgestimmt werden, nachdem die Korrektheit der Simulation bestätigt ist: Ein weiches Bild kann dauerhafte Abweichungen verdecken, ohne sie zu beheben.

Quellen

[1] Client-side prediction and reconciliation — Gabriel Gambetta.

[2] Source SDK prediction implementation — Valve.