Kundenseitige Vorhersage ist eine Technik, die in Multiplayer-Spielen verwendet wird, um die Verzögerung (das Aussehen von) zu reduzieren: Der Computer jedes Spielers führt eine eigene Simulation des nächsten Ereignisses durch und synchronisiert sich dann schnell mit der "offiziellen" Version des Servers. In diesem Artikel schauen wir uns an, warum wir das überhaupt tun wollen.
Diese Technik wurde populär, als vernetzte Spiele wie Quake (dessen Quellcode auf GitHub verfügbar ist) auftauchten. Die zur Zeit verfügbaren Netzwerkgeschwindigkeiten waren - insbesondere für das Internet - nicht so hoch, sodass der Versuch, alle Spieler perfekt mit dem Server zu synchronisieren, schlechte Ergebnisse lieferte.
Um das Problem zu erklären, lassen Sie uns wissen, woher es kommt.
Auf den ersten Blick gibt es das Problem, das die clientseitige Vorhersage löst, einfach nicht!
Alles ist einfach: Der Spieler bewegt seinen Charakter und das Spiel teilt dem Server die neue Position mit; Der Server gibt diese neue Position dann an die anderen Spieler weiter, deren Clients die Position des ersten Spielers im Spiel aktualisieren. Das ist es.
Was aber, wenn der Spieler das Spiel ändert, um eine andere Position als den Server zu erreichen?
Betrug! Der Server vertraut der neuen Position des Spielers von (39, 4)
, Auch wenn der Player einige Entfernungen entfernt ist, werden die anderen Clients entsprechend aktualisiert. Der Betrüger kann dann effektiv teleportieren, wodurch das Spiel für die anderen Spieler nicht mehr spielbar ist.
Da Schummeln so einfach ist, brauchen wir eine neue Lösung. Was wäre, wenn der Server die vollständige Kontrolle über den Spielstatus hätte?
Mit dem autorisierender Server Version des Spiels, der Fluss wird wie folgt aussehen:
Hier sagt der Client dem Server: "Ich möchte den Charakter nach rechts verschieben"; Der Server verarbeitet dies und entscheidet, dass der Charakter jetzt stehen soll (1, 0)
; Der Server teilt dann allen Clients der Spieler mit, dass der Charakter des ersten Spielers sein sollte (1, 0)
; und alle Spieler sehen, dass sich der Charakter an die neue Position bewegt.
Problem gelöst, richtig? Nicht komplett…
Das Teleportationsproblem wurde größtenteils vermieden, das Latenzproblem wurde jedoch eingeführt. Der Client muss auf die Antwort des Servers bezüglich seiner Bewegungsabsicht warten, bevor er dem Spieler die Bewegung anzeigt. Durch diesen Workflow fühlt sich das Spiel bei durchschnittlichen Verbindungen anfällig an und bei armen ist es kaum spielbar.
Die clientseitige Vorhersage verfeinert das obige Modell. Während der Phase, in der der Client die Absicht gesendet hat und auf die Antwort des Servers wartet, zeigt er die Bewegung an sagt voraus wird passieren:
Dadurch wird das Gefühl einer Verzögerung vermieden, indem die Wartezeit zwischen der Eingabe des Spielers und der angezeigten Ausgabe verringert wird.
Die auf dem Client stattfindende Simulation sollte dasselbe Ergebnis haben wie die auf dem Server stattfindende Simulation. Es gibt jedoch Ausnahmen. Wenn beispielsweise zwei Spieler versuchen, sich an dieselbe Stelle zu bewegen, wird einer herausgezwungen. Wenn die Antwort des Servers an den Client gesendet wird, muss der Client lediglich bestätigen, dass er seiner eigenen Vorhersage entspricht. Wenn dies nicht der Fall ist, muss der Client die Antwort des Servers als echte Informationsquelle verwenden und die Vorhersage verwerfen, um den Status des Clients zu bestimmen.
Ich hoffe, dass dieser Artikel Ihnen hilft, diese nützliche Technik für Netzwerkspiele zu verstehen, bei denen die meisten Betrugsprobleme vermieden und Verzögerungen vermieden werden müssen.