In der Theorie klingt manches logisch, was man in der Praxis plötzlich nicht mehr plausibel findet. Trotz besseren Wissens setzt man oft Dinge ganz anders um, als man es sich vorher vorgenommen hat. Es ist das Bauchgefühl, das solche Entscheidungen beeinflusst. Und manchmal liegt man damit sogar richtig – oft aber auch falsch. Erst eine Summe von Erfahrungen macht aus einem unabhängigen Entwickler einen erfolgreichen App-Unternehmer. Damit Sie nicht alle diese Erfahrungen am eigenen Leib machen müssen und auch mit Ihrer ersten App eine Chance auf Erfolg haben, gibt es in diesem Buch eine Reihe von sogenannten Fallstudien. Sie sollen Ihnen helfen, Ihre Entscheidungsfähigkeit zu schulen. Gezielte Fragen am Ende der Fallstudie werden Ihre unternehmerische Kreativität herausfordern und Ihr neues Wissen vertiefen. Entwickler aus aller Welt haben für diese Fallstudien ihre Erfolge und Misserfolge mit uns geteilt. Lernen Sie aus ihren Erfahrungen, machen Sie es (zumindest theoretisch) besser und lassen Sie sich inspirieren von der Willenskraft und dem unternehmerischen Witz, den die meisten von ihnen an den Tag gelegt haben.

Da wir im ersten Abschnitt die Meilensteine der App-Vermarktung nur kurz angesprochen haben und noch nicht in die Tiefe gegangen sind, ist es nicht sinnvoll, Sie bereits zum App-Marketing-Berater zu machen und eine Fallstudie durcharbeiten zu lassen. Stattdessen stelle ich Ihnen das erfolgreiche Entwickler-Team vor, das ein sehr geistreiches Spiel namens Casey’s Contraptions kreiert und wohlüberlegt vermarktet hat. Noel Llopis und Ángel Friginal waren so freundlich, die Geschichte ihrer App für alle unabhängigen Entwickler da draußen öffentlich zu machen. Von der ersten Idee bis zum Aufstieg in den Ranglisten behandeln sie wichtige Fragen, die sich jeder Entwickler im Laufe der Zeit wird stellen müssen. Noch können Sie nicht alle der angesprochenen Themen richtig einordnen und vielleicht auch nicht jeden Schachzug der beiden nachvollziehen. Aber Sie werden beim Lesen der folgenden Kapitel immer wieder feststellen, wie klug die beiden die meisten ihrer Entscheidungen getroffen haben – und was sie hätten besser machen können.

Casey’s Contraptions – die Geschichte einer App

Casey’s Contraptions ist ein iOS-Spiel der Entwickler Noel Llopis und Miguel Ángel Friginal. Noel arbeitet seit über zehn Jahren in der Spieleindustrie und hat sich vor vier Jahren als Entwickler selbstständig gemacht. Seinen ersten Erfolg feierte er mit dem in-app-purchase-basierten Spiel Flower Garden. Schon vor einigen Jahren hat er den Grafikdesigner Miguel über Twitter kennengelernt und bei einer Entwickler-Konferenz persönlich getroffen. Schließlich entstand aus dieser Bekanntschaft eine Zusammenarbeit. Casey’s Contraptions war für Miguel das erste veröffentliche Video-Spiel. Zwanzig Jahre zuvor hat er noch ein gedrucktes Rollenspiel kreiert.

Die beiden erzählen im folgenden Erfahrungsbericht von den Anfängen ihrer gemeinsamen App und sparen auch nicht die vielen kleinen Misserfolge aus, die ihnen entlang des Weges passiert sind.

  • Erste Entscheidungen

Wir wussten, dass wir unser nächstes Projekt für iOS entwickeln würden, weil wir den iTunes App Store nicht nur aus Nutzer-, sondern auch aus Entwicklersicht sehr schätzen – und weil es eine Plattform ist, auf der auch unabhängige Entwickler finanziell erfolgreich sein können. Darüber hinaus waren die weiteren Entscheidungen aber nicht leicht, denn ein neues Spiel zu kreieren ist niemals einfach. Obwohl wir seitenweise Ideen hatten, war es schwer, sich auf ein ganz spezifisches Spiel-Konzept festzulegen. Wir wollten etwas, das gleich drei Erwartungen erfüllte: Erstens musste das Spiel kreativer Natur sein und nicht auf Zerstörung als hauptsächliches Element basieren. Es sollte etwas sein, von dem wir auch selbst begeistert waren, und es musste sich natürlich auch gut im App-Store verkaufen lassen. Einfacher gesagt als getan! Wir haben einen Prototyp nach dem anderen erstellt, und viele Ideen waren zwar nicht schlecht, aber trotzdem waren sie nicht umwerfend. Nach dem siebten oder achten Prototyp entschieden wir uns schließlich für ein Konzept, bei dem der Spieler verschiedene Puzzles mithilfe physikalischer Grundsätze lösen muss – ganz im Stil der unnötig komplizierten Maschinen des Künstlers Rube Goldberg (Bild 1.3). Im Herzen ähneln die mechanischen Möglichkeiten denen von klassischen Spielen wie The Incredible Machine, aber unser Spiel legt einen stärkeren Schwerpunkt auf Kreativität statt darauf, die eine richtige Antwort zu finden. Außerdem sollte es möglichst sozial gestaltet sein, mit Optionen zum Teilen, und von vornherein auf das Touch-Interface der iOS-Geräte abgestimmt sein.

casey6

Ein typisches Rätsel aus Casey’s Contraptions. (Screenshot: Llopis & Friginal)

Wir haben unser Projekt von vornherein als eine Partnerschaft mit 50/50-Beteiligung angelegt – ohne zusätzliche Investoren oder Verleger. Miguel kündigte seine Vollzeitstelle, um die Gestaltung von Casey’s Contraptions (Bild 1.4) machen zu können, und ich kümmerte mich um die Programmierung. Das Design des Spiels bestimmten wir beide mit: die Regeln, die Spielatmosphäre, die Levels. Alles andere teilten wir uns nach unseren Fähigkeiten und unserer Erfahrung auf: Website, Server-Pflege, PR und so weiter.

casey1

Bild 1.4            Das Logo von Casey’s Contraptions. (Grafik: Llopis & Friginal)

Noch kann ich hier nur eine Bilanz nach dem Launch ziehen und keinen abschließenden Bericht geben. Denn die Spieleindustrie, und besonders die für iOS oder Facebook, hat sich mehr zu einem Service als einem Produkt entwickelt. Wenn alles gutgeht, werde ich aber bald mehr zur Entwicklung von Casey’s Contraptions sagen können.

Was gut lief

  • Gutes Theme und starker Style

Casey’s Contraptions startete das Rennen ohne Casey! Der ursprüngliche Prototyp sah nur die Entwicklung von kreativen Aufbauten vor und natürlich die physikalische Simulation, die dahinterstecken musste. Es hatte Potenzial, aber irgendwie fehlte noch etwas. Es fehlte Persönlichkeit.

Nach einem Brainstorming kreisten wir schnell um die Idee, einen klugen Achtjährigen die Apparaturen bauen zu lassen. Nicht nur, dass wir so schnell eine gehörige Portion Persönlichkeit im Spiel hatten, es entschied auch wichtige Teile der restlichen Entwicklung. Denn statt eines klassischen Physik-Spiels mit Flaschenzügen, Rollen und all dem industriellen Kram, konzentrierten wir uns natürlich auf Dinge, die einem Achtjährigen zur Verfügung stehen würden, um seine Apparate zu bauen: Spielzeuge und Haushaltsgegenstände wie die Puppe seiner Schwester, Papierflugzeuge oder einen Plastik-Lastwagen.

Dieser Fokus auf Spielzeug führte wiederum dazu, dass wir die Levels anders gestalteten: Wir dachten anfangs an Aufgaben, die Casey während des Alltags würde bewältigen müssen – zum Beispiel, sein Spielzeug auf kreative Weise wegzuräumen. Aber dann kamen wir auf die Idee mit den „playtime levels“. Das Ziel dieser Levels war plötzlich sehr kreativ und phantasievoll („Rette Dschungel-Entdecker mit Hilfe eines Heißluftballons“). Ganz so, wie Casey es sich beim Spielen eben selbst ausdenken würde.

Unser achtjähriger Hauptcharakter (Bild 1.5) bestimmte natürlich auch die Art Direction. Wir wollten eine sehr breite Zielgruppe erreichen, vom Kind bis zum älteren Gelegenheits-Spieler. Miguel knabberte länger am Stil des Cartoons, er ließ sich von modernen Animationen genauso inspirieren wie von verrückten Warner-Bros-Figuren. Doch am Ende wurde es ein Stil mit starken Umrissen und klaren Farben, um alle Altersgruppen mit dem Design abzuholen. Wir konnten diesen Stil auf alle Gegenstände, Orte und das User Interface übertragen und finden, dass wir einen sehr wiedererkennbaren, beständigen Spielcharakter geschaffen haben.

casey2

Bild 1.5            Entwürfe für den Hauptcharakter „Casey“. Am Ende entschieden sich die Entwickler für den Casey rechts unten. (Grafiken: Llopis & Friginal)

  • Die soziale Komponente

Etwas selbst zu erschaffen macht Spaß. Aber noch mehr Spaß macht es, etwas selbst zu erschaffen und es dann mit anderen zu teilen. Wie schon erwähnt, wollten wir Casey’s Contraptions zu einer sehr sozialen Spielerfahrung machen. Kein Spiel, das man alleine durchspielt und dann weglegt, sondern etwas, bei dem man seine Erfolge mit Freunden teilen kann.

Da Casey’s Contraptions ja eine vollwertige Physik-Simulation beinhaltet, kann man teilweise mit sehr verrückten, chaotischen und meistens ziemlich unerwarteten Lösungen zum Ziel kommen. Wochen nach dem Launch waren wir immer noch erstaunt darüber, mit welcher Kreativität die Menschen gewisse Levels lösten und wie viele Kombinationen von Gegenständen sie schufen, an die wir bei der Entwicklung nie gedacht hätten. Es ist sehr lustig, diese Apparaturen in Aktion zu sehen, und darum sind sie perfekt geeignet, um sie mit Freunden zu teilen.

Mit diesem Gedanken im Kopf haben wir das Spiel ja von Anfang an entwickelt. Nach jedem Level kann man seine Lösung mit einem simplen Knopfdruck seinen Freunden zeigen (Bild 1.6). Inzwischen ist das Spiel im Default-Modus so eingestellt, dass man automatisch seine Lösung teilt, wenn man seine Punktzahl verbessert hat. Hat man ein Level beendet, sieht man auch die Lösungen seiner Freunde als kleine Vorschau und kann sie auf Wunsch immer und immer wieder abspielen.

Zusätzlich dazu haben wir auch einen Level-Editor eingebaut, mit dem man seine eigenen Puzzles frei erstellen kann. Es war genau dasselbe Programm, das auch wir benutzt haben, um die Levels zu erfinden. Man muss eben die eigene Suppe löffeln, wenn man dem Nutzer etwas wirklich Genießbares servieren will. Ursprünglich konnten die Spieler ihre Levels per E-Mail mit anderen teilen und jetzt, nach dem ersten Update, auch über eine öffentliche Website. So entstanden Hunderte neue Levels für alle Nutzer.

Wie es bei Spielen mit Level-Editors üblich ist, machen natürlich nur wenige der Nutzer wirklich davon Gebrauch. Doch diejenigen, die es doch tun, sind sehr schnell sehr verbunden mit dem Spiel und sehen es als Ehrensache an, es auch bei ihren Freunden zu verbreiten.

casey3

Bild 1.6            Präsentation der sozialen Funktionen des Spiels. (Grafik: Llopis & Friginal)

  • Schrittweise Entwicklung

Für Casey’s Contraptions haben wir ein sehr entspanntes und reduziertes Projektmanagement angewandt. Wir hatten kleine Schritte geplant, und in jeder Schleife haben wir uns nur vorgenommen, die jeweils wichtigsten Funktionen zum Laufen zu bringen. Wir hatten kein richtiges Aufgabenmanagement oder einen rigiden Zeitplan (abgesehen von: „Hm, das könnten wir in zwei Wochen schaffen“) und haben uns für die einzelnen Meilensteine keine strengen Limits gesetzt. Sie variierten in etwa von eineinhalb bis drei Wochen. Das Wichtigste war wohl, dass wir bei jedem Meilenstein innehielten und uns ein konkretes neues Ziel setzten – mit all dem Wissen, das uns bis zu diesem Punkt geführt hatte.

Zum Beispiel haben wir die Entwicklung gar nicht mit einer vollen Übersicht über all die Gegenstände gestartet, die wir am Ende im Spiel haben wollten. Stattdessen hatten wir in unserem Wiki eine Liste von Dingen, die wir möglicherweise einbauen könnten. Immer, wenn uns etwas Neues einfiel, ergänzten wir sie. Erst mit jeder neuen Entwicklungs-Schleife entschieden wir uns für die neuen Gegenstände, die das Spiel noch ergänzen sollten. Dank dieser langsamen Evolution konnten wir gute Entscheidungen für neue Spielinhalte fällen: „Die meisten Dinge, die wir derzeit haben, fallen zu Boden. Wir brauchen mehr aufsteigende Sachen.“ Oder: „Der Magnet ist lustig, aber wir brauchen noch mehr Metallgegenstände, wenn er nützlich sein soll.“

Diese Mentalität kam überall zum Tragen: Von der Level-Erstellung bis zu den Menüs, Funktionen und so weiter. Rückblickend können wir von so ziemlich jeder späteren Entscheidung sagen, dass wir sie so wohl zu Beginn des Projekts nicht gefällt hätten.

  • Ein starker Launch

In weniger als 24 Stunden nach dem Launch hatte sich Casey’s Contraptions schon in die Top zehn der bezahlten Apps in den USA und in 20 anderen Ländern vorgearbeitet. Am nächsten Tag lag es auf Platz zwei aller Apps in den USA und brachte großartige Verkaufszahlen am ersten Wochenende.

Dieser starke Start war nicht nur Schicksal. Wir haben den Launch monatelang geplant, und hart geschuftet, um einen so erfolgreichen Start zu schaffen (natürlich gehört auch immer eine Portion Glück dazu). Wir hatten natürlich einen Buzz, um das Spiel kreieren zu wollen, doch der knappe Entwicklungs-Zeitraum bei iOS-Spielen bedeutet, dass man das in verhältnismäßig kurzer Zeit vorbereiten muss.

Wir fingen mehr als sechs Monate vor dem Launch an, das Spiel bekannt zu machen (da standen wir etwa bei einem Viertel der Entwicklungsarbeit). Während der folgenden Monate kommunizierten wir über Twitter und unseren Blog und zeigten die verschiedenen Stadien der Entwicklungsarbeit. Ein wichtiger Meilenstein war für uns, das Spiel bei der Game Developers Conference herumzuzeigen. Nicht nur haben so viele Entwickler unser Spiel ausprobiert und uns unschätzbar wertvolles Feedback gegeben; wir kamen so auch mit der Presse in Kontakt, was uns zu einigen netten Previews verhalf.

  • Apple gab den großen Anstoß

Der große Streich kam jedoch, als wir das Spiel bei Apple einreichten. Wir hatten uns ein fixes Datum für den Start gesetzt: drei Wochen nach der Einreichung. Das würde uns genug Zeit geben, um die ganze PR-Arbeit vorzubereiten: Video drehen, Medienpakete zusammenstellen, Journalisten kontaktieren und so weiter. Auch intensivierten wir die Frequenz auf unserem Blog und zeigten mehr spannende Aspekte unseres Spiels her.

Nachdem wir das alles gemacht hatten, bekam Casey’s Contraptions glücklicherweise besondere Aufmerksamkeit von Apple. Sie präsentierten es zu Beginn sehr prominent als iPad Game der Woche – weltweit. Wir hatten die Presse rechtzeitig mit allem Material versorgt, sodass gleichzeitig auch einige positive Rezensionen erschienen und sich die Kunde von unserem Spiel sehr schnell verbreitete.

casey4

Bild 1.7            Casey’s Contraptions auf dem Ehrenplatz im iTunes App Store. (Screenshot: Llopis & Friginal)

  • Platzierung in den Ranglisten

Obwohl wir ursprünglich 4,99 Dollar für das Spiel verlangen wollten, zielten wir jetzt auf maximale Verkäufe ab und setzten den Preis auf 2,99 Dollar fest. Das erwies sich als richtig, denn es führte uns direkt in die Top Ten. Die Plätze in den Ranglisten haben eine sehr scharfe, exponentielle Kurve von Verkäufen im Hintergrund. Das heißt, ein Platz fünf bedeutet einen großen Anstieg in den Verkäufen gegenüber einer niedrigeren Platzierung.

Wenn man sich den App Store heute ansieht, wird es immer schwieriger für kleine Spiele, sich wirklich an die Spitze der Ranglisten hochzuarbeiten. Mit über einer halben Million verschiedener iOS-Apps und Hunderten Spielen, die täglich veröffentlicht werden, muss man wirklich aus der Masse herausstechen, um bemerkt zu werden. Die meisten der Spiele, die das schaffen, wurden mit erheblichem Zeitaufwand, viel Energie und Know-how produziert. Der App-Store-Goldrausch ist vorbei.

  • Genug Entwicklungszeit

Vom Beginn bis zum Launch dauerte die Entwicklung von Casey’s Contraptions etwa acht Monate. Das scheint eine lange Zeit zu sein, gerade für iOS-Verhältnisse. Aber es sieht so aus, als würden mehr und mehr iOS-Spiele so viel Zeit beanspruchen.

Unser ursprünglicher Plan war, das Spiel zu Weihnachten auszuliefern. Das war nicht unbedingt das Ergebnis rigoroser Zeitkalkulation, sondern einfach nur eine Schätzung. Es fühlte sich so an, als könnten wir es bis dahin schaffen. Natürlich lagen wir da falsch.

Dass wir uns so viel Zeit genommen haben, ist aus meiner Sicht sehr positiv. Denn wir haben nicht wirklich Zeit verschwendet, es dauerte eben so lange, um das Spiel reifen zu lassen und dahin zu führen, wo es heute ist. Hätten wir es früher ausgeliefert, wäre das Endprodukt ein ganz anderes gewesen.

  • Noch mal drüber nachdenken

Die schwierigste Aufgabe bei der Entwicklung von Casey’s Contraptions war für uns, interessante Levels zu gestalten. Da wir den Level Editor von Beginn an in Gebrauch hatten, konnten wir die Levels im Laufe der Zeit gestalten. Gerade einige der frühen Levels waren im Nachhinein gesehen viel zu schwer und nicht wirklich interessant. Erst nach einigen Monaten fanden wir das richtige Maß und wussten, was gute Levels mit dem richtigen Schwierigkeitsgrad waren.

Auch war es gut, dass wir so viel Zeit hatten, um fundamentale Änderungen am Design vorzunehmen, wenn etwas noch nicht so funktionierte, wie es sollte. Zum Beispiel sollte jedes Level ursprünglich drei verschiedene Ziele beinhalten, die man erreichen musste. Je nachdem, wie viele dieser Ziele man erreicht hatte, sollte man eine Bronze-, Silber- oder Goldmedaille bekommen. Es wurde uns schnell klar, dass die drei verschiedenen Ziele die Spieler nur verwirrten. Wir haben die Levels also auf nur ein Ziel reduziert. Da wir aber trotzdem das erneute Spielen spannend machen wollten, sollten die Spieler Sterne verdienen können, indem sie sie mit den verwendeten Gegenständen berührten. Der erste Stern sollte natürlich einfach zu haben sein, der zweite schon schwerer, und der dritte sollte schon einiges an Knobelarbeit erfordern.

Das war schon eine gute Alternative zu den Medaillen, aber wir fanden schnell heraus, dass die Sterne noch nicht perfekt waren. Denn die meisten Spieler würden erwarten, dass sie alle Sterne beim ersten Durchspielen erreichen sollten, und so lange denselben Level spielen, bis sie irgendwann frustriert aufgeben würden. Das brachte uns dazu, die Sterne wieder zu überarbeiten. Dieses Mal knüpften wir die Schwierigkeit, mit der die Sterne zu erreichen waren, an die Schwierigkeit des Levels. Mit dieser Lösung waren wir am Ende sehr glücklich. Wir hätten sie nicht gefunden, wenn wir durch das Projekt hätten hetzen müssen.

  • Das letzte Finish

Wir gaben uns am Ende auch noch genügend Zeit, um das Spiel noch einmal zu polieren. Dieser letzte Glanz macht natürlich das Spiel an sich nicht mehr besser, aber er trägt sehr viel zum ersten Eindruck bei, den es vermittelt. Jede Animation, jedes Geräusch, jeder kleine Effekt ist wirklich wichtig in diesen ersten Sekunden, die ein Nutzer mit dem Spiel verbringt. Auf einer mobilen Plattform wird diese letzte Politur umso wichtiger. Wenn es den Nutzer nicht sofort packen kann, verliert dein Spiel dessen Aufmerksamkeit, und er wendet sich anderen Dingen zu.

Was schiefging

  • Kein gleichzeitiger Launch für das iPhone

Der ursprüngliche Prototyp von Casey’s Contraptions lief auf dem iPhone. Während er schon sehr viel Potenzial zeigte und es anfangs auch noch lustig war, die Apparaturen zusammenzustellen, merkte man schnell, dass es eigentlich mehr Platz brauchte.

Daher war das iPad natürlich die naheliegende Plattform für das Spiel. Sein großer Bildschirm zeigt wunderbar auch sehr detaillierte Grafiken an und erlaubt dem Spieler sehr intuitiv eine händische Einrichtung der verschiedenen Gegenstände. Es war perfekt für Casey’s Contraptions.

Trotzdem, auch wenn das iPad mit damals 14 Millionen Geräten schon sehr verbreitet war, waren die Nutzer von iPhone und iPod Touch natürlich immer noch die unbestrittenen Könige des iTunes App Stores (zu diesem Zeitpunkt ungefähr 185 Millionen Geräte). Gerade ein Spiel, das eine starke soziale Komponente hat, muss eine kritische Masse an Spielern erreichen, die zur selben Zeit spielen, Lösungen teilen und Levels erstellen. Wir hatten zwar die iPad-Charts gestürmt, aber das ließ die meisten iOS-Anwender immer noch außen vor, da sie das Spiel nicht für ihre Geräte kaufen konnten.

Warum haben wir nicht mit dem Launch gewartet, bis die iPhone-Version fertig war? Wir hatten keinen wirklich guten Grund dafür, außer, dass wir das Spiel endlich veröffentlichen wollten. Wir wussten auch nicht, wie stark sich ein guter Launch auf unsere Server auswirken würde, und dachten daher, ein vorgezogener iPad-Launch wäre ein guter Plan. Inzwischen würden wir wohl eher beide Versionen zur selben Zeit oder zumindest in etwa im selben Zeitraum veröffentlichen (vielleicht ein oder zwei Wochen verzögert).

  • Ein neuer Buzz

Um das auszugleichen, wollen wir den iPhone-Start zu einer Art zweitem Launch machen: Die iPhone-Version wird mit einigen Updates einhergehen, die sehr viel neue Inhalte bringen (gratis für alle, die das Spiel bereits gekauft haben), und wir werden versuchen, den starken iPad-Launch zu wiederholen. Der Hintergedanke ist, dass wir alle, die das Spiel bereits gespielt haben, noch einmal locken wollen, damit wir, zusammen mit allen iPhone-Spielern, die kritische Masse erreichen.

  • Wir sind zu oft aneinandergeraten

Wir sind eigentlich ein perfektes Zwei-Mann-Unternehmen: Wir haben komplementäre Fähigkeiten, aber auch überlappende Talente. Wir gehen die Dinge auch oft von zwei verschiedenen Seiten an: Ästhetik versus Usability, Schnelligkeit versus Spieleigenschaften, Einfachheit versus Spannung, Außergewöhnlichkeit versus Gewohnheit, Tee versus Kaffee. Das ist eigentlich eine sehr gute Sache, und der Erfolg von Casey’s Contraptions beruht zu einem großen Teil auf der Kombination dieser verschiedenen Eigenschaften und Talente.

Doch manchmal ist die Gegenseitigkeit auch zu viel des Guten. Wir sind beide sehr stur, und wir brauchen sehr lange, bis wir uns durchringen können, die Dinge anders zu sehen. Es gab Zeiten, da haben wir mehr Stunden damit verbracht, eine Sache zu diskutieren, als sie am Ende umzusetzen.

Dass wir nicht persönlich zusammenarbeiteten, sondern über größere Entfernung, hat die tägliche Entwicklungsarbeit nicht wirklich beeinflusst. Doch es war dadurch schwieriger, manche dieser Diskussionen zu beenden. Stattdessen führten wir sie viel länger als nötig. Es war auch das erste Mal, dass wir an einem so großen Projekt zusammenarbeiteten, was die Sache nicht einfacher machte. Nachdem wir dieses erste Projekt durchgezogen haben, werden wir in Zukunft für diese Problematik hoffentlich besser gerüstet sein.

  • Unnötige Überarbeitungen

Überarbeitungen sind ein notwendiger Teil jedes kreativen Prozesses. Es ist sehr unwahrscheinlich, dass man gleich alles im ersten Entwurf eines Texts oder einer Musikkomposition richtig macht. Das gilt sogar noch mehr für Spiele-Entwicklung, weil dabei so viele Teile zusammenpassen müssen. Es ist sehr schwer, das Endprodukt vorherzusehen; doch auch wenn man das könnte, würde man gar nicht wissen, was man will, bis man weitere Versionen gesehen hat.

Fast jeder einzelne Screen und jeder Gegenstand des Spiels wurde mehrmals überarbeitet – in Hinblick auf Optik, Verhalten, Klang oder Platzierung. Keine Frage, dass jede Überarbeitung sie verbessert hat. Allerdings gab es ein paar Teile des Spiels, die wir eindeutig zu oft überarbeitet haben. Vor allem manche der User Interfaces, wie zum Beispiel der inzwischen legendäre „level completed“-Screen, oder auch der Look und das Arrangement des Menüs, das wir bestimmt sechs oder sieben Mal komplett überarbeitet haben.

Wir glauben, dass Design nicht einfach nur in eine Richtung arbeitet. Wenn man das beste Endprodukt erreichen will, kann man nicht nur über die Funktionalität eines Interface entscheiden (oder irgendeines anderen Teils des Spiels) und dann ein paar nette Grafiken darüberlegen. Die Programmierung und das Design müssen ineinandergreifen, um die Funktionalität des User Interface zu garantieren. Wenn man diese Dinge einige Male durchdacht hat, kann man sich auf sehr starkes Design einigen, das nicht nur funktionell ist, sondern auch optisch etwas hermacht.

Problematisch ist es, wenn man diese Schleifen zu oft durchmacht oder wenn der Prozess sich nicht zu einem spezifischen Design verdichtet, sondern eher zu einem Slalom verschiedener Versionen führt. Das passierte uns sehr oft, da wir uns meist an kleinen Details aufrieben, oder einfach gewisse Funktionen vergaßen, die wir eigentlich in das neue Design hatten einbauen wollen.

  • Nutzerfeedback ist wertvoll

Andererseits bekamen wir oft Feedback von Testpersonen, die uns vermittelten, dass ein Screen noch nicht klar genug war. Dann mussten wir ihn noch einmal überarbeiten, trotz der Verlockung, einfach weiterzumachen und ihn für gut zu erklären. Es war immer die richtige Entscheidung, sich noch einmal hinzusetzen und diese Punkte zu überdenken.

Zum Beispiel taucht Casey zu Beginn jeden Levels auf und erklärt, welches Ziel diesmal erreicht werden muss. Dieser Screen erscheint eigentlich sehr klar und verständlich, nur dass in unserer frühen Version die Sicht auf das Level geblockt wurde, während der Screen gezeigt wurde. Die Testpersonen beschwerten sich, dass man sich nur schwer merken konnte, welche Gegenstände dargestellt wurden. Daher wird in der finalen Version Caseys Dialog am unteren Rand angezeigt, und die relevanten Gegenstände werden sogar umrandet.

Solche Probleme kann man lindern, indem man gewisse Teile des User-Interface oder des Spiels in kleinere Schritte aufteilt, ohne jeden davon sofort zu vollenden. Statt sofort den Screen einzubauen oder das perfekte Mock-Up mit allen grafischen Elementen zu gestalten, muss man zuerst einen Screen aufsetzen, der mit simplen Boxen und Buttons versehen ist und die Grundfunktionen besitzt. Erst dann kann man diesen Entwurf absegnen, mit echtem Layout und grafischen Elementen versehen, einige neue Funktionen und damit verbundene Animationen einbauen – und das Ganze so lange in Schleifen überprüfen, bis es stimmt. Wir wurden darin im letzten Drittel der Entwicklungsarbeit immer besser, und es ist eine Arbeitsweise, die wir in künftigen Projekten forcieren wollen.

  • Nicht genug Unit Testing

Ich bin ein großer Fan von Modultests und Testgetriebener Entwicklung (TDD). Diese Techniken haben wir in bisherigen Projekten erfolgreich benutzt und wollten sie auch bei Casey’s Contraptions weiterführen.

Das Ziel war natürlich nie eine hundertprozentige Abdeckung mit Modultests oder dass jede Zeile Code erst getestet werden sollte. Stattdessen sollte Code getestet werden, auf dem ein großer Teil des restlichen Codes (zum Beispiel das Management der Gegenstände), andere komplizierte Elemente (die Interaktion der Werkzeuge) oder schwierige Patienten beruhten (Seil-Manipulation).

Am Ende schummelten wir und machten nicht so viele Tests, wie wir geplant hatten. Manche Dinge, wie zum Beispiel die Object-Attachments, bereiteten mir Kopfzerbrechen wegen all des komplizierten, ungetesteten Codes. Als wir merkten, dass wir doch mehr Tests durchführen sollten, war es dafür teilweise schon zu spät, weil der Code auf Schnittstellen beruhte, die nicht sehr modultest-tauglich waren.

  • Teste lieber jetzt, statt später Fehler zu beheben

Wir hätten uns die Zeit nehmen sollen, als diese Probleme erstmals auftauchten, Tests schreiben und langsam den Code überarbeiten, während wir Bugs entfernten und neue Funktionen einbauten. Stattdessen fühlten wir uns ständig „nur ein paar Monate vom Launch entfernt“, verzichteten auf Tests und zahlten dafür später einen hohen Preis. Wir lieferten Casey’s Contraptions sogar mit ein paar unwahrscheinlichen Spiel-Situationen aus, von denen wir wussten, dass sie Fehler produzieren könnten, aber wir trauten uns nicht mehr, sie so kurz vor der Veröffentlichung noch anzufassen.

Wir arbeiten bereits an den Updates und an der iPhone-Version, also werden wir uns noch lange mit diesem Code herumschlagen müssen. Wir werden diesmal langsam in allen Bereichen Modultests einführen, wo es nötig ist.

  • Statische Preisstrategie

Die Preisstrategie haben wir schon während der Entwicklung ständig wieder diskutiert. Trotz des langfristigen Erfolgs von Flower Garden und anderen Gratis-Spielen, die auf In-App-Purchases basieren, entschieden wir uns für ein fixes Preismodell bei Casey’s Contraptions.

Wir dachten, dass unsere Zielgruppe einen festen Preis mehr schätzen würde als die vielen kleinen Beträge, die innerhalb der App anfallen würden. Außerdem dachten wir, dass es ja für andere iPad-Spiele wie Angry Birds oder Cut The Rope gut funktioniert hatte. Es erschien uns sicher, diesen Beispielen einfach zu folgen.

Unglücklicherweise war das womöglich die falsche Entscheidung – ökonomisch betrachtet. Nach einem starken Launch verlor Casey’s Contraptions innerhalb ein paar Wochen schnell seine gute Position in den Ranglisten. Nachdem die Umsätze einer scharfen exponentiellen Kurve folgen, bedeutet selbst eine Platzierung unter den besten hundert iPad-Spielen nur wenige Einnahmen pro Tag. Was zu einem sehr dünnen Ende der Sales-Kurve führt.

  • In-App-Purchases müssen gut organisiert sein

Spiele mit In-App-Purchases sind nicht nur in traditionellen Spieler-Kreisen nicht sehr angesehen, sondern es ist auch noch sehr viel schwerer, diese zu entwickeln. Nicht nur, dass man sehr robuste Server braucht, auch muss man die spieleigene Ökonomie gut ausbalancieren, Belohnungen richtig verteilen und die Kosten für neue Käufe gut überlegen. Unsere optimistische Schätzung war damals, dass dieses Modell uns mindestens einen zusätzlichen Monat kosten würde (also vermutlich eher zwei Monate, wenn man unsere bisherigen Zeitpläne auswertet).

Eine andere Möglichkeit wäre gewesen, ein traditionell bepreistes Spiel anzubieten, aber neue Levels oder Orte gegen Bezahlung anzubieten. Das wäre viel einfacher einzubauen, würde aber vielleicht keinen großen Unterschied für den Umsatz machen. Normalerweise kaufen nur zwischen zwei und fünf Prozent der Spieler Extra-Inhalte. Damit diese In-App-Purchases sich also signifikant niederschlagen, müssen sie unlimitiert sein (Dünger, Spielgeld usw.) oder eine sehr große Nutzerbasis muss sie nachfragen. Mit einer sehr kleinen Zahl an möglichen Gegenständen, die man kaufen kann, bräuchten wir also sehr viele Spieler, damit In-App-Purchases die Umsätze in die Höhe schnellen lassen würden.

Wir hoffen natürlich, dass die iPhone-Version dem Spiel insgesamt wieder Auftrieb geben, die Verkäufe auf beiden Plattformen steigern und hoffentlich zu einem langfristig guten Ranglistenplatz führen wird. Falls das nicht passiert, können wir immer noch mit der Preisstrategie experimentieren.

casey5

Bild 1.8

  • Eine Zwischenbilanz

Wir sind sehr glücklich mit der gesamten Entwicklung von Casey’s Contraptions und vor allem mit dem Launch. Wir haben es geschafft, ein besonderes, kreatives Spiel zu veröffentlichen, das sehr gute Kritiken bekommen hat und sich auch sehr gut verkauft hat.

Während Sie das lesen, ist das Update schon länger erhältlich. Jetzt sollten mehr und mehr Menschen bereits ihre Lösungen und Levels mit anderen geteilt haben, was hoffentlich wieder mehr Aufmerksamkeit für unser Spiel gebracht hat. Auch können inzwischen mehrere Spieler – zum Beispiel Eltern mit ihren Kindern – zusammen an Puzzles arbeiten; der Multiplayer-Modus wurde sehr stark nachgefragt.

Ganz im Gegensatz zum traditionellen Spielehandel ist die Geschichte für uns iOS-Entwickler hier aber noch lange nicht zu Ende. Was wir in der nächsten Zeit alles richtig oder falsch machen werden, wird den Erfolg unseres Spiels in Zukunft ausmachen.

Fakten, Fakten, Fakten

Website: http://www.caseyscontraptions.com

Release: 19. Mai 2011 (iPad)

Entwicklungszeit: 8 Monate

Unternehmensgröße: 2 Personen (Vollzeit)

Entwicklungskosten: Lebenshaltungskosten für zwei Personen über acht Monate plus etwas über 1000 Dollar

Open source code: Box2d, UnitTest++

Vor allem genutzte Werkzeuge: Xcode, svn, Versions, Trac, TexturePacker, Adobe Illustrator, Audacity

Zeilen Code: 46.518

Größe der Rohdaten: 510 MB

App Größe: 12,2 MB

Überarbeitungen: 2442

Trac Tickets bearbeitet: 683

Gallonen gekochter Tee: 77 (also 291,5 Liter)

Konsumierte Portionen Espresso: etwa 1500

 

Ich hoffe, dass Ihnen diese Geschichte einer App gefallen hat und dass Sie nun ganz gespannt darauf sind, auch für Ihre App die besten Strategien und die kreativsten Lösungen zu finden.

Mein Dank gilt den beiden Entwicklern Noel Llopis und Miguel Ángel Friginal für ihre Offenheit. Diese Geschichte wurde erstmals auf www.gamasutra.com veröffentlicht und für dieses Buch von Rebecca Sandbichler übersetzt.