Du bist nicht faul. Du bist allein gelassen: Warum 90 % aller Indie-Games in der Ideenphase sterben

Dein Indie-Game stagniert nicht, weil dir Talent, Disziplin oder Ideen fehlen. Es stagniert, weil du kreative Arbeit in einer Umgebung machst, die kreative Arbeit gezielt abwürgt.

Wahrscheinlich siehst du das anders. Die meisten Stuck Starter tun das. Wenn ein Projekt stirbt, schaust du als Erstes nach innen: Mir fehlte die Willenskraft. Der Funke ist weg. Ich bin halt einfach kein Finisher. Dieser Reflex ist falsch. Und er ist die teuerste Lüge, die ein Game-Dev sich selbst über sich erzählen kann. Die sieben Muster unten sehen aus wie Charakterfehler. Sind sie nicht. Sie sind der vorhersehbare Output einer ganz bestimmten Umgebung: der, in der jeder Solo-Indie-Dev per Default aufwacht. Wechsle die Umgebung, und die meisten davon lösen sich von selbst auf.

1. Du baust ein AAA-Game mit einem Indie-Team

Der häufigste Killer. Du hast dir ein Open-World-RPG ausgedacht, mit verzweigten Dialogen, Crafting, Wettersystem, 40 Stunden Content. Es wird der Hammer. Es wird auch 200 Leute und fünf Jahre brauchen.

Cyberpunk 2077 hatte rund 500 Entwickler hinter sich. Elden Ring und Armored Core 6 wurden von einem FromSoftware-Team von etwa 300 Leuten gemacht. Das sind die Games, mit denen du dein erstes Projekt mental abgleichst. Das sind die Games, die fertig wurden und die man dir gezeigt hat. Jedes unfertige Spiel hast du per Definition nie gesehen. Dein inneres Modell davon, "wie ein Spiel aussieht", ist also ausschließlich auf den Output von Armeen trainiert.

Dann sitzt du abends um neun nach der Arbeit allein an deinem Schreibtisch und wunderst dich, warum das Ding, an dem du baust, sich so unfassbar weit weg anfühlt.

Ein Indie-Dev formuliert es schonungslos:

"Indie-Games werden oft über ihren Scope definiert. Und das liegt daran, dass ein zu ambitioniertes Spiel entweder nie fertig wird oder viel zu lange dauert."

Der Ratschlag "Mach kleinere Spiele" ist so oft wiederholt worden, dass er bedeutungslos geworden ist. Die meisten Devs hören kleiner und denken kürzer. Also bauen sie ein kürzeres Open-World-RPG statt eines ausgewachsenen. Immer noch Desaster. Kleiner heißt nicht kürzer. Es heißt weniger bewegliche Teile, jedes davon besser gemacht.

Mini Metro entstand aus einem Game Jam mit harten Constraints: keine animierten Figuren, keine einzeln gebauten Level. Das Spiel hat sich millionenfach verkauft. Die Constraints waren keine Einschränkungen. Sie waren Design-Entscheidungen, die das Spiel besser und gleichzeitig das Leben des Entwicklers einfacher gemacht haben. Wenn eine Entscheidung nur eins von beidem tut, ist sie die falsche.

Der Fix ist nicht Willenskraft. Es ist ein zweites Paar Augen, das deinen Scope kassiert, bevor du dich in ihn verliebt hast.

2. Perfektionismus ist kein Charakterfehler. Es ist das, was passiert, wenn keiner hinschaut

Es gibt einen ganz bestimmten Moment, den jeder Solo-Dev kennt. Du verbringst eine Stunde damit, eine Variable zu tweaken, den Sprungbogen um einen Pixel zu justieren, fünfzehn UI-Blautöne zu testen. Dann machst du alles rückgängig und gehst zurück zum Ausgangspunkt. Keine Qualitätsarbeit. Prokrastination im Handwerker-Kittel.

Der Teil, über den niemand redet: Dieses Verhalten ist umgebungsbedingt. Es passiert nur, wenn niemand sonst auf deine Arbeit schaut. In dem Moment, in dem jemand bis Freitag auf deinen Build wartet, hört die Frage "Ist dieser Blauton jetzt genau richtig?" auf, wichtig zu sein, und die Frage "Ist der Button überhaupt verdrahtet?" übernimmt. Playtester interessiert dein Sprungbogen nicht; sie interessiert, ob das Level Spaß macht. Perfektionismus gedeiht in der Stille.

Ein erfahrener Indie-Dev drückt es so aus:

"Viele Artists zielen darauf ab zu erschaffen, nicht darauf zu shippen."

Der Unterschied klingt klein, ändert aber alles. Wenn Shippen das Ziel ist, läuft jede Entscheidung durch den Filter "Bringt das das Spiel in die Hände der Spieler?". Statt monatelang ein einzelnes System zu perfektionieren, baust du das ganze Spiel auf gut-genug und hebst dir den Polish-Durchgang für den Moment auf, an dem alles von Anfang bis Ende spielbar ist. Eine andere Entwicklerin hat einen Klebezettel über ihrem Monitor, auf dem nur steht go with good enough, weil sie sich selbst täglich daran erinnern muss.

Der Klebezettel ist der Punkt. Ohne externen Zwang sucht sich dein Gehirn immer die eine bequeme Ecke des Projekts und tut so, als wäre das Produktivität.

3. Die letzten 10 % sind eigentlich 90 % der Arbeit (und du dachtest, du wärst fast fertig)

Du hast das Spiel gebaut. Der Core-Loop läuft. Die Level sind drin. Die Art steht. Du bist vielleicht zu 90 % fertig.

Die brutale Wahrheit: Du bist ungefähr auf der Hälfte.

Die Zielgerade ist ein unsichtbarer Berg: Polishing, Bugfixing, UI-Menüs, Einstellungsscreens, fünf Größen von Store-Icons, fünf Größen von Splash Screens, Store-Texte, Screenshots, Playtesting, Balancing, Lokalisierung, Build-Pipelines. Die meisten Projekte sterben hier. Nicht beim Spaß-Teil. Hier.

"Die letzten 10 % haben so viele Dinge, von denen du nicht mal weißt, dass du sie fixen, polieren oder hinzufügen musst."

Indie-Devs nennen das die dunkle Arbeit: die Arbeit, die keinen sichtbaren Fortschritt erzeugt. Keine neuen Level, keine Screenshots für Bluesky, keine spannenden Features. Nur das Durchackern des unglamourösen Zeugs, das aus einem Prototyp ein Produkt macht.

Ein Solo-Dev hat rund zehn Jahre damit verbracht, immer wieder Projekte zu starten und jedes Mal aufzugeben, sobald die dunkle Arbeit anfing. Nicht weil er faul war. Er hat durchgehend gearbeitet. Jeder Abbruch an diesem Punkt hat sein Selbstbild als Finisher weiter abgetragen. Bis zum siebten Projekt hatte er in seinem Kopf einen Track Record, der sagte: "Ich bringe Dinge nicht zu Ende." Self-fulfilling Prophecy. Er ist da rausgekommen, indem er sich öffentlich vor die Kamera gestellt und sich verpflichtet hat, ein Spiel fertigzustellen, und alles andere nicht mehr anzufassen, bis es draußen ist.

Die 90/90-Regel ("die ersten 90 % des Codes brauchen 90 % der Zeit, und die letzten 10 % brauchen die anderen 90 %") wurde in den 1980ern in den Bell Labs geprägt und 1985 in Communications of the ACM zitiert. Vierzig Jahre später stimmt sie immer noch. Spiele sind keine Ausnahme. Wenn überhaupt, ist die dunkle Arbeit bei Spielen schlimmer, weil "fertig" hier subjektiv ist, anders als bei reinem Code-Verhalten.

Das Versagen ist nicht deine Ausdauer. Es ist, dass dich niemand vorgewarnt hat, dass sich die Form der Arbeit ändern würde. Und wenn der Wechsel kommt, interpretierst du die Verlangsamung als "Mir ist die Motivation abhandengekommen" statt als "Der Job ist gerade schwerer geworden". Andere Story, anderer Fix.

4. Du lügst dich selbst beim Scope an, und niemand ruft dich zurück

Overscoping ist kein Planungsfehler. Es ist das, was passiert, wenn die einzige Person, die den Plan bewertet, die Person ist, die ihn geschrieben hat.

Wenn du Monate in ein Projekt steckst, entwickelst du ein Investment, das deine Fähigkeit korrumpiert, es klar zu lesen. Du willst, dass der Scope vernünftig ist. Du willst, dass die Nische groß genug ist. Und wenn du etwas stark genug willst, dass es wahr sein soll, filtert dein Gehirn die gegenteilige Evidenz einfach aus.

"Warum verbringen Leute vier Jahre mit Projekten? Sie wollen glauben, dass sie erfolgreich sein werden, sie wollen glauben, dass sie eine Million Kopien verkaufen werden."

Tom Francis, der Entwickler hinter Gunpoint und Heat Signature, hat öffentlich geschrieben, dass Heat Signature rund zwei Jahre länger gedauert hat als geplant. Die Kernidee ließ sich in kleinen Prototypen nicht validieren, und er hat es nicht früh genug gemerkt. Er ist ein guter Entwickler. Er hat das schon mal gemacht. Es hat ihn trotzdem erwischt. Der Unterschied zwischen ihm und dem Solo-Dev, dessen Scope ihn bei lebendigem Leib auffrisst, ist nicht Talent oder Selbstreflexion. Es ist, dass Tom danach öffentlich darüber spricht, damit der Rest von uns etwas lernt. Die meisten überlaufenen Projekte sterben einfach still vor sich hin, und die Lektion stirbt mit ihnen.

Der unangenehme Teil: Der Bias, deinen eigenen Scope klar zu sehen, ist von innen heraus fast nicht zu fixen. Du kannst ein Projekt nicht objektiv bewerten, wenn deine Identität daran hängt. Der Fix muss von außen kommen: Playtester, ein Partner, ein Mentor, irgendjemand, der nicht emotional investiert ist und dir sagt, dass die Nische zu klein oder die Content-Pipeline zu lang ist, bevor du achtzehn Monate verbrannt hast.

Solo-Devs scheitern nicht am Scope, weil sie schlechte Planer wären. Sie scheitern, weil niemand im Raum steht, der fragt: "Bist du dir sicher?"

5. Shiny-Object-Syndrom ist ein Dopamin-Problem, kein Disziplin-Problem

Ein Projekt zu starten ist eine Droge. Alles ist aufregend. Die Möglichkeiten sind unendlich. Dein Gehirn feuert, weil du in der kreativen Flitterwochenphase bist.

Fertig werden ist das Gegenteil. Der Scope ist festgezurrt. Die Probleme sind bekannt. Das Dopamin der Neuheit ist weg und wurde durch das Grinden ersetzt, denselben Animations-Bug zum vierten Mal zu fixen.

Manche Devs verbringen 90 % ihrer Gamedev-Zeit in diesem Zyklus: starten, begeistert sein, an die erste Wand laufen, pivoten. Einer von ihnen hat die Nachwirkungen so beschrieben:

"Zombie-Projekte – die Projekte, die wir nicht offiziell aufgegeben haben, aber zu denen wir zu anderen weitergezogen sind, technisch arbeiten wir noch dran, aber wirklich angefasst haben wir sie seit ein paar Monaten nicht."

Die Zombie-Projekte sind das Schlimmste. Jedes hängt im Hinterkopf als schuldgeladener offener Loop. Du hast sie nicht offiziell aufgegeben, also ziehen sie mentale Energie ab, ohne etwas zu produzieren. Deine Aufmerksamkeit ist technisch auf elf Spiele verteilt, obwohl du nur an einem arbeitest. Kein Wunder, dass du erschöpft bist.

Das ist auch keine Faulheit. Es ist das, was ein Gehirn auf Neuheits-Suche tut, wenn es keinen externen Preis fürs Weglaufen gibt. Niemand sonst hat Assets in dein Repo gepusht. Niemand ist auf deinen Freitags-Build angewiesen. Du kannst ein Projekt zu Nullkosten ghosten, also ghostet dein Gehirn jedes Projekt in dem Moment, in dem das Dopamin aufgebraucht ist. Die Kosten sind nicht null. Sie sind der Friedhof. Aber die Kosten werden Jahre später bezahlt, nicht heute. Dein Gehirn rechnet sie auf null ab.

Der Fix ist zweiteilig. Erstens: Kündige deine Zombie-Projekte absichtlich. Sag es laut: Das ist tot, das ist in Ordnung, ich lasse es los. Den Loop zu schließen ist mehr wert als der Versuch, ihn still im Hintergrund am Leben zu halten. Zweitens: Wenn du dich nur vier Wochen lang für ein Projekt begeistern kannst, plane kein Sechs-Monats-Spiel. Plane ein Zwei-Wochen-Spiel, denn es wird einen Monat dauern.

Oder häng ein Preisschild ans Weggehen. Stell jemanden an die andere Seite, der mit deiner Arbeit bis Freitag rechnet. Die Kosten des Abbruchs sind nicht mehr null. Dein Gehirn rechnet neu. Plötzlich wird die Neuheit eines neuen Projekts gegen die realen Kosten abgewogen, ein Teammitglied hängen zu lassen. Bei den meisten Menschen kippt diese Rechnung zugunsten des Fertigwerdens.

6. Es gibt keine Ziellinie, und Dauerentwicklung ist sicherer als Shippen

Software hat ein natürliches "fertig": Das Tool tut, wofür es gebaut wurde. Spiele nicht. Es gibt immer noch ein Feature, noch ein System, noch eine Content-Schicht. Kein Fenster poppt auf und sagt "Spiel fertig, 100 %". Passiert nie.

"Spiele werden nie wirklich fertig, sie sind nur gut genug zum Launchen. Wenn du nicht fokussiert bleibst, ist es kinderleicht, aus einem Drei-Monats-Spiel oder einem Wochenend-Spiel drei Jahre zu machen."

Heißt: Fertigstellen ist eine aktive Entscheidung, kein natürlicher Endpunkt. Du musst entscheiden, dass es fertig ist, auch wenn es sich nicht fertig anfühlt. Und diese Entscheidung macht Menschen panisch, weil Shippen heißt, sich Marketing, Reviews, dem Steam-Algorithmus und der Möglichkeit zu stellen, dass Spielern nicht gefällt, was du gemacht hast.

Im Dauerentwicklungs-Modus zu bleiben ist sicher. Niemand kann ein Spiel kritisieren, das nicht released ist. "Es ist noch nicht soweit" wird zum Schild, und das Schild fühlt sich wie Handwerksethos an, funktioniert aber wie Vermeidung. Der Solo-Dev hinter Blue Prince hat acht Jahre lang 80 Stunden die Woche gearbeitet, um seinen Roguelike fertigzustellen, und hat hinterher gesagt, er könne "körperlich kein zweites so ambitioniertes Spiel mehr machen". So sieht Shippen am Ende eines achtjährigen Dauerentwicklungs-Zyklus aus. Nicht romantisch. Überleben.

Ein Solo-Dev hat es auf Hacker News so formuliert:

"Das größte Problem beim Solo-Bauen ist, dass du niemanden hast, der deine Tiefphasen ausgleicht. Wenn du nicht produktiv bist, steht alles still."

Wenn du eine Ein-Mann-Armee auf einem Spiel bist, ist jede schlechte Woche ein projektweiter Stillstand. Niemand fängt dich auf, niemand verliert etwas, wenn du nicht shippst, niemand schubst dich in die unbequeme "okay, das ist jetzt fertig"-Entscheidung. Dauerentwicklung ist keine Persönlichkeit. Sie ist das Default-Ergebnis eines Teams aus einer Person.

7. Das Muster, das du nicht siehst: "Das kann ich nicht" killt mehr Projekte als jeder Bug

Dieses Muster ist leiser als die anderen, und wahrscheinlich das tödlichste.

Es ist dieser Bruchteil einer Sekunde, in dem dein Gehirn sagt "Das kannst du nicht", und eine ganze mögliche Zukunft für dein Spiel löst sich auf. Prozedurale Generierung? Bist du nicht schlau genug für. Ein eigener Art Style? Bist du nicht talentiert genug für. Networking? Bist du nicht erfahren genug für. Das Projekt stirbt, bevor eine einzige Zeile Code geschrieben ist. Du merkst nicht mal, dass es stirbt. Es war einfach einen Gedanken später nicht mehr da.

"Das größte Handicap, das ich bei Game-Devs sehe, ist die Tatsache, dass sie denken, sie hätten ein Handicap."

Die brutale Ironie: Die Tools und Tutorials, die einem autodidaktischen Entwickler heute zur Verfügung stehen, wären vor zwanzig Jahren Science-Fiction gewesen. Die Hürde, Spiele zu machen, war noch nie niedriger. Du schaffst fast alles davon, was dein Gehirn dir gerade als unmöglich verkauft. Du willst es nur nicht tun, oder du willst es nicht allein tun, und das sind zwei unterschiedliche Gespräche.

Ein kleiner sprachlicher Shift hilft. Statt "Kann ich das?", was ein Ja-oder-Nein-Urteil provoziert (meistens nein), frag "Wie würde ich das machen?". Die zweite Frage zwingt dein Gehirn in den Lösungsmodus. Du brauchst die Antwort nicht sofort. Du musst nur die Tür lange genug offen halten, um durch sie hindurchzugehen. Und jemanden neben dir zu haben, der sagt "klar kannst du das, hier fängst du an", ist mehr wert als zehn Ratgeber.

8. "Aber was ist mit den Solo-Devs, die es schaffen?"

Fair. Es gibt sie. Stardew Valley. Undertale. Axiom Verge. Blue Prince. Echte Spiele, von einer Person geshippt. Wenn das Problem rein strukturell wäre, dürften die nicht existieren. Was also ist da los?

Schau dir irgendeinen davon genauer an und du findest immer dasselbe: Jeder erfolgreiche Solo-Dev hat sich die Struktur, die Teams geschenkt bekommen, selbst hergestellt. ConcernedApe hat jahrelang regelmäßige Devlog-Updates gepostet, die als externe Deadline und als Playtester-Feedback-Loop funktioniert haben. Toby Fox hatte eine Fanbase, die Updates aus ihm herausgezogen hat. Die meisten hatten einen Partner oder ein Familienmitglied, das den Scope beobachtet und reklamiert hat, wenn er abgedriftet ist. Der Blue-Prince-Dev hat in nahezu vollständiger Isolation gearbeitet und dafür bezahlt: acht Jahre, kaputter Körper, "Das kann ich nicht noch mal".

Das Muster ist nicht "Solo-Devs shippen und Team-Devs nicht". Das Muster ist: "Die Solo-Devs, die shippen, haben sich das Gerüst eines Teams auf andere Weise um sich herum gebaut. Die, die dieses Gerüst nicht bauen, shippen nicht." Das ist immer noch eine strukturelle Geschichte. Sie hat nur einen zusätzlichen DIY-Schritt.

Was in Ordnung ist, wenn du die Energie und Selbstreflexion hast, gleichzeitig Bauherr und Gerüst zu sein. Die meisten Menschen haben das nicht. Die meisten versuchen es, brennen aus und landen mit einem weiteren Eintrag im Friedhof. Das "zum Solo-Sein verdammt"-Framing, das du in Solo-Dev-Threads liest, ist nicht poetisch. Es ist eine Diagnose.

9. Was das konkret für dich heißt

Zieh den Rahmen mal kurz zurück.

Jedes Muster oben sieht von innen aus wie ein persönliches Versagen. Fehlende Disziplin. Perfektionismus. Verlorene Motivation. Shipping-Angst. Selbstzweifel. Aber sie haben alle dieselbe umgebungsbedingte Ursache: Du machst die Arbeit in Isolation, ohne externen Zwang, ohne jemanden, der deine Tiefphasen ausgleicht, ohne jemanden, der deinen Scope abfängt, bevor du dich in ihn verliebst, ohne eine Deadline, die du nicht still mit dir selbst neu verhandeln kannst.

Der Fix ist nicht mehr Biss. Es sind die vier Dinge, mit denen sich erfolgreiche Finisher umgeben, egal ob Solo oder im Team:

1. Jemand, der bis Freitag mit deiner Arbeit rechnet. Ein echter Mensch, keine To-do-Liste. Die psychologische Rechnung ist komplett anders, wenn ein Teammitglied auf deinen Build wartet.
2. Eine externe Deadline, die du nicht allein verschieben kannst. Eine Jam-Einreichung, ein Demo Day, ein Publisher-Milestone, der Kalender eines Co-Founders. Etwas, das du nicht still auf "nächste Woche" schieben kannst, und zwar für immer.
3. Playtester, die dich nicht lieb haben. Das Feedback, das dein Partner gibt, ist nett. Das Feedback, das ein Fremder gibt, ist nützlich. Die zweite Sorte brauchst du früh und oft.
4. Ein zweites Paar Augen auf deinem Scope. Bevor du sechs Monate verbrannt hast. Bevor du dich in die Idee verliebt hast. Jemand, der fragen kann "Bist du sicher, dass das shippbar ist?", ohne dass du es als persönlichen Angriff wertest.

Du kannst dir alle vier allein bauen. Manche Leute tun das. Es kostet eine enorme Menge Selbstmanagement zusätzlich zum Spiel selbst, weshalb die meisten Solo-Versuche stehen bleiben. Du versuchst, gleichzeitig Bauherr und Gerüst zu sein.

Oder du baust sie absichtlich, mit anderen Menschen.

Genau dafür haben wir Clowdr gebaut. Kein weiteres totes Discord-Projekt. Ein Team: strukturierte Verbindlichkeit, ein geteiltes Playbook, jemand, der deinen Freitags-Build tatsächlich erwartet. Mitwirkende behalten die Rechte an ihrer Arbeit. Deadlines sind real. Scope wird reklamiert, bevor er dich frisst. Eine Möglichkeit, sich die Struktur absichtlich zu holen, statt zu hoffen, dass man zufällig hineinstolpert.

Wenn du es satt hast zuzusehen, wie deine Projekte in der Ideenphase sterben, ist die Antwort fast nie "allein mehr versuchen". Sie ist, die Leute zu finden, die das "mehr versuchen" überflüssig machen.

Weiterlesen: Scope Creep killt dein Spiel geht die Scope-Falle im Detail durch, Solo-Dev vs. Team nimmt sich dem falschen Entweder-oder frontal an, Der komplette Guide, um dein Indie-Game fertigzustellen ist die Playbook-Version dieses Posts, und Wie du verlässliche Teammitglieder für dein Indie-Game-Projekt findest beantwortet das "Wer?", sobald du dich beim "Wie?" entschieden hast.

Die Projekte, die in deinem Friedhof sterben, sind kein Beweis dafür, wer du bist. Sie sind Beweis dafür, worin du die Arbeit machst. Ändere den Container. Der Rest folgt.