Wie funktioniert die clientseitige Vorhersage?

Ich habe Valve + Gafferon und Hunderte von Seiten von Google gelesen, aber aus irgendeinem Grund kann ich mich nicht mit der Kundenvorhersage befassen.

Meines Erachtens ist das Grundproblem:

• Client A sendet Eingaben an T0
• Server empfängt Eingaben um T1
• Alle Kunden erhalten die Änderung um T2

Unter T2Verwendung der Client-Vorhersage befindet sich Client A nun an einer Position, die für geeignet ist T4.

Wie stellen Sie sicher, dass der Client A dem Server nicht voraus ist, wenn er voraussagt, dass der Server die Bewegungsanforderung akzeptiert? Offensichtlich sind sie die ganze Zeit voraus, was dazu führt, dass sie an den Ort zurückkehren, an dem der Server sie zuletzt gesehen hat. Bei allen Korrekturen, die ich versucht habe, ist dies immer noch spürbar, wenn Sie anhalten, da der Server hinter Ihnen anhält

Ich habe eine Reihe von Artikeln dazu geschrieben. Es basiert auf denselben Ideen, die Sie an anderer Stelle gelesen haben, wird jedoch sehr detailliert und (ich hoffe) verständlich erklärt.

Insbesondere ist der Artikel über die clientseitige Vorhersage dieses .

Ich habe dies nicht implementiert (es kann also Probleme geben, die ich nicht sofort sehe), aber ich dachte, ich würde versuchen zu helfen.

Folgendes hast du gesagt:

Client A sendet eine Eingabe bei T0

Der Server empfängt Eingaben bei T1

Alle Kunden erhalten die Änderung bei T2

Bei T2 jedoch befindet sich Client A unter Verwendung der Client-Vorhersage an einer Position, die T4 entspricht.

Es wäre wahrscheinlich nützlich, in Bezug auf die Serverzeit zu denken. Es ist (wahrscheinlich) sehr ähnlich wie die Interpolation funktioniert.

Jeder Befehl wird mit einer Serverzeit gesendet. Diese Serverzeit wird zu Beginn eines Matches ermittelt, indem der Server-Tick abgefragt wird, um die Ping-Zeit zu kompensieren. Auf dem Client haben Sie Ihre eigene lokale Tickanzahl und jeder Befehl, den Sie senden, wird in Server-Ticks konvertiert (eine einfache Subtraktionsoperation).

Außerdem rendert der Client immer "in der Vergangenheit". Sie gehen also davon aus, dass die Welt, die der Client sieht, beispielsweise 100 ms hinter der Zeit des Servers liegt.

Formulieren wir also Ihr Beispiel mit der Serverzeit (mit S bezeichnet).

Der Client sendet eine Eingabe bei T0 mit der Serverzeit S0 (was meiner Meinung nach wirklich "Client-Darstellung der Serverzeit minus Interpolationszeit" ist). Der Client wartet nicht auf die Antwort vom Server und wechselt sofort.

Der Server empfängt Eingaben bei T1. Server ermittelt die maßgebliche Position des Clients zur Serverzeit S0, die vom Client angegeben wird. Sendet das an den Kunden.

Der Client erhält die maßgebliche Position bei T2 (noch mit Angabe der Serverzeit S0). Der Client protokolliert vergangene Ereignisse (wahrscheinlich nur eine Warteschlange aller unbestätigten Vorhersagen).

Wenn sich die vorhergesagte Position / Geschwindigkeit / was auch immer der Server an S0 zurücksendet von dem unterscheidet, was der Client an S0 gespeichert hat, handhabt der Client dies irgendwie. Entweder, indem Sie den Player auf die vorherige Position zurücksetzen oder die vorherige Eingabe erneut simulieren, oder vielleicht etwas anderes, woran ich nicht gedacht habe.

Tatsächlich gibt es eine Open-Source-Implementierung in Github, die zeigt, wie das gemacht wird. Schauen Sie sich Lance.gg an

github repo: https://github.com/lance-gg/lance

Der Client-Vorhersagecode ist in dem aufgerufenen Modul implementiert src/syncStrategies/ExtrapolateStrategy.js

Neben der Extrapolation gibt es zwei Konzepte, die ich oben nicht erwähnt habe:

1. Inkrementelles Biegen. Anstatt die Serverkorrektur auf einmal anzuwenden, lassen Sie das Delta grundsätzlich in kleinen Schritten anwenden. Auf diese Weise passen entfernte Objekte ihre Positionen schrittweise an die Serverpositionen an. Es gibt Positionsbiegung, Geschwindigkeitsbiegung, Winkelbiegung und Winkelgeschwindigkeitsbiegung. Möglicherweise möchten Sie auch unterschiedliche Biegefaktoren für unterschiedliche Objekte.
2. Step Re-Enactment. Die Tatsache, dass die Daten in der Vergangenheit liegen, bedeutet, dass Sie die Zeit auf die Serverdatenzeit zurücksetzen und ab diesem Zeitpunkt neu starten können. Natürlich müssen Sie sich immer noch in Richtung der neu gefundenen Position beugen, anstatt dorthin zu springen.

Client A ist dem Server immer voraus - aber das spielt keine Rolle. Sie müssen den Client nur zurücksetzen, wenn der Server angibt, dass ein Problem mit der gemeldeten Position vorliegt. Zu diesem Zeitpunkt führt der Client alle Änderungen, die er seit dem Fehler mit den korrigierten Werten vorgenommen hat, erneut aus, um ihn in einen kompatiblen Zustand zu versetzen mit dem Server.

Zu diesem Zweck muss sich der Client einen Teil seines früheren Status und vergangener Aktualisierungen merken. Dies sind möglicherweise nur einige einfache Werte wie Position, Geschwindigkeit, Ausrichtung und dergleichen. Der Server sendet in regelmäßigen Abständen eine Bestätigung, dass verschiedene Client-Updates legitim waren, dh, sie können jetzt vom Client vergessen werden. Wenn der Server jedoch meldet, dass eine Aktualisierung ungültig war, wird der Clientstatus auf diesen Punkt zurückgesetzt und die zukünftigen Änderungen werden auf diesen geänderten Status angewendet.

Es gibt einige zusätzliche Links am Ende des Valve-Artikels, die es wert sind, gelesen zu werden. Dies ist einer von ihnen: https://developer.valvesoftware.com/wiki/Prediction