Abyss: Making of Tiny Bobble, Tiny Galaga, TinyInvaders, Tinyus

Drei Entwickler starteten bei Abyss in der Demoszene. Sie veröffentlichen uralte Arcade Games per Reverse Engineering auf dem Amiga.

Bartman, Pink und FadeOne von Abyss stellen sich immer wieder die Frage: Wieso gibt es das nicht auf dem Amiga? Oder auch: Warum konnte man das eigentlich nicht besser umsetzen? Statt weiter zu meckern, haben sie letztes Jahr angefangen, den Quellcode mehrerer Spiele von verschiedenen Arcade-Maschinen auseinanderzunehmen, um sie auf dem Amiga zu präsentieren.

Abyss: Wenn Demoszener ihre Liebe für alte Arcade-Maschinen entdecken

Nicht nur, dass man per Reverse Engineering den Code retten musste. Nein, sie entnahmen der Hardware aus den 80er-Jahren auch die Grafiken, Sprites und vieles mehr. Das Problem war aber, dass sowohl die Chips für die Sound- als auch für die Grafikerstellung auf den Arcade-Maschinen dem des Amiaga überlegen sind.

Von daher musste man sich einiges für die Umsetzung einfallen lassen. Bartman von Abyss aka Bernhard Wodok, erklärt, wie es ursprünglich zu den selbst gemachten Ports gekommen ist.

Abyss hat darüber hinaus im April 2019 den Musikeditor Pretracker veröffentlicht. Und für alle Programmierer einen komfortablen C-Compiler auf Windows-Basis. Auf diesem kann man den Code direkt auf dem Emulator WinUAE ausführen. Ihr Demotool mit dem kryptischen Namen vscode-amiga-debug hat schon mehrere Updates erhalten. Bernhard (Bartman) führte die aktuelle Version des Tools zuletzt im Herbst in seinem Seminar auf der Berliner Party Deadline vor.

Entwicklerstudio Shin’en im Jahr 1999 gegründet

Ihre plattformübergreifende Spieleschmiede Shin’en mit Sitz in München gründeten sie im Jahr 1999. Es folgten zahlreiche Spiele auf dem Gameboy Advance, Nintendo DS, Nintendo Switch und Wii U. Später kamen Games auf der Xbox One, Windows, PS4 und PS5 hinzu. Ihr neuester Titel ist das Action-Adventure-Puzzle „The Touryst“, was so aussieht, als hätte man sich ein Stück weit von der Klötzchengrafik von Minecraft inspirieren lassen. Davon abgesehen haben die beiden Spiele aber höchst wenig gemeinsam.

Lars Sobiraj: Für den Anfang wäre es gut, ihr würdet euch einmal mit ein paar Daten kurz vorstellen.

Abyss: Hi! Wir sind Bartman (Bernhard), Pink (Manfred) und FadeOne (Martin). Vom Alter her sind wir in den 40ern und machen seit Anfang der 1990er-Jahre Demos für den Amiga. Dann haben wir 1999 das Game-Development-Studio Shin’en gegründet. Seit dem haben wir unsere Szene-Produktionen sehr zurückgefahren, da wir ja schon hauptberuflich Spiele machen.

Wir haben seitdem aber die Szene weiter aktiv beobachtet. Irgendwann haben wir bemerkt, dass viele sehr gute Produktionen für alle möglichen Plattformen rauskommen, aber nicht für OCS-Amiga (Amiga 500, 600, 2000). Pink meinte dann, einige dieser guten Effekte könnte man eigentlich auch auf einem Amiga machen. Wir haben uns gewundert, warum das noch keiner gemacht hat.

Da hat ihn dann die Lust gepackt, selbst wieder ein Intro zu coden. In Assembler zu coden kam aber nicht in Frage. Da kamen Erinnerungen an die 90er-Jahre hoch, wo man wochenlang an einem einzigen Effekt saß, und den optimiert hat.

Tarnkappe.info: Oder hängt das mit eurer gemeinsamen Arbeit bei eurer Firma zusammen? Also dass das Thema Gaming in den Vordergrund gerückt wurde? Tiny Bobble, Tiny Galaga, Tiny Invaders, Tinyus – sind die alle nach dem gleichen Strickmuster entstanden?

C-Compiler selbst optimiert

Abyss: Pink hat dann einen C-Compiler gefunden (vbcc), mit dem er am PC Amiga-Programme kompilieren kann. Als ich mir dann aber den Code angeschaut hab, den dieser Compiler erzeugte, dachte ich mir, da muss es doch was Besseres geben. Ich hab dann Bebbo’s gcc 6.2 gefunden, der doppelt so schnellen Code erzeugt. Ich bin auch bei uns in der Firma für Tools zuständig, also habe ich Pink eine Entwicklungsumgebung mit diesem Compiler eingerichtet.

Damals gab es bereits neuere Versionen von gcc, die jedoch keinen Amiga-Code erzeugen konnten. Also habe ich mir das mal genauer angeschaut, und Teile von Bebbo’s Änderungen auf die neuen Versionen übertragen. Das hat dann nochmal 20-30% schnelleren Code gebracht. Jetzt waren wir also auf einer aktuellen Compiler-Version. Da gab’s erstmal keine Verbesserungen mehr.

Allerdings war der ganze Entwicklungszyklus noch nicht optimal. Compilen, dann WinUAE starten, dann per Hand das Intro starten. Also hab ich eine Extension für Visual Studio Code geschrieben, die das alles vereinfacht. Also nur noch F5 zum Compilen drücken, danach startet automatisch WinUAE und dann das Intro.

Dann kam natürlich noch der Wunsch auf, zu debuggen, also Breakpoints zu setzen, Variablen zu watchen, Debug-Text auszugeben. Das habe ich dann auch noch eingebaut.

Später kamen dann noch ein Profiler und Grafik-Debugger dazu. Das sind alles Features, die man vom Entwickeln auf modernen Plattformen kennt, aber für den Amiga eher unüblich waren. Für manche Features musste ich auch in den Code von WinUAE eingreifen, aber das hat uns viele Vorteile gebracht.

Hierauf lief übrigens Tinyus, also der Arcade-Maschine Gradius. Und darauf lief ursprünglich Bubble Bobble in der Taito Arcade.

Abyss: Wir wollten etwas Cooles machen!

Lars Sobiraj: Wieso seid ihr überhaupt von Demos und Intros auf Games gewechselt? Oder ist das nur vorübergehend?

Abyss: Unser Ziel war es immer, etwas Cooles für den Amiga zu machen, was es so noch nicht gab. Und dabei kam’s öfter vor, wenn wir uns Retro-Games angeschaut haben, dass wir gedacht haben: „Wieso gibt’s sowas nicht für den Amiga?“ oder es kamen Aussagen wie: „Das muss doch besser gehen“.

So haben wir uns auch über die Amiga-Version von Bubble Bobble geärgert und eine bessere gemacht: Tiny Bobble. Die kam in der Szene sehr gut an, und dann juckt’s einen natürlich gleich, etwas Neues zu machen. Man schaut sich dann alle möglichen Games an, und analysiert: „Geht sowas am A500?“

Schließlich kamen wir auf Gradius/Nemesis, und fragten uns, wieso es da nie eine Amiga-Version gegeben hat, obwohl auf dem Amiga gefühlt 100 Plattform-Games rauskamen. Bei Bubble Bobble hat die Community schon einen Level-Editor geschrieben, was es uns ermöglicht hat, direkt die Original-Levels und -Sprites zu benutzen. Sowas gab’s leider für Gradius nicht. Ich hab mich dann angeboten, den original Arcade-Code zu reverse-engineeren. Dabei hab ich das original Arcade-ROM disassembled und die Background-Maps, Sprites, und Objekt-Placement gerippt.

CPU der Arcade-Maschinen dem Amiga weit überlegen

Tarnkappe.info: Ihr schreibt, die Original Hardware basiert auf einem Motorola 68000 mit 10 MHz. Was für ein Gerät war das denn, auf dem das Original lief? Etwas für eine Spielhalle, ein Videospiel-System für daheim?

Abyss: Die Original-Arcade-Hardware war dem Amiga 500 in vielen Dingen überlegen: Die CPU war schneller getaktet, die Grafik-Hardware kann zwei scrollende Playfields und hunderte zoomende Sprites anzeigen. Trotzdem hatte die Arcade oft Slow-downs in etwas hektischeren Situationen.

Damit war also klar, mit dem Original-Code kann man nicht viel anfangen. Das müssen wir viel effizienter neu coden. Wir hatten jetzt mit Tiny Bobble schon Erfahrungen gesammelt, wie man das meiste aus der Amiga-Grafik-Hardware herausholen kann.

Lars Sobiraj: Die Musik habt ihr jeweils selbst gemacht, warum?

Abyss: Die Original-Arcade-Hardware hatte insgesamt drei Sound-Chips, und die Musik benutzte sechs Stimmen. Das kann man so natürlich nicht am Amiga machen. Ich hab dann ein Tool geschrieben, dass die Original-Musik ins FastTracker-Format konvertiert und Pink hat die als Basis benutzt, die Musik mit Pretracker (Pink’s neuer Amiga-Soundtracker) zu optimieren.