Verzögerungen in Online-Spielen durch Client-Side Prediction kompensieren

Viele Online-Spiele setzen auf schnelle Interaktionen. Hinter den Kulissen sind dafür große Datenmengen zu befördern, was zu Verzögerungen führen kann. Damit sie Spieler nicht um den Sieg bringen, gibt es Mechanismen, die Latenzen verbergen.

In Pocket speichern vorlesen Druckansicht 14 Kommentare lesen
Lesezeit: 18 Min.
Von
  • Christian Oeing
Inhaltsverzeichnis

Viele Online-Spiele setzen auf schnelle Interaktionen. Hinter den Kulissen sind dafür große Datenmengen zu befördern, was zu Verzögerungen führen kann. Damit sie Spieler nicht um den Sieg bringen, gibt es Mechanismen, die Latenzen verbergen.

In Multiplayer-Spielen kommt es durch die verteilte Ausführung der Spiele auf Clients und einem zentralen Server gezwungenermaßen zu Verzögerungen (engl. "Lags"), die durch die Datenübertragung zwischen den Rechnern entstehen. Während das bei den meisten Anwendungen und Spielen nicht groß ins Gewicht fällt, können sie die Spielerfahrung bei aktionsgeladenen Multiplayer-Titeln negativ beeinflussen.

Da sich diese Verzögerungen nicht verhindern lassen, wurden Methoden entwickelt, um sie zu kompensieren, sodass sie dem Spieler weniger auffallen und ein flüssigeres Spielen möglich ist. Die Methoden werden unter dem Begriff "Lag Compensation" zusammengefasst.

Nahezu alle Multiplayer-Spiele nutzen heutzutage Client-Server-Systeme, um Spieler gegeneinander antreten zu lassen. In ihnen fallen den Clients und den Servern sehr unterschiedliche Aufgaben zu.

Client:

  • Annahme der Eingaben des Spielers
  • Senden der Eingaben an den Server
  • Darstellung der Spielwelt

  • Ausführen der Eingaben, die die Clients senden
  • Simulation der Spielwelt
  • Übertragung der Zustandsdaten der Spielwelt an die Clients, die sie zur Darstellung benötigen

Die Clients sind somit nur für die Ein- und Ausgabe zuständig, sie können die Spielwelt nicht direkt verändern. Das obliegt einzig dem zentralen (sogenannten autoritativen) Server. Wird den Clients das Recht gewährt, dem Server Änderungen an der Spielwelt mitzuteilen, wird dies über kurz oder lang (meistens eher kurz) zu Cheatern führen, die gefälschte Änderungsmeldungen an den Server übertragen, um sich so einen Vorteil gegenüber den anderen Spielern zu verschaffen ("I'm now at position x and, by the way, I just shot player 2 in the head."). "Der Client ist in den Händen des Feindes" hat sich, was Multiplayer-Spiele betrifft, als guter Leitspruch für Netzwerkprogrammierung erwiesen.

Aus den getrennten Zuständigkeiten sowie der Verzögerung bei der Datenübertragung ergibt sich nun für den Spieler eines schnellen, aktionsreichen Titels ein durchaus spürbares Problem: Seine Eingaben haben keine direkten Auswirkungen auf die Spielwelt, sondern werden erst verzögert ausgeführt.

Verzögerte Darstellung der Spieleraktion (Abb. 1)

(Bild: Gabriel Gambetta, http://www.gabrielgambetta.com)


Was passiert? Zunächst nimmt der Client die Eingaben auf und schickt sie an den Server. Die Übertragung dauert, wie bereits erwähnt, eine gewisse Zeit. Sobald die Eingaben beim Server eintreffen, werden sie ausgeführt und verändern den Zustand der Spielwelt.

Doch damit nicht genug: Bevor der Spieler überhaupt die ersten Auswirkungen seiner Aktionen sieht, greift noch einmal dieselbe Verzögerung, da der neue Zustand der Spielwelt noch zum Spieler zurückzusenden ist, bevor er die Änderungen angezeigt bekommt. Der Zeitraum von der Eingabe bis zu deren Sichtbarwerden wird als Ping oder Round Trip Time (RTT) bezeichnet. Ein typischer Ping liegt etwa im Bereich von 100 ms.

Gerade was die Reaktion auf Eingaben angeht, sind Spieler (und Anwender im Allgemeinen) sehr anspruchsvoll. Bereits vor Jahrzehnten wurde festgestellt, dass eine Reaktion eines Computers auf eine Eingabe, die länger als 100ms benötigt, als Verzögerung wahrgenommen wird. Speziell bei Spielen, die eine schnelle Reaktion erfordern, liegt diese Schwelle oft noch niedriger.

Man sollte also versuchen, dem Spieler eine unmittelbare Reaktion auf seine Eingaben zu geben. Und was wäre als Reaktion besser geeignet, als die Bewegung, die der Spieler ausführen möchte?

Die im Folgenden vorgestellte Methode zum Reduzieren der gefühlten Verzögerung nennt sich Client-Side Prediction (ein begleitendes Codebeispiel ist auf GitHub zu finden). Die Verantwortlichkeiten bleiben bei diesem Ansatz unangetastet, die Clients haben also weiterhin keine direkte Kontrolle über die Spielwelt. Dennoch müssen sie mehr Arbeit erledigen. Wie der Name bereits andeutet, werden auf Clientseite Vorausberechnungen durchgeführt. Sie beziehen sich auf die Eingaben der Spieler.

Statt zu warten bis der Server die veränderten Zustandsdaten der Spielwelt sendet, werden die Eingaben des Spielers, nachdem sie zum Server geschickt wurden, lokal bereits verarbeitet und dargestellt. Es wird davon ausgegangen, dass der Server die Eingaben nach der Verzögerung durch die Datenübertragung akzeptiert und ebenfalls ausführt. Voraussetzung dafür ist, dass die Bewegung möglichst deterministisch ist, das heißt aus einem Bewegungszustand und einer Eingabe ergibt sich jedes mal derselbe Folgezustand.

Kein Warten auf die Bestätigung durch den Server (Abb. 2)

(Bild: Gabriel Gambetta, http://www.gabrielgambetta.com)

Nachdem die durch die Eingaben veränderte Spielwelt beim Client angekommen ist, muss er prüfen, ob die tatsächlichen Änderungen mit den vorausgesagten übereinstimmen, um synchron zum Server zu bleiben. Wurden die Eingabedaten etwa nicht in der angenommenen Zeit zum Server übertragen, berücksichtigt der Server sie zu einem anderen Zeitpunkt als auf dem Client.

Daraus ergeben sich zwei Vorteile:

  • Das Spiel reagiert ohne Verzögerung auf Spielereingaben.
  • Der Server ist weiterhin autoritativ und bietet damit keine zusätzliche Angriffsfläche für Cheater.