3D-Spieleprogrammierung - Professionelle Entwicklung von 3D-Engines und -Spielen

13D-Engines und Spieleprogrammierung (S. 37-38)

»Wir würden es ganz gut finden, wenn man uns heute nur als Objekte der menschlichen Begierde betrachtet und nicht als Musiker.«
(Campino auf dem Frauenkonzert in Rottweil)

Kurz überblickt ...

In diesem Kapitel werden die folgenden Themen behandelt: Was ist eine Engine? Einführung in die Welt der APIs Historisches über DirectX Betriebswirtschaftliche Aspekte der Spiele-Entwicklung

1.1 Modewort 3D-Engine

Die Bezeichnung Engine, oder gar 3D-Engine, erfreute sich in den Kreisen der angehenden Spieleprogrammierer in den letzten Jahren immer größerer Beliebtheit. Doch nicht immer wussten diejenigen, die diese Begriffe verwendeten, was damit ursprünglich gemeint war oder auch heute noch gemeint sein sollte. Einleitend wollen wir also erst einmal die Frage klären, was man überhaupt unter dem Begriff Engine versteht. Schließlich wird es in diesem Buch ausschließlich darum gehen, eine vernünftige Engine für die Entwicklung von Computerspielen zu programmieren und diese dann natürlich auch sinnvoll einzusetzen.

Aus dem Englischen übersetzt, bedeutet das Wörtchen Engine zunächst einmal nichts anderes als Motor. Im Kontext mit der Programmierung bezeichnen wir also die Teile unseres Programms, die eine gewisse Funktionalität des Programms quasi antreiben, als Motoren oder eben als Engines. Diese Begrifflichkeit ist hier nahe liegend, denn wenn wir den Schlüssel in das Zündschloss eines Autos stecken und ihn umdrehen, dann erwarten wir von der Engine des Autos, dass sie das Auto in Fahrbereitschaft versetzt und wir nur noch auf das Gaspedal treten müssen, damit die Engine Bewegungsenergie auf die Antriebsachse bringt und das Auto sich bewegt. Ganz analog starten wir beispielsweise unsere 3D-Engine, indem wir die Schlüssel_im_Zündschloss_umdrehen() Funktion aufrufen. Dann erwarten wir von der 3D-Engine, dass sie die Grafikkarte in Ausgabebereitschaft versetzt. Jetzt können wir auf das virtuelle Gaspedal treten und unsere 3D-Modelle zur Grafikkarte pumpen. Die 3D-Engine hat dann dafür zu sorgen, dass diese 3D-Modelle auf dem zweidimensionalen Monitor erscheinen, und zwar pronto, also so performant wie möglich.

So viel zum Grundprinzip. Nun zu den Missverständnissen. Heutzutage gibt es bereits einige Bibliotheken, die die grundlegendsten Funktionen einer 3D-Engine übernehmen können, und sogar solche, die schon umfassendere Funktionen implementieren. Als Beispiele sind hier DirectGraphics, OpenGL, Java3D oder OpenInventor zu nennen. Schließen wir die eher umfassenderen Ansätze einmal aus und konzentrieren wir uns auf die beiden großen APIs (Application Programming Interface) DirectGraphics und OpenGL, dann haben wir mehr oder weniger integrale Bestandteile der Grafikprogrammierung, die sich über Treiber und DLLs nahtlos in die Schnittstelle zwischen Grafikkarte (Hardware) und Betriebssystem bzw. Applikation (Software) einfügen. Bei solchen APIs handelt es sich aber eben nicht um 3D-Engines. Vielmehr sind sie eigentlich nur dazu da, dreidimensionale Daten zu projizieren und mit schönen Farben versehen als zweidimensionale Pixeldaten auf dem Bildschirm anzeigen zu lassen. Man spricht hier besser von einer 3D-Pipeline, durch die die dreidimensionalen Daten auf dem Weg vom Programm zum Monitor müssen. Zu oft entdeckt man jedoch im Internet kleine Progrämmchen, die gerade mal ein rotierendes Dreieck auf den Bildschirm bringen.

Durch Verwendung einer entsprechenden API ist das mit wenigen Zeilen Quellcode möglich, wie wir schon bald sehen werden. Solche Progrämmchen nennen sich jedoch bereits stolz »3D-Engine« und haben kilometerlange Feature-Listen.

Beispielsweise wird man Folgendes dort lesen können:
Meine 3D-Engine namens MegaMonsterKiller3D hat folgende Features:

Hardware-Rasterisierung von Triangles
Hardware-Transformation and Lightning
Texture-Filtering und Antialiasing
Texture-Blending von bis zu acht Texture-Stages usw.
usw. ...