Zeitalter3 – Browsergames Entwicklerblog

Seit dem letzten Update ist eine Weile vergangen. Wir haben viel Zeit in die Planung von Testfällen, aber auch die Entwicklung des Framework gesteckt. Eine Entwicklung soll an dieser Stelle einmal beleuchtet werden, denn es ist ein Punkt, an dem viele Hobbyprojekte sparen: die Aktionsverwaltung (Eventhandler).

Viele index.php-Dateien sehen ungefähr so aus:

// Initialisierung

if ($action == 10)
{
lade dies;
mache das;
gib jenes aus;
}

if ($action == 20)
{
lade jenes;
mache dies;
gib das aus;
}

Wenn sich nun das Projekt langsam aber sicher weiterentwickelt, werden diese Index-Dateien schnell sehr, sehr groß und damit auch enorm unübersichtlich. Schlimmer wird es, wenn mehrere Aktionen zusammengefasst werden oder mittendrin die Aktion geändert wird. Beispiel:

if ( ($action > 30) || ($action < 40) )
{
lade jenes;
mache dies;

if (foo = 1) gib das aus
else $action = 41;
}

Spätestens hier ist es aus mit der Lesbarkeit und nach 2 Wochen weiß auch niemand mehr, was welche Aktion genau bewirkt. Im Team an solchen Index-Dateien zu arbeiten wird mit der Zeit nahezu unmöglich.

Die Lösung ist eine Verwaltung für Aktionen: ein Mechanismus, der sich automatisch um das Laden und Ausführen von Aktionen kümmert. Die Index-Datei sieht anschließend etwa so aus:

// Initialisierung

$eventhandler = new tEventhandler();
$eventhandler->callEvent($action);

Der erste Gedanke ist nun: “Das ist doch dann nur ausgelagert, das Chaos verteilt sich doch nur über mehrere Dateien.” Fast richtig. Deshalb noch eine weitere Maßnahme: Zunächst wird jede Aktion in eine logische Schublade gesteckt. Diese Schubladen, oder auch Module, sind Sammlungen zusammengehörender Aktionen. Beispielsweise zum Modul “Spieler” kann gehören: “Profil ansehen”, “Nutzerdaten verändern”, “Nutzer löschen”. Ein anderes Modul könnte “Gegner” sein: “Gegnerprofil anzeigen”, “Gegner angreifen”, “Gegner Nachricht senden”. Das führt zu so einem Aufruf:

$eventhandler = new tEventhandler();
$eventhandler->callEvent($module, $action);

Nun sind die logisch zusammenhängenden Aktionen getrennt. Dies hat den Vorteil des Lesbarkeit, aber auch die Modularität an sich ist ein Vorteil. Ein Programmierer kann (zum Beispiel) am Kampfsystem arbeiten, ein anderer an der Darstellung der Weltkarte, ohne dass sie sich auf die Füße treten – sogar ohne ein Versionierungs-System (viele Hobby-Projekte nutzen seltsamerweise keine Versionierung. Tipp an dieser Stelle: SVN).

Was macht nun eine Aktionsverwaltung genau? Nun, unsere Aktionsverwaltung ist relativ umfangreich, da sie sich auch um Sicherheitsmechanismen, Rechteverwaltung etc. kümmert. Ein weiterer Vorteil dieser Lösung ist, dass es eine zentrale Stelle gibt, an der man mit solchen Maßnahmen ansetzen kann. Im Einzelnen macht eine Aktionsverwaltung pro Aufruf in etwa folgendes:

function callEvent($module, $action)
{
// Prüfung ob das Modul geladen werden kann
// Laden des Moduls
// Prüfung ob die Aktion im Modul vorhanden ist
// Prüfung ob der Benutzer die Rechte für die Aktion hat
// Konfiguration für die Aktion laden
// Aktion ausführen
}

Zugegeben, in Wirklichkeit ist unsere Aktionsverwaltung für Zeitalter3 komplexer. Ich will aber auch nicht zu sehr ins Detail gehen. Man erreicht auch mit einer rudimentären Aktionsverwaltung bereits sehr viel:

• Sicherheit: jede Aktion ist durch die Sicherheitsmechanismen abgesichert
• Übersichtlichkeit: Aktionen sind logisch in Module gekapselt, aufgeräumte Codedateien
• Modularität: Mehrere Entwickler können an verschiedenen Aufgaben getrennt entwickeln
• Erweiterbarkeit: Man kann jederzeit problemlos Module mit Aktionen hinzufügen

Um eine solche Aktionsverwaltung zu erreichen, bedarf es keiner hohen Magie und keines hochkomplexen Systems, wie sie beispielsweise bekannte Content-Management-Systeme mitbringen. Solche “Monster” von Applikationen haben zum Teil sehr verworrene Methoden der Ablauflogik, was für ihr Einsatzgebiet (vielleicht) sinnvoll ist, aber eigentlich zu Anfang nicht notwendig. Anfangen kann jeder, indem er seine Module in eigene Klassen packt. Diese werden von der Aktionsverwaltung einfach instanziert und jede Aktion ist eine Methode dieser Klasse. Wenn man so weit ist, kann man dann Schritt für Schritt Funktionalität und Sicherheit hinzufügen. Aber alles, was die Index-Datei aufräumt und lesbar hält, ist eine enorme Hilfe. Das Schlimmste ist immer, wenn man nicht mehr weiß, was genau seine eigene Applikation eigentlich macht.