Neben der Höhenstruktur und der Bedeckung des Geländes mit Terrain-Texturen sind Objekte die wichtigsten Elemente eines Kurses. Sie sorgen für den Pflanzenbewuchs, sie formen Felsen und Steine, sie präsentieren sich in Form von Gebäuden usw. Bei den Objekten stehen immer zwei Aspekte eine Rolle: Wie werden sie dargestellt und wie reagiert die Spielfigur, wenn sie auf ein Objekt trifft (Kollision). Da gibt es große Unterschiede bei den Tuxracer-Versionen.

Objekte in Tuxracer 0.61 und allen davon abgeleiteten Versionen

Die Auswahl der Objekte ist extrem klein: Es gibt einige Kursmarkierungen (Flaggen, Start- und Zieltor), es gibt die Heringe und schließlich noch drei Typen von Bäumen. Bei einigen Entwicklungen, z.B. PPRacer, wurden weitere Objekte hinzugenommen, die im Grunde aber lediglich Abwandlungen der bestehenden Objekte sind. Alle Objekte werden ganz einfach in Form von Sprites, d.h. durch simples Zeichnen einer einfachen Textur gebildet. Bei den Bäumen werden zwei Texturen kreuzweise gezeichnet, so dass ein grober Eindruck von Dreidimensionalität entsteht. Alle diese Objekte arbeiten mit dem Alphakanal, können also durchsichtige Teile enthalten. Im Prinzip lassen sich damit relativ filigrane Objekte gestalten, wenngleich die in Tuxracer angebotenen Texturen recht rudimentär sind.

Die Kollision ist ebenfalls extrem spärlich. Einige Objekte wie z.B. Flaggen sind ohne irgendeine Kollision, man kann einfach hindurchfahren. Eine Sonderstellung haben die Heringe inne. Im Kollisionsfall werden sie für den laufenden Kurs deaktiviert, und gleichzeit ertönt das Schnappgeräusch. Tux verschlingt die Fische. Das Prinzip hat sich auch in anspruchsvolleren Versionen übrigens nicht geändert. Eine gewisse Kollision gibt es bei den Bäumen. Zu den Bäumen existieren intern unsichtbare Hüllkörper in Form von polygonalen Meshes, sogenannte Polyhedrons. Die Polies der Tannen haben z.B. die Form von Pyramiden. Wenn nun Tux einen solchen Hüllkörper berührt oder schneidet, tritt der Kollisionsfall ein, aber, wie gesagt, ziemlich simpel. Die Bewegung wird verlangsamt, die Richtung wird geändert und das Objekt wird für den weiteren Verlauf aus der Kollisionserkennung entfernt. Lezteres ist wichtig, damit Tux bei dichtstehenden Objekten nicht hängenbleibt. Einfach und mitunter etwas komisch, aber irgendwie funktioniert es.

Die Objekte beim Gestalten von Kursen

Kursentwickler haben es einfach. Es existiert eine zur Heightmap und Terrainmap korrenspondierende Objektmap. Da alle Objekttypen keine relevante Ausdehnung haben und punktgenau platziert werden können, werden sie einfach als farblich codierte Punkte auf die Ojbektmap gezeichnet. Mit einem Grafikprogramm, das mit Ebenen arbeitet, ist das kein Problem, die Objekte an die richtige Stelle zu setzen. Es ist nicht möglich, die Objekte einzeln zu skalieren oder zu drehen, was zu einer unschönen Gleichförmigkeit führt. Besonders bei Wäldern stört das ziemlich. Außerdem lassen sich Objekte nur im ganzzahligen Pixelraster unterbringen, was für strenge Reihenbildungen sorgt.

Die interne Objektbehandlung

Beim Laden eines Kurses wird die Objektmap ausgewertet, und die Objekte werden in Listen eingetragen, nach Typen getrennt. Während alle Objekte gerendert werden, brauchen nur die Bäume zur Kollisionsbehandlung herangezogen zu werden. Sowohl das Rendern als auch der Kollisionstest erfolgen in jedem Frame, ein bisschen brute force kommt hier in den Ablauf hinein. Das macht sich bei Kursen mit sehr viel Objekten bemerkbar, denn sie laufen spürbar langsamer. Die Geschwindigkeits- und Richtungsänderungen im Kollisionsfall erfolgen werden von der eingebauten Physik-Engine gesteuert, die übrigens den Gleichlauf auf unterschiedlich schnellen Rechnern mit Hilfe eines ODE-Solvers erzielt.

Objekte in Tuxracer 1.1

Die Objekte in diesem kommerziell vertriebenen Programm sind überhauüt nicht mit denen in den freien Versionen vergleichbar. Während alle freien Tuxracer-Versionen sich nicht von der primitiven Objektvehandlung der ursprünglichen Version 0.61 lösen können, wurd in der Version 1.1 ein großer Sprung getan. Alle Objekte sind hier dreidimensional, also aus polygonalen Meshes gebildet. Und alle Objekte erlauben eine vollständige Kollisionsbehandlung, wenn man von den Heringen absieht, die ja einfach nur verschluckt werden. Vollständige Kollisionsbehandlung, das bedeutet, dass Tux je nach Aufprallwinkel an den Polygonen der Objekte entlangrutscht oder bei steilem Aufprall auch mal zurückgeschleudert wird. Alles verbunden mit entsprchenden Richtungswechseln und Geschwindigkeitsverlusten. Teilweise sind die Aufpralle sogar animiert.

Entsprechend den Möglichkeiten gibt es nun ein wesentlich größeres Sortiment an Objekten, vor allem Felsen, Steine, Gebäude, Eisgebilde, Brücken usw. Interessant ist das Baumproblem gelöst. Die Bäume bestehen aus einem sechseckigen Stamm und einer Reihe sattelförmiger Blätterdächer. Wenn der Tux in eine Baumkrone springt, dann kollidiert er mit den Blätterdächern und schießt weiter oder rutscht nach unten. Das ist etws ungewöhnlich, aber überaus reizvoll. Andererseits gibt es nicht viele dieser aufwendig konstruierten Baumtypen, ich glaube nur zwei: eine grüne Tanne und eine schneebedeckte Tanne. Das macht aber nichts, denn die Bäume lassen sich skalieren, verformen, rotieren. Macht man sie entsprechend groß, hat man das Gefühl, durch einen Wald zu gleiten. Die Forest-Kurse demonstrieren dieses sehr beeindruckend. Wegen der aufwendigen Zusammensetzung muss man mit den Bäumen etwas sparsam umgehen, sonst frisst das Rendering zuviel Performance. Aus diesem Grunde gibt es in Tuxracer 1.1 sogenannte "Billboards"; das sind Bäume, sie in herkömmlicher als gekreutzte Texturen gezeichnet werden. Bei größere Abstand von der Kamera schaltet der Baumrenderer auf die Billboard-Methode um.

Die Objekte beim Gestalten von Kursen

Hier sieht's nicht gut aus, denn für die Gestaltung eigener Kurse ist Tuxracer 1.1 nicht gedacht. Es gibt keinerlei Unterstützung, im Gegenteil. Man bekommt den Eindruck, als sei es höchst unerwünscht, mit Eigenkreationen in das System einzudringen. Kurz: Ohne speziellen Editor kommt man nicht weiter. Jedes einzelne Objekt benötigt eine Fülle von Daten, damit es richig gezeichnet werden kann, auch für die Kollision. Das geht nur mit einer ausführlichen Liste, die in Tuxracer 1.1 den Namen items.tcl trägt. Aber selbst das Eintragen eines weiteren Objektes in der Liste ist quasi unmöglich. Alleine schon die Positionierung kann ohne konkrete Anhaltspunkte nicht erfolgreich sein. Fazit: So leistungsfähig und flexibel das Verfahren mit der Objektliste ist, ohne Editor ist da nichts zu machen.

Es kommt ein weiteres Problem hinzu. Die 3D-Meshes werden im Programm in Form von TCL-Skripten erwartet. Die Konvertierung in das lesbare TCL-Format erfolgte bei den Originalobjekten mit Hilfe eines exotischen Hilfsprogramms, das nicht mehr zum Laufen zu bringen ist. So ist man grundsätzlich auf die bestehenden Objekte angewiesen, und da diese wiederum im Kontext der einzelnen Pokale (jeweils 3 Kurse) in den jeweiligen Cup-ordnern untergebracht sind, muss man sich die Ressourcen aus den Nachbarordnern zusammensuchen, was wiederum die Installation neuer Kurse zu einem Abenteuer macht.

Die interne Objektbehandlung

Auch hier bleibt man weitgehend im Unklaren. Der Quelltext wurde nicht veröffentlicht, und wie das Programm intern mit den Ojekten umgeht, lässt sich nur an Hand von Indizien und Beabachtungen erahnen. Vermutlich arbeitet das Programm mit einer Art Paging, denn die Itemliste ist in verschiedene Nodes gegliedert. Inwieweit das wirklich zutrifft, ist ungewiß. Ich konnte bei meinen Experimenten jedenfalls keinen Vorteil dieser Nodes erkennen oder messen.

Objekte in Bunny Hill

Mein Eigenprojekt Bunny Hill gehört - streng genommen - zwar auch zu den Ablegern von Tuxracer, fällt aber dennoch aus dem Rahmen, weil ich von Anfang an andere Schwerpunkte gesetzt habe. Während Openracer, PPRacer und ETRacer vor allem den Renncharakter mit Bestzeiten und Punkten im Fokus hatte, ging es mir vorrangig um die Landschaft und die Bewegung darin. Schöne 3D-Objekte auf den Kurs zu bringen, war das wichtigste Nahziel, wobei Tuxracer 1.1 zunächst mal der Maßstab war. Im Prinzip habe ich einen enormen Schritt in diese Richtung machen können, denn ich schaffte es tatsächlich, kollisionsfähige 3D-Objekte auf den Kurs zu bringen, zunächst natürlich nur einige Prototypen. Leider vergaloppierte ich mich etwas, denn ich betrachtete auch das Terrain als großes Objekt, mit denselben Merkmalen wie die einzelnen Objekte auf dem Terrain. Das funktionierte, aber letzten Endes gelang es mir nicht, den physikalischen Ablauf einigermaßen flüssig zu gestalten. Ich gab das Unterfangen auf.

Die Objekte beim Gestalten von Kursen

Selbstverständlich arbeitet das Bunny-Hill-Konzept mit einer Liste, die gewisse Ähnlichkeit mit der TCL-Liste von Tuxracer 1.1 hat, aber in dem von mir entwickelten SP-Format gespeichert wird. Die SP-Listen sind wesentlich kürzer, übersichtlicher und fehlerresistenter als die umständlich zu händelnden TCL-Listen. Hierbei kann man auch schon mal ein Objekt von Hand eintragen und solange korrigieren, bis der Testlauf zeigt, dass es richtig "sitzt". Doch wie gesagt, über die Testphase ist diese Bunny-Hill-Version nicht gekommen.

Die interne Objektbehandlung

Auch wenn das Projekt nicht über die Testphase hinausgekommen ist, so hat es doch einige wichtige Erkenntnisse gebracht, wie man programmintern mit den Objekten umgehen kann und wie man es besser nicht sollte. Da ist zum einen die Darstellung der 3D-Objekte. Sollen die einzelnen Objekte mit Hilfe von Open-GL-Funktionen direkt vor dem Zeichnen skaliert und rotiert werden, oder sollen diese Parameter bereits im voraus berechnet werden, z.B. beim Einlesen der Itemliste? Es ist ja so, dass die Positonen aller Vertices von der Rotation abhängig sind. Da kommt einiges an Rechnenarbeit zusammen, was man schon vorher einmalig erledigen kann. Andererseits kann OpenGL dieses durch Ausrichten des lokalen Koodinatensystem ebenfalls schnell erledigen. Hier scheinen gezielte Tests sinnvoll zu sein.

Dann die Kollision. In Bunny Hill wurden alle Algorithen selbst programmiert, eine ziemlich wüste Angelegenheit. Es funktioniert zu 99%, aber es kommt doch vor, dass man vor unerwarteten Fehlersituationen steht. Es dürfte deutlich sinnvoller sein, in Kollisionsangelegenheiten auf die Bullet-Library zurückzugreifen.

Und dann wieder die Bäume. So konsequent wie Tuxracer 1.1 alle Bäume als 3D-Objekte zu gestalten, halte ich nach den Erfahrungen mit Bunny Hill nicht für sinnvoll. Diese simplen Kreuztexturen können durchaus ihre Berechtigung haben, denn sie sind güngstig für die Performance, und von weitem können sie zudem noch gut aussehen - vorlausgesetzt, die Texturen werden sorgfältig und sauber gestaltet. Da gibt es noch sehr viel Luft nach oben. Und was die Kollision mit diesen einfachen Dingern betrifft, so muss man sich die Frage stellen, ob es nicht reicht, eine volle Kollision am Stamm einzurichte und in die Baumkronen lediglich eine Abbremsung vorzunehmen. Vielleicht ist auch das überflüssig, wenn kaum die Gefahr besteht, dass Tux in solchen Baumkronen landen. Am Boden allerdings ist die Situation etwas anders. Genau genommen ist es hauptsächlich der Stamm, der ein totales Hindernis darstellt.