The Black Lotus (TBL) – ein Name, der die Amiga-Demoszene seit Jahren in Entzückung versetzt, jedoch andere noch aktive Amiga-Gruppen in pure Verzweiflung treibt. Die Schweden um die Kernmannschaft Kalms, Louie und Rubberduck halten noch immer dem mittlerweile doch arg veralteten Amiga-System die Treue und vollziehen darauf jedes Jahr aufs Neue technische Höchstleistungen. Und das, obwohl sie hauptberuflich moderne PCs und Konsolen mit Spielestoff bei Digital Illusions versorgen. RalliSport Challenge 2 oder Battlefield 2 sind nur einige der Titel, an denen die drei von der Demo-Tankstelle mitgewirkt haben.


Wie in jedem Jahr zur Osterzeit, so hat auch 2005 ihre aktuelle Amiga-Demo „Ocean Machine" den ersten Platz in der Amiga-Demo-Compo auf der Breakpoint 2005 ergattert. Völlig zu Recht, denn kaum eine andere Gruppe außer TBL versteht es, Szenen so kunst- und stilvoll zu arrangieren, veraltete AGA-Grafikchips und 68060 Motorola-CPUs an die Grenzen ihrer Leistungsfähigkeit zu treiben und dazu mit einem brillanten Soundtrack zu unterlegen. Lars „Ghandy" Sobiraj unterhielt sich mit Kalms, dem Hauptprogrammierer dieser Demo über den Entstehungsprozess von „Ocean Machine".

--=The Making of Ocean Machine=--

Irgendwie ist es bereits Tradition, ob man diese Tatsache jetzt mag oder nicht. Jedes Jahr zur Osterzeit trifft sich die Elite der europäischen Demoszene in Bingen am Rhein, während der Rest der Welt nach großen, bunten Schokoladeneiern sucht – und jedes Jahr gewinnen die Jungs von The Black Lotus an diesem Wochenende den Amiga-Demo-Wettbewerb von Deutschlands größter Demo-Party. Genau so spielt es sich ab und nicht anders. Wir haben gemeinsam mit TBLs Programmiermaschine Kalms einen Blick hinter die Kulissen geworfen und berichten von der Entstehungsgeschichte dieser großartigen Demo.



Ghandy: Kannst du mir bitte erzählen, in welcher Form euch dieses Project-Management-Tool, von dem ihr einen Screenshot im originalen Amiga-Archiv beigefügt habt, beim Entstehungsprozess der Demo geholfen hat? Zerstört ein solches Planungsprogramm nicht die Spontaneität des Demo-Makings und raubt dabei auch ein bisschen den Spaß daran? Man könnte fast meinen, dass dies eine Art professioneller Job anstelle eines Hobbys für euch geworden ist.

Kalms: Um zu verstehen, warum wir ein solches Tool benutzt haben, muss man etwas mehr über die Unterschiede zwischen einem Demo-Projekt und einem professionellen Software-Projekt wissen.

1) Wenn jemand an einer Demo arbeitet, dann tut er dies normalerweise in seiner Freizeit. Demzufolge hat man weniger als 40 Stunden pro Woche, die man dafür investieren kann. Noch dazu arbeitet man meist in Schüben (in der einen Woche hat man beispielsweise drei Abende Zeit um an der Demo zu arbeiten, in der nächsten leider überhaupt keinen).

2) An einer Demo arbeitet man freiwillig. Es ist unmöglich, einen Zeitplan zu "erzwingen", wenn jemand gerade keine Lust verspürt.

3) Was letztendlich im finalen Produkt enthalten ist, wird von den Leuten bestimmt, welche die Demo kreieren und nicht von irgendeinem externen Auftraggeber.

Wenn man sich diese Tatsachen vor Augen hält, sollte man diesen Plan als eine Art glorifizierte „Todo"-Liste ansehen. Wenn man also der Meinung ist, dass ein bestimmter Effekt in der Demo gezeigt werden sollte, kann man ihn dem Projektplan hinzufügen, inklusiver spezieller Vermerke für das Grafikdesign und den Programmieraufwand. Auch sollte man eintragen, wie viel Zeit die Fertigstellung dieses Effekts ungefähr dauern sollte.

Mit einem gut durchstrukturierten Plan kann man jederzeit sehen, ob eine Person alarmierend viel für die Demo zu erledigen hat. Sollte dies der Fall sein, kann man eventuell eine der aufwändigeren Szenen streichen und durch ein andere ersetzen, die etwas weniger Arbeitsaufwand bedeutet.

Es ist wichtig, dass man den Plan jederzeit aktualisiert. Dieser Plan zeigt genau auf, welche Dinge noch in der Demo fehlen. Er sollte jederzeit an die Idee, wie die fertige Demo aussehen soll, angepasst werden.

Auf diese Art und Weise arbeiten wir schon seit einigen Jahren zusammen. Zuerst bestimmen wir, welche Dinge möglichst frühzeitig fertig sein sollten, beurteilen wie hoch das Risiko für die rechtzeitige Fertigstellung bestimmter Szenen ist und überlegen uns für solche Risiko-Parts auch einen eventuellen Notfallplan – üblicherweise jedoch nur mündlich.

Durch die Nutzung eines Projektüberwachungsprogramms lassen sich nicht nur diverse Aufgaben überwachen, man kann jederzeit erkennen, wie viel Zeit ein bestimmter Teil der Demo noch benötigt. Wenn die Freizeit knapp bemessen ist, ist diese Art der Zeitüberwachung sehr nützlich.

Ich bin leider etwas nachlässig. Meist schiebe ich Sachen bis zur allerletzten Minute hinaus. Aufgrund unseres Plans habe ich mit einigen der umfangreicheren Programmierarbeiten bereits frühzeitig angefangen. Ohne diesen Plan hätte ich mir bestimmt gedacht, das ich das morgen auch noch angehen kann, denn immerhin sind es noch einige Wochen bis zum Abgabetermin, nur um es dann noch weiter zu verschieben. Dank dieser Übersicht war es jedoch unübersehbar, dass etwa die Voxel-Engine zumindest innerhalb einer Woche in einen funktionierenden Zustand gebracht werden musste, oder es würden keine Voxels auf der Breakpoint gezeigt werden können. Glücklicherweise verfügen Louie und Rubberduck über etwas mehr Selbstdisziplin als ich. Sie würden auch ohne einen solchen Plan zu Recht kommen. Die goldene Regel für einen Projektplan ist: du kontrollierst den Plan – nicht er dich.



Ghandy: Die meisten von euch arbeiten gemeinsam in derselben Firma. Wer denn genau und was genau macht ihr dort? Hat diese berufliche Zusammenarbeit irgendeinen Einfluss auf die jährliche Demo für die Breakpoint?

Kalms: Rubberduck arbeitet als Producer für DICE, während Louie die Position eines Art Directors in derselben Firma bekleidet. Auch ich habe dort gearbeitet, bin jedoch vor ein paar Monaten ins Studentenleben zurückgekehrt. Tudor hingegen ist bei SimBin beschäftigt, während Yolk unten in Spanien weilt (vermutlich um seiner Freundin zu entgehen).

Oft ist es ziemlich stressig in der Spieleindustrie zu arbeiten. Ich verstehe nicht wie es Louie anstellt, ständig neue Grafiken in seiner Freizeit zu erstellen. Für mich ist es wirklich schwierig die Balance zwischen Beruf und Freizeit zu finden – entweder arbeite ich mit 120% Einsatz oder überhaupt nicht. Unter solchen Umständen ist es wirklich schwierig eine qualitativ gute Demo zu machen. Sofern sich jemand gewundert hat, warum nur wenige neu geschriebene Effekte in Little Nell oder Magia eingebaut wurden, dann ist das die Antwort dafür. Dies ist jedoch eine andere Geschichte.

Nehmen wir einmal die Voxel-Engine (so hässlich sie auch sein mag). Diese Engine hätte ich niemals schreiben können, wenn ich nach wie vor für DICE arbeiten würde. Als Student hat man jedoch so seine Vorteile – mehr Freizeit zum Beispiel.

Wenn man hingegen in derselben Firma arbeitet ist es ein Vorteil, die anderen Jungs tagtäglich zu treffen. Man kann die Ideen der Anderen sofort diskutieren. Momentan ist das zwar nicht mehr der Fall, aber wir telefonieren regelmäßig und plaudern ein bisschen über ICQ. Außerdem ist es nicht weit von Linkoping nach Stockholm – höchstens zwei Stunden, womit die Entfernung nicht wirklich ein Problem ist.

Ghandy: Wie seid ihr auf die Idee gekommen, bei der Musik dieses Mal mit Yolk von CNCD zusammenzuarbeiten?

Kalms: Louie hat diesen Tune vorgeschlagen, aber eigentlich hatten wir schon länger vor eine Demo mit diesem Soundtrack zu machen. Ich habe die Möglichkeit begrüßt einmal eine Demo zu schreiben, die nicht diesen typischen Industrial-Sound verwendet. Rubberduck war zwar von diesem Konzept nicht allzu begeistert, doch letztendlich konnten wir ihn auf unsere Seite ziehen.

Ghandy: Angeblich handelt es sich bei der Hintergrundsängerin um Yolks Schwester, während Yugi/Komplex am Piano spielt. Stimmt das tatsächlich?

Kalms: Ja.



Ghandy: Gegen Ende des Soundtracks hört man einige seltsame Geräusche. Zuerst dachte ich an einen Fehler im Programmcode, aber die originale MP3-Datei von Yolk weist exakt dieselben Geräusche auf. Wollte er wirklich die letzten Sekunden des Stücks so fremdartig klingen lassen?

Kalms: Ja, diese Sound-Bugs waren Absicht; das Stück wurde nicht speziell für die Demo geschrieben.

Ghandy: Welche in Ocean Machine gezeigte Effekte waren eigentlich vorberechnete Animationen? Die tanzende Frau soll es angeblich nicht gewesen sein.

Kalms: Was bitte ist eine Animation? Für mich ist das nichts anderes als eine Folge von aneinander gereihten Bildern, die auf irgendeine Art komprimiert sind. Oder eine Serie von 2D-Polygonen (wie in State of the Art). Vielleicht auch etwas Ähnliches. Die Tatsache ist, dass jede Menge Programmcode hinter jeder einzelnen Szene der Demo steckt. Nichts am Code ähnelt einem üblichen „Animation Player / Decompressor".

Die Charakteranimation der Frau wurde mithilfe von LightWave 7 sowie einigen Extra-Plug-ins erstellt. Dann wurde die Animation als individuelles Keyframe (so genannte Schlüsselbilder) mit einer Auflösung von 12.5 Keyframes pro Sekunde gespeichert (jedes Keyframe enthält die exakte Position aller Endpunkte des Objekts zum augenblicklichen Zeitpunkt).

Während die Szene läuft, mixt die Demo zwei passende Keyframes zusammen, um die Bewegung der Frau zum richtigen Zeitpunkt zu bekommen und sendet diese Informationen dann zusammen mit dem Hintergrundpanorama an die 3D-Engine, die dies auf dem Bildschirm wiedergibt.

Ghandy: Über die Voxel-Szenen wurde in der Szene bereits viel diskutiert – wie kamt ihr auf diesen Visualiserungsstil?

Kalms: Rubberduck war schon immer ein Voxel-Engine-Fetischist. Vielleicht kann sich noch jemand an das Ende von Mindprobe (1995), an diese Baumszene, erinnern? Einige Leute sagten damals, dass diese Szene hässlich aussieht. Ich hingegen behaupte, dass sie der Phantasie genügend Freiraum ließ.

Wie dem auch sei, er kam jedenfalls mit einem Render-Algorithmus an, der auf dem Amiga in ungefähr zwei Monaten umsetzbar sei. Also machten wir uns an die Arbeit. Es kostete uns wirklich extrem viel Zeit diesen Algorithmus in vernünftiger Geschwindigkeit ablaufen zu lassen – 12 Stunden bevor der Demo-Wettbewerb auf der Breakpoint startete, war es uns überhaupt erst gelungen die Voxel-Engine in akzeptabler Framerate darzustellen. Den Stress war es jedoch wert, wie ich finde.



Ghandy: Die ebenfalls aus Schweden stammenden Three Little Elks waren über Jahre hinweg euere Herausforderer in der Amiga-Szene. Weißt du, was die Jungs heutzutage machen?

Kalms: Explorer/3LE arbeitet ebenfalls als Programmierer bei DICE; ich weiß allerdings nicht, was aus den anderen Mitgliedern dieser Gruppe geworden ist.

Ghandy: Was stehst du zur Aussage des C64/PC Musikers und Programmierer KB/Farbrausch, die dieser als Kommentar auf Pouet.net hinterlassen hat: „Seit Jahren zeigen uns TBL Demos wie dieses. Natürlich gibt es ein paar Verbesserungen wie die Tänzerin mit gefälschter Bandphysik, dies kann aber nicht die Tatsache verschleiern, dass sie immer noch dasselbe Farbschema verwenden, die gleichen Landschaften, das selbe Design und das gleiche weibliche Modell mit geringer Polygonanzahl. (...)"

Kalms: Wir machen Demos die wir auch selbst gerne anschauen. Wenn einige Leute sagen, dass sich unsere Demos ähneln, dann würden wir sagen, dass sie irgendwie zusammen gehören. Wenn wir jedoch der Meinung sind es wäre Zeit unseren Stil zu ändern, machen wir das natürlich auch.

Ghandy: Kalms, ich danke dir für die Beantwortung meiner Fragen. Wir sehen uns auf der Breakpoint 2006!!!

(18.11.2005, Bobic - Übersetzung)