HackAddict

Nun da wir endlich ein Blog für das TankYou-Projekt haben, denke ich wir sollte mit einem kleinen Rückblick auf die Geschichte des Projektes beginnen. Auch wenn es unglaublich scheint und ziemlich peinlich ist, reichen die Wurzeln von Tank You zurück in das Jahr 1995. Das Projekt (bzw. sein Vorgänger) startete unter dem Namen "Martes Zibellinae" (Latein für Zobel). Geplant war einen simplen Worms-Clone mit kleinen Zobeln anstatt Würmern zu bauen. Wir liebten Worms sehr, doch fanden dass es mit der Qualität der Serie mit jeder Fortsetzung weiter Berg ab ging. Weil wir damals noch zur Schule gingen, hatten wir eine Menge Freizeit, aber wir begannen mit wenig Erfahrung in Spieleentwicklung und nur mit mittelmässiger Programmiererfahrung.

Der erste Versuch wurde in C++ entwickelt und nutzte reine Direct X. We kamen überraschend weit und hat eine Art Demo mit Explosionen, zerstörbarem Land, minen und so genannenten "Quietscheentchen", aber ohne spielbare Zobels. "Quietscheentchen" sollten eine spezielle Minenart werden, die explodiert sobald ein Zobel sie wieder verlässt, nachdem er auf sie drauf getretten war. Wegen unsere fehlenden Erfahrung war die Codequalität grauenvoll und das ganze Projekt war kaum Wart- oder Erweiterbar. Da war ein Bug in der Zündungslogik der "Quietscheentchen" und egal wie sehr wir es versuchten, wir konnten ihn nicht beheben. Letztendlih haben wir dann den ersten Versuch für tot erklärt und uns entschieden nochmal komplett von vorne zu beginnen. Ich würde euch gerne diese alte Demo mit ihrer Pixelgrafik zeigen, aber unglücklicherweise ist sie während eine Plattencrashs verloren gegangen (wir hatten auch wenig Erfahrung in Datensicherung und Versionskontrolle ;) )

Im zweiten Versuch wollten wir ein Fundament schaffen, auf dem wir das Spiel aufbauen konnten, also versuchten wir eine kleine Spriteengine als abstraktion von Direct X zu schaffen. Das Ding hiess HASE ein backronym für (HackAddict Sprite Engine). Es konnte Animationen und hatte einen coolen Algorithmus für die automatische Aufteilung der Spritegrafiken auf die einzelnen Offscreensurfaces. Ich weiss nicht mehr genau warum der zweite Versuch schief lief, aber er tat es. Ich denke es war, als wir die Schule verliessen und der Wehrpflicht sei dank zur Bundeswehr mussten. Wir hatten kaum noch Freizeit und die die wir hatten verbrachten wir damit den Sold zu versaufen.

Im dritten Versuch wechselten wir von Direct X zu SDL zunächst nur um das Spiel plattformunabhängig zu entwickeln, aber in Endeffekt hat es sich als Verbesserung in fast allen Bereichen herrausgestellt. SDL ist eine super Engine, aber dass hielt die Entwicklung nicht davon ab wieder einzuschlafen.

In der Zwischenzeit hatten wir begonnen auch hauptberuflich als Softwareentwickler zu arbeiten und auf der Arbeit entwickelten wir Applikationen in Java. Auch wenn Java nicht den besten Ruf für Spieleentwicklung hat, entschlossen wir uns es einfach mal auszuprobieren. Wir schauten uns damals auch Slick an, entschieden uns dann aber auf 3D umzuschwenken und die jMonkeyEngine einzusetzen. Es klappte ziemlich gut, aber wir hatten viel Ärger mit der Landgenerierung und wieder einmal zu wenig Erfahrung, diesmal in der 3D-Entwicklung.

Nach dem Ausflug in die Java-Welt gingen wir zurück auf C++ und SDL. Wir bauten eine Engine auf die ich immer noch recht stolz bin. Sie konnte mit erweiterbaren und in XML-beschriebenen Ressourcen umgehen und war sehr flexibel und performant. Dieser Versuch starb, als wir merkten, dass wir hardware-beschleunigte Rotation brauchen könnten. SDL unterstüzt nur sehr langsame software Ration und die OpenGL einbindung erforderte sehr viel OpenGL erfahren, welche wir nicht hatten.

Nach diesem Fehlschlag entschieden wir uns dann das Spielkonzept radikal zu verändern und Panzer statt Zobel zu verwenden, hin zum jetzigen Design. Aller guten Dinge sind Sechs. We ihr sehen könnt sind wir wieder auf Java unterwegs, mit Slick und echtzeit Physics in (j)box2d. Wir sind alt und erfahren genung und wissen was wir tun, dass einige Problem ist immernoch unser Mangel an Freizeit, die wir in das Projekt investieren können.

Jetzt sind wir sehr heiss darauf endlich ein Projekt abzuschliessen.

Wie einige von euch bereits wissen, war Tank You urspünglich ein komplett anderes Projekt, das mehr oder weniger ein Klon von Worms war. Es gibt natürlich immer noch einige Gemeinsamkeiten, aber vor allem seit wir uns entschieden haben, Panzer als Hauptakteure zu verwenden, hat sich einiges verändert, was Tank You einzigartiger macht (zumindest in unseren Augen).

Als unser Tank-You-Voränger startete, sollte das Land sich, wie das meiste andere auch, wie in Worms verhalten. Das bedeutet, dass bei einer Explosion ein kreisrunder Schnitt ins Land gemacht wurde und ein Loch entstand. Wie es im Original gemacht wurde, wussten wir nicht genau, aber wir reimten uns zusammen, dass das Level am besten als Grafik hinterlegt wird, bei der eine bestimmte Farbe den Himmel - also den leeren Platz - markiert. Sieht man sich die Amiga-Version von Worms 1 an, so stellt man auch fest, dass genau dieses Format für Benutzerdefinierte Levels verwendet wird.

Ungefähr ein Jahrzehnt lang verfolgten wir diese Taktik. Wir mussten dabei die Riesengrafik immer in kleinere Stücke aufteilen - zuerst, weil die Grafikkarten damals keine Bilder größer als die eingestellte Bildschirmgröße erlaubten, später aus Performancegründen. Und schlussendlich, nach dem Umstieg auf Slick, mussten wir die maximale Texturgröße bei OpenGL berücksichtigen und stiegen von der Farbmarkierung auf Alphawerte um.

Ich würde sagen, dass diese Struktur nicht nur eine der feststehendsten in unserem Projekt war, sondern dass sie auch maßgeblich das Spielgefühl ausmachte und das Aussehen des Spieles bestimmte. Jedenfalls war es so, bis wir beschlossen, eine Physikengine zu verwenden.

Eine Physikengine nimmt uns eine Menge Last ab: Wie Projektile sich bewegen, wann und wo sie aufschlagen, wann ein Fahrzeug zum stehen kommt wenn es den Boden berührt und welchen Winkel es dabei hat - all dies hätten wir per Hand und alles andere als optimal programmieren müssen. Die Verwendung einer Engine bringt aber auch Einschränkungen mit sich: Alle Objekte, die etwas bewirken sollen, müssen im Format angegeben werden, die die Engine versteht. Und alle Engines, die wir ausprobierten, wollten Polygone, mit einem Bild können sie natürlich nichts anfangen.

Ein Bild in die Form von Polygonen zu bringen wäre wenig sinnvoll gewesen. Entweder wäre es ungenau oder wahnsinnig viel Speicheraufwand. Die Idee mit dem Bild als Level war somit gestorben. Stattdessen legen wir nun das Land in Form von kleinen Landstückchen als Polygone an. Das hat zur Folge, dass man nicht einfach so einen Kreis aus dem Land rausschneiden kann.

Unzerstörbares Land war uns allerdings auch zu langweilig. Wir haben deshalb die Landstücke mit Hitpoints versehen. Sie werden normalerweise nicht sofort zerstört, aber wenn man sie mehrfach trifft, oder einmal besonders hart, so verschwinden sie. Das ist grafisch natürlich nicht vergleichbar mit einem kreisrunden Loch und wir empfanden diese Lösung eher als Kompromiss.

Ein kleiner Zusatz aber verwandelte den Kompromiss in eine geniale Neuerung: Landstücke können locker werden und herumfliegen. Wenn die Hitpoints unter einen bestimmten Punkt sinken, so löst sich nun das Landstück. Das bringt eine ganz neue Dynamik in das Spiel.

Landstücke fallen nun runter, versperren einem den Weg, helfen einem aber vielleicht auch kleine Abgründe zu überwinden. Möglicherweise verursachen sie eines Tages Schaden, wenn sie aus großer Höhe auf einen Panzer fallen. Bis dahin kann man sie aber nur versuchen wegzuschieben oder einfach wegzuballern!

Wir haben endlich die Motivation gefunden unsere Seite zu relaunchen.