Die Engine

Ein Computerspiel mit einer Komplexität, wie sie bei Cyber E-Razor rockt die Galaxis gegeben ist, benötigt als Basis eine Engine, die grundlegende Funktionen zur Verwaltung von Resourcen, Rückverfolgung von Fehlern (Bugs), Initialisierung von Hardware-Komponenten etc. zur Verfügung stellt. Darüber hinaus bietet es sich an, in so eine Engine bereits etwas spezifischere Datenstrukturen und Algorithmen zu packen, die unter Umständen jedoch nur bestimmte Arten von Computerspielen bzw. bestimmte Techniken zur konkreten Realisierung der Games unterstützen.

Für Hobbyprojekte programmiere ich übrigens in der Regel immer alles viel lieber selbst als fremde Bibliotheken, Frameworks oder ganze Engines zu benutzen. Das bringt gewisse Vor- und Nachteile mit sich: Zum Einen kann ich nach getaner Arbeit fürchterlich stolz auf mich sein und mir selbst auf die Schulter klopfen. Die Entwicklung basiert ausschließlich auf meinem eigenen Code. Ich weiß also immer, was möglich ist und was nicht; und ich vermeide etwaige lizenzrechtliche Fragen. Zum Anderen zieht das natürlich die gesamte Entwicklung unheimlich in die Länge. Ferner laufen die ausschließlich von mir entwickelten Komponenten vermutlich nicht so optimal und fehlerfrei wie es weitverbreitete, etablierte Bibliotheken etc. tun. Oder vielleicht doch? Jedenfalls nehme ich das gerne in Kauf. Schließlich ist aus meiner Sicht des Hobbyprogrammierers der Weg das Ziel, nicht das fertige Produkt. Es soll am Ende natürlich trotzdem was Tolles herauskommen, ganz klar.

Daher möchte ich natürlich mein wahrscheinlich viel zu großes Projekt möglichst schnell vorantreiben. Dieses Entwicklungs-Blog soll nicht nur den aktuellen Entwicklungsstand von Spiel und zugrunde liegender Engine nach außen tragen, sondern zusätzlich für mich einen Ansporn darstellen, das Projekt relativ kontinuierlich voranzutreiben.

Bei meiner dem Spiel zugrunde liegenden Engine handelt es sich um eine volle 3D-Engine, die weitestgehend recht allgemein gehalten ist. Sie ist nicht nur auf Jump-and-Runs beschränkt. (Cyber E-Razor rockt die Galaxis ist ja ein 2,5D-Jump-and-Run. Was man unter 2,5D versteht, ist zunächst eine andere Geschichte und soll ein andermal erzählt werden.) Die Engine besteht im Wesentlichen aus fünf Modulen, die im Folgenden einzeln vorgestellt werden:

MathLabs

Das Modul MathLabs bietet mathematische und geometrische Grundfunktionen. Der Schwerpunkt liegt dabei auf Rechnung mit und Transformation von Vektoren (und Matrizen). Unterstützt werden 2D-, 3D- und (homogene) 4D-Vektoren sowie 2×2-, 2×3-, 3×3-, 3×4- und 4×4-Matrizen. Es ist nicht schlimm, wenn man sich darunter nix vorstellen kann. Aber für diejenigen, die wissen, wovon die Rede ist, mag das vielleicht interessant sein.

BodyLabs

Das Modul BodyLabs ist eine Rigid-Body-Physik-Engine. Rigid Bodies wird in diesem Fall übrigens eher so ausgesprochen: “Ridschid Budies” bzw. [ɹɪdʒɪd 'bu:di:z]. Ist cooler. Also eine Engine zur Simulation von Starrkörperphysik. Das ist etwas verwirrend: Eine Engine als Unterelement einer Engine. Aber so ist das halt: Ein System kann grundsätzlich aus mehreren Systemen bestehen. Zack.

CoreLabs

Das Modul CoreLabs ist der umfangreichste Brocken. Hier findet die Initialisierung der DirectX-Komponenten statt. Texturen, Soundquellen und allgemeine Resourcen werden verwaltet. Ein Logging-System unterstützt insbesondere bei der Entwicklung das Aufspüren von Fehlern. Hier wird auch das Scripting-System zu Hause sein. Die 3D-Modelle werden hier ebenfalls verwaltet. Eigentlich alles, was mit Grafik, Sound, Eingabe, Speicher/Resourcen, Dateizugriff etc. zu tun hat, findet sich hier wieder.

FaceLabs

Das Modul FaceLabs bietet eine grafische Benutzeroberfläche. Das ist aus zweierlei Gründen wichtig: Erstens sind die vom Betriebssystem zur Verfügung gestellten Fenster nicht gut bei einer Fullscreen-Anwendung nutzbar. Denn wenn die Fullscreen-Anwendung aufgrund eines neu aufpoppenden Fensters ihren Fokus verliert, knicken viele der DirectX-Resourcen ein und müssen neu initialisiert werden. Ganz grob gesagt. Zweitens machen geil gerenderte Fenster doch viel mehr her!

ProgLabs

Das Modul ProgLabs stellt hauptsächlich einen Wrapper der gesamten Anwendungsinstanz dar. Es bietet eine geringe Anzahl einfacher Funktionen, mit denen sich die erforderlichen Komponenten der Engine “booten” lassen. Zusätzlich gibt es eine Konsole, die sämtliche Log-Einträge offenbart und auch manuelle Eingaben entgegen nimmt. Die Berührungspunkte des Programmierers mit den einzelnen Komponenten der Engine werden somit verringert, was Entwicklungszeit spart und Programmierfehlern vorbeugt.

Das Modul MathLabs bietet darüber hinaus noch die Möglichkeit, High-speed-Implementierungen zeitkritischer Rechenoperationen zu nutzen. Darunter fällt z.B. die Transformation tausender Vektoren, um die Objekte in einem einheitlichen Koordinatensystem miteinander agieren lassen zu können, oder so. Das ist sehr zeitaufwändig. Das muss nämlich immer wieder neu berechnet werden. Über die Technologien 3DNow! und SSE lässt sich die ganze Sache aber optimieren. Da kann man nämlich die 64- bzw. 128-Bit-Register des Koprozessors nutzen und bis zu vier primitive Rechenoperationen parallel abfrühstücken. Sau geil! Jedoch bin ich mir nicht sicher, ob ich diese Funktionalität nicht doch lieber in das Modul CoreLabs packe. Vielleicht bleibt es nicht nur bei Vektorrechnung, sondern auch Farbräume sollen stapelweise konvertiert werden. Oder vor dem eigentlichen Rendering sollen Objekte bereits beleuchtet werden und erhalten somit andere Farben… ich weiß es noch nicht.