Game-Engines vs. C++
Alle Tuxracer-Varianten, einschließlich meiner Bunny-Hill-Versionen - wurden unter minimaler Verwendung zusätzlicher Libraries verwendet. Lediglich SDL für die Fensterverwaltung und den Sound sowie FTGL für die Schriftdarstellung wurden eingebunden. Immer wieder erhielten die Entwickler den Tip, die Arbeit durch den Einsatz von Engines und Libraries zu erleichtern und zu beschleunigen. Gerade die Beschleunigung ist ein nicht zu vernachlässigendes Argument, denn die Misserfolge aller Tuxracer-Varianten sind nicht nur, aber auch darauf zurückzuführen, dass die Arbeit viel zu langsam voranging. Die Entwicklung bei der Spieleprogrammierung hat das Programm in verschiedener Hinsicht überholt. Darüber hinaus lassen alle bisherigen Versionen einige Optionen vermissen, die vernünftigerweise am besten mit speziellen Libraries zu realisieren sind. Dazu gehört z.B. eine Kollisionserkennung, die das Programm wesentlich aufwerten würde.
Zweifellos sind die Ratschläge gut gemeint und im Prinzip auch vernünftig, doch fehlt den Ratgebenden in der Regel die Einsicht in die inneren Strukturen und Besonderheiten von Tuxracer. Die guten Erfahrungen mit der einen oder anderen Engine oder Library basieren auf der Kennnis von Spielen, die mit Tuxracer nicht sehr viel gemein haben. Viele Entwickler haben Erfahrungen mit Ego-Shootern und glauben, diese Erfahrungen könnten auch Tuxracer zugute kommen. Doch es gibt eine einige Besonderheiten in Tuxracer, die kaum einen sinnvollen Vergleich zulassen. Gleichwohl habe ich mich vor Beginn der Arbeit aufgeschlossen für jeden Vorschlag gezeigt und mich über die Engines kundig gemacht. Einige davon habe ich gründlich getestet.
Ungeeignete Engines und Libraries
Die folgenden Engines konnte ich schnell wieder verwerfen, obwohl sie etwas Verführerisches an sich hatten:
- UDK. Eine Engine zum schnellen Zusammenklicken von Spielen. Scheidet aus, da nur für Windows verfügbar. Außerdem in abstoßender Weise für Ego-Shooter mit Monstern und Waffengetöse optimiert.
- Unity. Wie UDK nur für Windows, deshalb nicht geeignet.
- TrueSpace. Eine Klick-Engine, die nur unter Windows zur Verfügung steht. Scheidet deshalb aus.
- Maratis. Eine sehr sympathische Game-Engine, die aber zu begrenzt ist. Kann kaum etwas zu Tuxracer beitragen.
- Crystal Space. Alles, was das 3D-Herz begehrt: Grafik-Library und Game-Engine in einem. Im Laufe der Zeit aber zu einem Monster ausgewachsen und wie OGRE kaum installierbar, mit einer unüberschaubaren Anzahl von Abhängigkeiten. Ich hab's nicht hinbekommen.
Engines und Libraries, die evtl. geeignet sind
- SDL. Library, die einige elementare Aufgaben übernehmen kann, z.B. das beim Laden von Grafiken. Vor allem aber bietet SDL eine Fensterverwaltung und stellt ein OpenGL-Fenster zur Verfügung, eine unerlässliche Option. Dazu gehört auch die Abfrage von Benutzereingaben mittels Tastatur oder Maus. SDL_image und SDL_mixer erweitern die Möglichkeiten und bieten mehr Komfort im Umgang mit Grafik oder Sound. Insgesamt relativ komplett, wenn auch nicht sehr komfortabel.
- Irrlicht. Grafikengine, die das Rendern von Grafiken auf dem OpenGL-Screen in komfortabler Weise ermöglicht und wie SDL die Fensterverwaltung sowie die Verwaltung der Benutzereingaben übernimmt. Viele Dinge rund um 3D-Grafik, das Laden von Bildern sowie die Darstellung auf dem Screen erfolgt äußerst komfortabel. Bietet allerdings kein Audio und erfordert deshalb eine weitere Library. Die Zusammenarbeit mit SDL scheint nicht angebracht zu sein; die beiden würden sich zu sehr in die Quere kommen.
- Bullet. Physik-Engine für das Verhalten von beweglichen Objekten entsprechend den Naturgesetzen. Ferner eine leistungsfähige Kollisionsbehandlung. Es gibt mehrere andere ordentliche Physik-Engines, aber Bullet scheint nach meinen Recherchen die derzeit beste zu sein.
- Blender-Game-Engine. Ein Exot unter den Engines, weil der gesamte Spielablauf mit Hilfe von vorprogrammierten, logischen Elementen (logic bricks) programmiert wird. Das ist bei größeren Programmen ziemlich umständlich, bei überschaubaren Programmen durchaus vertretbar. Die Performance scheint nicht besonders gut zu sein.
Eignung für bestimmte Aufgaben
X X X - hervorragend geeignet
X X - geht ganz gut
X - zur Not
--- ungeeignet bzw. nicht dafür vorgesehen
| Aufgabe | C++ | SDL | Irrlicht | Blender (1) | Bullet | Sonstiges |
| Fensterverwaltung Eventloop |
--- | X X X | X X X | X X | --- | . |
| Texturen Bilder |
X | X X | X X X | X X | --- | . |
| Terrain Scene-Rendering (2) |
X | --- | X | X | --- | Quadtree gesucht |
| Terrain Eigenschaften |
X X X | --- | --- | --- | --- | . |
| Terrain Licht, Fog |
X X | --- | X X X | X X X | --- | . |
| Charakter Animation |
X | --- | ? ? | X X | --- | . |
| Charakter Keyframes |
X X X | --- | --- | X X | ? | . |
| Objekte Rendering |
X X | --- | X X X | X X X | --- | . |
| Bewegung Physik |
X X X | --- | --- | X | X X X | . |
| Bewegung Kollision |
X | --- | --- | X X X | X X X | . |
| Audio | --- | X X X | --- | ? | --- | Audio-Lib gesucht |
| Menüs Font |
X | --- | X X | X | --- | C++ mit FTGL GUI-Lib gesucht |
| Partikel Schneeflocken |
X X X | --- | ? | X X X | --- | . |
| Trackmarks | X X | --- | --- | --- | --- | . |
(1) Die Blender-Spalte hat eine besondere Stellung, denn das sind die geschätzten Optionen beim Einsatz der Blender-Game-Engine. Diese kann nicht mit anderen Libraries oder Engines kombiniert werden, nicht einmal C++-Code ist ohne großen Aufwand damit zu kombinieren.
(2) Beim Rendering des Terrains spielt natürlich die Qualität eine Rolle; noch wichiger ist aber die Performance, da bei Tuxracer immer große Teile der Szene im Visible-Bereich liegen, teilweise mit mehreren hunderttausend Triangles. Bis jetzt erfüllt noch keine Engine die gewünschten Erfordernisse. Zwar hat Tuxracer schon einen Quadtree implementiert, doch der gehört zu den Programmteilen, die am dringendsten ersetzt werden müssen. Grund: Der Algorithmus erlaubt nur sehr wenige Terrain-Texturen gleichzeitig.
Wie entscheiden?
Die Blender-Game-Engine, so phaszinierend sie sein mag, scheidet eigentlich aus. Die Wahrscheinlichkeit, dass damit das Programm mit hinreichender Performance zu realisieren sein wird, ist sehr gering. Außerdem ist zu beachten, dass die Terrain-Eigenschaften (Reibung, Steuerungsfähgigkeit, Eintauchtiefe, Gleitsound usw.) sehr wichtig sind und letztlich nur in C++ realisiert werden können. Das Terrain in Tuxracer ist mehr als nur Grafik! Wenn Tuxracer mit der Blender-Engine eine Chance hat, dann nur mit einer anderen Spielidee.
Der Einsatz von Bullet dürfte klar sein. Unklar ist aber noch die Rolle von Irrlicht. Auf den ersten Blick stellt sich sowas wie Begeisterung ein. Einbindung von Figuren samt Animation? Lediglich 2 oder 3 Codezeilen sind erforderlich. Oder das Laden von Bitmaps? Kein Problem, mit allen wichtigen Grafikformaten kann Irrlicht umgehen. Selbst GUI-Widgets bietet Irrlicht, die zugehörigen Callback-Funktionen werden wie Keyboard- oder Mausaktivitäten in der Ereignisschleife behandelt. Alles also überzeugend und wunderbar.
Wie gesagt, auf den ersten Blick. Die Engine ist universell angelegt und will alles managen. Das hat z.B. zur Folge, dass die so komfortabel geladenen Texturen nur im Rahmen dieser Engine, d.h. unter Verwendung der implizierten Funktionen, verwendet werden können. Oder die Widgets: Abgesehen davon, dass diese Art von Widgets wahrscheinlich gar nicht für Tuxracer geeignet ist, ist z.B. die Schriftdarstellung realitiv bescheiden. Gegenüber den skalierbaren Schriften in den bisherigen Versionen von Tuxracer wäre das ein Rückschritt. Wenn man nun genau hinschaut, dann stellt man fest, dass Irrlicht gar nicht so viel mehr leistet als der C++-Code, der ja zum großen Teil schon vorliegt. Und das, was im bisherigen Tuxracer noch fehlt, bietet Irrlicht ebenfalls nicht in überzeugender Weise.
Ein möglicher Grund für das Festhalten an Irrlicht könnte die Charakter-Animation sein. Als Editor kommt nur Blender in Frage, doch die aktuelle Version hat keinen Exporter für ein von Irrlicht unterstütztes Format. Die Quake-Formate können zwar (beschränkt) exportiert werden, aber ob sie für Tuxracer geeignet sind, ist zur Zeit fraglich.