clowdr.devIndie-Game-Postmortems: 7 Gründe, warum Projekte nach dem ersten Jahr sterben
Indie-Game-Postmortem-Analyse: 7 Gründe, warum Projekte nach dem ersten Jahr sterben - Scope, Burnout, Team-Kollaps - und der strukturelle Fix für jeden davon.
Es gibt tausend Artikel darüber, warum 90% der Indie-Games in der Ideenphase sterben. Fast niemand schreibt über den Friedhof, der sich zwischen Monat vierzehn und Monat achtundzwanzig öffnet. Da, wo tatsächlich fertige Spiele und tatsächlich gegründete Studios sterben.
Dieser Artikel geht über genau diesen Friedhof.
Wir haben über ein Dutzend öffentliche Postmortems durchgearbeitet, dazu den IGDA Developer Satisfaction Survey 2023, die Talks aus dem GDC Failure Workshop, die Abbruch-Berichte aus dem Game Developer Magazin und die lauteren Indie-Dev-YouTube-Kanäle, die über ihre eigenen Zusammenbrüche sprechen. Sieben Muster tauchten immer wieder auf. Keines davon ist "fehlender Wille". Sie sammeln sich an genau den Stellen, an denen ein zweiter Stuhl hätte stehen sollen.
"Es gibt so viele großartige Spiele und Kunstprojekte und schöne Dinge, die wir nie zu sehen bekommen, weil jemand dachte, Intensität sei die Antwort, dann intensiv gearbeitet hat, ausgebrannt ist und das Projekt nie wieder angefasst hat." Tim Ruswick
Du bist nicht faul. Du bist ohne Unterstützung. Die Postmortem-Akten machen diesen Satz greifbar.
Wenn du gerade auf dein eigenes Projekt schaust und denkst "irgendwas fängt an zu rutschen", stehen die Chancen gut, dass einer der nächsten sieben Gründe dahintersteckt. Jeder Abschnitt benennt die strukturelle Ursache, nicht den Charakterfehler, und benennt die Team-Entscheidung, die das Problem hätte auffangen können. Eine längere Version davon, wie einige dieser Muster ineinandergreifen, haben wir in der 90-90-Regel des Indie-Game-Devs geschrieben; genau in der Mitte dieser Liste fängt diese Regel an, zuzubeißen.
1. Der Scope ist über den Kalender hinausgewuchert
Die öffentliche Postmortem-Version: "wir hatten uns übernommen". Die gefühlte Version: jeden Monat wuchs das Design-Dokument ein bisschen, der Kalender nicht.
Tim Ruswick hat zehn Jahre gebraucht, um sein erstes Spiel fertigzustellen. Seine eigene Diagnose war nicht mangelndes Können. Sie war: "Ich habe ein Projekt angefangen, es aufgebaut, dabei so viel gelernt, dass ich dachte, oh mein Gott, das ist ein Riesen-Chaos, und dann habe ich wieder von vorne angefangen." Jedes Rewrite schleppte den Scope der letzten Runde mit, plus eine neue Runde "wenn wir schon dabei sind". Das Game Developer Magazin schreibt sinngemäß immer wieder vom Indie-Iceberg: "zu ambitionierter Scope ist ein klassisches Indie-Problem". Die Reddit-Version: "Ein 4-Jahres-Spiel ist absolut riesig und klingt nach überdehntem Scope."
Keiner dieser Leute war faul. Ruswick hat Stunden geliefert. Der Reddit-Poster arbeitete an einem Vier-Jahres-Spiel. Wer macht das ohne Commitment? Was ihnen fehlte, war jemand mit der Autorität, den Scope zu schließen.
Solo-Devs können ihren eigenen Scope nicht schließen. Die Version, die du baust, lebt in deinem Kopf, und der Drang zu polieren ist nicht zu unterscheiden vom Drang, es gut zu machen. Jedes "nur noch ein Feature"-Argument kommt von derselben Stimme, auf beiden Seiten.
Der Team-Entscheidungs-Fix ist ein benannter Scope-Owner, der nicht du bist. In einem kollaborativen Indie-Team ist das die Person mit der Erlaubnis zu sagen "Feature abgelehnt, wir sind über dem Cutoff". Für eine längere Analyse, warum dein Scope deinen Kalender auffrisst, siehe Scope Creep tötet dein Spiel.
2. Niemand hat den Kern getestet, bis es zu teuer war, ihn zu fixen
Das StarLicker-Team hat seinen Prototypen zu den IndieCade-Juroren gebracht. Das Feedback war ein sauberer Satz: "Ihr habt alles getroffen, außer dem Kern-Gameplay." Das Team hat es weitestgehend ignoriert. Nach dem Launch endeten 65% der Matches in Forfeits. Das eigene öffentliche Postmortem benennt Zeit- und Gelddruck als den Grund, warum der Kern nicht früher neu gebaut wurde.
Dryden, der Disinherited gemacht hat, hat fast ein ganzes Jahr an seinem Metroidvania gearbeitet, bevor er es irgendjemandem gezeigt hat. Der erste externe Playtest hat aufgedeckt, dass der Einstieg zu lang war, zu schwer und die Mechaniken nie richtig einführte. Das ist die Art Feedback, mit der du nur in Monat drei etwas anfangen kannst. In Monat elf sind die Rewrite-Kosten strukturell. In Monat zwanzig sind sie terminal.
Hier ist das Muster: Solo-Devs shippen selten mit kaputten Cores. Sie shippen mit unvalidierten Cores. Sie denken, sie polieren. Sie verstecken sich vor dem einen Test, der das Projekt gerettet hätte.
Der Team-Entscheidungs-Fix ist ein Vertical-Slice-Gate. Du erarbeitest dir das Recht, Content zu bauen, erst, wenn eine zweite Person den Core Loop gespielt und "ja, das verdient Skalierung" gesagt hat. Unsere vollständige Aufschlüsselung des Finishing-Problems, inklusive der Stelle im Zeitplan, an der das Vertical-Slice-Gate sitzt, findest du in dem kompletten Leitfaden, um dein Indie-Spiel fertigzustellen.
3. Das Team hat sich in Monat sechs leise aufgelöst
Es gibt keine Discord-Ankündigung. Eric Nevalas oft zitierte Zeile aus "Your Indie Game Dev Team Will Fail" trifft das Muster genau: "Irgendwann gewinnt das echte Leben häufiger, und der wöchentliche Stundenbeitrag ebbt ab... Viele Leute verlieren einfach das Interesse und verschwinden leise... Nach und nach verschwinden ein paar Mitglieder komplett, aus dem einen oder anderen Grund."
Das ist das häufigste Team-Kollaps-Muster im Indie-Bereich. Niemand kündigt wütend. Es gibt keinen Bruch. Eine Nachricht bleibt vier Tage unbeantwortet, dann sechs, dann zwei Wochen. Dein Producer geht davon aus, dass sie beschäftigt sind. Sie gehen davon aus, dass du beschäftigt bist. Zwei Monate später merkst du, dass du seit März nichts mehr von ihnen gehört hast.
Die Ursache ist strukturell, nicht charakterlich. Freiwilligen-Teams ohne verbindliche Contributor-Agreements zerfallen in einer vorhersagbaren Rate, so wie alles zerfällt, wenn die Kosten des Aussteigens null sind. Das Projekt wird zum Letzten, was irgendjemand umplant, wenn der Day Job laut wird.
Der Team-Entscheidungs-Fix ist ein strukturiertes Commitment: ein unterschriebenes Contributor-Agreement, das Deliverables benennt, plus eine wöchentliche Demo, auf die jemand wartet. Setze zumindest einen kleinen Preis aufs stille Verschwinden. Nevalas eigener Rat: "Geh davon aus, dass alle anderen im Team das Projekt irgendwann entweder aufgeben oder ghosten werden." Wenn das düster klingt, siehe wie du verlässliche Teammitglieder für dein Indie-Spiel findest für die Umkehrung. Filtern, bevor irgendjemand unterschreibt.
4. Der Jahr-eins-Burnout kam exakt nach Plan
IGDA Developer Satisfaction Survey 2023: 40% der Indie-Entwickler haben in dem Jahr Burnout gemeldet. 55% der Indie-Teams haben Crunch erlebt. Das sind keine Einzelfälle. Das ist der erwartete Zustand von Indie-Entwicklung.
Ruswick beschreibt den Mechanismus: "Je intensiver du arbeitest, je länger du intensiv arbeitest, desto stärker ist der Burnout am Ende, desto weniger Motivation spürst du, desto weniger willst du dein Projekt je wieder anschauen... es gab Monate in meinem Leben, in denen ich mich nicht mal an den Computer setzen wollte, so hart bin ich rangegangen."
Das Projekt stirbt nicht, weil du aufgibst. Es stirbt, weil dein Körper dich die Engine nicht mehr öffnen lässt.
"Ich stimme nicht unbedingt einer Kultur zu, die Leute glorifiziert, die sich in ihrer Freizeit zu Tode arbeiten, um ein Spiel zu machen, das viel zu ambitioniert ist." IndieGameClinic
Lies die wörtlichen Kommentare, und die Sprache wird dunkler. "Du kannst deine psychische Gesundheit später reparieren, quäl dich jetzt und zieh das durch, weil es krass gut aussieht" ist eine echte Reddit-Antwort. "Wenn du dich wegen eines Projekts selbst quälst, lass es einfach fallen. Du zerstörst dich mental, und du kannst diese Zeit einfach nicht verschwenden" ist, wie ein Entwickler den Abbruch eines drei Jahre alten Projekts angekündigt hat, und sagte, es sei der glücklichste Moment seit langem.
Der Team-Entscheidungs-Fix ist Lastverteilung: ein Teammitglied, das bemerkt, wenn du nicht mehr auftauchst, Sonntage, die du nicht verteidigen musst, und die Möglichkeit, den nächsten Sprint für eine Woche an jemand anderen abzugeben, ohne dass das Projekt stirbt. Solo-Devs können nichts davon allein. Genau das bedeutet "solo".
5. Der Pivot, den du kommen sehen hast, kam nie
Matt Gilgenbachs GDC-Postmortem zu Retro/Grade ist ungewöhnlich ehrlich dazu. Er beschreibt, wie er monatelang wusste, dass seine Zwangsstörung das Spiel immer größer machte, und wie er sich selbst nicht autorisieren konnte, den Scope zu schneiden, zu dem er sich verpflichtet hatte. Joe Mirabellos Failure-Workshop-Talk nach Tower of Guns deckt dasselbe Terrain ab: der Entwickler weiß, dass das Spiel nicht funktioniert, und kann sich nicht selbst aus der Richtung feuern, die er gewählt hat.
Das ist der "ein Jahr drin, wir hätten es töten sollen"-Eintrag in fast jedem Postmortem, das du liest. Das Wissen war da. Die Entscheidung nicht.
Solo-Devs können nicht zuverlässig allein pivotieren. Pivotieren braucht jemanden, der die Sunk Costs akzeptiert, die du gerade abschreibst. Wenn das Geld und der Kalender und der Ruf alle dir gehören, gehört das Argument gegen den Pivot auch dir. Jede Stimme im Raum bist du. "Wenn ich jetzt aufhöre, waren drei Jahre umsonst" ist der häufigste Reddit-Satz in dieser Kategorie, und kein Solo-Dev redet sich da je selbst heraus.
Der Team-Entscheidungs-Fix ist ein geplantes Kill-or-Continue-Review. Jedes Quartal (oder an jedem Meilenstein) stellt das Team eine Frage mit schriftlicher Antwort: "Würden wir dieses Projekt heute starten, mit dem, was wir jetzt wissen?" Wenn die Antwort Nein ist, hat das Team explizite Befugnis, Shutdown oder kompletten Rebuild zu empfehlen. Jemand außer dir muss sagen können "es ist okay, aufzuhören". Für den strukturellen Aufbau dieser Entscheidungs-Autorität siehe Solo-Dev vs. Team.
6. Der Launch war in die Leere
Jonathan Powells "How I Failed as an Indie Dev" geht nichts schön. Dreizehn Monate, zwanzigtausend Dollar aus eigener Tasche, ein poliertes erstes Indie. Bezahlter Release: Verkäufe auf null innerhalb von Tagen. Ein späterer kostenloser Release desselben Spiels: 12.000+ Downloads.
Das Spiel funktionierte. Das Publikum existierte nicht.
Jeder SERP-Konkurrent zu "warum Indie-Games scheitern" listet Marketing als Top-drei-Ursache. Fünf von fünf der am höchsten gerankten Seiten, die wir geprüft haben, listen es. Das gemeinsame Framing: "der Dev hat nicht genug Marketing gemacht". Das ist rückwärts. Eine einzige Person kann nicht gleichzeitig in sechs Monaten eine Audience aufbauen und ein poliertes Spiel shippen. Das sind zwei Jobs.
"Kein Marketing" ist ein Staffing-Problem, kein Disziplin-Problem.
Der Team-Entscheidungs-Fix ist ein Marketing-Contributor, der in Monat minus-sechs reingeholt wird, nicht in Monat plus-null. Jemand, der Community baut, ein Pressekontakt, eine Person, deren Job es ist, bis zur Release-Woche zweitausend Leute auf deine Steam-Wishlist geschrieben zu haben. Genau das bedeutet "früh reingeholt, nicht spät reingeholt" in Clowdrs Collaboration-Pillar. Dein Komponist, dein Artist und dein Marketer sind Dienstleister, wenn du sie bei 90% fertig reinholst. Sie sind Partner, wenn du sie bei 10% reinholst.
7. Die Post-Ship-Trauer hat das Studio leise geschlossen
Joe Mirabello hat Tower of Guns geshippt und sich trotzdem wie ein Versager gefühlt. Er hat einen Talk darüber gehalten. Die Gründer von Spry Fox haben, nachdem ihr Netflix-Deal endete, ihr eigenes Gehalt auf zwanzigtausend Dollar pro Jahr gekürzt, damit das Studio weiter existieren konnte. Die Abschieds-Notiz eines Indie-Devs: "Ich bin es leid, Spiele zu machen, also verlasse ich GameDev. Ich weiß nicht, wann ich wiederkomme. Und ist es das wert?"
Das Spiel zu shippen rettet das Studio nicht. Der Absturz nach dem Launch, kombiniert mit dem finanziellen Druck, den der Launch selten entlastet, schließt die Tür fürs nächste Projekt. Was Jahr zwei tötet, ist die Trauer von Jahr eins, nicht der Scope von Jahr eins.
Wie ein Game-Developer-Artikel es formuliert hat: ein einziger schlechter Release kann ein Indie in den Ruin treiben, weil zwei Jahre Arbeit ein paar hunderttausend Dollar an unbezahltem Lohn sind. Der Launch stellt diese Uhr nicht zurück. Er legt sie offen. Solo-Devs entdecken in Monat 25, dass sie wieder einen Job brauchen, und das nächste Projekt startet nie.
Der Team-Entscheidungs-Fix hier ist der schwerste, über den man ehrlich schreiben kann. Das Team muss den Launch überleben. Solo-Studios überleben selten einen. Zwei-Personen-Studios überleben manchmal zwei. Teams machen bessere Spiele (tun sie), aber das Wichtigere, was sie tun, ist, die Trauer des Shippens so zu verteilen, dass keine Einzelperson sie alleine trägt.
Wenn du das hier liest und denkst "Jahr eins ist die Klippe", widerspricht die Postmortem-Akte sanft. Jahr eins ist eigentlich Jahr null für das nächste Spiel. Für das, was das am Anfang bedeutet, siehe warum 90% der Indie-Games in der Ideenphase sterben.
Welche der sieben kriecht schon in dein zweites Jahr?
Sieben Muster. Sechs davon haben einen Team-Entscheidungs-Fix, den der Solo-Dev nicht allein ausführen kann. Das siebte, die Post-Ship-Trauer, hat einen Fix, der voraussetzt, dass du überhaupt ein Team hast.
Dieses Verhältnis ist der Punkt dieses Artikels. Die Postmortem-Literatur liest sich nicht wie sieben verschiedene Probleme. Sie liest sich wie ein Problem, strukturelle Isolation, das sich in sieben verschiedenen Monaten des Projekts zeigt.
"Du bist nicht faul. Du bist ohne Unterstützung" ist der konsistenteste Befund in der Indie-Postmortem-Akte. Das ist kein Aufmunterungsspruch.
Wenn du gerade auf ein Projekt schaust, das anfängt, in eines dieser Muster zu passen, ist die ehrliche Frage nicht "wie drücke ich härter". Sie ist: "wer ist der zweite Stuhl, den dieses Projekt braucht, und wie bekomme ich ihn besetzt?"
Clowdr ist um genau diesen zweiten Stuhl herum gebaut. Managed Indie-Game-Teams, strukturierte Commitments, behaltenes IP, jemand, der am Freitag auf deine Arbeit wartet. Wenn dir eines der sieben bekannt vorkam, melde dich bei Clowdr an. Wir helfen dir, Teammitglieder zu finden, die shippen.