Post Mortem: Fart Fiasco – Teil 2: Das mobile Minenfeld

Zurück zu Teil 1: Post Mortem: Fart Fiasco

Zwei Aspekte waren für mich ausschlaggebend, um Fart Fiasco für Mobilgeräte zu entwickeln:

1. Das einfache Gelegenheitsspielprinzip ist eher für Smartphones mit Touchscreen geeignet als für Desktop.
2. Der Mobile-Markt ist enorm groß und hat somit viel Potenzial zur Vermarktung.

Allerdings zeigte sich, dass diesen vermeintlich attraktiven Zielen eine ganze Menge unerwartete Hindernisse gegenüberstehen, von denen nur einige technischer Natur sind.

Eingabeformen: Klick oder Touch?

Die Kernsteuerung der Kuh geschieht über Tippen und Drehen, was sich gut auf Fingereingaben abbilden lässt. Weil der Bildschirm jedoch auch Eingabe-Elemente wie den Menü-Knopf enthält, muss die Eingabe dabei lokal begrenzt werden.

Im zweidimensionalen Spielbrett darf Klicken/Tippen die Kuh nur innerhalb des Spielfelds steuern, dort aber unabhängig davon, wo genau hin getippt wird. Menükomponenten sollen beim Antippen dagegen nicht die Kuh steuern, sondern die Eingabeelemente. Dabei sind Überlappungen auch dreidimensional zu berücksichtigen, d.h. wenn des Menü aufgeklappt ist, soll dieses die Eingaben abfangen und nicht das darunterliegende Spielbrett.

Der einfachste Lösungsansatz bestand darin, ein unsichtbares Rechteck im 2D-Grafikstapel einzufügen, das mittels Pointer-Events Klicks abfängt, grafisch ganz einfach ins Spielfeldlayout ausgerichtet werden kann und dessen Interaktionsereignisse Verdeckungen automatisch berücksichtigen.

Bei der Gestaltung der Programmoberfläche musste ich zudem darauf achten, dass Eingabeelemente groß genug sind, um sie mit der im Vergleich zu Mausklicks sehr groben Fingereingabe bequem treffen zu können. Spezialeingaben wie zum Beispiel das Drehen der Kuh per Tippen und Ziehen des Fingers waren nicht direkt mit Unity-Boardmitteln möglich, so dass ich diese Lücke mit dem Touch Kit-Modul schließen musste.

Bildformat

Bei PC-Desktop-Spielen liegen Bildschirmproportionen häufig in Querformaten vor, die nur relativ gering variieren, so dass man sich z.B. um 16:9 oder 16:10 kümmern muss. Zwar verlangt das auch schon ein gewissermaßen responsives Layout der HUD-Elemente, doch ist die Situation bei Mobilgeräten deutlich komplizierter. Die Bildschirmformate der vielen verschiedenen Handys auf dem Markt unterscheiden sich oft drastisch. Soll das Spiel auf dem Handy auch noch sowohl im Hoch- als auch Querformat funktionieren, erhöht das den Entwicklungsaufwand für das Bildschirm-Layout.

Die Hauptfrage, die sich dabei aber stellt ist eigentlich: Wie testet man schnell und einfach, wie sich das Spiel in den vielen unterschiedlichen Bildschirmformaten verhält und ob sich das Layout überall gut zugänglich und fehler- bzw. überschneidungsfrei anpasst? Hierfür kam bei Fart Fiasco das Editor-Plugin Universal Device Preview zum Einsatz, das den Spielbildschirm in einem Zug in unterschiedliche Formate zeichnet und so unglaublich viel Zeit spart.

Monetarisierung

Leider hat sich im App-Markt das Konzept kostenloser Spiele durchgesetzt und das reine Premium-Modell ist eher unüblich. Weil der Produktverkauf zum damaligen Zeitpunkt eine wichtige Einnahmequelle für mich war, musste ich eine Monetarisierungsstrategie finden. Der Verkauf digitaler In-Game-Items kam aber eher nicht in Frage, weil hierfür das gesamte Produktkonzept zu dieser Verkaufsform passen muss. Das Spiel und seine Inhalte erfordern psychologisch präzise gesetzte Gestaltungsentscheidungen. Mikro-Transaktionen bringen auch langfristig einen gewissen Technik- und Verwaltungsaufwand mit sich.

Unity Ads und die DSVGO

Die offensichtliche, weit verbreitete Lösung besteht aus dem Schalten von Werbung innerhalb des Spiels. Hierfür hatte Unity bereits seit längerem seine Unity Ads-Lösung im Angebot, die eine nahtlose Integration in die Game-Engine versprach. Abgesehen davon, dass sich die Unity Services in den letzten Jahren ständig verändert haben, was einiges an Pflegeaufwand mit sich zog, kam die Umsetzung der Datenschutzgrundverordnung ins Rollen. Die jetzt umzusetzenden sehr strengen Regularien zogen eine enorme Last an technischer und rechtlicher Umsetzung nach sich. Zwar hatte Unity relativ schnell reagiert und das nötige Einholen von Nutzerzustimmungen in ihre Ads-Bibliothek integriert, doch blieb sowohl ein gewisser Verwaltungsaufwand als auch ein bedrohlicher Beigeschmack hinsichtlich der rechtlichen Risiken für Produktanbieter. Und das noch zusätzlich zur damals ohnehin schon datenschutzrechtlich eher ungewissen Praxis der Datensammlung durch Unity.

Der klassische Weg

Da die Ads-Lösung technisch wie auch hinsichtlich DSGVO in den Kinderschuhen zu stecken schien, warf ich diesen Ansatz wieder aus meiner Software raus und kam zur Freemium-Lösung zurück, die aus einer simplen kostenlosen Basisversion sowie einer kostenpflichtigen Vollversion bestand.

Zunächst ging ich davon aus, dass sich das Umschalten zwischen Basis- und Vollversion mit einem In-Game-Kaufmechanismus realisieren ließe. Das hätte den Vorteil, dass alles innerhalb der selben Softwareversion liefe und der Status über Abfragen des Kaufstatus im Benutzerkonto synchronisiert werden könnte. Kurz zusammengefasst funktionierte das so leider nicht. Hauptproblem war noch nicht einmal die Abwicklung des Kaufs, sondern die Behandlung von Rückerstattungen, wie sie in den USA z.B. bei Softwarekäufen möglich sind. Wurde der Kauf storniert, so hat mein Spielcode dies nicht in Erfahrung bringen können, d.h. ein einmal freigeschaltetes Spiel blieb auch nach Kaufstornierung für immer freigeschaltet. Dies war ein Problem der Google-API selbst, das auch in den Entwicklerforen diskutiert wurde und für das es damals auch seitens der Google-Entwickler keine echte Lösung gab – wenngleich ich mich frage, wie das all die anderen Produkte in der Vergangenheit lösten.

Letztlich bestand der Ausweg darin, von der sich sehr unzuverlässig anfühlenden In-Game-Update-Variante zu einem klassischen Zwei-Versionen-Modell zu wechseln. Durch eigene Compiler-Switches hatte ich mein Spiel so programmiert, dass Unity sowohl eine Demo-Version als auch in eine Vollversion aus der gleichen Projektbasis erzeugen konnte.

Build Automation

Würde ich nun für Android und iOS jeweils eine Demo- und eine Vollversion bauen, so käme ich schon auf vier nötige Erstellungsvorgänge, deren manuelle Konfiguration und Auslösung schnell umständlich wurde. Daher suchte ich nach einer Möglichkeit des schnelleren Umschaltens und Erstellens plattformspezifischer Spielversionen und landete letztlich bei Super Unity Build. Damit konnte ich nicht nur mehrere Plattformziele definieren und auf Knopfdruck gesammelt erstellen lassen, sondern auch gleich noch Pre- und Postprocessing-Schritte automatisieren, wie z.B. Dateien zu kopieren oder das Programmsymbol für Demo- und Vollversion zu ändern.

Mit der Erstellung von plattformspezifischen Datenpaketen ist das Produkt allerdings noch längst nicht für Mobilgeräte verfügbar. Neben der technischen Anbindung ist auch die Publikation im Store nötig, was einige neue unerwartete Probleme mit sich brachte.

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