(Paradigmen)
K (fixed links)
Zeile 25: Zeile 25:
 
* '''[[Klasse:Game|<code>Game</code>]]-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 <code>Game</code> zweifelsfrei die zentrale Klasse für den API-Nutzer dar.
 
* '''[[Klasse:Game|<code>Game</code>]]-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 <code>Game</code> zweifelsfrei die zentrale Klasse für den API-Nutzer dar.
  
* '''[[Klasse:Raum|<code>Raum</code>]]-Klasse und -Hierarchie''': Die Klasse <code>Raum</code> ist zentraler Bestandteil der sichtbaren Grafike; und zwar ([[Tutorial:Simple Grafiken|fast]]) aller. Sie stellt eine starke Funktionalität bereit, die ([[Tutorial:Simple Grafiken|fast]]) allen grafischen Elementen zur Verfügung steht.
+
* '''{{Doc|ea/Raum}}-Klasse und -Hierarchie''': Die Klasse <code>Raum</code> ist zentraler Bestandteil der sichtbaren Grafike; und zwar ([[Tutorials/Simple Grafiken|fast]]) aller. Sie stellt eine starke Funktionalität bereit, die ([[Tutorials/Simple Grafiken|fast]]) allen grafischen Elementen zur Verfügung steht.
  
* '''Das grafische [[Software Pattern in der Engine Alpha#Composite Pattern|Composite Pattern]]''': Eine wesentliche Verständnis- und Umsetzungsaufgabe ist das ''Composite Pattern'', das bei dem [[Tutorial:Einführung#Objekte werden sichtbar|Rendern]] zu Rate gezogen wird.  
+
* '''Das grafische [[Software Pattern in der Engine Alpha#Composite Pattern|Composite Pattern]]''': Eine wesentliche Verständnis- und Umsetzungsaufgabe ist das ''Composite Pattern'', das bei dem [[Tutorials/Einführung#Objekte werden sichtbar|Rendern]] zu Rate gezogen wird.  
  
 
Mehr ist nicht nötig, um einen sehr primitiven, aber grundlegend funktionierenden Spielprototypen zu entwickeln.  
 
Mehr ist nicht nötig, um einen sehr primitiven, aber grundlegend funktionierenden Spielprototypen zu entwickeln.  
Zeile 35: Zeile 35:
 
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|Module]] ausgelagert, die für sich zumeist unabhängig voneinander über die [[:Kategorie:Tutorials|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:
 
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|Module]] ausgelagert, die für sich zumeist unabhängig voneinander über die [[:Kategorie:Tutorials|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:
  
* '''[[Tutorial:Multitasking|Multitasking]]'''
+
* '''[[Tutorials/Multitasking|Multitasking]]'''
* '''[[Tutorial:Figuren|Figuren]]'''
+
* '''[[Tutorials/Figuren|Figuren]]'''
* '''[[Tutorial:Sound|Sound]]'''
+
* '''[[Tutorials/Sound|Sound]]'''
* '''[[Tutorial:Kamera|Kamera]]'''
+
* '''[[Tutorials/Kamera|Kamera]]'''
* '''[[Tutorial:I/O|Dateien Schreiben und Lesen]]'''
+
* '''[[Tutorials/IO|Dateien Schreiben und Lesen]]'''
* '''[[Tutorial:User Interface|Breit angelegtes User Interface]]'''
+
* '''[[Tutorials/User Interface|Breit angelegtes User Interface]]'''
* '''[[Tutorial:Farben|Freie Farbwahl im ARGB-Bereich]]'''
+
* '''[[Tutorials/Farben|Freie Farbwahl im ARGB-Bereich]]'''
* '''[[Tutorial:Physik|Eine einfache Physik-Engine]]'''
+
* '''[[Tutorials/Physik|Eine einfache Physik-Engine]]'''
  
 
Mehr ist geplant.
 
Mehr ist geplant.
Zeile 64: Zeile 64:
 
== Geplante Features ==
 
== Geplante Features ==
  
Für die nahe und ferne Zukunft sind einige Erweiterungen geplant. [[Contribute|Mithilfe]] ist gerne erwünscht.
+
Für die nahe und ferne Zukunft sind einige Erweiterungen geplant. [[Mithelfen|Mithilfe]] ist gerne erwünscht.
  
 
=== Plattformfeatures ===
 
=== Plattformfeatures ===
Zeile 80: Zeile 80:
 
=== Performance- und Strukturfeatures ===
 
=== Performance- und Strukturfeatures ===
  
* Verbesserung der [[Klasse:Sound|Sound]]-API
+
* Verbesserung der {{Doc|ea/Sound}}-API
* Verbesserung der [[Tutorial:Multitasking|Multitasking]]-API
+
* Verbesserung der [[Tutorials/Multitasking|Multitasking]]-API
 
* Umstrukturierung der internen Klassen: Auslagerung der Module außerhalb der API in neue Packages zur besseren Übersicht und Wartbarkeit
 
* Umstrukturierung der internen Klassen: Auslagerung der Module außerhalb der API in neue Packages zur besseren Übersicht und Wartbarkeit
 
* Neuanordnung des Figurenformats
 
* Neuanordnung des Figurenformats

Version vom 1. November 2014, 12:04 Uhr

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:

  • Minimal einfach bei größtmöglicher Funktionalität: Die Umsetzung von Spieleideen sollte möglichst einfach sein. Das ist aufgrund des [Didaktik der Engine|didaktischen Gedankens] der Engine essentiell. Trotzdem sollte die Funktionalität auch ausreichend groß sein, um die Produktion ansehnlicher Spiele zu ermöglichen. Dieses Ziel rückt allerdings im Angesichts zu komplexer Programmstrukturen klar in den Hintergrund.
  • 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:
    • Komplexe Methoden werden stets mit einfacheren überladen (Standardwerte).
    • Exceptions werden stets intern gefangen und eine deutsche Bildschirm-Fehlerausgabe informiert über das Problem, ohne dass man sich z.B. mit try-catch-Strukturen auseinandersetzen muss.
    • Möglichst viele Features sollen über die Klasse Game erreichbar sein, die auf viele Funktionalitäten als Fassade zugreift und diese als einheitliche Hauptschnittstelle bereitstellt.
    • Auch die zusätzlichen Features zu der Kernfunktionalität sind stufenweise aufgebaut. Man kann von einfachen Grundlagen bis hin zu der komplexen Funktionalität möglichst gut stufenweise voranschreiten.

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:

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.

Kompatibilität

Die Engine läuft derzeit auf allen Desktop-Systemen, die Java (das Java Runtime Environment installiert haben, zum Beispiel Windows, Mac und Linux-Distributionen.

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
  • Neue Figurfunktionen

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
  • Neuanordnung des Figurenformats