Archiv Jahresübersicht der Artikel

Aktionsverwaltung 3

Nov22

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.

Benutzerverwaltung 2

Okt23

Die Benutzerverwaltung ist fertig. Es ist seltsam, aber jedes von mir geplante System zur Benutzerverwaltung wird automatisch wesentlich komplexer, als ursprünglich angenommen. Warnung: es folgt Tech-Talk. Nicht-Programmierer dürfen den Artikel überspringen.

Grundsätzlich ist Benutzerverwaltung eine einfache Sache: ein Benutzer gibt seinen Nutzernamen und das Passwort ein. Anschließend ist er eingeloggt, bis er sich ausloggt oder seine Session abläuft. Hinter den Kulissen läuft jedoch mehr ab. Sehr viel mehr. Da das Framework, welches bei Zeitalter3 zum Einsatz kommt, auch für andere Projekte eingesetzt werden soll, wurde es entsprechend komplex. Fragen wie “Was brauche ich wirklich?” bis hin zu “Was sind konkrete Anwendungsfälle des Frameworks?” mussten zunächst einmal geklärt werden. Mit folgendem Ergebnis:

  • Das Framework soll für alle Arten interaktiver Webapplikationen geeignet sein.
  • Angaben über Benutzer sollen pro Projekt einfach zu konfigurieren sein.
  • Das Benutzersystem soll über ein Rechtemanagement verfügen.
  • Rechte sollen sich in Rollen bündeln lassen.
  • Sicherheitskonzepte sollen transparent im Benutzersystem integriert sein.

Im Detail bedeutet das:

Das Framework soll nicht nur auf Spiele ausgelegt sein, sondern auf alle Arten webgestützte Mehrbenutzerapplikationen. Dies schließt zum Beispiel Communities, eLearning-Systeme und dergleichen mit ein. Daumenregel: alle Systeme mit vielen Nutzern gleichzeitig.

Bei verschiedenen Projekten sind die Daten, die ein Benutzer über sich angeben kann/muss unterschiedlich. Nutzerangaben sollen einfach pro Projekt definiert werden können. Darüber hinaus sollen für jeden Benutzer Rechte für bestimmte Aktionen definiert werden können. Eine Rolle definiert ein festgelegtes Set von Rechten, die ein Benutzer haben kann.

Und schließlich: Sicherheitskonzepte in jeder Komponente müssen für die möglichst manipulationssichere Funktionsweise sorgen – völlig transparent, ohne dass sie der Anwender des Framework je zu Gesicht bekommen muss.

Diese schlappen 5 Punkte kosteten mich etwas über ein Woche. Folgende Komponenten entstanden in dieser Zeit:

Grundlage von allem ist der Session Handler. Dieser verwaltet eine Session, nimmt eventuell vorhandene Session-Cookies des Benutzers auf, prüft Session-IDs gegen die IP und einen Zufallsschlüssel und startet vorhandene und verifizierte Sessions. Die Klasse kümmert sich ebenso um das Auslesen und Speichern von Session-Variablen. Laufende Sessions werden in der Datenbank und nicht als Datei auf dem Server abgelegt.

Von der Seite des Frameworks gibt es eine User-Klasse. Diese verwaltet für die Applikation alles, was mit den Benutzern zu tun hat: Ein- und Ausloggen, Verifizieren des Benutzers aus der Session, Auslesen, Ändern und Speichern von Benutzerdaten, Rechten und Rollen etc. Für Letzteres greift die Klasse ihrerseits auf zwei Helferklassen zurück: eine für die Rechte- und Rollenverwaltung und eine für die Benutzerdaten. Diese sind vor der Applikation im Grunde verborgen, nur die User-Klasse greift darauf zu. Alle Funktionalitäten haben in den jeweiligen Klassen Sicherheitsmaßnahmen, Validitätsprüfungen und fangen eventuell auftretende Fehler ab.

Alles in allem ziemlich “Enterprisey”, wie es ein Entwicklerkollege bezeichnete. Wie aber bereits geschildert soll das Framework in der Lage sein, möglichst viele Aspekte von webbasierten Mehrbenutzersystemen abzudecken. In diesem Fall sind Rechte und Rollen für ein browserbasiertes Spiel eher ungewöhnlich, für Community- und eLearning-Systeme allerdings nicht. Durch die Konfiguration in dem zu dem Framework gehörende Entwickler-Backend wird es möglich sein, die Leistung der Benutzerverwaltung auf die Bedürfnisse der Applikation anzupassen.

Als nächstes ist endlich der Eventhandler dran und dann folgen langsam aber sicher die ersten Prototypen und begleitenden Anwendungen.

Das Marke-Ding 0

Okt20

Marketing hat etwas mit Marke zu tun. So weit so einfach. Doch genau dieses kleine Detail übersehen Betreiber von Hobbyprojekten oft, wenn Sie versuchen Marketing für ihr “Baby” zu machen. Was ist eine Marke? Kann man eine Marke erzeugen, und wenn ja: wie? Und was hat das ganze mit MMOGs bzw. Browserspielen zu tun?
Genauer betrachtet sind das keine leichten Fragen. Klaus Brandmeyer hat Marke einmal definiert als:

“Ein kaufmännisches Handeln, welches auf Nachhaltigkeit ausgerichtet ist und das Ziel verfolgt, sich in seiner Zielgruppe einen guten Namen zu machen.”

Marke dient also dazu, dass man das Produkt, welches man anbietet, in den Köpfen seiner Zielgruppe verankert. Sobald der Begriff erwähnt wird, soll jeder (mindestens jeder Angehörige der Zielgruppe) wissen, worum es geht. Und wenn möglich soll dieser Begriff positiv belegt sein. Wenn wir “Mercedes Benz” hören, dann haben wir ein Bild im Kopf, worum es bei dieser Marke geht: Sicherheit, Qualität, Made in Germany. Bei “World of Warcraft” hat auch jeder ein Bild im Kopf. Und genau darum geht es: ein Begriff soll mit einem Set von Assoziationen verknüpft werden.

Und gleich noch eine Aussage von Klaus Brandmeyer hinterher:

“Marke ist keine Frage des Geldes, Marke ist eine Frage der Disziplin.”

Niemand stampft eine Marke aus dem Boden, nur weil er viel Geld hineinsteckt. Beispielsweise musste dies Sony feststellen, als sie versuchten mit einem gigantischen Medienhype die Playstation 2 einzuführen (wer genau erinnert sich noch an “The Third Place”?). Gleiches stellen gerade viele Entwicklerstudios von MMOGs fest: egal, wer sie sind oder wie viel Geld sie in Marketing stecken: es kratzt noch nicht einmal an der Benutzerzahl von WoW. Und es wäre nicht so, als hätten SOE und Kollegen es nicht versucht. Nein, hier wurde richtig Geld verbrannt. Und? Herr der Ringe Online? Star Wars Galaxies? D&D Online? Kennt man, aber nicht als “Next best Thing”. Man kann WoW nicht dadurch schlagen, indem man einen Medienhype erzeugt, nein, das Spiel an sich muss ebenfalls nachhaltig gut sein, dass es über einen längerfristigen Zeitraum Spieler von WoW abziehen kann. Zur Zeit schaut jeder auf Mythic und Warhammer Online. So weit, so gut. Doch wenn sie nicht auch auf spielerischer Ebene liefern, werden sie in der vorigen Liste von Spielen landen, in der Kategorie: “Netter Versuch”.

Dass ein guter Name nichts mit Geld zu tun hat scheint zunächst mal eine gute Nachricht für Hobbyprojekte zu sein, denen oft Geld fehlt. Genauer betrachtet bedeutet Disziplin hier aber eine gnadenlose Hingabe und ein unnachgebiges Auge für Details. Nachhaltigkeit will erstmal erreicht werden. Und wir reden hier über einen Zeitraum von mehreren Monaten bis Jahren. Werbung kann kurzfristig Köpfe füllen, ja. Aber insbesondere bei Onlinespielen geht es nicht darum, kurzfristig etwas zu verkaufen. Hier muss ein langfristiges Konzept her, um bestehende Spieler (aka Kunden!) zu binden und immer attraktiv für neue Spieler (aka Neukunden!) zu sein. Also Marketing, Weiterentwicklung und Betreuung über einen langen Zeitraum. Scheinbar sind wir also doch wieder bei Geld – oder vielmehr nötigen Ressourcen. Nur nicht auf einen Schlag, sondern über einen langen Zeitraum hinweg. Aber wie erzeugt man nun Bilder in Köpfen?

Zunächst einmal die Grundlage: Definiere die Marke. Es muss definiert werden, wofür das Spiel stehen soll. Was transportiert es? Welche Bilder sollen in den Köpfen der Leute entstehen? Für den Anfang reicht eine abstrakte Liste mit Begriffen. Beispielsweise: “Einsteigerfreundlich”, “Abenteuerlich”, “Episch”, “Spaß”, “Heldenhaft”. Das alles sind Begriffe, direkt von der WoW-Seite. Und zum Vergleich: “Komplex”, “Kriegszustand”, “Marktwirtschaft”, “Spielergesteuert”, “Kommunikativ”. Diesmal von der Webseite von Eve-Online. Selbst, wenn man das Spiel nicht kennt, entstehen Bilder im Kopf. Je genauer die Vorstellung dessen, was euer Projekt repräsentieren soll, desto besser. Natürlich ist es hier mit reiner Begrifflichkeit nicht getan – das Spiel muss natürlich auch alle Begriffe repräsentieren.

Zweiter Schritt: Definiere die Zielgruppe. Bei wem sollen diese Bilder und Assoziationen ausgelöst werden? Nun ist die Vorstellung schön, dass sofort jeder angesprochen werden soll, aber das ist utopisch. Beispiel: “Zeitalter3 ist ein browserbasiertes Weltraum-Handelspiel, bei dem die Spieler in einem umfangreich beschriebenem Universum gegeneinander antreten, um sich in regelmäßigen Spielrunden in verschiedenen Kategorien mit ihren Mitspielern zu messen.” (Direkt aus dem Konzept-Paper). Nun ist klar, dass man mit einem solchen Produkt nicht die Ego-Shooter-Fraktion als Zielgruppe hat. Unterschiedliche Gruppen werden mit dem gewählten Konzept mehr oder weniger anfangen können. In einem Forum für Shooter folglich Werbung zu machen, wird wenig bringen. Es geht darum die Bilder in den richtigen Köpfen zu verankern.

Schritt Drei: Disziplin, Disziplin, Disziplin! Wenn man erst einmal ein Bild definiert hat, dann darf dieses nicht, unter keinen Umständen, NIEMALS geändert werden. Wir sprechen hier von langfristigen Beziehungen. Der Spieler hat eine Beziehung zu seinem Avatar im Spiel, zur Spielwelt, zum Spiel an sich. Verändert man nun das Spiel oder auch nur die Werte und Eigenschaften, für die das Spiel steht, dann hat man ein Problem. Man hat es eben nicht mit “Kunden” zu tun, sondern mit Menschen. Selbst wenn die Neuausrichtung des Spiels es objektiv besser macht, den Spielern wird die Grundlage ihres Spiels genommen.

Tatsächlich gibt es Fallbeispiele für diesen Fehler: Star Wars Galaxies. In einem Versuch Star Wars Galaxies einsteigerfreundlicher und “mehr wie WoW” werden zu lassen (das sich damals auf die 5 Millionen Spieler zubewegte), wurde im November 2005 eine neue Erweiterung veröffentlicht. Diese Erweiterung veränderte das Spiel auf fundamentale Weise: das Kampfsystem wurde schneller, 34 Klassen wurden auf 9 zusammengestrichen, Fähigkeiten und Berufe leichter zugänglich für alle. Auch wenn dies alles objektiv das Spiel einsteigerfreundlicher und damit leichter zugänglich machte, war dies ein Schlag ins Gesicht für alle bislang Spielenden. Hier ging es nicht darum, dass Spieler generell keine Veränderungen mögen. Hier ging es darum, dass sich die Spieler plötzlich nicht mehr in ihrer “eigenen” Welt zurechtfanden. Ein über Monate hinweg liebevoll gespielter Charakter war plötzlich etwas fremdes, eigenartiges. Einst mühevoll erlernte Fähigkeiten nun entfernt und durch andere ersetzt. Das Bild im Kopf der Spieler stimmte plötzlich nicht mehr. Alle Hinweise, Drohungen, Flehen und Bitten der Spieler im offiziellen Forum vergingen scheinbar ungehört. Ergebnis: von 275.000 Spielern zum Zeitpunkt der Einführung der Erweiterung blieben 6 Monate später nur noch 125.000 übrig (Quelle). Gute Artikel über diesen “Zwischenfall” kann man im Escapist lesen: Blowing Up Galaxies oder in Wired: Star Wars Fans Flee Net Galaxy.

Zusammenfassung: Diszipin. Nachhaltigkeit. Durchhaltewillen. Alles im Bezug auf das Projekt muss sich der Marke unterordnen. Alles muss sich dem “Bild”, das transportiert werden soll, entsprechen. Es darf keine Ausnahmen geben. Coca Cola wird morgen nicht mit grünem Farbstoff versehen. Grünes Ketchup ist ein netter Scherz, aber wer kauft das schon? Ganz tief im Kopf macht es “klick” und man denkt: “Das kann doch gar nicht schmecken” – selbst wenn es von einem namhaften Hersteller ist und selbst wenn es 1:1 das Selbe ist. Spieler von Final Fantasy rümpfen die Nase, wenn sie “Kämpfe in Echtzeit” hören. WoW führt nicht plötzlich globales, für alle verbindliches PvP ein. Wenn euer Projekt einmal eine Ausrichtung hat, dann muss diese beibehalten werden. Spieler müssen sich wohl fühlen. Und das sollten sie, wenn sie Tage, Wochen und Monate euer Spiel spielen sollen. Sie müssen sich identifizieren mit eurem Spiel, dem dahinterstehenden Konzept und der Marke, die hinter dem Spiel steht. Wenn sie das nicht mehr können, werden sie gehen. Wenn sie allerdings erst einmal einen Platz gefunden haben, an dem sie sich wohlfühlen, andere finden, denen das ebenso geht, tja, dann werden die Spieler plötzlich zum besten Marketinginstrument überhaupt. Dann nämlich holen sie ihre Freunde.

Zeitalter3 – Browsergames Entwicklerblog is powered by WordPress
Theme based on FREEmium Theme, developed by Dariusz Siedlecki by FreebiesDock.com