Zeitalter3 – Browsergames Entwicklerblog

Wir haben an dieser Stelle bereits einiges zu unserem Framework fallen gelassen. Hier nun die im letzten Post versprochene Überraschung: es ist an der Zeit nähere Details über den Motor unserer Projekte zu veröffentlichen: Zeitgeist.

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.