Ein anderes Side-Project hat einen großen Teil meiner Zeit in Anspruch genommen. Es ist allerdings kurz vor der Veröffentlichung und ich habe es in 1-2 Wochen aus meinem Kopf

Ich bin von Aptana Studio auf Zend Studio umgestiegen. Aptana selbst entwickelt ihr PHP Plugin für Eclipse nicht weiter, sondern empfiehlt von nun an PDT. In so fern dachte ich mir, kann ich auch gleich Zend verwenden. Aktuell nutze ich die 30 Tage Testversion und ich hoffe, ich kann mich damit anfreunden. Im Moment ist mein Eindruck sehr gemischt und ich befürchte ja schon, dass es wieder auf eine längere Suche hinauslaufen wird.

Für unser erstes Spiel auf Basis von Zeitgeist habe ich einen Hudson aufgesetzt. Ein Deployment auf die Preview-Umgebung kostet also nicht mehr 2 Klicks (auf Batch-Skripte), sondern gar keinen mehr (der Hudson baut die Versionen, sobald sie ins SVN eingecheckt werden und rollt sie auf die Preview-Umgebung aus). Da ich mir das Gefummel mit Hudson und SimpleTest sparen will, bin ich gerade dabei die Unit Tests von Zeitgeist auf PHPUnit3 zu konvertieren. Zumindest dabei hilft Zend Studio ungemein.

Das Spiel-Projekt geht gut voran. Letzte Woche habe ich das Achievement-System und die Grundlagen der Statistik-Elemente hinzugefügt. Tut gut, wenn nach langer Pipeline-Arbeit alles ineinander passt.

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 vebreiten 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 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.

• 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: die Downloads runterladen, der Readme folgen, schon hat man funktionierende Zeitgeist-Beispiele.

Ein berühmtes Zitat von Reid Hoffman, dem Gründer von LinkedIn, lautet:

If you are not embarrassed by the first version of your product, you’ve launched too late.

Entsprechend dieser Regel veröffentlichen wir hiermit das Zeitgeist Framework.

Gehostet wird das Projekt von Google Code und ist unter folgenden URLs zu erreichen:

• http://zeitgeist-framework.googlecode.com/
• http://www.zeitgeist-framework.com/

Wie gesagt ist das Framework nicht wirklich vollständig: es hat noch Fehler, einige Module sind noch nicht mit drin, die Tests laufen gerade mal wieder nicht durch, die Dokumentation ist löchrig,.. aber es funktioniert. Und das ist genau die richtige Zeit es zu veröffentlichen. Alles andere wird sich mit der Zeit schon ergeben.

Happy coding!

p.s. Wer in den Revisions ein wenig stöbert, könnte ganz interessante Dinge finden: Testprojekte, Prototypen, Konzepte und anderes unfertiges Zeug. Seht diese als spezielle Achievements an.

In den kommenden Wochen werde ich Zeitgeist einer handvoll befreundeter Entwickler zugänglich machen, auf dass diese es auseinander nehmen können und mir möglichst schonungslos alle Designfehler und kleinen Faulheiten unter die Nase reiben. Dabei geht es darum zum ersten Mal das Framework wirklich in seiner Gänze an Dritte zu geben, damit diese es benutzen bzw. durchtesten können.

Interesse?

Wenn du jetzt gerade aufgehorcht und schon überlegt hast mit wem du ins Bett gehen musst, um ebenfalls an das Framework heranzukommen – keine Sorge: eine Mail genügt. Es muss nur die richtige Mail sein. Genauer gesagt musst du selbst einige Voraussetzungen erfüllen.

Zeitgeist ist ein PHP5 basiertes Framework, was ordentlich Gebrauch von OOP macht. Dazu kommt, dass ZG kein WYSIWYG Framework ist, das euch an die Hand nimmt, sondern nur ein ziemlich dünner Unterbau, der einem zwar viele Freiheiten lässt, aber auch viel abverlangt. Kurz: du solltest kein Einsteiger in Sachen Webentwicklung sein. Am besten hast du schon ein paar eigene, kleinere Projekte erfolgreich umgesetzt. Und damit meine ich nicht “phpBB installiert”, sondern eigene Applikationen und Plattformen entwickelt.

Ideal wäre es natürlich, wenn ihr gerade mit der Entwicklung eines kleinen Projekts beginnen wollt und genug Gottvertrauen habt, um auf ein völlig fremdes Framework zu setzen.

Was habt ihr davon Zeitgeist zu nutzen?

Mit einem Wort: Unterstützung. Ich rede nicht von First-Level-Support oder Hotlines, sondern davon, dass ich euch zuhören werde, jede Anregung beachte und zumindest überdenke, gerne zu konstruktiven Diskussionen bereit bin und natürlich euch bei Fragen zum Einsatz des Frameworks unterstützen will.

Dazu kommt, dass Zeitgeist selbst mitnichten ungetestete Alpha-Software ist. Das Framework wurde als Ganzes und in Teilen erfolgreich in mehreren kleinen und mittleren Projekten getestet. Natürlich kann und wird sich noch einiges am Framework verändern, jedoch ist es in jeder Hinsicht für den produktiven Einsatz verwendbar.

Die Zukunft von Zeitgeist

Zeitgeist wird mittelfristig Open Source werden und für alle zugänglich gemacht. Der Zeitplan sieht vor, dass dies allerdings noch bis mindestens 2010 dauert, also haltet nicht den Atem an. Der Plan sieht vor die Ergebnisse dieser geschlossenen Feedback-Runde einzuarbeiten und die Dokumentation weiter auszubauen. Dazu kommt eine Art FAQ und First-Steps-Dokument, um einsteigende Entwickler zu unterstützen. Das wird jedoch noch einige Zeit in Anspruch nehmen. Bis dahin bleibt es spannend.

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”.

Ein Projekt mit Zeitgeist ist so aufgebaut:

• _additional_material: alles, was nicht direkt zum Projekt gehört, aber mit im SVN ist (Konzept, Schemata, etc)
• classes: Projektspezifische Klassen
• configuration: Projektspezifische Konfiguration
• forms: Formularbeschreibungen für den Formularhandler von Zeitgeist
• includes: Klassen und Module von Dritten
• modules: Alle Module, die von dem Eventhandler angesprochen werden. In MVC wären das die Models
• templates: alles, was mit dem Presentation Layer zu tun hat. In MVC die Views
• tests: Alle Unit Tests landen hier
• zeitgeist: Das Framework. In MVC hätte es die Controller-Aufgaben

Und um noch einen Blick auf Zeitgeist an sich zu werfen:

Zunächst wären da unter classes alle Core-Klassen von Zeitgeist. Diese werden unabhängig von dem Projekt immer geladen (auch wenn sich die Funktionalität deaktivieren lässt).

• configuration: Kümmert sich darum, die Konfigurationen eines Projekts zu laden und zu verwalten
• database: Simple Datenbank-Abstraktionsklasse
• debug: Debugging, Tracing, Profiling und SQL-Querylogs
• errorhandler: PHP-Fehlerausgabe (Errors, Warnings)
• eventhandler: Der Handler, die die Module der Applikation steuert
• locale: Verwaltet Sprachpakete
• messagecache/messages: Verwaltet Systemnachrichten
• objectcache: Verwaltet Objekte. Eine Art Multi-Purpose-Cache
• parameterhandler: Programmierbarer Eingabefilter
• session: Verwaltet die Session eines Nutzers
• template: Simple Template-Engine, basierend auf Dreamweaver Templates
• trafficlogger: Speichert alle Aufrufe und Zustände
• userhandler: Kümmert sich (mit den anderen Userklassen) um die Nutzerverwaltung.

In configuration wird Zeitgeist grundsätzlich konfiguriert. Da die Konfiguration in der Applikation selbst überschrieben werden kann, liegt hier nur ein Default-Set.

In includes liegen wieder alle Klassen und Module von Dritten.

In modules liegen alle zusätzlich einbindbaren Module von Zeitgeist: Formularhandler, Payment, Shop, Dispatcher und so weiter. Und schließlich noch die Unit-Tests.

So, das war’s in Kürze. Das sollte als Teaser reichen und vielleicht als Vorlage für einige Fragen dienen.

Das erste Spiel geht voran. Aus dem Prototyp sind in den letzten Wochen richtige Klassen erwachsen, die inzwischen gerade zum zweiten Mal überarbeitet werden. Diesmal nicht auf Funktionalität (alle Unit Tests laufen), sondern auf Qualität. Nebenbei werden noch PHPDoc-Kommentare zu allen Funktionen angelegt. (Do you want to know more?)

Zeitgeist habe ich seit Monaten nicht mehr richtig angefasst. Alle 2-3 Wochen stoße ich noch auf einen Bug oder (eher wahrscheinlich) eine doppeldeutige Implementation, aber ansonsten läuft es einfach nur. Als Basis macht es sich ausgezeichnet, auch wenn bald im Laufe der Entwicklung des Spiels und weitere Module hinzukommen werden. (Do you want to know more?)

Das Taskkun-Projekt steht leider etwas. Das überarbeitete Konzept ist zwar sehr weit, aber ich muss einfach noch mehr meinen Kopf frei bekommen. (Do you want to know more?)

So weit in aller Kürze. Cu!