Serverstruktur, Startseite und Aufbau des Spiels

Jan Philipp Vogtherr

Der Grundaufbau des Servers

Die Grafik-Bibliothek THREE.js erlaubt den Einsatz von 3D-Programmierung auf der Basis von WebGL im Browser. Dazu wird die Bibliothek in eine Website eingebunden, die mit HTML erstellt wird. Nun können die Funktionen der Bibliothek mit der Skriptsprache Javascript verwendet werden. Dabei werden die Skripte und somit auch die Grafikberechnungen vollständig client-seitig ausgeführt.

Der Grundaufbau des Spiels besteht somit aus einer HTML-Komponente, die das Layout der Website beschreibt. Mithilfe von Javascript und THREE.js werden die 3D-Szenen erzeugt. Im Hintergrund wird ein Datenbankserver benötigt, um die Highscores der Spieler zu speichern.

Um diesen Aufbau zu realisieren, wird ein Webserver aufgesetzt. Der Server ist in Node.js geschrieben, einer weiteren Bibliothek für Javascript, die das serverseitige Ausführen von Javascript erlaubt. Der Server hat zwei zentrale Funktionen: einerseits betreibt der Server das nötige File Hosting für die Website. In einem dedizierten Ordner auf dem Server befinden sich alle Dateien, die die Website benötigt. Dabei handelt es sich beispielsweise um die HTML-Datein, die Skripte, sowieso Resourcen in Form von Bild- und Audiodateien für das Spiel. Diese Dateien sind öffentlich abrufbar. Insbesondere wird die Datei "index.html" automatisch abgerufen, wenn der Benutzer die Webadresse des Servers besucht.

Die zweite zentrale Funktion des Servers ist, neben dem File Hosting, die Verwaltung der Datenbank. Dazu wird eine MySQL Datenbank aufgesetzt, in der sich eine Tabelle zum Speichern der Highscores befindet. Der Zugriff auf die Tabelle erfolgt über eine REST-Schnittstelle. Über zwei Endpoints können Daten aus der Datenbank ausgelesen werden:

• GET /api/1/highscore gibt die 10 besten Ergebnisse zurück
• POST /api/1/highscore ist die Schnitstelle, an die neue Highscore-Daten im JSON-Format gesendet werden, um anschließend in der Datenbank gespeichert zu werden

Über die Kommandozeile wird der Server entweder zu Test- und Entwicklungszwecken lokal auf dem eigenen Rechner ausgeführt, oder das Programm wird auf einem Webserver installiert, um es öffentlich zugänglich im Internet zu starten.

Die Startseite des Spiels

Sobald der Server gestartet ist und die URL im Browser aufgerufen wird, öffnet sich die Startseite.

Dabei wird automatisch die Datei "index.html" aufgerufen. Auf der Startseite ist eine Szene aus dem Spiel zu sehen, in der das Raumschiff vor einem Planeten und der Sonne im Hintergrund schwebt. Die Bedienelemente auf der Startseite umfassen eine Highscore-Tabelle und den Start-Button, der das Spiel beginnen lässt. Außerdem gibt es eine Anleitung zur Steuerung, die ebenfalls per Button erreichbar ist.

Die Implementierung der Startseite findet in zwei Schritten statt: zunächst wird die Szene im Hintergrund mit THREE.js unabhängig vom Hauptspiel erstellt. Anschließend werden die Bedienelemente in HTML definiert und über die Szene gelegt, sodass sie als 2D-Elemente vor der 3D-Szene hängen. Die Buttons werden per Javascript mit Events belegt. Damit wird für jedes Bedienelement definiert, was bei einem Klick auf dieses Element geschehen soll. Beispielsweise soll ein Klick auf den Start-Button die nächste Seite aufrufen und das Spiel starten.

Die Programmstruktur des Spiels

Wenn der Nutzer das Spiel über das Hauptmenü gestartet hat, wird die Datei "game.html" geladen, die das Layout des Spiels beschreibt. Ähnlich wie beim Startbildschirm wird die 3D-Szene im Hintergrund erzeugt, während die Interface-Elemente per HTML erstellt werden und über das Spiel gelegt werden. Bevor die Szene erstellt werden kann, müssen einige Probleme gelöst werden, die die Entwicklung mit Javascript im Web mit sich bringt.

Für das Anzeigen von Modellen, Texturen und Sounds müssen die Dateien erst geladen werden, denn sie sind nicht automatisch vorhanden. Standardmäßig werden Ressourcendateien wie diese in einer Web-Anwendung erst dann geladen, wenn sie benötigt werden, um die Ladezeiten zu Beginn so gering wie möglich zu halten. Im Falle dieses Spiels ist dies jedoch fatal, denn die Modell- und Texturdateien sind meist sehr groß und sorgen für enorme Ladezeiten, die das Spiel aufgrund der entstehenden Verzögerungen unspielbar machen.

Daher wurde ein Weg gefunden, um die Dateien zu Beginn des Spiels zu laden und das Spiel erst dann zu starten, wenn alle benötigten Dateien vorliegen. Während des Ladeprozesses werden dem Nutzer humorvolle Nachrichten zum aktuellen Status angezeigt. Sobald der Ladeprozess abgeschlossen ist, startet das Spiel.

Die Implementierung dieses Ladeprozesses findet im "FileLoader.js" statt. Der FileLoader hat eine Liste mit allen benötigten Dateien vorliegen. Jedes einzelne Element der Liste soll nun vom Webserver über HTTP in den Arbeitsspeicher geladen werden, sodass bei späteren Zugriffen auf die Dateien keine (bemerkbaren) Ladezeiten auftreten. Hier greift eine Besonderheit von Javascript: der Download-Prozess wird nebenläufig angestoßen. Das bedeutet, dass dem Entwickler nicht garantiert ist, dass die Dateien überhaupt ankommen (aufgrund eines Netzwerkfehlers). Sollten Sie ankommen, so ist unbekannt, wann sie ankommen werden. Allerdings gibt es sogenannte Callbacks, die ein sehr wichtiges Element der Entwicklung mit Javascript sind. Dabei handelt es sich um Funktionen, die dem Befehl zum Herunterladen der Datei mitgegeben werden. Sobald die Datei heruntergeladen ist, führt Javascript automatisch die übergebene Funktion aus. Im Falle des FileLoaders werden diese Callbacks benutzt, um dem FileLoader mitzuteilen, dass die geforderte Datei angekommen ist. Sobald der FileLoader Rückmeldung von allen Callbacks bekommen hat, dass die entsprechenden Dateien da sind, ist der Ladeprozess abgeschlossen und das Spiel ist bereit.

In der Datei "Core.js" befindet sich die Logik für das gesamte Spiel, sie stellt damit das Fundament der Anwendung dar. Hier wird zunächst der FileLoader angestoßen. Wenn der FileLoader fertig ist mit dem Herunterladen der benötigten Resourcen, kann das Spiel beginnen. Dazu werden alle Module geladen und gestartet. Bei den Modulen handelt es sich um Kapselungen der einzelnen Spiel-Funktionalitäten, wie etwa der Welt-Generierung, der Kollisionsberechnung oder dem Partikelsystem. Nun sind alle Dateien vorhanden und alle Module initialisiert. Zu diesem Zeitpunkt wird die Renderloop des Programms gestartet, also die Schleife, in der die 3D-Szene auf den Bildschirm gerendert wird. Diese Renderloop wird 30 mal pro Sekunde aufgerufen, daraus ergibt sich also die Aktualisierungsrate von 30 Frames pro Sekunde (FPS) für das Spiel. Innerhalb jedes Frames wird für alle Module ein Update aufgerufen, welches die Module mit aktuellen Daten des Spielgeschehens versorgt.

Die Implementierung der Module ist in den folgenden Kapiteln beschrieben.