Post Mortem: Fart Fiasco – Teil 3: Roboterchaos & iTürsteher

Zurück zu Teil 2: Post Mortem: Fart Fiasco – Das mobile Minenfeld

Auf dem Mobile-Markt sind vor allem Google (Android) und Apple (iOS) verbreitet und damit relevant. Für beide lässt sich zwar grundsätzlich kostengünstig entwickeln, jedoch muss dabei das jeweilige SDK genutzt und auf die Systemeigenheiten eingegangen werden. Immerhin bieten heutige Game-Engines wie Unity bereits die Möglichkeit allgemeine Spielinhalte unabhängig vom Gerät zu erstellen und dann per Knopfdruck eine jeweilige plattformspezifische Version zu generieren. Jedoch geschieht auch dies letztendlich über das jeweilige Plattform-SDK, wenn auch teil-automatisiert.

Entwicklung für mobile Geräte

Ganz konkrete Systemfunktionen und Gerätebesonderheiten lassen sich naturgemäß nicht verallgemeinern. Ein Beispiel ist das jeweilige Benutzerkonto. Sowohl Google als auch Apple bieten mit Google Play bzw. Game Center inhaltlich ähnliche, aber eben nicht völlig identische Funktionen im Zusammenhang mit den Benutzerprofilen. Somit erfordert die Programmierung unterschiedlichen Code, abhängig davon, in welcher Umgebung das Spiel läuft. Ein Möglichkeit, um dies zu erreichen ist die bedingte Compilierung, die Code beim Erstellungsvorgang abhängig von der aktiven Konfiguration ein- oder ausschließt.

Da die bedingte Compilierung aber dennoch das Schreiben (und Testen) von mehrfachem Code erfordert, um letztlich aber ähnliche Dinge zu erreichen, versuchen einige Entwickler den Code zu abstrahieren und in Bibliotheken zusammenzufassen. Für Fart Fiasco habe ich das Cross Platform Native Plugins – Ultra Pack von Voxel Busters Interactive eingesetzt, das inzwischen in eine Nachfolgerversion überging. Dieses Plugin versuchte die konkrete Store-Anbindung zu kapseln, so dass man sich als Entwickler nicht mehr um die plattformspezifischen Details kümmern muss. Das hat jedoch nur teilweise gut funktioniert, es gab immer wieder Probleme in dieser im Detail doch recht komplexen Angelegenheit.

Google Android-Entwicklung

Die Stärken von Google-SDKs liegen wie so oft auch in diesem Fall klar in der zunächst relativ unkomplizierten Zugänglichkeit und niedrigen Kosten.

Das Android-SDK lässt sich auf einem Windows-Entwicklungs-PC einfach herunterladen und lokal ausführen. Der Test des Spiels geschieht über einen Emulator oder ein per USB angeschlossenes Android-Gerät. Zudem ist es möglich, das Spiel in Form der fertig erzeugten apk-Datei einfach auf ein Android-Handy zu kopieren und dort zu installieren.

Spätestens bei Veröffentlichung im Play Store ist ein Entwicklerkonto nötig, wofür eine einmalige Gebühr von ca. $25-$35 zu entrichten ist.

Google’s typische Schwächen finden sich in der Produktkomplexität. Es gibt unglaublich viele Stellen an denen irgend etwas konfiguriert werden muss. Ich empfinde die Webseite zum Einrichten eigener Produkte (genannt Entwickler-Konsole) bis heute nicht intuitiv und unglaublich unübersichtlich. Noch schlimmer ist jedoch die ständige Überarbeitung seitens Google, dessen Konsequenz ist, dass man permanent die SDKs-Versionen aktualisieren muss, weil z.B. ältere Android-Versionen nicht mehr unterstützt werden. Dabei entsteht jedoch ein neues Problem: Alle abhängigen Module müssen ebenfalls diese Änderung unterstützen. Wenn Google z.B. ein neues SDK erzwingt und das Native Plugins-Modul nicht ebenfalls vom Entwickler aktualisiert wird, passt der Code nicht mehr zusammen und das Projekt ist kaputt. Was sich auf den ersten Blick vielleicht „mit großer Sorgfalt irgendwie handhabbar“ anhört, war ein riesiges Problem. Die Unterstützung für Android bedeutet einen langfristig immer wiederkehrenden Wartungsaufwand, der am eigentlichen Spiel nichts ändert, aber Entwicklungsressourcen kostet.

Apple iOS-Entwicklung

Eine Stärke der iOS-Welt liegt ganz klar in der besseren Nachhaltigkeit und dem glatten Zusammenspiel von Apple-Produkten. Entwickler werden meines Erachtens sehr viel besser und verständlicher durch die nötigen Vorgänge geführt und das bei Google vorzufindende Chaos bleibt hier aus.

Eine der größten Schwierigkeiten stellen dabei aber die mit dem zuvor genannten Qualitätsanspruch zwangsläufig einhergehenden Einschränkungen dar. Das geht schon damit los, dass Apple-Hardware nötig ist, um ein Spiel für die iOS-Welt zu erstellen. Ich brauchte also z.B. ein MacBook auf dem Xcode installiert wird. Auf dieses konnte ich mein Fart Fiasco-Unity-Projekt kopieren und dort eine iOS-Version des Spiels erzeugen.

Abgesehen davon, dass der Synchronisationsprozess relativ mühsam ist, gibt es weitere Probleme. So verlangt Xcode dem ausführenden System viel ab, was den Erstellungsprozess auf meinem alten MacBook von 2012 extrem langsam machte. Zudem müssen auch hier aktuelle Versionen des Tools verwendet werden. Das wurde dann zum Problem als eine neue Xcode-Version auch eine neue MacOS-Version voraussetzte, diese aber auf meinem alten MacBook nicht mehr installierbar war. Ich hätte also ein komplett neues MacBook kaufen müssen, nur um das Projekt für iOS-Geräte zu generieren.

Auch das Testen gestaltet sich in der Apple-Welt erheblich komplizierter. So können Programme nicht einfach auf Geräte kopiert werden (zumindest bisher). Ein Upload über die Store-Infrastruktur und die zeitlich eingeschränkte Installation per Testflight-App sind unumgänglich. Hierfür war wiederum das Eröffnen eines Entwicklerkontos nötig, das jährlich wiederkehrend $99 kostet. Hier entstehen also laufende Kosten, die auch laufend wieder eingespielt werden müssten.

Der Brückentroll: Apple’s Review-Team

Nun hatte ich tatsächlich sämtliche bisher genannten Hürden überwunden und hatte es geschafft, dass Fart Fiasco auch auf meinem iPhone lief. Allerdings ist bei diesem Vorgang noch eine Sache entscheidend: jede hochgeladene Version wird von Apple-Mitarbeitern kontrolliert, auch wenn es sich um nicht öffentlich sichtbare Softwareversionen handelt. Während mehrere Versionen problemlos eine Freigabe erhielten, erwischte ich eines Tages einen Gutachter, der das Projekt blockierte.

Fart Fiasco wurde als Spam eingestuft. Die Begründung war, dass es zu viele Farting-Apps im Store gebe und man daher nicht noch mehr wolle. Dass sich der Mitarbeiter oder die Mitarbeiterin offensichtlich überhaupt nicht mit dem Produkt auseinandergesetzt hat, sollte jedem klar werden, der das Spiel spielt. Bis heute ist Fart Fiasco meines Wissens einzigartig und im App-Store nichts ähnliches zu finden. Es mit plumpen Furzgeräusche-Generatoren gleich zu setzen, ist meiner Meinung nach schlichtweg sachlich falsch.

Leider konnte auch ein nachfolgender Dialogversuch keine Überzeugung leisten. Statt sich nochmal ernsthaft mit der Sache zu beschäftigen, riet man mir, ich soll das Produkt doch über Webtechnologie realisieren, so dass man es im Browser spielen kann, wodurch der App-Store umgangen wird. Natürlich geht das nicht so einfach, zumal das gesamte Interaktionssystem auf eine Vollbild-App ausgelegt ist und dies im Browser eine völlig andere technische Umsetzung erfordert.

Mit dem Wegfall von iOS war quasi über Nacht der gefühlt halbe Mobile-Markt unerreichbar geworden, was für eine Handy-App katastrophal ist.

Weiter in Teil 4: Post Mortem: Fart Fiasco – Im Content-Generation-Labyrinth