Joe Cassavaugh stellt in einem von InfoQ veröffentlichten Vortrag seine Entwicklung vom Softwareentwickler zum Betreiber eines Einzelprojekts rund um die Rätselspielreihe Clutter vor. Cassavaugh zufolge überstiegen die Verkäufe der Reihe 6 Millionen US-Dollar, während er selbst mehr als 2 Millionen US-Dollar netto erzielte. Außerdem bereitete er die Veröffentlichung des neunzehnten Spiels innerhalb des Franchises vor. Der Wert dieser Erfahrung liegt jedoch nicht allein in den Zahlen, sondern auch in den Methoden, mit denen er ein einzelnes Produkt in ein über Jahre tragfähiges Geschäft verwandelte.
Die Geschichte begann, nachdem das Unternehmen iWin die Entwicklung eines Spiels eingestellt hatte, an dem er arbeitete. Seine spätere Partnerin schlug ihm vor, das Spiel selbst zu entwickeln. Daraufhin erstellte er innerhalb eines Wochenendes einen Prototypen, der auf der Idee beruhte, ähnliche Gegenstände einander zuzuordnen. Er erhielt von iWin die Rechte am geistigen Eigentum, verbunden mit einer Vereinbarung, die dem Unternehmen zwei Jahre lang das Erstverweigerungsrecht für die Veröffentlichung jedes neuen Spiels einräumte. Anschließend veröffentlichte er 2011 das erste Clutter-Spiel.
Das erste Spiel erfüllte seine Erwartungen nicht. Nach 15 Monaten erzielte es Einnahmen von etwa 50.000 US-Dollar statt eines von ihm erwarteten von zwei Szenarien: weniger als 10.000 US-Dollar oder mehr als 100.000 US-Dollar. Dennoch nutzte er die vorhandene Engine und die bestehenden Werkzeuge, um den zweiten Teil in etwa sechs Monaten Entwicklungszeit zu erstellen. Der zweite Teil erzielte etwa 50.000 US-Dollar und trug außerdem dazu bei, die kumulierten Einnahmen des ersten Spiels zu steigern. An diesem Punkt begann Cassavaugh, die Reihe als einen wachsenden Vermögenswert und nicht als eine Sammlung separater Produkte zu betrachten.
Was hat sich tatsächlich verändert?
Cassavaugh bezeichnete diesen Effekt als „Franchise-Effekt“. Jede neue Veröffentlichung zieht zunächst eigene Einnahmen an, belebt aber zugleich die Verkäufe der vorherigen Spiele neu. Er erklärt, dass die Veröffentlichungen nicht immer dieselben Ergebnisse erzielen, dass die Veröffentlichung eines neuen Spiels die Reihe jedoch im Blickfeld ihrer Zielgruppe hält. Dies half ihm, mit dem schrumpfenden Markt für herunterladbare Computerspiele Schritt zu halten.
Die Erfahrung zeigt auch die Grenzen einer Anpassung an die Vorlieben des Publikums. Als der vierte Teil vom grundlegenden Clutter-Spielstil abwich und Minispiele hinzufügte, nahmen die Spieler die Änderung nicht wie erwartet an. Andere Teile erzielten dagegen bessere Ergebnisse, weil sie Variationen innerhalb der bekannten Mechanik boten, statt diese zu ersetzen. Cassavaugh verwendete außerdem Geschichten, Bilder und Zitate, um den Rätseln eine eigene Persönlichkeit zu verleihen, und begann anschließend, direkt um Rückmeldungen der Spieler zu bitten.
Warum ist diese Nachricht für Entwickler relevant?
Die wichtigste technische Erkenntnis des Vortrags ist, dass die Geschwindigkeit nicht durch längere Arbeitszeiten entstand, sondern durch die Verringerung wiederkehrender Arbeit. Nachdem Cassavaugh ein bei iWin entwickeltes internes Framework verwendet hatte, wechselte er schrittweise zu Unity. Er schätzt, dass seine Produktivität im Vergleich zu seiner früheren Umgebung um das Vier- bis Sechsfache stieg. Gleichzeitig erklärt er, dass Unity auch den Umfang dessen erweiterte, was er leisten konnte. Daher führte nicht jede Steigerung der Fähigkeiten unmittelbar zu einer Verkürzung der Entwicklungszeit.
Danach setzte er auf kontinuierliche Umstrukturierung. Er erstellte eine Basisklasse für Minispiele, die gemeinsame Elemente wie die Menüleiste, den Wechsel zwischen Spielen, den Timer und Fenster übernimmt. Dadurch kann er ein neues Spiel hinzufügen, ohne diese Funktionen jedes Mal neu zu erstellen. Außerdem verlagerte er mehr Arbeit in Inhaltsdateien und automatisierte Werkzeuge, anstatt für jedes Rätsel neuen Code zu schreiben.
Cassavaugh nennt ein kleines, aber aussagekräftiges Beispiel: Die Änderung der Methode zur Speicherung von Rätselkonfigurationen durch die Verwendung mehrerer Schlüssel-Wert-Paare in derselben Zeile verkürzte eine zuvor manuell wiederholte Arbeit. Auch die Erstellung von Bildersammlungen automatisierte er mit Werkzeugen wie Batch und PaintShop Pro, nachdem deren Vorbereitung zuvor etwa drei Tage wiederkehrender Arbeit beansprucht hatte.
Die Balance zwischen Umfang und Herstellbarkeit
Jedes Spiel umfasst seiner Beschreibung zufolge scheinbar etwa 1.800 Rätsel. Praktisch liegt die Zahl jedoch näher bei 900 oder 1.000 Rätseln, da große Teile auf der erneuten Zusammenstellung von Inhalten sowie auf der Änderung von Bildersammlungen und Regeln beruhen. In jeder Veröffentlichung bietet die Reihe etwa 200 Rätsel, die auf Zitaten oder Absätzen basieren. Diese Trennung zwischen Code und Inhalt ermöglichte es ihm, den Umfang des Spiels zu vergrößern, ohne das Softwaresystem im gleichen Maß ausweiten zu müssen.
Außerdem gab er den Spielern Optionen für die Spielweise, etwa das Anhalten des Timers oder das Anpassen der Rotationsgeschwindigkeit der Elemente, während die grundlegenden Rätselregeln erhalten blieben. Er weist darauf hin, dass ungefähr die Hälfte seiner Spieler den Timer nicht verwendet. Das veranlasste ihn, das Erlebnis so zu gestalten, dass es sowohl für Menschen geeignet ist, die eine Herausforderung suchen, als auch für diejenigen, die in Ruhe spielen möchten.
Die redaktionelle Einordnung von certi.news
Was sich im Fall von Clutter tatsächlich verändert hat, ist der Übergang von einem einzelnen Spiel zu einem kleinen Produktionssystem, das von Wiederverwendung, einer wachsenden Menge an Inhalten und einer fortdauernden Beziehung zum Publikum getragen wird. Dies ist kein garantiertes Rezept für den Aufbau eines Einzelprojekts. Die von Cassavaugh dargestellten Zahlen beziehen sich auf seine Erfahrung und seinen Markt. Außerdem beruhte sein Erfolg auf jahrelanger Kontinuität und auf einem Publikum, das zu neuen Veröffentlichungen zurückkehrte.
Die am ehesten auf andere Entwickler übertragbare Lehre besteht darin, festzulegen, was unverändert bleiben muss und was verändert werden kann: eine klare Spielregel, eine gemeinsame technische Struktur und sich erneuernde Inhalte. Offen bleibt, inwieweit dieses Modell in anderen Märkten wiederholbar ist und welche Risiken daraus entstehen, dass das Projekt von einer einzelnen Person und von einem einzigen Franchise abhängt. Daher sollte der Vortrag als Praxisbeispiel für Umfangs- und Produktionsmanagement gelesen werden, nicht als Beleg dafür, dass Einzelarbeit Entwicklungsteams generell überlegen ist.