Diesen Artikel habe ich 2008 verfasst; er berücksichtigt also nicht die neuesten Entwicklungen. Aus Gründen der Authentizität gebe ich den teilweise obsoleten Artikel unverändert wieder. Am Schluss habe ich allerdings noch einen ergänzenden Abschnitt "Aktueller Stand" hinzugefügt, der kurz auf die derzeitige Situation (2015) eingeht.

September 2015

Begonnen hat die Entwicklung wohl im Jahr 1999. Eine Gruppe von jungen Leuten rund um Jasmin Patry, allesamt Absolventen der University of Waterloo (Ontario, Kanada) entwickelte das Programm bis zur lauffähigen Version 0.61, die 2000 erschien. Das Programm wurde unter der GPL veröffentlicht, und da es zu der Zeit praktisch das einzige Programm war, das unter Linux in 3D und Echtzeit lief, wurde es von fast allen Distributionen aufgegriffen und integriert. Hinzu kam, dass zu dieser Zeit die ersten Treiber verfügbar wurden, die einen hardwarebeschleunigten Betrieb von OpenGL-Programmen auch unter Linux erlaubten.

Doch die Version 0.61 sollte zugleich die letzte freie Version bleiben. Es gibt Anzeichen, dass die Entwicklergruppe bereits beim Erscheinen der Version 0.61 die Absicht hatten, das Spiel unter kommerziellen Gesichtspunkten weiterzuentwickeln. Diese kommerzielle Version, gleich mit der Versionsnummer 1.0 bzw. 1.1 versehen, erschien etwa 2002-2003, den genauen Zeitpunkt kann ich nicht sagen. Tuxracer 1.1 war sowohl für Linux als auch für Windows verfügbar und wurde vertrieben von Sunspire Studios, einer Gründung des Entwicklerteams.

Aber auch die offizielle, kommerzielle Version dümpelte eher vor sich hin. Inzwischen gab es gewaltige Konkurrenz in Form von groß angelegten Action-Spielen, gegen die das stille und bescheidene Tuxracer keine wirklichen Chancen hatte, owohl das Programm gegenüber der freien Version 0.61 dramatische Fortschritte gemacht hatte und insbesondere mit einer erheblich besseren optischen Ausstattung aufwarten konnte. Hinzu kam, dass Tuxracer 1.1 kaum noch ausbaufähig war, nicht zuletzt, weil die Entwickler sich alle Erweiterungswege durch eine strikt geschlossene Konzeption verbauten.

Das Ende von Tuxracer 1.1 kann aus heutiger Sicht nicht überraschen, wohl aber die Art und Weise, wie der Schlussstrich gezogen wurde. Genau genommen wurde überhaupt kein Schlussstrich gezogen, sondern Tuxracer verschwand (etwa 2004 oder 2005) sang- und klanglos von der Bildfläche. Die Domäne von Sunspire Studios wurde anderweitig belegt und genutzt, und zu den Entwicklern führt bis heute keine Spur mehr. Alle Versuche, mit ihnen noch einmal in Kontakt zu treten, schlugen fehl. Dabei gab es eine ganze Reihe von Leuten, die das Ende von Tuxracer 1.1 zutiefst bedauerten und insgeheim mit dem Gedanken spielten, die Entwickler könnten das Programm ja nun frei geben.

So verständlich dieser Wunsch war, ja, so naheliegend ein solcher Schritt gewesen wäre, es geschah nichts dergleichen. Eher durch Zufall stießen wir im letzten Jahr (2007) darauf, dass das Programm nun im Besitz von Roxor Games ist und als Arcade-Spiel betrieben wird. Es gibt gute Gründe für die Annahme, dass die Rechte regelrecht verscherbelt wurde. Das, was die Entwickler von Roxor Games daraus gemacht haben, ist allerdings schlimm. Sie folgten dem Verlangen nach Action und Score und zerstörten das Wesentliche des Programms, nämlich die Atmosphäre und die Optik. Übergroße Bonbons, ein Karussel mitten in eisiger Naturlandschaft - Zeichen einer Verstümmelung.

Das Verschwinden von Tuxracer 1.1 hatte zur Folge, dass die freie Version 0.61 wieder an Aktualität gewann. Es entstand bald eine neue Initiative zur Weiterentwicklung, diesmal unter der Bezeichnung Planet Penguin Racer (ppracer). Die Entwicklergruppe hatte offensichtlich hoch gesteckte Ziele und ging das Projekt sehr offensiv an. Das Program wurde umstrukturiert und größtenteils von C nach C++ umgeschrieben. Ferner wurden einige Erweiterungen implementiert. Die Offensive erstreckte sich auch auf die Veröffentlichung; bereits im halbfertigen Stadium löste ppracer in einigen Linux-Distributionen das inzwischen schon verstaubte Tuxracer 0.61 ab.

Allerdings waren die Fortschritte von PPRacer eher oberflächlicher Art. Die eigentlichen Schwachstellen von Tuxracer 0.61 wie z.B. die starre Physik-Engine oder das miserable Kollisionsmodell wurden unverändert übernommen. Auch optisch gewann das Programm in keiner Weise, im Gegenteil, manches wirkte nun synthetisch, der natürliche Charakter ging teilweise verloren. Wenn man außerdem bedenkt, dass ppracer erhebliche Performance-Probleme hatte, kann man verstehen, dass sich mancher das "gute alte Tuxracer" zurückwünschte. - Wie dem auch sei, Ende 2006 kam das ppracer-Projekt zum Erliegen, und genau wie beim großen Vorbild verschwanden die Entwickler sang- und klanglos von der Bildfläche. Es schien das Ende von Tuxracer zu sein.

Im April oder Mai 2007 gab es dann doch ein neues Erwachen. Eine Gruppe von Computer-Fans schloß sich anlässlich eines Ubuntu-Treffens zu einem neuen Entwicklerteam zusammen. Man richtete eine Projektseite im Internet ein und gab der Initiative nach einiger Diskussion die Bezeichnung Extreme Tuxracer (ETR). Als Basis diente die letzte Version von ppracer.

Das mit dem Projekt verbundene Forum war anfänglich lebhaft besucht und machte deutlich, dass die Betroffenen mit großem Eifer an die Sache herangingen. Die Akteure sprühten förmlich vor Ideen, und es hagelte Verbesserungsvorschläge. Das Projekt ist noch aktiv, inzwischen aber wesentlich ruhiger geworden. Bemerkungswerte Fortschritte wurden bis jetzt (Oktober 2008) nicht erzielt, denn es fehlt etwas sehr wichtiges, nämlich Entwickler, die hinreichend kompetent sind und zudem noch das unerlässliche Durchhaltevermögen haben. Wie es weiter geht, ist zur Stunde ungewiss, ich befürchte aber, dass sich das Projekt in absehbarer Zeit totläuft. Originalton des Moderators von ETR: "That seems to be the curse of Tuxracer."

Meine Beziehung zu Tuxracer

Ich denke, bevor ich einen Blick hinter die Kulissen werfe, sollte ich kurz beschreiben, was mich persönlich mit Tuxracer verbindet. Ich gehöre nicht zu den typischen Computerspielern, im Gegenteil: Abgesehen vom Flugsimulator, mit dem ich mich eher unter physikalischen Aspekten befasse, ist Tuxracer für mich das erste und bisher einzige Computerspiel. Es war allerdings Liebe auf den ersten Blick. Als ich begriff, wie einfach die beeindruckenden Landschaften erzielt werden können, begann ich, mit dem Grafikprogramm Gimp eine Reihe von Rennkursen für Tuxracer 0.61 zu entwickeln und zu veröffentlichen.

Nach dem Erscheinen von Tuxracer 1.1 wurde ich gebeten, die Kurse zu konvertieren, so dass sie in der kommerziellen Version verwendet werden konnten. Das war aber nicht ohne weiteres möglich, denn Tucracer 1.1 wartete mit einem ganz anderen Konzept auf. Ich begann daraufhin, einen Kurseditor für die Version 1.1 zu schreiben, ein enormes Unterfangen. Ohne offenen Quelltext war ich auf Beobachtungen, Messungen und eine Unmenge von Experimenten angewiesen, um die internen, mathematischen Strukturen aufzuschlüsseln. Irgendwie gelang es aber, und bald konnte ich eine Reihe von Kursen für die kommerzielle Version vorweisen und veröffentlichen.

In diese Aktivitäten fiel plötzlich das Ende von Tuxracer 1.1. Die Wirkung kann man sich leicht vorstellen, nach mehreren Jahren intensiver Beschäftigung trat eine Flaute ein. Auch ppracer war nicht imstande, mich neu zu motivieren, denn ich merkte schnell, dass sich da nichts Wesentliches tat. Ich hoffte aber, dass ppracer irgendwann den Durchbruch schaffen würde.

Dann auch das Ende von ppracer. Als ich nach mehreren Wochen begriff, dass sich nichts mehr tat, stand ich vor einer Entscheidung. Entweder ich gab ganz auf, oder ich beschäftigte mich selber mit dem Programm. Ich entschied mich für das letztere und nahm mir erstmals den Code von Tuxracer 0.61 vor. Mit dem aufgeblähten Code von ppracer konnte ich mich Anfang an nicht anfreunden. Es war ein hartes Stück Arbeit, denn ich musste mich nicht nur in die Programmiersprache C einarbeiten, sondern darüber hinaus in OpenGL und die 3D-Programmierung. Dazu der eigenwillige Tuxracer-Code, der sich nicht gerade als "benutzerfreundlich" erwies. Wohin das alles steuern sollte, war mir unklar, jedenfalls gab ich meinem Vorhaben den Namen "Bunny Hill".

Die wesentliche Arbeit bestand im Aufräumen. Ich ersetzte manche aufgedunsenen Programmstrukturen durch einfachere und erreichte nach halben Jahr etwa den Stand, den auch ppracer erzielt hatte, nur mit einem wesentlich kompakteren C-Code. An den Programmkern mit den oben genannten Schwächen wagte ich mich ebenfalls nicht heran. Die Aktivitäten hielt ich allerdings ziemlich privat und dokumentierte nur einiges davon auf meiner Webseite.

Wie es nun weiter gehen sollte, wußte ich nicht. In diese Situation platzte der Hinweis eines Lesers auf das neu initiierte Extreme-Tuxracer-Projekt. Logischerweise meldete ich mich im Forum und las höchst interessiert die Beiträge. Ich merkte jedoch sehr schnell, dass der anfängliche Enthusiasmus den Charakter von Strohfeuern hatte. Vor allem vermisste ich ein klares, zielstrebiges Konzept. Es wurde, ähnlich wie bei ppracer, vor allem an der Oberfläche herumgebastelt, die Schwächen im Programmkern, die ppracer immerhin noch deutlich artikuliert hatte, wurden nicht einmal richtig wahrgenommen bzw. in ihrer Tragweite realistisch eingeschätzt. Ich warnte davor, in diesem Stil weiterzumachen, da es dadurch immer schwieriger würde, einen besseren Programmkern hinzubekommen. Die Resonanz war nicht sehr ermutigend.

Ursprünglich hatte ich beabsichtigt, mich in das ETR-Projekt einzubinden, doch das fiel nun offenbar flach. Hinzu kam allerdings, dass ich den ppracer-Code schlicht schrecklich fand - und finde. Jedenfalls entschloss ich mich, erst mal mit Bunny Hill weiterzumachen, und zwar von Grund auf. Ich kürzte das Progamm auf das absolut Notwendige und befasste mich mit den Kernfunktionen. Das ist die Arbeit, mit der ich zur Zeit immer noch befasst bin. Eine neue, offenere Physik-Engine arbeitet schon ordentlich, und auch das gewünschte Kollisionsmodell, das nun mit 3D-Objekten umgehen kann, ist weitgehend fertig. Den Entwicklern von ETR steht es frei, sich jederzeit an meinem Code zu bedienen, doch die Einbindung in den ppracer-Code kann und werde ich nicht leisten. - Soviel zu meiner persönlichen Situation in der Tuxracer-Geschichte.

Eine Prognose

Ich glaube, der Moderator vom ETR-Forum hat irgendwie recht, wenn er vom "Fluch des Tuxracer" spricht. Tatsächlich scheint das Programm mit dem Nimbus des Unlösbaren belastet zu sein. Zugegeben, das Programm ist alles andere als trivial und eine gehörige Herausforderung, was die freien Entwicklerteams wahrscheinlich nicht erkannt haben. Ein bisschen hier herumbasteln, ein bisschen dort einbauen, das war wohl die Erwartung, die zwangsläufig zu einem Scheitern führen muss. Ich denke, nach allen Erfahrungen und Beobachtungen kann ich diese pessimistische Aussage rechtfertigen.

Ein großer Fehler war es nach meiner Auffassung, dass ETR auf den ppracer-Code zurückgegriffen hat und nicht auf den Original-Tuxracer-Code. Letzterer ist zwar sperrig, lässt sich aber immerhin noch umorganisieren und öffnen, wie ich selber erfahren konnte. Der ppracer-Code dagegen ist so in in eine dicke Hülle von peripherem Code einzementiert, dass der Kern kaum noch erreichbar ist. "Cleaning up" war die erste, überaus angebrachte Devise von ETR, nur stellte sich wohl heraus, dass das praktisch unmöglich war.

Überhaupt, sollte das Ende von Tuxracer besiegelt sein, und einiges spricht dafür, dann würde ich aus heutiger Sicht ppracer als die eigentliche Ursache bezeichnen. Mit dem offensiven Eindringen in die Distributionen wurde Tuxracer 0.61 wohl endgültig in die Ecke gestellt, ohne etwas Besseres an die Stelle treten zu lassen. Stattdessen wurde der Weg zu wirklicher Verbesserung verbaut. Schade.

Dass irgendwann meine eigene Enticklung "Bunny Hill" zum Tragen kommen wird, ist zwar nicht gänzlich ausgeschlossen, aber dennoch unwahrscheinlich. Bei aller Liebe zum Programm, die ich den Leuten von ETR durchaus zugestehen will, kommt nämlich ein weiterer Aspekt hinzu, nämlich die persönlichen Empfindlichkeiten der Entwickler. Sie können Ansporn sein, aber auch blockieren. Spuren solcher Empfindlichkeiten sind überall zu finden, in den Beiträgen zu den Foren, im Auf- und Abschwellen von Aktiväten, ja sogar im Programmcode. Und natürlich in der Art und Weise, wie man das Ende eines Projektes gestaltet.

Im Code lesen - auch zwischen den Zeilen

Wenn man in den Quelltexten anderer Programmierer herumschnüffelt, dann kommt es zwangsläufig zu Fragen wie: Warum haben die Leute es so gemacht und nicht anders? Was haben sie sich denn dabei gedacht! Was sind das für Menschen, die sich solche raffinierten Funktionen einfallen lassen?

Tatsächlich verrät der Code einiges über den Werdegang des Programms, aber auch über die Programmierer. Im Falle von Tuxracer bin ich mir nun fast sicher, dass am Anfang gar nicht das Programm selbst im Fokus stand, sondern dass sie sich in einem Lernprozess befanden und nach einer geeigneten Anwendung suchten, um das Gelernte in die Praxis umzusetzen. Es gibt kaum etwas, was sie nicht in das Programm eingebaut haben, und vieles davon wäre zweifellos nicht nötig gewesen oder stellt für das Programm sogar einen Ballast dar. Ein weiteres Indiz für diese Annahme ist die Häufung von bestimmten Programmierelementen, die sich eindeutig verschiedenen Entwicklungsstufen zuordnen lassen.

Da gab es, wahrscheinlich ganz zu Beginn, die "Kommentierungs-Periode". Jede Funktion, selbst Einzeiler, wurde mit einem 5-8-zeiligen Kommentar belegt (Urheber, Datum usw.). Das ist typisch für Anfänger, die jeden Schritt, und sei er noch so klein, als Wertschöpfung betrachten. So etwas gibt man aber schnell auf, es sei denn, man arbeitet in einem sehr großen Team an einem Großprojekt.

Da gab es die "Makro-Periode". Alle denkbaren Makroformen wurden implementiert, manche so verschachtelt aufgebaut, dass sie nur noch mit Mühe zu entschlüsseln waren. Ja, in einem Programmmodul ging es sogar so weit, dass Makros dynamisch per Code erzeugt wurden. Thema: Was man alles mit Makros machen kann!

Da gab es die "Min-Max-Periode", wo jede denkbare Begrenzung fast liebevoll mit Min-Max-Makros vorgenommen wurde, mitunter mehrfach verschachtelt. Einfache Größer-Kleiner-Abfragen, die deutlich leichter zu lesen und zu warten sind, kamen wohl nicht in Frage.

Da gab es eine kurze "char*-Periode". Funktionen, die normalerweise die erfolgreiche Durchführung mit einem boolschen Wert zurückmelden, leferten stattdessen durchgängig einen String zurück, der direkt zur Anzeige gelangen konnte, aber andererseits umständlicher auszuwerten war. Motto: So muss es doch auch gehen! Natürlich ging es auch so.

Das sind nur einige auffällige Beispiele. Sie sollen aber in keiner Weise eine Kritik an dem Programm sein, im Gegenteil. Im Gunde wird hier nur deutlich, wie begeistert und lernwillig die Programmierer ihre Sache angingen. Das äußert sich auch in einigen Algorithmen, an denen sich womöglich die "Nachentwickler" die Zähne ausgebissen haben: Ode-Solver, Terrain-Rendering mit Quadtree und einem ausgeklügelten Blending-Verfahren, Drehungen mit Quaternionen, Physik-Engine, die jedes Detail berücksichtigt (z.B. Luftviskosität und Reynoldsche Zahl im Zusammenhang mit dem Luftwiderstand) usw. Selbst die Hauptfigur, nämlich der animierte Tux, wurde nicht mit einem Modellierprogramm, sondern per Tcl (!) aus verschiedenen Ellipsoiden zusammengebastelt. Alles in allem eine stramme Leistung. Kann man den Entwicklern ankreiden, dass ihre Nachfolger ihre liebe Mühe damit hatten und gescheitert sind?

Nachtrag: Aktueller Stand (2015)

Das Programm Tuxracer (und entsprechende Seitenlinien) gibt es praktisch nicht mehr, nur noch tote Relikte aus vergangenen Jahren. Ein Programm muss in irgendeiner Form gepflegt werden, und wenn das nicht mehr geschieht, kann man nicht mehr von einem Programm sprechen. Im Debian-Repository befindet sich noch die Version 0.4 von Extreme Tux Racer, aber die liegt um einiges hinter dem letzten Stand von ETR zurück, und außerdem stecken gerade in dieser Version einige grobe Fehler. So stellen einige Kurse Felsgestein als Eis dar. Auch die Beleuchtung ist krass fehlerhaft. Immerhin können z.B. Ubuntu-Benutzer das Spiel noch mit Bordmitteln installieren. Meistens werden sie wohl enttäuscht sein, denn inzwischen wimmelt es in Linux-Repositories nur so von (teils wirklich guten) Spielen.

Tuxracer ist also nur noch etwas für eingefleischte Liebhaber, was für mich Grund genug ist, wenigstens die verfügbaren Ressourcen noch vorzuhalten. Genau das ist das Ziel dieser Internetseite.

Ein Interview mit Jasmin Patry

Dieses Interview wurde von dem Autor der Webseite tuxracer.fubaby.com geführt und veröffentlicht. Ich denke, der (nicht mehr erreichbare Autor) wird nichts dagegen haben, wenn ich es hier wiedergebe, zumal die genannte Seite nicht mehr aktiv ist und demnächst geschlossen werden soll. Auf jeden Fall ist das Interview sehr aufschlussreich. Wann genau es stattfand, kann ich nicht feststellen.

1. How did you get into the gaming industry?

I got into the gaming industry by forming Sunspire Studios with several friends from school. All of the current and past team members met at the Computer Graphics Lab (CGL) at the University of Waterloo in Ontario Canada, where we were Master's students. Some of us (like myself) were pursuing CS degrees, while others were pursuing MFA degrees (Master's of Fine Arts). So this environment was the perfect place for gathering the required skills necessary to start a game company. The original idea for starting a company came from Rick Knowles and Mark Riddell; they approached several people in the lab, including myself, in December 1999 with their ideas for a new game.

2. What other games were you involved in?

All of my other game development work has been on various "pet projects" that were never released publicly. As a game developer, Tux Racer is my first professional project.

3. Do you think that Linux can become a good gaming platform?

Wow, that's a loaded question. You're assuming that it isn't already a good gaming platform! I think that Linux is a great gaming platform -- it's stable, fast, free, has good development tools and support libraries, and has good drivers (faster than Windows in some cases) for several major lines of graphics cards. So (for example) in a game-console type of environment, Linux would be a great platform.

What's holding Linux back (in the desktop gaming arena, at least) is that setting all this up can be very tricky for the novice (and even the expert at times ). However, as progress is made to bring Linux to more desktops, this situation will only get better, and that should help to increase the popularity of Linux as a desktop gaming platform.

4. What started Tux Racer?

Tux Racer originated as a final project for a computer graphics graduate course that I took at the University of Waterloo in the summer of 1999. People really seemed to enjoy the game (even though it was still very primitive), and so I decided to keep working on it and released it to the public in early 2000.

Sunspire decided to adopt Tux Racer as its first project in August 2000, and serious development on the game began shortly thereafter.

5. What do you like most of the game?

I'm a graphics guy, and so I have to say that I really like how the game looks. This is largely due to the great textures and models that Mark and Rick created, but I also think that we did a pretty good job on the engine as well.

Even after spending so long with the game, I'm still often impressed with the visuals in the game.

6. What was the hardest to accomplish?

While there were some very challenging technical hurdles, I think the toughest thing about making a game (especially when you're a self-funded startup like we are) is finding the perseverance and determination to keep moving forward and finish the project. Luckily, our team fed very well off each other -- if one person was having a down period, others would be working on cool features and that kept the team motivated. The few "death march" periods we went though as we struggled to meet deadlines were also pretty tough, but we survived.

7. Have the sales generated enough gross income to break even yet?

Sorry, it's our policy not to discuss sales or revenue figures publicly.

8. What sort of game are you planning to make next? Any ideas yet, is a project ready, or are you still just working on getting Tux Racer refined?

We're still in the brainstorming and planning stage for the next project. We're also still very busy with Tux Racer -- providing support, working on the marketing and distribution aspects, preparing for the release of the level editor, etc.

9. Does it look like Tux will be in retail any time soon?

We're hoping to have Tux Racer in retail stores this Spring, but we're still in negotiations at this point.

10. Should Tux go on a diet?

No way!

Actually, he has lost some weight from all the racing he's done since the 0.61 release... who knew eating all those herring was also a great workout?

11. If Tux does well in sales, will there be a console port?

That is certainly something we're looking at, but we have no definite plans yet.

12. If a console port is possible, which system would get the port? PS2, Gamecube, XBox?

We haven't made a decision in this area. It will likely depend on various practical considerations (given that our resources are quite limited), in addition to the technical issues. The Gamecube would be a fairly logical choice though, since Tux Racer is a title that appeals to the family audience, and this is a market that Nintendo targets very well.

That said, an XBox port would be interesting simply from the amount of press it would generate. :)

Anmerkung: Ich möchte einen Satz von J. Patry wiederholen: "Even after spending so long with the game, I'm still often impressed with the visuals in the game." - Mit geht es genau so.