Server Rewind für lag-kompensiertes Hit Testing

Auf welchen Zeitpunkt hat der Spieler gezielt?

Ein auf dem Client angezeigtes entferntes Ziel zeigt einen früheren Weltzustand. Wenn ein Angriff den Server erreicht, kann ein Test allein gegen die aktuelle Position des Ziels von dieser Ansicht abweichen. Server Rewind begegnet diesem Timing-Problem durch historisches Hit Testing; es berechtigt einen Client nicht, Schaden selbst festzulegen.

Verlauf mit begrenzter Autorität

Riot beschreibt, den Zustand des Ziels auf den Moment zurückzusetzen, den der Schütze gesehen hat, und den Rewind zu begrenzen, um die Fairness zu wahren. [1] Valves Implementierung hält den Verlauf der Spieler vor, prüft das Timing, berücksichtigt die Interpolationsverzögerung und stellt nach der Kompensation vorübergehend geänderte Zustände wieder her. [2] Die genaue Regelung ist spielspezifisch; historisches Hit Testing muss nicht die gesamte Simulation erneut ausführen.

Durchgerechnetes Beispiel

Angenommen, ein beispielhafter Server empfängt einen Schuss bei 12.000 s und validiert dessen Sichtzeitpunkt als 11.880 s. Der angeforderte Rewind beträgt 120 ms und liegt damit innerhalb des für dieses Spiel gewählten Limits von 200 ms. Keine der beiden Zahlen ist ein Engine-Standardwert.

Der Verlauf enthält für die Zielmitte die Positionen 2.0 m bei 11.875 s und 2.5 m bei 11.900 s. Für ein Segment, in dem lineare Interpolation zulässig ist, ergibt sich der Anteil (11.880 - 11.875) / (11.900 - 11.875) = 0.2 und damit 2.1 m. Der validierte Schuss wird zu diesem Zeitpunkt gegen die historische Treffergeometrie getestet; das akzeptierte Ergebnis wird anschliessend über die aktuellen, autoritativen Spielregeln angewendet.

Trennt ein Teleport diese beiden Stützpunkte, würde die Interpolation Positionen erfinden, die es nie gab. Eine solche Diskontinuität ist zu markieren, und stattdessen ist eine ausdrückliche Ablehnungs- oder Sampling-Regel anzuwenden.

Ablauf der Implementierung

Den Umfang des Rewinds festlegen: Spieler, animierte Hitboxen, bewegliche Türen oder andere relevante Verdeckungsobjekte. Wird ein historisches Ziel mit der aktuellen Deckung kombiniert, können Ergebnisse entstehen, die keiner der Beteiligten gesehen hat; die beabsichtigte Regel ist zu wählen und zu dokumentieren.

Angriffssequenz, Zeitgrenzen, Waffenberechtigung, Munition und plausiblen Schussursprung validieren. Beliebige Zeitstempel des Clients dürfen nicht als massgebliche Anfragen an die Historie akzeptiert werden. Es sind genügend Posendaten zu speichern, um die gewählte Trefferrepräsentation zu rekonstruieren, einschliesslich einer Lebenszyklus-Identität, damit eine wiederverwendete Entity nicht den Verlauf eines anderen Ziels erbt.

Wo praktikabel, sind isolierte historische Abfragen vorzuziehen. Werden Live-Objekte vorübergehend verschoben, muss die Wiederherstellung auf jedem Ausstiegspfad garantiert sein, und unbeteiligte Spiellogik darf diese temporäre Welt nicht beobachten können.

Fairness und Diagnose

Grössere Verlaufsfenster akzeptieren ältere Sichten, verlängern aber die Zeitspanne, in der ein Verteidiger noch getroffen werden kann, nachdem er scheinbar in Sicherheit war. Kleinere Fenster lehnen mehr verzögerte Angriffe ab. Dieser Zielkonflikt lässt sich auch mit perfekter Buchführung nicht beseitigen.

Angeforderte und akzeptierte Zeitpunkte, Verfügbarkeit der Historie, Ablehnungsgrund und getestete Geometrie sind zu protokollieren. Zu testen sind ungleiche Latenz, stossweise Verzögerung, bewegliche Deckung, Respawn und Zeitstempel an den Grenzen. Das Trefferfeedback ist konsistent zur gewählten Regelung zu erklären, statt zu versprechen, dass das Bild jedes Clients eine gemeinsame Gegenwart abbildet.

Quellen

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

[2] Source SDK lag compensation — Valve.