• Verwaltung der Nutzer und deren Daten
• Ein Eventhandler zur Ablaufsteuerung
• Konfigurationsmanagement für die Applikation, Sprachen usw.
• Sicherheit und Fehlerbehandlung

Doch welche Eigenschaften und Funktionalitäten brauchen Spiele, die sich nicht aus einem allgemeinen Framework für Webapplikationen ergeben?

Auf der Suche

Am Anfang stand die Idee, dass Zeitgeist ein Framework speziell für Spiele sein sollte. Mit der Zeit wandelte es sich zu einem allgemeinen Framework für Webanwendungen und alle Abläufe für Spiele musste das Spiel selbst liefern. Nach 3 Spiele-Prototypen stellte ich jedoch fest, dass es Elemente gab, die in jedem Spiel vorkommen und somit genauso gut in ein generisches Modul für Spiele ausgelagert werden könnten.

Um zu bestimmen, was ein solches Spielsystem eigentlich können soll, muss man sich darüber im Klaren sein, was ein Spiel aus Sicht einer Applikation eigentlich ist. Ich habe lange hin und her gestrichen und kam schließlich auf folgende Definitionen:

• Jeder Benutzer mit einer Session ist ein potentieller Spieler
• Jede Instanz der Applikation ist ein potentielles Spiel (Sharding)
• Jedes Spiel hat Spieler
• Jeder Spieler hat Metadaten, die seinen Zustand im Spiel beschreiben
• Das Spiel an sich hat ebenfalls Metadaten, welche die Spielwelt definieren
• Spieler agieren mit anderen Spielern und der Spielwelt durch das Spiel
• Jede Interaktion mit dem Spiel wird durch eine Aktion abgebildet
• Aktionen verändern die Metadaten der Spieler und der Spielwelt
• Aktionen können sich unmittelbar oder zukünftig auswirken

Das ergibt folgende Komponenten:

• Aktionsverwaltung: Ein Eventhandler, der alle Aktionen verwaltet, die ein Spieler (oder Spiel) ausführen kann
• Datenhaltung: Ein System, welches alle Daten verwaltet, die einen Spieler oder die Spielwelt betreffen können

Nun, auf den ersten Blick deckt sich die Aktionsverwaltung des Spiels mit der Ablaufsteuerung einer Webapplikation und die Datenhaltung ebenfalls. Brauchen wir wirklich alles nochmal, obwohl das Framework alles schon mitbringt?

Kurze Antwort: ja.

Der Gamehandler

Der Gamehandler besteht im Wesentlichen aus 2 Komponenten: einem Eventhandler, der hereinlaufende Aktionen verwaltet und einem Gamehandler, der die Aktionen auf die Logik mappt.

Eine Aktion des Eventhandlers hat folgende Parameter:

• Aktion: Eine ID für eine Aktion, die auf ein Stück Code gemapped werden kann
• Parameter: Ein Parameter-Objekt, welches dem Aktionscode mitgegeben wird
• Ausführungszeit: Der Zeitpunkt im Spiel, an dem die Aktion relevant wird
• Spieler: Der Spieler, der die Aktion ausgeführt hat
• Shard: Die ID des Shards, auf dem die Aktion ausgeführt wird
• Zeitpunkt: Der Zeitpunkt, an dem die Aktion ausgeführt wurde

Durch die Angabe des Shards wird ermöglicht, dass mehrere Spiele in einer Datenbank abgelegt werden können. Dies ist unabhängig davon, ob die Spiele selbst auf einem oder mehreren Servern laufen. In einem typischen Aufbau-Strategie-PBBG ist es meistens so, dass viele Mitspieler in einem Spiel (bzw. einer Spielwelt) agieren. Bei Spielen mit einer kleinen, abgegrenzten Anzahl von Spielern pro Spiel (Bsp. Tic Tac Toe) laufen viele Spiele gleichzeitig nebeneinander. Solange für jeden Spieler die ID seines eigenen Spiels mitgegeben wird, lassen sich die Daten sauber trennen.

Der Gamehandler mappt die vom Eventhandler aufgenommenen Aktionen auf Klassenobjekte. Jede Aktion steht also für eine externe Klasse, welche für die eigentliche Logik hinter der Aktion sorgt. Was dort dann genau passiert ist nicht mehr Sache des Gamehandlers. Er reicht nur alle relevanten Aktionen für einen gegebenen Zeitpunkt, einen gegebenen Spieler und ein gegebenen Shard weiter.

Alternativ zu dem Gamehandler kann natürlich auch ein permanent laufender Application Server eingesetzt werden, der andauernd die Eventliste abarbeitet.

Datenhaltung

Die Datenhaltung muss für alle Spiele und alle Spieltypen passen. In der Theorie müsste sie also die Daten eines typischen Aufbau-Strategie-PBBG genauso gut verwalten können, wie die einer Tic Tac Toe Plattform.

Das ist natürlich Unsinn. Eine spezialisierte Datenhaltung, die genau auf das Projekt zugeschnitten ist wird immer performanter, aber vor allem auch lesbarer sein, als eine generische. Aber: eine solche spezialisierte Datenhaltung zu entwickeln kostet Zeit. Bei einem Tic Tac Toe mag der Zeitaufwand sehr gering sein, aber man wird schnell an die Grenze stoßen, wo man überlegen muss, ob es sich tatsächlich lohnt sofort auf eine performante Datenhaltung zu optimieren, oder ob nicht erst einmal eine generische genügt.

Aber gibt es Datenstrukturen bzw. Ansätze, mit denen man so unterschiedliche Anforderungen abdecken kann? Antwort: ja, gibt es. Es ist nicht so, als hätte die Spieleindustrie nicht schon lange an dem Problem zu knabbern. Deren Antwort lautet: Entity Systeme.

Die Gamedata-Klasse nimmt sich die Datenhaltung eines Entity Systems zum Vorbild und implementiert diese in PHP. Für Details und Erklärungen der Funktionsweise verweise ich auf den Artikel, der das so wie so viel besser erklärt, als ich hier in Kürze könnte.

Im Einzelfall muss aber jeder selbst entscheiden, ob er diese nutzt, oder ob es sinnvoller ist die Datenhaltung speziell für das Spiel zu entwickeln.

In Aktion

Die letzten beiden Versionen der Spiele-Prototypen wurden mit dem neuen System umgesetzt und ich bin ziemlich zufrieden. Ich werde mich bemühen in den kommenden Wochen ein kleines Spielchen damit (möglichst sauber) zu entwickeln und als Beispiel ins SVN aufzunehmen.

Kurz zur Problematik: ein Spieler führt eine Aktion aus, beispielsweise will er sich nach Punkt D bewegen. Daraus ergeben sich einige Fragen. Darf er das in diesem Moment? Wie lange braucht er dazu? Wo befindet er sich überhaupt in diesem Moment gerade? Um eine Aktion auszuführen muss das System also in dem meisten Fällen erst einmal wissen, in welchem Zustand sich der Spieler befindet (im Sinne von Ort, Zeit etc.).

Die Reihenfolge sieht also in etwa so aus:

• Ein Spieler führt eine Aktion aus
• Das System schaut, in welchem Zustand sich der Spieler befindet
• Es prüft, ob diese Aktion dem Spieler im Moment gestattet ist
• Falls ja führt es sie aus und stößt eventuelle Konsequenzen (für den Spieler selbst und für andere Spieler) an

Das klingt so weit ganz einfach, doch spannend wird es, diesen Ablauf in einen sauber verständliches und vor allem performantes Konstrukt zu bringen. Je nach Spiel kann der aktuelle Status des Spielers recht kompliziert werden. Insbesondere, wenn er noch mit anderen Spielern interagiert.

Das aktuelle Konstrukt sieht in etwa so aus:

Zur Erklärung:

• Die Präsentationsschicht nimmt die Eingaben der Spieler auf
• Die Aktionsverwaltung stößt die entsprechenden Prozesse an, die zu einer Aktion gehören
• Der aktuelle Spielzustand, der den Benutzer betrifft, wird generiert. Er setzt sich zusammen aus den relevanten vergangenen Aktionen des Benutzers und aus den Events, die ihn in diesem Moment betreffen
• Diese ganzen Daten werden zu einen aktuellen Snapshot der Situation für den Spieler verarbeitet und in einer Struktur gespeichert
• Die Aktionen der Aktionsverwaltung greifen auf diese Struktur zu und führen die vom Spieler durchgeführten Aktionen aus
• Zukünftig wirkende Aktionen werden als Events gespeichert
• Die gerade durchgeführte Aktion des Spielers wird gespeichert, um später den Spielzustand wieder zu rekonstuieren

Durch die selektive Betrachtung des für den Spieler relevanten Spielzustands werden unter Umständen eine ganze Menge Ressourcen gespart. Darüber hinaus gibt es durch die gespeicherten Aktionen ein definitives Backlog, was jeder Spieler wann gemacht hat. Ein schöner Nebeneffekt ist damit die komplette Nachvollziehbarkeit, um Fehler im Ablauf zu finden, aber auch um Cheater aufzuspüren. Um die Größe der Daten mache ich mir in diesem Fall keine Sorgen: die Tabelle enthält nur die ID des Spielers, die ID der Aktion, die Parameter und einen Zeitstempel. Entsprechend alte Einträge werden in eine Archiv-Tabelle verschoben.

Alles in allem hat mich das jetzt lockere 2 Wochen gekostet bis alles Hand in Hand griff und ich mit dem Design zufrieden war (zumindest bis zur nächsten Refakturierungs-Runde). Als weiteren Nebeneffekt habe ich die Unit-Tests der Pipeline überarbeitet: sie benutzen nun zufällige IDs zum Erstellen von Objekten. Vorher kam es vor, dass ich im Code Primärschlüssel vertauscht hatte und die Tests nicht Alarm schlugen, weil beide im Test den Wert 1 haben sollten. Es knallte erst im eigentlichen Spiel an der entsprechenden Stelle. Faulheit verfolgt einen bei Unit Tests eben immer.