Game Engine

Dieser Artikel behandelt die Game Engine Engine Alpha. Also das von Michael Andonie im März 2010 initiierte Kernstück des Projektes.

Paradigmen

Bei der Entwicklung dieser Software sind einige Grundregeln zu beachten: Diese Engine richtet sich nicht primär an Professionalität. Hierbei geht es vielmehr um das didaktische Selbstverständnis der Engine, dass sich auch im Unterrichtskonzept basierend auf der Engine widerspiegelt. Hieraus folgen einige Paradigmen, die sich in der Architektur der Engine festsetzen:

• Der Weg ist das Ziel: Bei der Umsetzung von Spieleideen mit dem Engine-Alpha-Framework geht es nicht nur um ein möglichst professionelles Endergebnis, sondern um einen möglichst hohen Lerneffekt bei der Modellierung und Implementierung des Endergebnisses. Hierbei soll das Lernen jedoch nicht auf dem Verstehen von spezifischen APIs des JDK liegen, sondern vielmehr auf einer ganzheitlicheren Ebene stattfinden. Daraus ergibt sich die nächste Prämisse:
• Keep it simple, stupid! Die API wird maximal einfach gehalten. Dies passiert, auf verschiedene Arten:
  • A
  • B

Status

Aktuell ist die Engine Alpha in Version 2.0; demnächst wird ein Update-Sprung auf Version 3.0 mit einer Vielzahl neuer Features durchgeführt.

Aktuelle Funktionalität

Kern

Der Kern der Engine entspricht den zentralen, essentiellen Funktionen. Der Umgang mit der API des Kerns ist für die Verwendung der Engine selber daher unumgänglich. Folgende Elemente sind Teil des Kerns:

• Game-Klasse: Zentrale Fassade für eine wesentliche Menge an Funktionalitäten, die die Engine bereitstellt. Ein großer Anteil hiervon ist zwar fakultativ, dennoch stellt Game zweifelsfrei die zentrale Klasse für den API-Nutzer dar.

• Raum-Klasse und -Hierarchie: Die Klasse Raum ist zentraler Bestandteil der sichtbaren Grafike; und zwar (fast) aller. Sie stellt eine starke Funktionalität bereit, die (fast) allen grafischen Elementen zur Verfügung steht.

• Das grafische Composite Pattern: Eine wesentliche Verständnis- und Umsetzungsaufgabe ist das Composite Pattern, das bei dem Rendern zu Rate gezogen wird.

Mehr ist nicht nötig, um einen sehr primitiven, aber grundlegend funktionierenden Spielprototypen zu entwickeln.

Module

Der Grundstock an wirklich nötigem Wissen ist bewusst so knapp gehalten worden, um den Einstieg in die Engine möglichst einfach zu gestalten. Alle weiteren Funktionalitäten sind auf Module ausgelagert, die für sich zumeist unabhängig voneinander über die Tutorials erlernen lassen. So kann man möglichst früh ein eigenes Profil festlegen und sich auf die Module konzentrieren die für das persönliche Spiel relevant sind. Hier sind die derzeitigen Module aufgelistet:

• Multitasking
• Figuren
• Sound
• Kamera
• Dateien Schreiben und Lesen
• Breit angelegtes User Interface
• Freie Farbwahl im ARGB-Bereich
• Eine einfache Physik-Engine

Mehr ist geplant.

Performance

Performance ist ein wichtiger Punkt für die Entwicklung der Software, auch wenn der Fokus nicht hierauf sonder auf der Didaktik liegt. Dennoch soll das Spielerlebnis beim Programmieren und beim Nutzen der mit der API entwickelten Spiele Spaß machen. Dafür wird regelmäßig alter, überholter und umständlicher Code analysiert und verbessert.

Versionsgeschichte

Die Version 1.0 wurde im Februar 2011 der Öffentlichkeit bereitgestellt. Hier war die Funktionalität und Performanz noch relativ.

EDU-Version

Die EDU-Version der Engine Alpha nimmt eine Sonderrolle innerhalb der Game Engine ein. Hier geht es nicht um eine möglichst einfache, aber trotzdem individuell anpassbare Funktionalität, sondern vielmehr um die Verwendbarkeit im Rahmen des Informatikunterrichts.

Geplante Features

Für die nahe und ferne Zukunft sind einige Erweiterungen geplant. Mithilfe ist gerne erwünscht.

Plattformfeatures

• Android-Implementation für die Engine
• Entwicklung einer englischsprachigen API für die Funktionen der Engine

Funktionale Features

• Unterstützung weiterer Soundformate (wie mp3)
• Netzwerk-API
• Online-Highscores

Performance- und Strukturfeatures

• Verbesserung der Sound-API
• Verbesserung der Multitasking-API
• Umstrukturierung der internen Klassen: Auslagerung der Module außerhalb der API in neue Packages zur besseren Übersicht und Wartbarkeit