Status Update: Entwicklung

In diesem Beitrag richten wir unseren Blick auf die Entwickler*innen des E.F.A.-Teams.

Die Infrastruktur für E.F.A. wurde weitestgehend aus dem Vorgänger Projekt ”StressRekord” übernommen. Diese besteht aus dem Frontend und Backend. Das Frontend ist für das Anzeigen der Inhalte zuständig – beginnend mit den Elementen zum Eintippen der Anmeldedaten bis hin zum Anzeigen des Spiels. Das Backend ist für das Speichern, Analysieren und Bearbeiten der Daten zuständig. Beispielsweise die Überprüfung der Nutzerdaten, Speichern der Spielstände und Berechnungen, die für Adaptivität des Spiels nötig sind. Einen schematischen Überblick zeigt Abbildung 1. Das Frontend wurde mit Hilfe des Web-Frameworks ”Angular” umgesetzt. Das Framework unterstützt unsere Entwickler*innen bei der Erstellung einer Anwendung auf Basis des Web-Stacks. Praktisch verwenden wir es weniger für das Spiel selbst, sondern stattdessen für die Authentifizierung oder das Speichern der Spielstände. Das Spiel selbst wird eingebettet unter der Verwendung der WebAssembly-Technologie. Dabei handelt es sich um Binärcode, welcher direkt im Browser ausgeführt wird. Das erhöht die Performanz deutlich gegenüber der Verwendung von Javascript. Unser Werkzeug für die Erzeugung des WebAssembly-Binärcodes ist die Game-Engine ”Godot”. ”Godot” ermöglicht die Entwicklung von Spielen für Smartphones, Konsolen, PCs und Browser. Mit einer Game-Engine kann man den Prozess der Spielentwicklung vereinfachen, in dem man existierende Funktionen benutzt und sie nach eigenen Bedürfnissen anpasst. Am Beginn des Projekts hat unser Entwickler*innen-Team sich ausführlich mit unterschiedlichen Game-Engines auseinandergesetzt. Schlussendlich fiel die Entscheidung zugunsten der Game-Engine von ”Godot”. ”Godot” existiert seit Februar 2014 und ist ein Open-Source Projekt (MIT-Lizenz), welches viele Fans aus der Spieleentwickler-Szene zu sich gezogen hat. Die Verwendung dieser Open-Source-Lizenz ist ein großer Vorteil gegenüber anderen Engines, wie z.B. ”Unity”, und gab für uns den entscheidenden Ausschlag bei der Entscheidungsfindung.

Nach der Festlegung für eine Game-Engine standen unsere Entwickler*nnen vor einer großen Entscheidung. Wie soll das Spiel aussehen? 2D oder 3D? Um diese Frage beantworten zu können, haben wir angefangen, unterschiedliche 2D und 3D Spiele zu bauen. Bei der Entwicklung der Prototypen wurden Faktoren wie Auflösung der Grafiken und Texturen, die Größe und Umfang der Spielkarte sowie Art und Umfang der Hintergrundtöne berücksichtigt. Trotz des großen Interesses des E.F.A.-Teams für ein 3D-Spiel mussten wir uns für eine 2D-Spielumgebung entscheiden, da ein 3D-Spiel zu groß wäre, um es für die mobilen Geräte zur Verfügung zu stellen. Ein 2D-Spiel erzeugt kleinere Dateien und funktioniert flüssiger im Webbrowser und auf älteren Geräten. Trotz der Verwendung einer 2D-Welt ist der Umfang des E.F.A.-Spiels für den praktischen Einsatz im Webbrowser unter z.B. mobilen Bedingungen zu groß. Untersuchungen haben gezeigt, dass dieser Umfang mit einem Minimum von circa 17MB schnell auf 300MB und mehr anwachsen kann. Aus diesem Grund haben wir uns entschieden das Spiel in eine Anwendung zu verpacken und als Download anzubieten. Ein Doppel-Klick auf dem Bildschirm reicht aus, um das Spiel zu starten. Damit wird das Spiel nur einmal heruntergeladen und die verfügbare Bandbreite des Netzwerks wird nur noch für die Kommunikation mit dem Backend verwendet.

Für das E.F.A.-Team besteht ein großes Interesse an einem gut funktionierenden Workflow während der Entwicklung des ersten Prototyps. Unsere Entwickler*innen arbeiten beispielsweise sehr eng mit den Designer*innen und Grafiker*innen zusammen. Hierzu werden die einzelnen Bauteile des Spiels als PNG-Dateien von den Designer*innen zur Verfügung gestellt. Anschließend werden die Grafiken in ”Godot” importiert und für das Zusammenfügen ineinander, wie Puzzle-Teile, als Tile-Element für jede Spielszene bereitgestellt. Aktuell arbeiten wir daran die Spielkarte in Godot zu erstellen und die Funktionen, Minispiele und Herausforderungen zu programmieren.

Während im Frontend die Godot-Engine ausgeführt wird, arbeitet im Backend auf den Servern ein Kubernetes Cluster aus einzelnen Knoten, welche verschiedenste Microservices enthalten. Diese Microservices arbeiten wie ein Netzwerk zusammen, während jeder einzelne Service seine eigene Aufgabe erledigt, wie z.B. das Validieren der Anmeldedaten, das Erzeugen neuer Spieler*innen oder das Speichern und Aktualisieren des letzten Spielstandes. In den kommenden Wochen wird unser Entwickler*nnen-Team sich weiterhin mit der Erstellung der Minispiele beschäftigen und einen ersten Mini-Prototypen zum Testen herausbringen. Wir sind sehr gespannt auf das Ergebnis.