Entwicklung

Post Mortem Galaxy on Fire 2

Georg Kupitz   //   Juli 29, 2011   //   0 Kommentare


Das iPhone-Spiel Galaxy on Fire 2 konnte sich international im App Store behaupten. Lässt sich dies allein auf die vergleichsweise hochwertige Grafik zurückführen oder spielen noch andere Aspekte eine Rolle? Georg Kupitz von Fishlabs analysiert den Verlauf der Entwicklung.

 

Immer wieder lesen wir erfreut die Kommentare zu »Galaxy on Fire 2« für iPhone, iPod Touch und iPad. Das Spiel sei außergewöhnlich, die Grafik hervorragend und viele Spieler hätten sagenhafte 100 Stunden oder mehr im Spiel verbracht, das mit einem Preispunkt von 7,99 Euro in das Premiumsegment des App Stores fällt. Als unser Sprössling in diesem Jahr auch noch als Sieger aus dem Rennen um den Deutschen Computerspielpreis für das »Beste mobile Spiel« hervorging, war unser Glück als stolzer Entwickler perfekt. Weil dieser Erfolg bei Fishlabs viele Väter hatte, habe ich mich in der Firma umgehört und versucht, den Werdegang von Galaxy on Fire 2 nachzuzeichnen.

Mit einem Preis von 7,99 Euro liegt Galaxy on Fire 2 eher im Premium-Segment des App Stores.

Anders als die anderen Projekte
Die Grundidee für Galaxy on Fire 2 stammt aus Zeiten, als Handys noch eine Speicherbegrenzung von 512 KB hatten. Die Frage, die sich Chefentwickler Hans-Christian Kühl seinerzeit stellte, war simpel: Was kann man aus 512 KB rausholen? Der Forscher- und Entdeckerdrang ist noch heute das grundlegende Wesensmerkmal des Spiels. Im ersten Teil der Reihe auf Java-Basis gab es bereits 500 Planeten und 100 Systeme, was sich zum damaligen Zeitpunkt nur die wenigsten vorstellen konnten. Gleichsam vollzog sich schon hier der Wechsel vom rein linearen Leveldesign hin zur Sandbox, einer offenen Welt, die es zu erforschen galt. Von Beginn an war die Vision des Projekts Galaxy on Fire, die Grenzen des Möglichen auf der mobilen Plattform zu verschieben. Das Schiff auf der Reise ins Ungewisse hatte dabei stets denselben Kapitän, was für Kontinuität im Projektablauf und eine gleichbleibende Spielerfahrung gesorgt hat. Der Chefentwickler heute wie damals ist Hans-Christian Kühl, er kümmert sich fast ausschließlich um sein Baby. Er spielt die zentrale Rolle als Entwickler, Projektleiter, Creative Director und Drehbuchschreiber. In seinem Kopf sind alle Informationen gespeichert. Mit der Personalie HCK, wie er intern genannt wird, steht und fällt das Projekt. In seiner zentralen Rolle begründet sich auch der etwas unkonventionelle Projektablauf. Wo es normalerweise eine konzeptionelle Vorlage gibt, die in einem linearen Prozess auf Umsetzbarkeit geprüft, verfeinert, produziert und der Qualitätskontrolle unterzogen wird, war die Entwicklung von Galaxy on Fire 2 für iOS stattdessen eher ein organischer, evolutionärer Prozess. Das Ausarbeiten der Story und die Programmierung fanden simultan statt. Fast ein halbes Jahr lang hatte HCK die Freiheit, das Spiel ohne Vorgaben oder Eingriffe wachsen zu lassen. Der Producer Jörg Thomaschewski hatte zwar stets den Überblick über die Produktion von Programmierung, Design und 3D-Assets, mischte sich aber ausdrücklich nur dann ein, wenn es an irgendeiner Stelle hakte. Nachdem HCK das erste Mal eine Demoversion abgerungen werden konnte, liefen auch Entwicklung und Qualitätsmanagement simultan ab. In unzähligen Schritten wurden neue Versionen, inhaltliche Wendungen und Features getestet, verworfen oder weiterverfolgt.

Technische Herausforderungen
Zu Beginn des Projekts musste HCK eine erste, grundlegende Entscheidung treffen: Sollte er die »Galaxy on Fire 1«-Version in C nehmen und diese zu »Galaxy on Fire 2« weiterentwickeln oder die Java-Version von »Galaxy on Fire 2« nach C portieren? Diese Evaluierung dauerte allein schon zwei Wochen. Schließlich entschied er sich dafür, die Java-Version in C umzuwandeln, womit er rückblickend zufrieden ist. Die Portierung war, gelinde gesagt, ein Riesen-Akt. Es gab gleich mehrere Knackpunkte, die bei der Programmierung beachtet werden mussten. Das automatische Speichermanagement und die Strukturen von Java wurden per Hand in C übertragen. Einige der in Java entworfenen Strukturen haben wir neu angelegt, weil der Zugriff über Zeiger andere Routinen erfordert als in Java. Der Lebenslauf jedes einzelnen Elements im Speicher wurde von der Erstellung bis zur Freigabe überprüft. Mit Hinblick auf die neue Funktionalität der Touch Devices von Apple haben wir auch das Screendesign neu entworfen. Jeder Bildschirm und jedes grafische Element musste erneut angefasst und die Funktionalität des vorher mit Tasten gesteuerten Spiels auf eine touchbasierte Benutzeroberfläche übertragen werden.

<< erste Seite  nächste Seite >

Kommentare

Einen Kommentar hinterlassen

Um einen Kommentar hinterlassen zu können, müssen Sie sich zuerst anmelden oder registrieren.

» zur Anmeldung
» zur Registrierung