Vom iPhone zu AppUp: Portierung von „Ancient Frog“
Nachfolgend finden Sie die Fortsetzung einer Artikelreihe zur Portierung vom iPhone auf AppUp(SM). Dies ist mein Interview mit dem Entwickler James Brown, in dem ich ihn zu seiner Erfahrung bei der Portierung seines preisgekrönten Games „Ancient Frog“ vom iPhone auf AppUp befrage.
F: Was war Ihre Inspiration für dieses Game?
James Brown:
„Ancient Frog“ entstand, als ich der Mainstream Gaming-Industrie den Rücken zukehrte. Mein Hintergrund ist sehr divers - ich bin Designer, Programmierer, Künstler und Produzent. Die Gaming-Industrie wurde jedoch riesig und geschichtet, und ich fand mich bei Lionhead / Microsoft wieder als Manager eines Programmiererteams, wo ich nur über wenig kreativen Input verfügte, was weit weg von meinem Traumjob lag.
Also beschloss ich, wieder meine eigenen Games zu entwickeln. Die Idee für „Ancient Frog“ basierte auf den Bedingungen, die ich mir selbst auferlegte. Ich wollte ein Game entwickeln, das klein genug war, um von einem einzigen Entwickler auf professionellem Niveau entwickelt werden zu können. Wenn man bei einem Puzzle-Game mal die Mechanik des Puzzles niet- und nagelfest hat, besteht der Rest lediglich aus Variationen des Themas. Ich benötigte auch einen zentralen Charakter, der süß, aber nicht kitschig sein sollte, mit einer eigenen Persönlichkeit. Da ich kein Animator bin, untersuchte ich verfahrensorientierte Animationssysteme etwas genauer, und die Idee eines Kletterspiels mit einem Gecko wuchs darauf aufbauend heraus.
Nach den ersten Schritten mit einem Strichmännchen-Prototyp entwickelte sich die Idee ständig weiter. Aus dem Gecko wurde ein Frosch, da Frösche längere Hinter- als Vorderbeine haben, was mich zur Einführung von interessanten Entscheidungen für den Spieler führte. Der Kletteraspekt wich der etwas abstrakteren Idee des Treten auf Tröpfchen. Danach wurde das Animationssystem klarer - der Spieler fährt den Frosch nicht umher, sondern zieht eine Gliedmaße nach der anderen. Dadurch wurde das Puzzle interessanter, denn der Spieler und nicht das Game steuert die Animation.
Es war eine lange Reise vom anfänglichen Prototyp bis zum fertigen Game (während dieser Zeit zog ich auch in ein anderes Land und verbrachte einen Teil meiner Zeit damit, interaktive Ausstellungen für Museen zu gestalten), die Grundidee saß jedoch klar in meinem Kopf fest.
James Brown: Das hauptsächliche Tool, das ich bei der Entwicklung des Games verwendet habe, ist das Game selbst. Der größte Teil des Codes, den ich für „Ancient Frog“ geschrieben habe, war für die internen Tools und Editors (einschließlich des Codes zur Generierung der Puzzles und zum Auffinden der optimalen Lösungen für die Puzzles, was eine besonders interessante Herausforderung war). Der wichtigste Aspekt beim Festnageln des Designs war die Tatsache, das ich soviel wie möglich spontan bearbeitbar machte. Beim Erstellen einer interessanten interaktiven Erfahrung lässt sich konstante Iteration einfach nicht durch andere Methoden ersetzen. Etwas Neues versuchen, testen, Fehler beheben, testen und so weiter, bis alle Fehler und Haken entfernt worden sind. Und dann geht die Arbeit weiter mit dem Hinzufügen der schönen und überraschenden Funktionen. Und wieder die ganzen Wiederholungen zum Entfernen von Fehlern und Haken. Alles wird von den Daten angetrieben, und wenn die Festplatte auf Änderungen überwacht wird, kann das Game alle Bearbeitungen problemlos erneut laden. Malen auf einer Textur in Photoshop, Speichern, und schon ist die Änderung im Game aufgenommen. Es gibt keine magischen Zahlen im Code. Ich habe eine kleine Vorlagen-Regelklasse, die sich wie ein nativer Typ verhält, es ist also eine extrem niedrige Schwelle vorhanden für das Offenlegen zu den Daten. Die Federkraft des Froschbeins? Die Dauer der Überblendung? Die Beschleunigung aufgrund der Schwerkraft? Selbst wenn ich mir sicher bin, dass ich etwas nie mehr ändern möchte, ist es da, und falls ich beim Testen trotzdem noch Änderungen vornehmen möchte, kann ich herumexperimentieren und sofort anzeigen, wie sich diese Änderungen auswirken. Wenn man jedes Mal stoppen, neu kompilieren und dann alles wieder abspielen muss, gelangt man schnell mal an einen Punkt, an dem kleine Änderungen einfach zu mühsam sind. Der Look von „Ancient Frog“ entstand aus einer mir selbst auferlegten Anforderung für maximale Auflösungsunabhängigkeit. Ich wollte alles von 640x480 bis hin zu Doppelbildschirm 1920x1200, und alle Seitenverhältnisse von Hochformat bis Breitbildformat. Was mich bei meinem letzten Spiel bei Lionhead störte, war, dass für das Ändern der Auflösung ein Neustart des Games erforderlich war. Jetzt wo ich alles selber machte, wollte ich es perfekt machen. Das Ziel war also, spontane Auflösungsänderungen möglich zu machen. Darüber hinaus wollte ich Spielern die Möglichkeit geben, das Fenster zu erfassen und es in eine beliebige Form oder Größe zu ziehen, wobei sich der Inhalt gleichzeitig nahtlos anpasst. Das scheint eine banale technische Entscheidung zu sein, sie hatte jedoch eine große Auswirkung auf dein einzigartigen Look des Games und die Möglichkeit der Portierung auf verschiedene Plattformen. Wenn ich mich einfach mit einigen vernünftigen Seitenverhältnissen begnügt hätte, hätte ich für die Grafiken lediglich einen kleinen leeren Rand und Zuschneiden zur Anpassung bereitstellen können. Da ich jedoch bei jedem Abspielen des Games mit der Fenstergröße spielen konnte, wollte ich sehen, was passieren würde, wenn das Fenster extrem breit war. Oder hoch. Oder riesig. Oder winzig. Dabei stößt man schnell an die Grenzen von festen Layouts. Deshalb erstellte ich ein Layoutmodul, gesteuert von Dateien auf XML-Ebene, die Ebenen in Schichten aufbauten. Jede Ebene kann verschiedene Layoutregeln haben, die grundlegende Strategie besteht jedoch darin, eine Ebene zu haben, die den Abspielbereich enthält und möglichst fensterausfüllend ist, und eine oder mehrere Ebenen mit Vorder- und Hintergrund, die gekachelt, gedehnt oder zugeschnitten werden können, um den Rest des Bildschirms auszufüllen. Nach dieser Idee des Erstellens von Ebenen in Schichten nutzte ich dies natürlich, um Bewegung auf den Bildschirm zu bringen, mit Schärfentiefe und Parallaxe. Ich verwendete Fotos für die Texturen der Schichten - Blätter, Baumstämme, Moos, Steine usw.. Dieser Ansatz schien vielversprechend zu sein, aber es dauerte mehrere Monate, bis alles als ein zusammenhängendes Ganzes zusammenkam. Der Durchbruch geschah, als ich die Regenrinne am Haus reinigte und mich vom Muster des Baumschattens am Garagentor ablenken ließ. Es war ein sich ständig weiter entwickelnder Tanz, mit einer grundlegenden Einfachheit basierend auf der Interaktion einiger einfacher Formen und Rhythmen. Ich ging zurück ins Haus und schrieb einen Code für diesen Effekt und schichtete ihn über jede Ebene mit multiplikativer Mischung, um dem Ganzen einen stark gesättigten Look zu geben, und das führte zum endgültigen Stil des ganzen Games. F: Für wie viele Geräte ist „Ancient Frog“ verfügbar und wie begannen Sie mit der xplatform-Entwicklung? James Brown: „Ancient Frog“ gibt es für das Apple iPhone und iPad, Pre und Pixi von Palm und jetzt auch für Netbooks mit dem Atom Prozessor. Ich habe auch eine Android-Portierung (die ich aber nicht von Neuseeland aus verkaufen kann) und Desktop-PC- und Mac-Versionen, wobei ich mich noch nicht für die besten Vertriebskanäle entschlossen habe. Den ursprünglichen Prototyp schrieb ich für mein Handy (zu der Zeit ein Windows Mobile-Gerät mit einem 240x240-Display). Damals spielte ich Games vor allem, wenn ich irgendwo wartete, z. B. an der Bushaltestelle oder an der Kasse im Supermarkt. Deshalb wollte ich ein für solche Situationen geeignetes Game entwickeln. Das war aber, bevor das iPhone den Markt eroberte. Der Smartphone-Markt war stark fragmentiert, und ich hatte keine klaren Vorstellungen der Spezifikationen, auf die ich abzielen sollte oder wie ich ein Game an Smartphone-Benutzer verkaufen konnte. Also legte ich diese Idee beiseite und konzentrierte mich auf die Entwicklung auf dem PC. Die Idee, das Game zu einem späteren Zeitpunkt auf das Handy zu portieren, blieb jedoch im Hinterkopf, und während der gesamten Entwicklung berücksichtigte ich Portabilität und Skalierbarkeit. Ich stellte fest, dass mein Code portierbarer ist, je weniger ich von externen Bibliotheken abhänge. Es gibt sicher gute Argumente für alle Arten von Dienstprogrammbibliotheken, Modulen oder Middleware, sie sind jedoch nur vorteilhaft, wenn sie auf eine interessante Zielplattform gelangen. Falls sich später herausstellt, dass die Abhängigkeiten nicht auf dem gewünschten Ziel funktionieren, können Sie wenig unternehmen. Ich verwende SDL (die Simple DirectMedia Layer) auf dem PC, das ist aber eine sehr schmale Ebene und es ist ziemlich einfach, falls nötig alternativen Code zu schreiben (wie ich das für das iPhone und Android tun musste). Sonst verwende ich einfach C++ Code, der auf OpenGL abzielt. Mit C++ liegen Sie immer richtig. Auch wenn für eine bestimmte Plattform andere Sprachen empfohlen werden, war der C/C++ Compiler mit ziemlicher Sicherheit zuerst vorhanden (wenn auch nur um diese Sprache zu kompilieren). OpenGL ist standardmäßig fast überall verfügbar (selbst unter Windows, obwohl die Hersteller den Einsatz von Direct3D bevorzugen, jedoch nicht darauf beharren). Es ist zudem sehr einfach, einen gut definierten Untersatz von OpenGL zu verwenden, und auf Plattformen, auf denen keiner verfügbar ist, können Sie den Untersatz einfach selbst implementieren. Ich führe den größten Teil meiner Entwicklungsarbeit unter Windows mit Visual Studio durch, ich verwende jedoch ein Macbook Pro, wenn ich außerhalb meines Büros arbeite. Es ist gut für die Portabilität des Codes, regelmäßig mit zwei verschiedenen Compilern und Betriebssystemen zu arbeiten. Damit wird ein großer Teil der plattformübergreifenden Probleme gelöst, bevor sie sich festsetzen und später schwierig zu entfernen sind. Ich habe aus diesem Grund bei der Portierung auf eine andere Plattform nur wenige Überraschungen erlebt. F: Welche Tools und Methoden haben Sie für das Portieren Ihrer App auf ein Netbook verwendet und warum haben Sie diesen Weg eingeschlagen? James Brown: Das Game lief bereits unter Windows, und Netbook-Auflösungen waren bereits durch meine vorherige Arbeit abgedeckt, das Wort „Portierung“ ist also vielleicht etwas zu grandios, um die benötigte Arbeit zu beschreiben. Ich konnte meine Tests nur auf einer beschränkten Anzahl von Zielhardwaregeräten ausführen, daher entwickelte ich mit den konservativsten Einstellungen. Mein Game-Modul hat einige Einstellungen, die ich je nach Fähigkeit des Zielsystems verwenden kann, und ich deaktivierte Framebuffer-Objekte und Shader-Support. Sobald ich etwas mehr Daten zur erhältlichen Treiberunterstützung habe, aktiviere ich diese wahrscheinlich wieder, um das Game etwas prickelnder zu machen. James Brown: „Ancient Frog“ setzt eigentlich keine Hardware ein, die nicht mit einer Maus oder einem Trackpad repliziert werden kann. Ich verwende den Beschleunigungssensor, um die Richtung zu beeinflussen, in die die Blumenblätter in der 'win'-Animation fallen, aber das Game würde auch ohne dies auskommen. Auf der iPad-Version wird Multi-Touch verwendet, damit mehrere Finger gleichzeitig ins Wasser eingetaucht werden können. Aber auch das wäre kein großer Verlust. Auf den Touchscreen-Versionen von „Ancient Frog“ beginnt das Game mit einem einführenden Tutorial, während dessen der Spieler keine Kontrolle hat. Das finden einige Spieler ärgerlich, aber Tests haben ergeben, dass dies notwendig war, um dem Spieler einige der Steuerungsbewegungen beizubringen. Auf Computern mit indirekter Steuerung (einer Maus oder einem Trackpad) ist dies jedoch aus irgendeinem Grund absolut inakzeptabel. Ich weiß nicht genau, warum das so ist. Vielleicht, weil eine fehlende Reaktion auf eine Berührung immer kontextabhängig ist und daher erwartet wird, während eine fehlende Reaktion auf die Maus als ein Hängen der Maschine interpretiert und nicht erwartet wird. Ich musste auf jeden Fall am Tutorial Änderungen vornehmen und es in Richtung eines Leitfadens ohne Benutzersteuerung gestalten. Ich entfernte zudem die „Rückgängig“- und „Wiederholen“-Gesten, zum Teil, weil diese Bewegungen auf einem Maus-/Trackpad-Gerät umständlich sind, und zum Teil, weil der erhöhte Bildschirmplatz bedeutet, dass Platz für Schaltflächen am Bildschirm vorhanden ist. Schaltflächen auf dem Bildschirm bedeuten zudem, dass der Spieler mit diesen Tasten experimentieren kann, sodass diese nicht unbedingt im Tutorial abgedeckt werden müssen. James Brown: Das Verfahren zum Erstellen des Looks von „Ancient Frog“ mit mehreren Mischungsdurchläufen ist sehr füllratenintensiv. Ich hatte auf der iPad-Portierung (an der ich vor der Netbook-Version arbeitete) Schwierigkeiten damit, da der Grafikprozessor des iPads einfach nicht mit so viel Nachzeichnen klarkommt. Ich verbrachte viel Zeit damit, die Beleuchtung in die Texturen einzubauen, Elemente aus dem Layout zu entfernen und das Game auf anderen Ebenen drastisch zu kürzen, damit es funktionierte. Ich machte mir also Sorgen, dass ich bei der Netbook-Version auf dieselben Probleme stoßen würde. Ich war jedoch angenehm überrascht von der Geschwindigkeit des integrierten Grafik-Chips und musste nichts eliminieren. James Brown: Beim Spielen treten auf den einzelnen Geräten eigentlich keine Unterschiede auf. Auf Handhelds ist das Aussehen der Ebenen vereinfacht. Sie haben nur eine Ebene und sind solide gestutzt, um den größtmöglichen Nutzen aus den winzigen Displays zu ziehen. Auf den Netbook-Versionen haben die Frösche etwas mehr Freiraum und einige spielerische Hintergrundelemente. Aber abgesehen von einigen kleinen Feineinstellungen beim Fortschreiten des Schwierigkeitsgrads sind die Puzzles identisch. F: Benötigten Sie Support von Intel im Verlauf der Arbeit? Wie bewerten Sie das Einreichungsverfahren und den Support für AppUp im Vergleich zu anderen Shops? James Brown: Das ganze Verfahren war unkompliziert. Es trat ein Validierungsfehler auf, weil ich mit einer alten Version des SDKs arbeitete, aber danach lief alles problemlos ab. F: Würden Sie irgend etwas anders machen, oder haben Sie Tipps für Entwickler, die vom iPhone auf AppUp portieren wollen? James Brown: Ich wünschte mir nur, ich hätte dies schon früher getan. Der Aufwand für die Entwicklung für das AppUp Center ist so gering, ich bin gespannt, wie sich das alles weiterentwickelt. Mein wichtigster Ratschlag für eine Portierung vom iPhone auf AppUp ist, bei der Entwicklung der iPhone App von Anfang an die Portierung im Auge zu behalten. Verwenden Sie also C++ und vermeiden Sie Apple-spezifische APIs. Falls Sie bereits eine fertige iPhone Version haben und sich wundern, ob es sich lohnt, Ihre Entwicklung so umzustrukturieren, dass sie plattformunabhängiger ist: abgesehen von der neuen Portierung werden Sie auch Vorteile für den ursprünglichen Code feststellen. Auf unterschiedlichen Geräten werden andere, kleine Fehler offen gelegt, und da der Code auf allen Plattformen gleich ist, kommen diese Fehlerbehebungen allen Versionen zugute. Wenn Sie für sowohl das iPhone als auch für AppUp entwickeln werden, macht es Sinn, AppUp als das Hauptziel während der Entwicklung zu designieren. Wiederholungen sollen schnell möglich gemacht werden, und das Debugging eines Netbooks ist um einiges schneller als auf dem iPhone Simulator oder beim Laden auf die physische Hardware.
F: „Ancient Frog“ hat einen eindeutigen Look. Wie sah Ihr Verfahren im Bezug auf das Design des Games aus, also was Tools, APIs usw. anbetrifft?
F: Wie sind Sie mit den Hardware-Unterschieden umgegangen, wie z.B. Multi-Touch-Technik im Vergleich zu Maus und Tastatur und Beschleunigungssensor im iPhone?
F: Hat Sie irgend etwas bei der Portierung überrascht – war es schwieriger oder leichter, als Sie dachten? Haben Sie Funktionen für das Netbook verloren oder erweitert bzw. verbessert?
F: Wie vergleichen Sie das Spielen selbst auf den einzelnen Geräten?
