Der Artikel geht über vier Seiten und beginnt mit den Problemen einer klassenbasierten Hierarchie bei Objekten mit komplexen Eigenschaften. Als Lösung beschreibt er ein Komponentensystem, welches die Eigenschaften eines Objekts definiert. Das System setzt die Objekte aus den Komponenten zusammen, die Logik steckt dabei allerdings, im Gegensatz zu meiner Implementation, in den Komponenten selbst. Es gibt einige Beispiele in Pseudo-Code (welche die Objekt-Initialisierung zeigen) und er spricht kurz über einen Property-Editor und dessen Anbindung.

Alles in allem kein sehr tiefgehender Artikel, aber mehr über andere Ansätze und Implementationen zu lesen ist immer gut. Kurz: Lese-Empfehlung.

Wie gut eignet sich das tatsächlich für Browsergames? Durch die component_data_N – Tabellen ist es ja nicht mehr möglich, effektiv mit Joins zu arbeiten. Dadurch muss ich aber pro Entity zig Queries absetzen (jede component_data – Tabelle) was auf die Performance schlägt. Für z.B. einen Kampf müssten dann auch noch mehrere Entities geladen werden. Das klingt für mich nach einem absoluten NoGo in einem Browsergame.
Mir kam die Artikelreihe daher eher vor, als wäre ES für Clientbasierte-Spiele ausgelegt.

Das ist eine gute Frage, da sie auf einem verbreiten Mißverständnis beruht wie Entity Systeme funktionieren. Es werden (wenn richtig implementiert) kaum Joins benötigt, da keine Notwendigkeit besteht die kompletten Entites zu laden (geschweige denn mehrere). Das Missverständnis beruht wohl auf dem Versuch sich Entity Systeme wie klassisch objektorientierte Systeme vorzustellen, in denen das System über die Objektklassen immer (mehr oder weniger direkten) Zugriff auf alle Daten des Objekts hat. Mir ging es nicht anders und ich brauchte einige Anläufe, um mich davon zu lösen.

Hier also mein Versuch zu erklären, wie ich Entity Systeme verstehe und wie sie in Zeitgeist implementiert wurden.

Ein simples Weltraum-Spiel

Da man anhand von Beispielen immer besser erklären kann, nehmen wir einmal ein einfaches Weltraum-Spiel mit folgenden Eigenschaften:

• Ein Spieler hat ein oder mehrere Raumschiffe
• Es gibt 3 Raumschifftypen: leicht, mittel, schwer
• Ein Raumschiff hat eine gewisse Panzerung, entsprechend den Typen: leicht, mittel und schwer (vergleichbar mit Lebenspunkten: wenig, mittel und viel)
• Ein Raumschiff hat eine festgelegte Waffe, entsprechend den Typen: leicht, mittel und schwer (vergleichbar Angriffskraft: wenig, mittel und viel)
• Ein Raumschiff fliegt durch das Universum
• Ein Raumschiff kann gegen ein anderes Raumschiff kämpfen
• Ein Raumschiff kann in Raumstationen fliegen, in denen es sich reparieren lassen kann
• Angedockte Raumschiffe können nicht angegriffen werden

Was würde für so ein Spiel also an Daten benötigt? Zunächst einmal die Raumschiff-Daten: Welcher Spieler besitzt welches Raumschiff? An welcher Position befindet sich das Raumschiff? Wie viel Waffenschaden und Panzerung hat es noch und so weiter. Dazu kommen noch die Daten für die Objekte im Raum: Raumstationen und deren Position.

Um die Unterschiede klar zu machen folgt nun eine beispielhafte objektorientierte und komponentenbasierte Umsetzung. Beide Varianten kann (und sollte) man sicherlich auch anders implementieren, aber dies soll nur als Veranschaulichung dienen.

Objektorientierter Ansatz

Der objektorientierte Ansatz sieht die Welt durch eine Ansammlung von Objektklassen, welche jeweils einen Typ von Gegenstand in der Welt repräsentieren. Deren Methoden sind die Aktionen, welche dieser Typ Gegenstand durchführen kann.

In unserem Beispiel gäbe es üblicherweise eine Objektklasse für Raumschiffe. Wie definiert hat ein Raumschiff einen Besitzer, eine Panzerung und Waffe, sowie eine Position im Raum. Außerdem kann es gerade fliegen oder an einer Raumstation angedockt sein. Daneben gäbe es wahrscheinlich eine Klasse für Raumstationen, die jedoch nichts weiter tun, als auf einer Position zu verharren.

Die Daten werden in Tabellen gespeichert, welche mehr oder minder den Objektstrukturen ähneln. In der Realität mag es mehr Streuung durch Normalisierung geben, aber im Großen und Ganzen sähen die Tabellen für unser Beispiel so aus:

• Tabelle 1: Raumschiff (Besitzer, Panzerung, Waffenschaden, Position, Angedockt)
• Tabelle 2: Raumstationen (Position)

Spieler sind im Besitz eines Raumschiffs, sobald dieses in der Tabelle Raumschiff eingetragen ist.

Die eigentlichen Raumschiffe der Spieler und Raumstationen in der Spielwelt wären Instanzen ihrer entsprechenden Objektklassen. Das System initialisiert die Instanz eines spezifischen Raumschiffs mit den entsprechenden Daten aus der Tabelle.

Neben den Daten verfügt eine Objektklasse über Methoden, welche die Daten der jeweiligen Instanz (und damit des Raumschiffs bzw. der Raumstation) verändern. Als Beispiel für die Raumschiffklasse:

• Raumschiff.bewegen(x,y,z): verändert die Position des Raumschiffs
• Raumschiff.angreifen(RaumschiffID): greift das Raumschiff mit der gegebenen ID an
• Raumschiff.andocken(RaumstationID): dockt das Raumschiff an die Raumstation mit der gegebenen ID an
• ..

So weit die kleine Wiederholung von objektorientierter Programmierung.

Komponentenbasierte Datenhaltung

Der komponentenbasierte Ansatz sieht die Welt durch eine Sammlung von Komponenten und Entitäten. Zunächst einmal die Erklärung, was diese eigentlich sind:

• Eine Komponente beschreibt eine Eigenschaft, die ein Gegenstand haben kann
• Eine Entität repräsentiert einen dedizierten Gegenstand in der Welt
• Eine Entität besteht aus einer oder mehreren Komponenten

An dem Beispiel können diese Definitionen vielleicht besser veranschaulicht werden. Mit folgenden Komponenten (Eigenschaften) können alle Gegenstände unserer fiktiven Spielwelt abgebildet werden (in Klammern steht jeweils der Wert, mit dem eine Eigenschaft bemessen werden kann):

• Komponente 1: Ein Gegenstand kann eine Waffe haben (Angriffsschaden)
• Komponente 2: Ein Gegenstand kann gepanzert sein (Panzerungswert)
• Komponente 3: Ein Gegenstand kann eine Position haben (x/y/z)
• Komponente 4: Ein Gegenstand kann einen Besitzer haben (SpielerID)
• Komponente 5: Ein Gegenstand kann beweglich sein (j/n)
• Komponente 6: Ein Gegenstand kann angreifbar sein (j/n)
• Komponente 7: Ein Gegenstand kann andere Gegenstände reparieren (j/n)

Nehmen wir nun einmal irgendein Raumschiff. Dieses hätte folgende Komponenten: Waffe, Panzerung, Position, Besitzer, istBeweglich, istAngreifbar. Eine Raumstation hingegen hätte nur folgende Komponenten: Position, kannReparieren. Diese Typen von Entities sind Assemblages - eigentlich nur Sammlungen von Komponenten, die einen bestimmten Typ von Gegenstand ausmachen.

Der nächste Schritt ist leicht – jede Komponente bekommt eine Tabelle in der Datenbank. Dazu noch eine für die Entities, sowie eine Tabelle, um die Verbindung zwischen einer Entity und ihren Komponenten herzustellen:

• Tabelle 1: Entities(ID)
• Tabelle 2: Entities_zu_Komponenten(Entity, Komponente)
• Tabelle 3: Komponente 1 – Waffe (Angriffsschaden)
• Tabelle 4: Komponente 2 – Panzerung (Panzerungswert)
• Tabelle 5: Komponente 3 – Position (x/y/z)
• Tabelle 6: Komponente 4 – Besitzer (Spieler_ID)
• Tabelle 7: Komponente 5 – istBeweglich (j/n)
• Tabelle 8: Komponente 6 – istAngreifbar (j/n)
• Tabelle 8: Komponente 7 – kannReparieren (j/n)

Die Assemblages würden so aussehen:

• Assemblage 1: Raumschiff (Waffe, Panzerung, Position, Besitzer, istBeweglich, istAngreifbar)
• Assemblage 2: Raumstation (Position, kannReparieren)

Damit wurden nur Daten beschrieben – nirgendwo steckt ein Stück Interaktion. Im Gegensatz zum objektorientierten Ansatz, bei dem die Interaktion in den Methoden der Gegenstände selbst steckt, ist eine Entität oder eine Komponente völlig losgelöst von Methoden oder überhaupt Code. Wo also kommt die Interaktivität her?

Entity Systeme

Die Interaktivität kommt von den sogenannten Systemen. Objektorientierung geht davon aus, dass eine Methode für eine Objektklasse sich von den Methoden anderer Objektklassen unterscheidet. Das Komponentenmodell geht im Gegensatz dazu davon aus, dass die Interaktion die auf eine Komponente einwirkt unabhängig vom Gegenstands immer gleich ist. Ein Beispiel wäre die Komponente “Position”. Es ist unerheblich welcher Gegenstand eine Position hat, das Prinzip “Bewegung” ist für alle Gegenstände gleich: die Position ändert sich. Damit hat sich der Gegenstand bewegt. Dies gilt für Raumschiffe ebenso wie für Rennautos, Flugzeuge oder Fußbälle.

Die Interaktion für Komponenten wird also in einzelnen, in sich abgeschlossenen Systemen gekapselt, die nur ihre jeweils relevante Komponente(n) bearbeiten. Alles andere interessiert sie nicht. Um einen Gegenstand zu bewegen ist es unerheblich wem er gehört oder wie er bewaffnet oder gepanzert ist. Das heißt nicht, dass diese Informationen in diesem Moment gänzlich unwichtig sind, aber dafür ist ein anderes System zuständig. Und deshalb laufen alle Systeme möglichst parallel.

Auswirkung 1: Komponentensicht = Flexibilität

In jedem Browsergame findet der Großteil der Entwicklung nach dem Launch statt. Bugfixing macht davon nur einen kleinen Teil aus. Früher oder später muss man am Balancing nachdrehen und in mehr oder weniger regelmäßigen Abständen wird es Erweiterungen geben: neue Einheiten, neue Regeln, neue Features, neue Dinge zu entdecken.

Nehmen wir unser Beispiel. Angenommen Spieler sollen auch Raumstationen besitzen können. Andere Spieler können diese natürlich zerstören. In einem objektorientierten Umfeld würde ich jetzt anfangen die Klasse der Raumstation zu erweitern. Bei einem Komponentensystem würde ich die Komponente “Besitzer” und “istAngreifbar” der Assemblage der Raumstation hinzufügen. Done. Keine Codeänderung nötig.

Oder fügen wir die Raumschiffklasse “Trägerschiff” hinzu. Es soll eine Art großes Raumschiff sein, das wie eine bewegliche Raumstation agiert und andere Raumschiffe daran andocken können. Also, ich erstelle eine neue Klasse dafür und fange an zu programmieren. Oder aber ich erstelle eine neue Assemblage und füge die entsprechenden Komponenten hinzu (was Datenbankeinträge sind!).

Und jetzt stellen wir uns einen einfachen Einheiten-Editor vor, der einfach nur Assemblages erstellen und mit Komponenten verknüpfen kann.

Wenn ich denn tatsächlich mal eine neue Eigenschaft brauche, muss ich natürlich das entsprechende System entwickeln. Allerdings steht die Eigenschaft damit automatisch auch allen anderen Assemblages zur Verfügung.

Zugegeben, mit Mehrfachvererbung oder Interfaces kann man auch in klassisch objektorientierten Umgebungen so eine Flexibilität versuchen, aber ich würde es nicht empfehlen. Früher oder später läuft alles auf massive Superklassen hinaus, die nicht mehr pflegbar sind.

Auswirkung 2: Kleine Systeme = Wartbarkeit

Wenn jedes System nur eine (oder wenige) Komponente(n) bearbeitet, sind diese per Definition relativ überschaubar. Anstatt über die Klassen verteilt habe ich auch nur an einem dedizierten Punkt meine Logik: in den Systeme selbst. Ich muss auch nicht in jeder Klasse immer wieder die gleiche oder ähnliche Logik unterbringen oder mich mit Vererbung und Interfaces herumschlagen, um den Code aus den Klassen herauszuhalten. Ich habe einen zentralen Punkt, an dem ein abgegrenztes Set von Daten geändert wird.

Durch diese Abgrenzung sind die Systeme außerdem großartig testbar.

Auswirkung 3: Spezialisierte Systeme = Performance

Nehmen wir als Beispiel an in der Queue des Eventhandlers liegen Events zur Bewegung von Schiffen. Es existiert ein System für “Bewegung”, dessen Aufgabe die Bearbeitung dieser Events ist. Es schaut also in der Event-Tabelle nach: was muss bewegt werden und wohin?

Klassisch objektorientiert wäre das “was” die ID eines Raumschiffs, aus dem dann die Raumschiff-Instanz erzeugt wird. Instinktiv mag man dem “was” in einem Entity System die ID der Entity zuweisen. In diesem Fall müsste das System jedoch erst einmal die Entity-ID finden, dann die Zwischentabelle befragen wo in der Komponententabelle “Position” denn der dazugehörige Eintrag liegt. Und da sind wir wieder bei der eigentlichen Frage von Gameplorer: “Sind diese Joins nicht unperformant?” Antwort: ja, aber warum sollte ich sie überhaupt machen? Wieso wird nicht einfach die ID des Komponenteneintrags als “was” genutzt? Sobald das passiert ist reduziert sich die Aufgabe des Systems auf einfache Updates.

Und noch besser: wer sagt, dass ein System in meiner Applikation leben muss? Letztendlich fragt es die Datenbank ab (Event-Tabelle), um mit den Ergebnissen eine andere Tabelle zu aktualisieren (Conponent_Data_Position). Das alles kann man bequem in einer Stored Procedure erledigen.

Auswirkung 4: Parallele Systeme = Skalierung

Angenommen ich habe alle Systeme ausgelagert. Weiter angenommen ich merke, dass ein System viele Ressourcen frisst, wohingegen andere recht genügsam sind. Was hintert mich daran das anspruchsvolle System einfach auf einen eigenen Server zu verlegen? Solange es Zugang zur Datenbank hat ist alles fein.

Was jetzt noch bleibt

Neben den Systemen bleibt noch der Logik-Server. Dies ist der Haupt-Gameserver, den die Clients ansprechen. Etwas muss ja auch dafür sorgen, dass sich Nutzer anmelden können, die Spielregeln implementiert sind und der Eventhandler befüllt wird. Dadurch dass aber alle Vorgänge innerhalb der Spielwelt nun losgelöst sind beschränkt sich dieser aber auch auf diese Aufgaben, wird deutlich schlanker und dadurch auch performanter.

So, der Artikel is jetzt lang genug. Ich hoffe ich habe euch meine Vorstellung von Entity Systemen etwas näher erklären können. Wie schon erwähnt gibt es viele Arten von Entity Systemen. Es würde mich freuen von euch zu hören, falls ihr eine Meinung zu dem Modell habt.

Ein Beispiel, um das Thema zu verdeutlichen: nehmen wir an, jeder Spieler repräsentiert einen Piloten eines Jets (Raumschiffs, Rennwagens). Als reguläre Spieloberfläche hat jeder Spieler eine Auflistung seiner Möglichkeiten auf dem Flughafen (Flugzeugträger, Raumschiff, Fahrerlager, ..), unter anderem sich mit anderen Piloten zu Übungszwecken zu duellieren. Bis zu insgesamt 4 Spieler können in “Dogfights” (Wettrennen) gegeneinander antreten. Nachdem sich 2-4 Spieler gefunden und geeinigt haben, starten sie. Die Oberfläche wechselt zu einem Cockpit, in dem nun jeder Spieler sein Jet (Raumschiff, Rennwagen) steuert (Wechsel von “Nicht Auseinandersetzung” zu “Auseinandersetzung”).

Gemäß des Aufrufs von Bernd Kreimeier in Gamasutra beschreibe ich kurz mal das Problem und skizziere die Lösungen, auf die ich gekommen bin. Die Problemstellung ist bei allen gleich:

Problem: “2-4 Spieler sollen in Auseinandersetzungen gegeneinander antreten können. Es steht während der Auswahl keine grafische Repräsentation der Spielwelt zur Verfügung. Die Auseinandersetzungen selbst finden in einer grafischen Repräsentation statt und sind so “losgelöst” von der sonstigen Oberfläche. Wie können sich Spieler finden, die gegeneinander antreten wollen? Wie können Spieler gezielt gegen spezifische Spieler antreten? Wie können die Spieler kontrolliert von der Oberfläche der “Nicht-Auseinandersetzung” in die der “Auseinandersetzung” wechseln?”

Skirmish

Lösung: Der Spieler gibt die Anzahl seiner gewünschten Mitspieler ein und bestätigt seine Wahl. Er wird in eine Warteschlage aufgenommen, die alle Spieler enthält, welche die gleiche Anzahl an Mitspieler wünschen. Er wartet so lange, bis diese Anzahl erreicht ist. Anschließend wechselt der Kontext für alle Spieler in der Warteschlage und sie treten in der Auseinandersetzung gegeneinander an.

Konsequenz: Das Finden der Mitspieler wird vom System automatisch übernommen. Ein Spieler kann nicht gezielt gegen spezifische Spieler antreten. Der Spieler hat keinen direkten Einfluss wann das Spiel stattfinden wird, sondern wird gezwungen passiv zu sein.

Beispiel: Battlegrounds in World of Warcraft. Skirmisch-Modus in Echtzeit-Strategiespielen.

Lobby

Lösung: Der Spieler gibt die Anzahl seiner gewünschten Mitspieler ein und bestätigt seine Wahl. Dies eröffnet einen neuen Raum mit der Anzahl an Mitspielern als offene Slots. Andere Spieler sehen diesen Raum und können diesen betreten. Wenn alle Slots von Spielern gefüllt sind, beginnt das Spiel.

Konsequenz: Das Finden anderer Mitspieler ist für den Ersteller des Spielraums nicht möglich, nur für die teilnehmenden Mitspieler. Der Spieler kann durch eigene Absprachen gegen spezifische Mitspieler antreten. Abhängig von der Implementation haben die Spieler Kontrolle über den Übergang auf die Oberfläche der Auseinandersetzung.

Beispiele: Viele Rennspiele implementieren eine vom Ersteller des Raums gesteuerte Variante: der Ersteller muss, nachdem andere Spieler seinen Spielraum betreten haben, manuell die Auseinandersetzung bestätigen bzw. beginnen. Er hat also Kontrolle über den Übergang. Echtzeit-Strategiespiele implementieren meistens eine Variante, in der jeder teilnehmende Spieler die Spielrunde bestätigen muss = alle Spieler haben Kontrolle über den Übergang.

Direkte Herausforderung

Lösung: Ein Spieler wählt aus einer Liste der existierenden und verfügbaren Mitspieler 1-3 weitere aus und bestätigt seine Wahl. Der Spieler wechselt direkt in den Kontext der Auseinandersetzung, die allerdings noch nicht beginnt. Es wird eine Benachrichtigung mit einer Herausforderung an die gewählten Mitspieler versendet, die einen Link enthält. Der Link führt die Spieler direkt in die Auseinandersetzung. Die Auseinandersetzung beginnt, sobald alle Mitspieler im Kontext der Auseinandersetzung sind.

Konsequenz: Die Spieler können gezielt gegen spezifische Mitspieler antreten. Sie haben allerdings kaum Kontrolle über den Wechsel – sie müssen warten, bis alle anderen Mitspieler der Herausforderung gefolgt sind. Die Zeitspanne dafür ist nicht absehbar und die Herausforderer müssen unter Umständen lange auf eine Reaktion warten. Spieler können sich gegenseitig über eine Liste der verfügbaren Mitspieler finden.

Beispiel: Einige Browsergames arbeiten mit dieser Art von Herausforderung. Bei einer Herausforderung ist es dabei üblich eine Mail zu versenden bzw. zusätzlich auf der Oberfläche des Browsergames die Herausforderung kenntlich zu machen. Seltener sind Benachrichtigungen per IM und SMS (eigentlich nur bei mobilen Spielen üblich).

Fällt euch noch ein Pattern ein? Falls ja, beschreibt es bitte als Kommentar. Und was mich noch interessieren würde: welches der drei vorgestellten Patterns sagt euch mehr zu? Ja, ich weiß, das ist abhängig vom Spielprinzip und der Implementation, aber wenn ihr einfach aus dem Bauch heraus antwortet: welches wäre das dann?

Oh, und den oben erwähnten Gamasutra-Artikel kann ich wirklich empfehlen

Die Frage war:

Was ist dieses angesprochene Message-System?

Nun, einfach gesagt: Die Message-Klasse stellt Funktionalitäten bereit, um systemweite Textnachrichten zu verwalten.

Das Prinzip der systemweiten Nachrichten sollte vielen bekannt sein, die schon einmal etwas tiefer in die  Dektop-Programmierung eingestiegen sind. Man kann es sich als eine Art Modul vorstellen, das von überall her angesprochen werden kann. An dieses Modul können Nachrichten übergeben und umgekehrt wieder angefordert werden. Auf diese Weise können alle Module eines Projekts miteinander kommunizieren.

Ein Beispiel

Nehmen wir einmal einen typischen Fall in einer Webapplikation: ein Benutzer kauft in einem B2B-Webshop den Inhalt seines Warenkorbs. Dieser einfache Klick setzt einige Abläufe in Gang – gehen wir der Einfachheit mal von folgenden Prozessen und Fragen aus, die das System nun anstößt:

• Ist der Benutzer eingeloggt?
• Kenne ich alle nötigen Angaben des Benutzers?
• Was ist denn der Inhalt des Warenkorbs
• Sind die Waren überhaupt noch verfügbar?
• Erstelle eine Rechnung
• Informiere das Warenwirtschaftssystem

Diese können leicht durch Klassen und deren Methoden beantwortet werden. Allerdings werden dabei viele, viele Zwischenfragen gestellt und lauter Klassen müssen ineinander greifen: Benutzerverwaltung, Warenkorb, Waren, Rechnungsstellung, Schnittstelle zum Warenwirtschaftssystem und so weiter. Der ganze Ablauf wird wahrscheinlich verwaltet durch eine Art Controller (in MVC), mit dem jede Klasse für sich sprechen kann. Doch wie können diese individuellen Klassen miteinander sprechen?

Falsch!

Einfache Antwort: in sauberem OOP sollen Arbeiterklassen auch gar nicht untereinander Daten austauschen. Gut, zugegeben. Aber abgesehen von Daten: wie wäre es, wenn sie Informationen über ihren Zustand austauschen? Oder sie alle wollen möglicherweise mit dem Controller oder gar dem Benutzer reden. Und dieses Mitteilungsbedürfnis kann eben über den einfachen Rückgabewert hinaus gehen. Wenn mir eine Methode einer Arbeiterklasse ein false zurückliefert, was ist denn eigentlich genau schief gelaufen? In welchem Zustand befindet sich dann die Arbeiterklasse? (An dieser Stelle würde ich ja gerne mit Exception Handling anfangen, aber die Implementation in PHP5 ist so mangelhaft, dass das leider nicht geht).

Also – gehen wir von einer Art Verbose-Modus innerhalb der Applikation aus, in dem jede Klasse ihre Schritte dokumentieren kann und alle anderen wissen, in welchem State sich die Applikation gerade befindet.

Die Umsetzung

Gundsätzlich könnte man jetzt das Problem mit globalen Variablen lösen. Mal abgesehen von dem “globale Variablen sind die Wurzel allen Übels”-Stigma sind sie wirklich nicht besonders sinnvoll. Es ist schwer im Blick zu halten, welche Funktion gerade was in welche Globale geschrieben hat, was Debugging und vor allem Testing zu einem Horrortrip macht.

Alternativ würden sich Session-Variablen anbieten, aber wenn man es genau betrachtet sind diese in dem Zusammenhang auch nichts anderes als Globale in Grün.

Was ist daran schlecht?

Das da:

Warum machst du es dann doch, obwohl sogar Google sagt, dass es schlecht ist?

Wer aufgepasst hat, der hat sich gemerkt, dass Singletons (über die wir hier reden) nicht per se schlecht sind. Man muss sie nur entsprechend designen. Denn grundsätzlich haben Singletons einige entscheidende Vorteile gegenüber einer Anzahl von “dummen” Globalen.

Zunächst einmal wäre da die Nachvollziehbarkeit. Die Klasse selbst kann nachvollziehen welche Methode oder Funktion gerade auf sie zugegreift und was diese verändert. Voraussetzung ist, diese Informationen fließen alle in eine Art Tracing-Mechanismus, was dem Entwickler zu jeder Zeit des Programms transparent macht, was an welcher Stelle passiert ist. In der Kombination mit dem Tracer bleibt dann nachvollziehbar, was genau mit dem Global State passiert (siehe Video).

Ich erwähnte bereits, dass das Nachrichtensystem die Informationen nicht nur speichert, sondern auch verwaltet. Eine Methode kann eine Nachricht mit einem expliziten Empfänger versehen. Somit erhält eine Methode an anderer Stelle bei einer Anfrage nach für sie relevanten Nachrichten auch nur die für sie gespeicherten Informationen.

Möglich ist auch eine effektive Rechteverwaltung, welche Module auf welche gespeicherten Informationen zugreifen bzw. diese verändern können.

Und schließlich: Nachrichten können über Aufrufe hinweg gespeichert werden. Ein Beispiel: wenn bei einem Aufruf einige Funktionen einen Fehler melden, der Benutzer daraufhin per Redirect auf eine andere Seite geleitet wird, kann das System immer noch nachvollziehen, welche Fehler eigentlich gemeldet wurden und dem Benutzer entsprechende Ausgaben präsentieren. Das ist eigentlich die Hölle für einen Global State, aber noch einmal: wir können leicht nachvollziehen wer den State wann gesetzt hat. Und umgekehrt können wir diesen auch leicht definieren, um ihn so testen zu können.

Fazit

Ja, das ist Overhead. Aber nicht so viel, wie man denkt. Macht es das Debuggen und Warten des Codes problematischer? Ja, ein bischen. Oder vielmehr: man sollte sich über ein paar Dinge im Klaren sein. Dann aber ist es immer nett, wenn man mehr Informationen zur Verfügung hat, was genau in der Applikation vorgeht – auch innerhalb der Applikation selbst.

Aber um eine Sache klarzustellen: wir reden hier von Nachrichten, Kommunikation und Übersicht. Die eigentilchen Arbeiterklassen sollten entsprechend korrektem OOP-Design erstellt werden (siehe oben, siehe Vortrag). Was nicht Sinn der Sache ist, dass (wie in unserem B2B-Shop-Beispiel) der Warenkorb plötzlich über das Nachrichtensystem von einer Arbeiterklasse zur nächsten gereicht wird. Dann sind wir in der Tat bei “Bad Global State”.

Ursprünglich wurde Zeitgeist geplant und entwickelt für unser erstes Browserspiel-Konzept: Zeitalter3. Und daher auch der Name: es ist der gute Geist, welcher Zeitalter3 antreibt. Jedoch wurde das Framework frühzeitig mit dem Fokus entwickelt ein generischer Unterbau für alle Arten von webbasierten Mehrbenutzersystemen zu sein. In so fern ist das Framework weder auf ein einziges Spiel spezialisiert, noch ist es nur auf Spiele festgelegt. Ob Browserspiel, Webapplikation oder Community – alle Webanwendungen können theoretisch auf der Basis von Zeitgeist entwickelt werden.

Technisch basiert Zeitgeist auf PHP5 mit einer Datenbank im Hintergrund. Es ist voll objektorientiert und stellt Klassen für viele Bereiche der Webentwicklung zur Verfügung. Features sind zum Beispiel:

• Debugging der gesamten Anwendung, inklusive Tracing
• Einfache Konfiguration der Applikation
• Datenbankanbindung, inklusive rudimentäres SQL-Profiling
• Transparente Session- und Benutzerverwaltung
• Transparente Validierung aller eingehenden Parameter
• Automatische Formularvalidierung und -Handhabung
• AJAX-Datenserver
• Lokalisierung
• Templatesystem, basierend auf Dreamweaver-Templates

Zeitgeist bietet also Hilfen und fertige Klassen für einen großen Teil der üblichen Aufgaben von Webprojekten. Aber wie ist nun eine Implementation eines Zeitgeist-Projekts aufgebaut?

Die Struktur von Zeitgeist

Gleich vorweg: Zeitgeist basiert nicht auf MVC. Der Model-View-Controler Ansatz mag für schnelle Prototypen gut geeignet sein, jedoch eignet er sich unserer Meinung nach nur bedingt für komplexere Projekte (das ist aber eine Diskussion für sich). Statt dessen verwendet Zeitgeist einen eher an klassische Event-basierte Systeme angelehnten Ansatz.

Die Basis von Zeitgeist bildet ein Set von grundsätzlichen Klassen, die in jedem Projekt verwendet werden und zum Betrieb des Frameworks notwendig sind. Dieser Kern trägt bezeichnenderweise den Namen Core. Alle weiteren Schichten des Projekts basiert auf diesem Unterbau.

Auf diesen Kern setzen die Framework-Module von Zeitgeit auf. Diese stellen weitere optionale Funktionalitäten zur Verfügung, die per Konfiguration aktiviert und deaktiviert werden können. Somit kann jedes Projekt nur die Module nutzen, die es wirklich braucht und kann auf unnötigen Overhead verzichten.

Der erste Applikationsschicht besteht aus einem Set von Worker-Klassen, welche die Anwendungslogik bereit stellen. Darüber hinaus sollten in dieser Schicht sinnvollerweise die Klassen des Kerns oder der Framework-Module erweitert werden, um sie für spezielle, projektspezifische Anforderungen zu erweitern.

Auf die Anwendungslogik setzen die Anwendungsmodule auf. Anwendungsmodule sind jeweils logische Teile der Applikation, bestehend aus mehreren Aktionen, welche zusammengenommen die einzelnen Schritte der Ablauflogik bilden. Ein Beispiel wäre in einer typischen Community-Plattform alle Aktionen eines Benutzers sich selbst betreffend im Anwendungsmodul User zusammenzufassen, bestehend aus den Aktionen: Passwort ändern, Benutzerdaten ändern, Passwort vergessen, usw.

Schließlich bedienen sich die einzelnen Aktionen üblicherweise dem Templatesystem als Präsentationsschicht. Grundsätzlich kann aber eine beliebige Technologie als Benutzerinterface verwendet werden: Flash, Silverlight, etc.

Die Funktionsweise von Zeitgeist

Wie bereits in einem vorhergehenden Artikel beschrieben ist Zeitgeist aktionsbasiert. Das bedeutet, dass bei jedem Seitenaufruf das Framework mit jeweils einer Angabe des gewünschten  Anwendungsmoduls und dessen Aktion aufgerufen wird. Zeitgeist verarbeitet diese Angaben mit seiner Aktionsverwaltung, die Teil des Kerns ist.

Die Aktionsverwaltung ist relativ umfangreich: sie kümmert sich um die Initialisierung der Anwendung und des jeweiligen Moduls, um Sicherheitsmechanismen, das Session-Handling inklusive Benutzer- und Rechteverwaltung und schließlich sorgt die Aktionsverwaltung, dass der Aufruf an das entsprechende Modul weitergegeben wird.

Ein Problem bei einer solchen Architektur ist die Kommunikation der einzelnen Schichten untereinander. Da alle Komponenten in allen Schichten (ausgenommen natürlich der Präsentationsschicht) als Klassen ausgelegt sind, können Informationen nicht einfach während des Ablaufs hin- und hergereicht werden. Der Einsatz von globalen Variablen ist in PHP zwar möglich, aber unserer Meinung nach sehr unsauber. Spätestens bei umfangreichen Webprojekten kann man sich nie sicher sein, ob eine Variable bereits existiert, wo sie herkommt, für wen sie bestimmt ist oder ob sie noch gebraucht wird. Ganz abgesehen davon, dass solche globalen Container, in die alles unstrukturiert hineingeworfen wird, irgendwann rießig werden und nicht mehr zu debuggen sind.

Um dieses Problem auch ohne Einsatz globaler Variablen zu lösen bietet Zeitgeist ein Nachrichten- und Objektsystem. Das Objektsystem ist als eine Art Manager zu sehen, mit dessen Hilfe die Komponenten Objekte, also Variablen oder Instanzen, untereinander austauschen können.

Das Nachrichtensystem dient zum Austausch von Meldungen zwischen den einzelnen Komponenten der Anwendung. Dabei können Nachrichten an bestimmte Komponenten (Empfänger) gesendet werden oder eine Komponente kann sich die Nachrichten aller oder nur bestimmter Absender abholen.

Durch das Objekt- und Nachrichtensystem können Zustände und Meldungen vom Framework über alle Schichten hinweg transportiert werden und beispielsweise von der Präsentationsschicht angezeigt werden.

Ebenfalls schichtübergreifend ist die Debugging-Komponente von Zeitgeist, die neben der üblichen Ausgabe von Debug-Nachrichten auch über Function Guarding (Tracing), sowie rudimentäres Anwendungs- und SQL Profiling für das gesamte Projekt verfügt.

Zeitgeist im Einsatz

Zeitgeist wird von uns zur Zeit in zwei Projekten aktiv eingesetzt.

Zum einen bei Taskkun, der vor kurzem angekündigten webbasierten Projektmanagement-Lösung. Taskkun basiert auf instanzierten Benutzergruppen (mehrere Gruppen von Anwendern können abgeschottet von einander Taskkun nutzen) und ist sehr flexibel (jede der einzelnen Gruppen kann den Arbeitsablauf von Taskkun selbst konfigurieren). Die Darstellung erfolgt mit XHTML. Das Projekt ist in der Closed Beta.

Zum Anderen nutzen wir Zeitgeist als Basis für unser erstes Spiel. Dieses ist ein schnelles, rundenbasiertes Action-Strategiespiel, in dem mehrere Spieler gegeneinander spielen. Die Darstellung erfolgt sowohl in XHTML (Seite), als auch in Flash (eigentlicher Spielclient). Es existiert ein lauffähiger Prototyp des Clients.

Und dann wäre da noch der Auslöser des Ganzen: Zeitalter3. Dabei handelt es sich um ein browserbasiertes Weltraum-Handelspiel, bei dem die Spieler in einem umfangreichen Universum gegeneinander antreten, um sich in regelmäßigen Spielrunden in verschiedenen Kategorien mit ihren Mitspielern zu messen. Kurz: ein browserbasiertes MMORPG. Zeitalter3 ruht zur Zeit in der Konzeptphase in unserer Schublade.

Trotz dieser 3 doch sehr verschiedenen Anwendungen hat sich Zeitgeist als enorm vielseitig herausgestellt. Es hat sich ausgezahlt viel Zeit in die Konzeption, aber auch die dauernde Refakturisierung der Komponenten zu investieren. Bei der Entwicklung steht der agile Ansatz “Fail early, Fail often” im Vordergund. Wenn eine Komponente nicht funktioniert, oder sich als zu unflexibel herausstellt, wird sie entfernt und durch eine komplett neu geschriebene ersetzt, ganz egal wie viele Module bereits darauf aufbauen. Dies mutet zunächst wie ein in der Praxis untragbarer Luxus an, erhöht aber die Qualität der Lösungen enorm und spart auf lange Sicht viel Zeit, die sonst in die Anpassung unflexiblen Codes fließen würde.

Vorläufiges Fazit

Bisher sind wir sehr zufrieden mit der Entwicklung von Zeitgeist. Der generische Ansatz erlaubt es unterschiedliche Anwendungen schnell und nachvollziehbar auf das Framework zu setzen. Die Struktur eines Projekts ist übersichtlich und alle Schichten sind logisch und von der Entwicklung her voneinander getrennt:

• Kein projektspezifischer Code im Framework
• Keine Anwendungslogik in der Ablauflogik
• Saubere Präsentationsschicht ohne Logik- oder Ablauf-Code
• Beliebige Technologie für Benutzeroberflächen (XHTML, Flash, Silverlight, ..)

Über die Zeit werden wir mehr Informationen zu dem Framework hier posten. Was jedoch zur Zeit nicht passieren wird ist, dass wir Versionen unseres Frameworks veröffentlichen. Dies ist für einen späteren Zeitpunkt geplant, jedoch steht noch nicht fest unter welchen Bedingungen.