Skip to content

Netzwerkarchitektur_alt

damios edited this page Mar 31, 2018 · 1 revision

ProjektGG verwendet eine Lockstep-Architektur, wie sie meist in Real-Time-Strategiespielen Anwendung findet. Die Auswirkungen dieses Ansatzes sind, dass das Spiel jeweils solange mit der Ausführung und Berechnung einer Runde wartet, bis es die Aktionen aller anderen Spieler empfangen hat. ProjektGG verwendet zum Verteilen der Nachrichten keine P2P-Architektur, sondern einen zentralen Server, der von einem der Spieler gehostet wird: D.h. jeder Spieler sendet seine Kommandos an den Server, der diese dann gebündelt an die Clienten verteilt.

Jeder Client hat eine eigene Simulation auf seinem System laufen, die allerdings zu allen anderen Simulationen synchron ist. Dazu müssen die Simulationen a) deterministisch ablaufen (so wird beispielsweise für Zufallszahlen ein fester Seed verwendet) und b) müssen alle Spieleraktionen an einem festen Zeitpunkt ausgeführt werden. Dazu ist das Spiel in Turns (= Runden) der Länge 150 ms unterteilt. Am Ende eines jeden Turns geschehen zwei Dinge:

  • Es werden die Kommandos aller Spieler (inklusive der eigenen) ausgeführt, die zuvor vom Server erhalten wurden
  • Es werden die eigenen Kommandos (für die zukünftige Verarbeitung) an den Server gesendet

Um einem zu großen Gefühl der Unresponsiveness entgegenzuwirken und auch Spieler mit höherer Latenz zu unterstützen, werden Aktionen immer erst zwei Turns in der Zukunft ausgeführt. Das bedeutet, dass das Spiel einen Turn Zeit hat, seine Aktionen an den Server zu senden (d.h. bis zu einer Latenz von 150 ms ist keine Anpassung der Turn-Länge nötig) sowie nochmal einen Turn Zeit hat, um die Aktionen aller Spieler zurückgesendet zu bekommen. Das Spiel rendert so gerade Turn 100, sendet seine Aktion aber so ab, dass sie erst in Turn 102 ausgeführt wird.

Sollte einer der Clients bis zum Zeitpunkt des Sendens der Turn-Nachricht durch den Server keine Nachricht über die Aktionen in seinem Turn gesendet haben, wartet der Server solange bis diese Nachricht eintrifft. Dadurch können natürlich die Clienten die Turn-Nachricht des Servers auch nur verspätet empfangen und pausieren solange ebenfalls das Spielgeschehen. Auf diese Weise kann eine kurzzeitige Latenzerhöhung eines Spielers ausgeglichen werden. Fernerhin ist geplant, die Dauer der Turns abhängig von der Clienten-Latenz und -Performance anzupassen. So kann das Spiel seine Geschwindigkeit einfach verlangsamen, statt immer wieder Synchronisierungs-Pausen einleiten zu müssen.

Weiterführende Links: