Schon immer konnten mit PHP Internet-Spiele entwickelt werden, dies bedingt allerdings die Benutzung eines Browsers zur Darstellung und eines Webservers für die eigentliche Spiel-Logik. Mit der immer weiter fortschreitenden Entwicklung PHPs hin zur allgemein verwendbaren Skript-Sprache und den verschiedenen Extensions für zeichen- und grafikbasierte Benutzeroberflächen ist es mittlerweile aber auch möglich, Standalone-Spiele (und natürlich auch Applikationen) zu entwickeln, die ohne Browser und Server auskommen. Das in diesem Artikel vorgestellte Spiel-System bietet die Möglichkeit, einfache rasterbasierte Spiele zu entwickeln, die mit nur einer gemeinsamen Codebasis auf allen unterstützten Frontends spielbar sind.

Dabei unterstützt das Spiel-System bisher nur eine spezielle Art von Spielen: Zugbasierte Einspieler-Spiele auf einem festen Raster. Die Darstellung des Spielfelds ist beschränkt auf vordefinierte Grafikelemente fester Größe, die innerhalb eines festen rechteckigen Rasters platziert werden. Durch diese Einschränkung ist es möglich, diverse Darstellungs-Frontends bis hin zum rein zeichenbasierten Ncurses zu unterstützen.
Das Spiel-System ist Event-gesteuert und verarbeitet nur durch den User ausgelöste Eingabe-Events. Timer Events werden nicht unterstützt, da sie nicht in allen Frontends umgesetzt werden können, insbesondere nicht im HTTP/HTML-Frontend. Damit sind Ereignisse, die unabhängig von User-Interaktionen stattfinden sollen, nicht umsetzbar (wie z.B. Feinde, die sich auch dann bewegen, wenn der Spieler still steht).
Die aktuelle Beschränkung auf einen Spieler ist künstlich und nur durch das aktuelle Design des Input Event Handlers bedingt. Die Umsetzung von Eingaben durch mehrere Spieler ist zwar trotzdem prinzipiell möglich, aber es ist dann Aufgabe der Applikation, Eingaben einem bestimmten Spieler zuzuordnen.

Frontends
PHPs Stärke im Vergleich mit anderen Sprachen wie PERL war stets der besondere Focus auf Web-Funktionalitäten. Aber auch als generell anwendbare Skript-Sprache bietet sich PHP mehr und mehr an. Scripting war schon länger durch Missbrauch des CGI-Binaries möglich, ab PHP 4.3 wird unabhängig vom gewählten Server-API grundsätzlich auch eine spezielle Kommandozeilenversion (CLI) erzeugt. Diese ist dem CGI Binary vorzuziehen, da sie im Gegensatz zu diesem keine Kompromisse in Hinblick auf Web-Funktionalitäten eingehen muss. Auch das PHP CLI Binary bietet zunächst einmal keine Benutzerführung, die über einfache zeilenweise Ein- und Ausgabe hinausgeht und entspricht diesbezüglich in der Funktionalität zunächst einmal einer einfachen Shell. Aber im Gegensatz zur Shell lässt sich das CLI durch entsprechende Extensions aufrüsten:

Ncurses

Ncurses erweitert die zeichengestützten Ein- und Ausgabefunktionen um Einzelzeichen-Eingabe und Ausgabe, farbigen Text und direct-positionierte Ausgaben. Weiterhin bietet es auch Unterstützung für Fenster, Menüs und Formulare auf Textbasis. Das Interface ist zwar nicht grafisch, dafür aber auf beinahe jedem jemals hergestellten Text-Terminal verfügbar.

Abb. 1: Das unter Benutzung von Ncurses erstellte Spiel Sokoban

Abb. 2: Das unter Benutzung von Ncurses erstellte Spiel Sokoban

SDL

Die Simple Direct Layer-Bibliothek bietet annähernd direkten Zugriff auf den Grafik-Buffer, Sound und Eingabegeräte. Sie ist auf verschiedenen Plattformen verfügbar, darunter auch Windows, und wurde auch bereits zur Umsetzung kommerziell erfolgreicher Spiele eingesetzt. Die PHP SDL Extension ist verfügbar unter sourceforge.net/projects/phpsdl/

Abb. 3: SDL bietet etwas mehr für's Auge

GTK

Das GTK Toolkit bietet abstrakte GUI-Elemente und kann von einer Vielzahl von Programmiersprachen aus genutzt werden. Auch PHP-Unterstützung ist mittlerweile verfügbar, wenn auch noch mit leichten Haken und Ösen. Nähere Informationen zu dieser Anbindung finden sich unter gtk.php.net/.

Das Spiel-System unterstützt zur Zeit Ncurses und SDL als direct Frontends sowie die klassische Aufteilung zwischen Webserver und Browser über HTTP/HTML. GTK-Unterstützung ist in Arbeit, aber zumindest während ich dies schreibe noch nicht vollständig umgesetzt.

Zusammensetzung
Für die Entwicklung eines Spieles benötigt man zunächst einmal die entsprechenden grafischen Bausteine. Unglücklicherweise benötigen die verschiedenen Frontends unterschiedliche Grafikformate. Das HTML Frontend kann jedes Format benutzen, das gängige Browser unterstützen, i.A. bietet sich hier GIF an. SDL dagegen akzeptiert nur Windows BMP-Dateien, die wiederum auf nicht-Windows Plattformen nicht unbedingt vom Browser unterstützt werden. Ncurses wiederum kann nur einfache Text-Zeichen darstellen, evtl. sogar nicht einmal farbig.
Die Bausteine müssen vor der Benutzung registriert werden, dazu muss der Datei-Stammname ohne Endung sowie ein Ersatzzeichen (mit optionaler Farbangabe) für die Textausgabe angegeben werden. Bausteine in verschiedenen Dateiformaten müssen unter dem jeweils gleichen Stammnamen abgelegt werden, das jeweilige Frontend wählt dann die für seine Zwecke geeignete Version selbständig aus.
Nachdem die Bausteine registriert sind kann das eigentliche Spielfeld aufgebaut werden. Zur Erzeugung des Spielfelds werden Breite und Höhe vorgegeben. Die einzelnen Teilfelder werden dabei mit dem zuerst registrierten Baustein vorbelegt, diese sollten daher möglichst ein Hintergrund-Element sein. Nachdem der Spielfeld-Aufbau nach den eigenen Vorstellungen modifiziert wurde, kann es angewiesen werden, sich selbst auszugeben. Im weiteren Verlauf des Spieles können Felder umbelegt und erneute Ausgaben angefordert werden. Das jeweilige Frontent entscheidet dabei transparent, ob es nur die Änderungen vornimmt oder das gesamte Spielfeld neu darstellt.

Ereignis-Schleife
Nachdem nun das Spielfeld vorbereitet ist wird es Zeit, die eigentliche Spiel-Logik umzusetzen. Das Spielsystem stellt Benutzereingaben als abstrahierte Events zur Verfügung. Ein Event gehört dabei zu einer der vier folgenden Kategorien:

• Relative Bewegungen wie LEFT, RIGHT, UP oder DOWN
• Absolute Positionen wie Zeile 6, Spalte 3
• Spezielle Benutzereingaben wie BACK oder QUIT
• Die speziellen Ereignisse SLEEP und WAKEUP

Die CLI Frontends laufen in einer einfachen Event-Schleife, bei der HTML/HTTP-Implementierung dagegen wird das Spiel-Script für jeden Zug neu gestartet. Mithilfe der speziellen WAKEUP- und SLEEP-Events kann dieses abweichende Verhalten ohne Änderungen im Design mit unterstützt werden. Jeder HTTP-Request führt dabei zu jeweils genau drei Events: einem WAKEUP, das das Wiederherstellen von Statusinformationen ermöglicht, dem eigentlichen Eingabe-Event, sowie einem SLEEP, das die Applikation dazu auffordert, ihre Status bis zum nächsten Request zu sichern. Der Spielfeld-Aufbau, die Position der Spielfigur, die Anzahl der Züge sowie der aktuelle Punktestand werden dabei bereits von der Applikation selbst gesichert. Für eigene Status-Informationen stellt das System Funktionalität zum Speichern und Wiederherstellen bereit.
Sokoban
Das Spiel-System enthält als Beispielimplementierung den Klassiker Sokoban, in dem man als Lagerarbeiter Kisten an ihre Zielposition verschieben muss, ohne sich selbst den Weg zu verbauen. Es sind alle 50 ursprünglichen Sokoban-Level in Form von serialisierten PHP-Arrays vorhanden, ebenso die benötigten Spielsteine als GIF- und BMP-Grafiken.
Das Spiel bietet an Besonderheiten u.a. eine unbeschränkte Undo-Funktion (würde man eine Highscore Liste führen, so würde man den Einsatz von Undo allerdings vermutlich beschränken wollen). Weiterhin ist das Spiel in der Lage, bei einem Mausklick auf ein freies Feld den kürzestmöglichen Weg dorthin zu bestimmen und direkt umzusetzen (natürlich nur in Frontends mit Mausunterstützung).
Ich werde hier nicht auf die Details der Implementierung eingehen, das Spiel-System und die Beispiel-Implementierung sind ausreichend dokumentiert und sollten zusammen mit der beiliegenden Readme-Datei die Umsetzung eigener Spielideen in kürzester Zeit ermöglichen.
Verfügbarkeit und Pläne
Das Spiel-System ist öffentlich verfügbar unter sourceforge.net/projects/phpgames/.
Zurzeit ist Sokoban das einzige damit implementierte Spiel, das Framework ist aber generell genug entworfen, um schnell und flexibel andere Ideen umzusetzen. Die Entwicklung eigener Spiele ist willkommen. Das Framework selbst ist unter der PHP-Lizenz veröffentlicht. Das GTK Frontend sollte, während sie dies lesen, vollständig umgesetzt sein, allerdings möchte ich dafür nicht garantieren.
Ich selbst habe darüber hinaus keine weiteren Pläne, das System zu erweitern. Nicht dass ich denke, es wäre nicht mehr zu verbessern, allerdings wird mein Fokus in absehbarer Zeit nicht auf PHP-Benutzeroberflächen liegen. Es steht aber trotzdem jedem frei, Verbesserungen einzubringen. Auch einer vollständigen Übergabe des Projekts an einen neuen Betreuer gegenüber wäre ich nicht abgeneigt. Einzige Voraussetzung für beides ist ein eigener SourceForge Account. Have Fun!