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.