Text 3 März 1 Anmerkung
Guter Talk von den Entwicklern der Push Button Engine. Im Grunde sind komponentenbasierte Systeme inzwischen Standard. Das Video erklärt in 5 Minuten wie sie funktionieren und was die Vorteile sind.

Text 15 Nov. 1 Anmerkung

Oh nein, das habt ihr nicht getan, oder?!

Da kann man sich noch so sehr den Mund fusselig reden, aber manche lernen es einfach nicht. Wieso gehen manche Leute nur so respektlos mit ihren eigenen Produkten um?

Text 23 Febr. 1 Anmerkung

Aktuell entwickle ich für das Zeitgeist-Framework Erweiterungen der Nutzerklassen, damit sich Benutzer nicht nur über ihre internen, von Zeitgeist verwalteten, Nutzeraccounts anmelden können, sondern auch per Facebook oder Twitter. Die Facebook-Klasse gibt es (als Versuchsballon und Proof-of-Concept) schon eine ganze Weile, neu hinzugekommen ist nun Twitter.

Ziel war es, dass der Entwickler die Wahl hat, welche Logins er den Benutzern anbieten kann. Er kann entweder vollständig auf eine Plattform setzen (intern oder Facebook oder Twitter) oder auf mehrere gleichzeitig. Das Login via externer Plattform soll transparent über der internen Nutzerverwaltung liegen, so dass sich an den Nutzerklassen, sowie am Rollen- und Rechtemodell nicht ändert.

Der Ablauf ist dabei für Facebook und Twitter gleich:


  • Login des Benutzers auf der externen Plattform. Dabei wird die jeweilige Authentifizierungs-API genutzt

  • Wenn der Login erfolgreich war, wird die Unique-ID des Benutzers auf der Plattform ausgelesen

  • Falls die Plattform-Id noch nicht im System bekannt ist, wird sie gespeichert und mit einem dazugehörigen Zeitgeist-Nutzer verbunden

  • Falls kein zugehöriger Zeitgeist-Nutzer gefunden wird, wird einer automatisch angelegt. Eventuell benötigte Nutzerdaten werden aus der externen Plattform ausgelesen und für den Benutzer gespeichert

  • An den Zeitgeist-Nutzer können wie gewohnt Rechte und / oder Rollen gebunden werden


Im Moment funktionieren die beiden Klassen wie gewollt. Allerdings werde ich die “Work in Progress”-Tags erst entfernen, wenn die beiden Klassen in einem echten Projekt getestet wurden.
Text 15 Febr.

Update 1: Jetbrains hat gestern Version 2 von PhpStorm veröffentlicht. Wie ihr vielleicht wisst verwende ich PhpStorm seit einiger Zeit beruflich und privat und bin ziemlich happy. In so fern habe ich nichts gegen ein Feature-Update - insbesondere da alle, die eine Lizenz von PhpStorm 1.0 erworben haben, dieses Update für lau bekommen. Von den vielen Änderungen ist mir zuerst die neue Code Inspection aufgefallen, die mir erst einmal große Teile meines Codes um die Ohren gehauen hat. Na schön, ich gelobe Besserung bei der Definition von Klassen.

Update 2: In Sachen Zeitgeist-Framework arbeite ich gerade noch an dem Game Tutorial und der allgemeinen Dokumentation (welches OSS-Projekt tut das nicht?). Außerdem bin ich dabei neben dem Facebook-Userhandler noch einen für Twitter zu implementieren. Kurz: Login via Facebook und Twitter leicht gemacht und anschließend Zugriff auf das volle Rollen- und Rechtemanagement des Frameworks. Noch kürzer: Facebook-Games! Twitter-Games!

Frage: kennt eigentlich jemand lesenswerten Open Source PHP-Code von Browserspielen? Ich hatte mich vor einiger Zeit mal auf Google Code umgesehen, war aber nicht so begeistert. Ich würde gerne mal wieder etwas inspirierendes lesen.

Text 21 Okt.

Eigentlich gab es in letzter Zeit eine Menge zu schreiben, ich habe mich aber auf andere Dinge konzentriert.

Zum Beispiel auf das Zeitgeist Framework Game Tutorial. Es geht darum, wie man ein PBBG mit dem Zeitgeist-Framework erstellt und die Serie hat inzwischen 5 Teile. Teil 6 und 7 folgen aber in Kürze. Wenn man das Tutorial durchgeht lernt man so gut wie alle relevanten Bereiche des Frameworks kennen: Controller, Konfiguration, Sicherheit, Nutzerverwaltung und als nächstes folgt dann die Implementation der eigentlichen Spielmechaniken.

Nebenbei habe ich ein kleines Sideproject umgesetzt: Questkun. Im Grunde eine kleine To-Do-Liste, bei der man für erledigte Aufgaben Punkte und Auszeichnungen bekommt, inklusive Facebook Connect. Der Fragebogen für meine Studenten an der h_da basiert darauf. Ich baue noch einige Funktionalitäten ein, räume den Code auf und schreibe die Tests zu Ende - dann mal sehen, ob ich das Paket veröffentliche. Oder eine richtige Facebook-App daraus mache.

Text 29 Juni

Wie bereits angekündigt ist für mich wieder einmal die Zeit der Suche angebrochen. Die Suche nach einer geeigneten IDE ist nie einfach. Eine IDE ist weniger abhängig von ihrem Funktionsumfang, als vielmehr von dem Gefühl des Programmierers. Insbesondere für PHP bin ich seit rund 5 Jahren auf der Suche nach einer IDE, die mich wirklich rundum zufrieden stellt. Oder mir zumindest nicht in regelmäßigen Abständen auf die Nerven geht.

Es gibt durchaus einige IDEs für PHP. Jedoch gibt es kaum aktuelle Tests und Vergleiche dieser IDEs von Leuten, die Ihre IDE als No-Nonsense Arbeitstier sehen und nicht als hübsches Gadget. Der letzte große Test von Smashing Magazine ist inzwischen auch über ein Jahr alt. Also machte ich mich wieder auf die Suche. Dieser Post stellt meine persönlichen Erfahrungen mit den aufgelisteten IDEs dar.

Dies ist nicht meine erste Suche. Hier sind Links zu Teil 1 und Teil 2 (beide von 2008) zu finden. Insgesamt ist mir aufgefallen, dass die Qualität der IDEs seitdem stark zugenommen hat, insbesondere im Bereich OOP. Inzwischen haben die meisten IDEs zum Beispiel keine Probleme mehr mit Singletons, abstrakten Klassen oder Interfaces.

Der Test der IDEs entstand über einen längeren Zeitraum: jede IDE wurde mindestens zwei Wochen produktiv auf Live-Projekten getestet. Von kommerziellen IDEs wurde jeweils die Trial-Version getestet. Die Wahl einer IDE ist natürlich sehr subjektiv und eine Frage des persönlichen Stils. Folglich sind die Vorstellungen und gezogenen Schlüsse ebenfalls subjektiv und mit Vorsicht zu genießen.



Zend Studio (2.7, 399€, Eclipse-basiert)

Nachdem Zend Studio in Teil eins nicht besonders gut wegkam, war ich von der neuen Version angenehm überrascht. Im Gegensatz zu früher lief es stabil und kam (nach einigen Code-Anpassungen) auch mit Singletons klar. Die Code-Features wie Refactoring, Debugging und so weiter funktionierten anstandslos und direkt “out of the box”. Besonders das Code Formatting hat es mir angetan und ist gegenüber dem alten Aptana Studio und dem aktuellen PDT vorbildlich umfangreich.

Im Zusammenspiel mit dem hauseigenen Zend Server dreht Zend Studio richtig auf. Die bereits guten Debugging-Möglichkeiten werden nochmals erweitert und man vergisst fast, dass man es mit PHP zu tun hat.

Wenn der Text-Zeitraum abgelaufen ist, bleibt eine IDE auf dem Niveau von PDT zurück. Essentielle Funktionen und Tools sind noch aktiv, aber andere (wie zum Beispiel das Code Formatting oder Debugging) werden deaktiviert.

Fazit: Zend Studio hat seit seinem Erscheinen als Eclipse-Erweiterung große Fortschritte gemacht. Die Integration von Tools und Features ist logisch und stabil, die Features funktionieren ohne weiteren Aufwand. Seine Stärken spielt Zend Studio erst aus, wenn man es gemeinsam mit dem Zend Server nutzt. Nutzt man diesen nicht, lassen sich die meisten Funktionalitäten (wie z.B. Debugging, SVN, etc.) auch mit freien Eclipse-Plugins nachrüsten. Allerdings muss man dann selbst fummeln und jeder muss für sich entscheiden, ob ihm die Zeitersparnis dann 399€ wert ist. Kurz: mit Zend Server: hui! Ohne Zend Server: meh.

Plus


  • Integration von Code Quality Tools (Unit Testing, Refactoring und Code Formatting) vorbildlich

  • Sehr stabil, robuste Features

  • Großartiges Zusammenspiel mit dem Zend Server


Minus

  • 399€


JetBrains PhpStorm (1.0, 47€ - 191€, Java-basiert)

PhpStorm ist eine neue IDE, auf die mich DFox aufmerksam gemacht hat. Der schnelle Überblick über die Features sah gut aus, die Community ist recht aktiv, also warf ich gerne einen Blick darauf. Was ich sah gefiel mir auf den ersten Blick. Zudem ist es mal wieder schön mit einem ganz anderen Look & Feel zu arbeiten.

PhpStorm bringt alle Features mit, die man inzwischen von einer PHP-IDE erwarten darf: Debugging, Refactoring, Unit Tests und Code Inspection. Die Features sind allerdings abhängig vom Projekt-Typ: Eigene Klassen werden erst erkannt, wenn man das Projekt als “Neues Projekt auf lokalem Server” definiert, nicht aber, wenn man es als “Neues Projekt, lokal, ohne Server” anlegt. Nachdem man aber durch die verschiedenen Arten von Projekten durchgestiegen ist, funktioniert alles ganz gut.

Wenn man will kann man sich in stundenlangen Konfigurationsorgien austoben. So ziemlich jedes Feature kann in Tiefe und Breite angepasst werden. Besonders positiv fand ich die Möglichkeit Keymaps zu konfigurieren und so Tastaturlayouts verschiedener bekannter IDEs zu nutzen. Das machte für mich den Umstieg von Eclipse wesentlich leichter.

Etwas verwunderlich mutet hingegen die Projektverwaltung an. PhpStorm kann jeweils nur ein geöffnetes Projekt bearbeiten. Das wirkt 2010 einfach komisch. Natürlich lassen sich übergeordnete Verzeichnisse einhängen, aber Abhängigkeiten etc. sind damit nicht abbildbar. Will man gleichzeitig Framework und Anwendung bearbeiten müssen zwei Fenster genutzt werden.

Ebenso bedauerlich: die phpDoc-Beschreibung zu einer Methode ist in der Code Completion nicht zu sehen. Variablenbeschreibungen funktionieren jedoch einwandfrei.

Ein charmantes Feature fand ich die Navigation Bar, die eine Art Breadcrumb-Funktionalität darstellt. Sie zeigt immer den jeweiligen Aufenthaltsort der ausgewählte Datei an. Per Klick auf die Verzeichnisse sieht man direkt deren Inhalt und kann schnell zu benachbarten Dateien springen.

Woran ich mich immer noch nicht ganz gewöhnt habe ist der lokale Cache für Dateien. Im Grunde arbeitet PhpStorm nicht auf den “echten” Dateien des Dateisystems, sondern legt einen eigenen Cache darüber. Jede Änderung wird sofort in diesen Cache übernommen. Diese lokalen Änderungen existieren ab da als Änderungen zu den Originaldateien. Entsprechend warnt PhpStorm auch nicht, wenn man Dateien einfach schließt - beim nächsten Öffnen bedient er sich aus dem eigenen Cache und eventuell noch nicht gespeicherte Änderungen sind nach wie vor vorhanden. Das klingt charmant (und ist es auch), nur sollte man sich tunlichst abgewöhnen manuelle Updates aus dem SVN zu machen, da sonst das Dateisystem und der lokale Cache auseinander laufen. Lösung: SVN über PhpStorm verwalten klappt ganz wunderbar.

Geradezu unglaubwürdig schnell ist die projektweite Suchfunktion. Nachdem Eclipse mal gerne für eine Kaffeepause gut ist, wenn man größere Projekte durchsucht, hat man bei PhpStorm kaum Zeit die Hand nach einer Tasse auszustrecken. Schade, dass bei der Suchausgabe nur Verzeichnisse und Treffer angezeigt werden, aber nicht die dazugehörige Datei.

Ebenfalls positiv ist die gute Unterstützung für weitere Webtechnologien wie HTML, CSS, XML, JavaScript und so weiter. Wenig verwunderlich, da PhpStorm auf der WebIDE WebStorm basiert.

Obwohl die IDE erst wenige Wochen aus der Beta entwachsen ist, läuft sie stabil. Gelegentlich traten im Hintergrund Fehler auf (erkennbar durch das rote Ausrufezeichen in der unteren Bildschirmleiste), jedoch stürzte das Programm nie ab, verlor keine Daten und verhielt sich immer vorhersehbar.

Fazit: Absolut beeindruckend. Für einen Newcomer ist PhpStorm ein ganz großer Wurf. Innerhalb kurzer Zeit ist es meine Standard-IDE für Webentwicklung geworden: solide implementierte Standard-Features, ein Set von schönen Neuerungen und eine brachial schnelle Suchfunktion sorgen für bequemes entwickeln. That’s it, meine Suche ist erst einmal gelaufen. Ich kann aber verstehen, wenn sich nicht jeder auf eine völlig neue IDE einlassen will.

Plus

  • Breadcrumb-Funktion für Verzeichnisse

  • Konfigurierbarkeit Deluxe

  • Brachial schnelle Suche

  • Solide Standard-Features


Minus

  • Nur ein Projekt gleichzeitig geöffnet

  • Keine PHPDoc-Beschreibungen in der Code Completion (Siehe Kommentare)

Text 10 Mai

Adam hat in seinem Blog eine Implementation eines kompletten Entitysystems in Java vorgestellt. Genug gesagt.

Text 27 Apr.

In der aktuellen Printausgabe des Making Games Magazin ist ein Artikel von Thorsten Lange (seinerseits Technischer Leiter bei Deck13) über komponentenbasierte Systeme (bzw. Entity-Systeme). Da meine Artikel zu dem Thema bei euch gut ankamen könnte dieser für euch ebenfalls interessant sein.

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.

Text 10 Apr.

Ich habe lange nichts mehr geschrieben, also dachte ich, es wird Zeit für ein kurzes Status-Update.

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.

Text 16 Febr.

In meinem Artikel über das Zeitgeist Gamesystem-Modul habe ich etwas mehr über die Klasse zur Datenhaltung (gamedata.class.php) geschrieben. Diese ist in Zeitgeist angelehnt an die Datenhaltung eines Entity-Systems. In den Kommentaren wurde mir von Gameplorer folgende Frage zu dem Prinzip gestellt:

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.

Design crafted by Prashanth Kamalakanthan. Powered by Tumblr.