Die Neunzig-Neunzig-Regel: Warum dein Indie-Game bei 90 % hängen bleibt

Du bist seit vier Monaten bei 90 %.

Der Core Loop läuft. Der Art-Style steht. Du hast Freunden einen Build gezeigt und sie fanden es nicht furchtbar. Aber jeden Freitag ist das Spiel immer noch bei 90 %, und an manchen Freitagen bei 88 %, weil du ein System rausgerissen hast, das niemand neu haben wollte. Die letzten 10 % deines Indie-Games sind ein eigenes Projekt geworden — größer als die ersten 90 % und deutlich weniger Spaß.

Du bist nicht das Problem. Die letzten 10 % sind es. Am Ende dieses Posts weißt du, wie du einen normalen Polish-Tail von der 90/90-Todeszone unterscheidest — und du hast einen Fünf-Schritte-Plan, um da rauszukommen.

Was du brauchst, bevor du loslegst:

• Ein Projekt mit spielbarem End-to-End-Content (du bist am Vertical Slice vorbei).
• Ein Mensch, der bereit ist, sich einen Freitags-Build anzuschauen.
• Einen Kalender, den du tatsächlich öffnest.

---

1. Was die Neunzig-Neunzig-Regel wirklich sagt (und warum Indie-Games sie härter treffen)

Die Neunzig-Neunzig-Regel ist älter als die meisten Indie-Devs. 1985 formulierte Tom Cargill bei Bell Labs es so: Die ersten 90 % des Codes brauchen die ersten 90 % der Entwicklungszeit; die restlichen 10 % des Codes brauchen die anderen 90 % der Entwicklungszeit. Jon Bentley druckte es in seiner Kolumne „Programming Pearls" in Communications of the ACM ab. Es war ein Witz über Software-Schätzungen. Er hörte auf, ein Witz zu sein, ungefähr in dem Moment, als du deinen ersten Game Jam fertig gemacht hast und gemerkt hast, dass die „Polish-Woche" zwei Monate gedauert hat.

Gamedev Tomas Sala, der Jahre an Bloodmead gefeilt hat, sagt es in seinem Dev-Podcast genauso:

„Es heißt oft, die letzten 10 % brauchen genauso lang wie die ersten 90 %, irgendeine komische kleine Regel, die sich immer wieder bewahrheitet."

Indie-Games trifft die Regel härter als den Rest der Software — aus drei strukturellen Gründen:

• Es gibt kein QA-Team. Niemand lädt deinen Build und versucht, ihn zu zerbrechen. Jeden Bug, den du findest, findest du, weil du selbst geschaut hast.
• Es gibt keinen Producer. Niemand zieht eine Linie, die sagt: „Das ist der Scope, und ab hier wird geshippt." Du ziehst diese Linie. Du streitest dich auch mit ihr.
• Es gibt keine externe Deadline. Ein Studio hat ein Geschäftsjahr und einen Publisher. Ein Solo-Dev hat ein Ship-Datum auf einem Klebezettel, und der Klebezettel ist das Ding, das sich jede Woche verschiebt.

Eine Person hält das Ganze zusammen. Deshalb sind deine letzten 10 % nicht wirklich 10 %. Sie sind ein anderes Projekt, das zufällig dieselbe Codebase trägt.

2. Fünf Muster, die dir sagen, dass du in der 90/90-Todeszone bist

Vor den Schritten: die Diagnose. Überflieg diese Muster und such dein eigenes. Du hast wahrscheinlich mehr als eins.

Muster 1: Der Restart-Loop. Du öffnest das Projekt, liest den Code von vor sechs Monaten, verziehst das Gesicht und fängst an, das System neu zu bauen. Nicht zu fixen. Komplett sauber neu zu bauen. Das neue System braucht drei Wochen. Es macht dasselbe wie das alte. Du fühlst dich einen Tag lang großartig — dann öffnest du die nächste Datei von vor sechs Monaten.

Muster 2: Der Polish-Loop. Jeden Freitag fixt du fünf Dinge. Jeden Freitag kommen fünf neue dazu. Das Spiel wird nicht schlechter. Es wird auch nicht fertig. Ein Indie-Dev brachte es auf einem Gamedev-Blog auf den Punkt: „Jeder Indie-Dev kennt das Gefühl: Dein Spiel ist fast fertig, und doch gibt es immer noch was zu tweaken, anzupassen oder zu verbessern. Du findest dich in einer endlosen Schleife aus Verbesserungen wieder."

Muster 3: Die Traum-Spiel-Flucht. Du denkst unter der Dusche an dein nächstes Projekt. Du skizzierst es in deiner Notizen-App. Du erwischst dich beim Devlog-Gucken von Spielen in dem Genre, in dem du lieber arbeiten würdest. Aus einem echten r/gamedev-Post: „Ich will dieses Spiel ASAP fertig machen, weil ich so müde davon bin, damit ich mein nächstes super aufregendes Traum-Spiel anfangen kann."

Das ist keine Inspiration. Das ist die hintere Hälfte deines Gehirns, die versucht, aus dem Raum rauszukommen.

Muster 4: Das Dread-Öffnen. Die IDE zu öffnen fühlt sich körperlich schlecht an. Der Dev hinter Blood and Mead beschreibt es in seinem Podcast so: „Ich kam an den Punkt, an dem ich mit einem Gefühl von Dread einschlief — Dread, das Projekt nicht zusammenzubringen, und Dread zu scheitern."

Muster 5: Der verschwundene Zeuge. Dein Devlog ist stehen geblieben. Du hast das Spiel seit sechs Wochen keinem anderen Menschen gezeigt. Niemand fragt nach dem Build. Du sagst dir selbst, du bist „im Tunnel" — aber in Wahrheit ist das Spiel unsichtbar geworden, und es ist viel leichter, etwas nicht zu shippen, das niemand erwartet.

Wenn du drei oder mehr davon erkannt hast, bist du nicht in den letzten 10 %. Du bist in der 90/90-Todeszone. Das ist ein strukturelles Problem, kein Charakterfehler. Lies weiter.

3. Warum die letzten 10 % kein Willenskraft-Problem sind

Jede Listicle zum Thema „So machst du dein Indie-Game fertig" sagt dir, du sollst härter grinden. Das ist für genau diese Phase der schlechteste Rat überhaupt.

Die letzten 10 % brechen unter Isolation zusammen, nicht unter zu wenig Einsatz. Du bringst den Einsatz schon — du würdest das hier sonst nicht lesen. Der Einsatz trifft nur auf eine Struktur, die aussieht wie ein Schweizer Käse.

Drei strukturelle Gründe, warum das Endgame zusammenbricht, wenn du allein bist:

• Der Bug-Tail ist unsichtbar ohne zweiten Loader. Du kennst jede Ecke deines Spiels. Du siehst den Softlock nicht mehr, weil dein Muscle Memory drumherum läuft. Jemand anderes lädt den Build, rennt in dreißig Sekunden in den Softlock — und plötzlich ist das Spiel wieder kaputt. Dieses Feedback kommt nie, wenn niemand sonst den Build lädt.
• „Fertig" hat keine externe Definition. Ein Publisher schickt eine Checkliste. Ein Producer cuttet Features. Ein Solo-Dev verhandelt jeden Freitag mit sich selbst über „fertig" — und verliert, weil die einzige Person, die fürs Shippen argumentiert, dieselbe ist, die shippen muss.
• Real life gewinnt öfter. Nicht weil du faul bist. Weil niemand sonst auf den Freitags-Build zählt. Eine Stunde, die du für Familie, Erledigungen, Schlaf abziehst, fällt keinem auf. Also wird die Stunde jede Woche ein bisschen früher abgezogen.

Du bist nicht faul. Du bist unsupported.

Sogar legendäre Teams hängen an dieser Wand. Team Cherry-Co-Founder Ari Gibson sagte über Silksong: „Wenn ich nicht aufhöre zu zeichnen, dauert das noch 15 Jahre." Silksong hing sieben Jahre in der Refinement-Phase — nicht weil das Team undiszipliniert war, sondern weil das Projekt die meiste Zeit davon keine externe Zwangsfunktion hatte. Ein Zwei-Personen-Studio ohne Zeugen ist strukturell identisch mit einem Solo-Dev in der 90/90-Zone. Es ist nur voller Talent.

Der Fix ist nicht mehr Disziplin. Der Fix ist ein System, das am anderen Ende deines Freitags-Builds einen Menschen sitzen hat.

4. Schritt 1 — Erklär den Scope-Cut

Öffne eine Textdatei. Nenn sie ship.md. Mach zwei Spalten: Ship-Liste und Someday-Liste.

Nimm jede offene Aufgabe in deinem Projekt — jedes Feature, jeden Bug, jedes „wäre nett", jede Trello-Karte, jeden Zettel — und zwing sie in eine der beiden Spalten. Es gibt keine dritte Spalte.

Regeln:

• Die Ship-Liste ist hart auf 20 Einträge gedeckelt. Wenn du 47 hast, hast du noch nicht gecuttet. Cut nochmal.
• Alles, was sich „uneindeutig" anfühlt, landet per Default auf Someday. Beweise, dass es auf die Ship-Liste gehört.
• „Aber die Spieler werden es hassen, wenn ich das rausnehme" ist kein Beweis. Das ist die Scope-Creep-Stimme. Cut es trotzdem. Schreib es auf Someday. Wenn es wirklich wichtig ist, wird es ein Patch.

Wenn du das noch nie kalt gemacht hast, geh vorher durch Scope Creep tötet dein Spiel. Dieser Schritt ist der strukturelle Vorfahre jedes anderen Schrittes in diesem Post. Du kannst keine Liste shippen, die du nicht geschrieben hast.

5. Schritt 2 — Setz ein Shipping-Fenster, das du nicht still verschieben kannst

Kein Datum. Ein Fenster. Zwei Wochen breit.

„Ich shippe in Q3" nützt nichts — niemand weiß, wann du es gebrochen hast. „Ich shippe zwischen 14. Oktober und 28. Oktober" ist testbar. Jemand kann am 29. Oktober fragen, ob du geshippt hast, und du musst antworten.

Schreib das Fenster irgendwohin, wo man es sieht:

• In einen Devlog-Post mit Datum in der Überschrift.
• In eine gepinnte Discord-Nachricht.
• In einen Tweet.
• Auf eine Steam Coming-Soon-Seite (die hier ist am schwersten leise zu verschieben — Valve zeigt das Datum den Spielern).

Es geht nicht um Marketing. Es geht darum, dass mindestens ein Mensch außerhalb deines Kopfes weiß, wann du gesagt hast, dass du fertig bist. Das ist die Zwangsfunktion. Eine private Deadline auf einem Klebezettel ist unsichtbar. Ein öffentliches Fenster ist ein Commitment, das dich Gesichtsverlust kostet, wenn du es verschiebst.

Mike Bithell hielt 2015 einen ganzen GDC-Talk mit dem Titel "Indie Polish: Making the Most of the Last 10%" — die ganze Prämisse: Die letzten 10 % sind ein eigenes Handwerk und brauchen einen eigenen Plan. Game Developer zitierte ihn damit, dass er „viel darüber nachgedacht habe, wie man das Maximum aus den letzten zehn Prozent der Entwicklungszeit herausholt". Er sagte nicht „grind härter". Er sagte: plan sie anders. Das öffentliche Fenster ist Schritt eins davon, sie anders zu planen.

6. Schritt 3 — Installier das Freitags-Build-Ritual

Jeden Freitag machst du drei Dinge:

1. Push einen Build von dem, was du hast.
2. Zeig ihn einer bestimmten Person.
3. Hol dir einen Satz Feedback.

Das war's. Das ist das Ritual.

Was du zeigst: einen Build, der startet und einen Loop abschließt. Nicht poliert. Nicht das ganze Spiel. Er läuft. Wenn der Build letzten Freitag gestartet ist und diesen Freitag nicht, hast du gerade was über deine Woche gelernt.

Wem du ihn zeigst: einer bestimmten Person, an einem bestimmten Tag, mit einer bestimmten Frage. Nicht „post es in einem Discord-Server". Discord-Server sind kein Zeuge — sie sind eine Diffusion von Verantwortung. Ein Zeuge ist ein benannter Teammate, ein Accountability-Partner, ein Playtester, der zugesagt hat, jeden Freitags-Build zu laden, oder eine kleine Gruppe, die sich jeden Freitag trifft. Genau so eine Person.

Was du misst: ob das Spiel diesen Freitag besser durchläuft als letzten Freitag. Nicht „ist es poliert". Nicht „macht es Spaß". Startet es, schließt der Loop, wird es monoton besser.

Ein Dev im Home Team-Podcast bringt es besser auf den Punkt, als ich es kann:

„Einen Zeitplan zu halten und wöchentlich zu präsentieren hilft nicht nur bei der Motivation, sondern zeigt auch, dass es Leute gibt, die wollen, dass du es schaffst."

Derselbe Dev, später in derselben Folge:

„Allein habe ich nie etwas fertig rausgebracht. Nach dem Einstieg habe ich an einer ganzen Reihe von Spielen mit so vielen Leuten gearbeitet."

Das ist kein Motivationszitat. Das ist ein Struktur-Zitat. Die Person sagt: Setz jemanden ans andere Ende des Builds, und der Build shippt. Wenn du noch keinen Freitags-Zeugen hast, führt dich Accountability Circles durch das Small-Team-Ritual, das einen installiert.

7. Schritt 4 — Schneid den Bug-Tail mit Triage, nicht mit Heldentum

Irgendwo in deinem Repo hast du 140 offene Bugs. Vielleicht 400. Die meisten sind echt. Fast keiner ist ein Ship-Blocker.

Triage in drei Eimer, einmal:

• Ship-Blocker. Crashes. Kaputte Saves. Softlocks, die den Fortschritt verhindern. Build kompiliert nicht auf dem Rechner eines Kunden. Die blockieren das Fenster. Fix sie.
• Nervig aber shippt. Visueller Glitch. Kleiner Softlock mit Workaround. Controller-Rebind, der komisch speichert. Logg es, dokumentier den Workaround, shippe. Patch später.
• Someday. Design-Debt. „Das würde sich besser anfühlen, wenn …". Alles, was eigentlich ein Feature im Bug-Kostüm ist. Someday-Liste. Vielleicht Niemals-Liste.

Regel: Vor dem Fenster fixt du nur Ship-Blocker. Das ist alles. Der „ich fix nur kurz diesen einen"-Bug ist der Grund, warum Freitage verschwinden — logg ihn und geh weiter. Niemand, der ein gutes Spiel geshippt hat, hat es geshippt, weil jeder Bug gefixt war. Geshippt wurde, weil jeder Ship-Blocker gefixt war.

8. Schritt 5 — Triff die Ship-Entscheidung mit einer einseitigen Checkliste

Bevor das Fenster aufgeht, schreibst du eine „Done heißt"-Checkliste. Eine Seite. Fünf bis zehn Punkte. Hier die Form:

• Jeder Punkt auf der Ship-Liste ist ✅ oder auf Someday verschoben.
• Jeder Ship-Blocker-Bug ist ✅.
• Der Build startet auf drei verschiedenen Maschinen.
• Store-Page-Copy, Screenshots, Trailer sind hochgeladen.
• Die Demo läuft auf einer frischen Installation ohne Crash durch.
• Credits-Datei ist aktuell.
• Build-Größe ist unter dem Plattform-Limit.

Done heißt „jeder Punkt auf dieser Checkliste ist abgehakt ODER auf Someday verschoben". Das ist die Definition. Die einzige Definition.

Wenn du sie triffst, shippst du. Auch wenn es sich nicht perfekt anfühlt. Gerade wenn es sich nicht perfekt anfühlt — das „nicht perfekt"-Gefühl ist das, was die letzten 10 % mit deinem Kopf anstellen; es ist kein Signal über dein Spiel.

Paul Valéry: „Ein Werk wird nie fertig, es wird nur aufgegeben." Zurück zu Silksong: Ohne Checkliste funktioniert Gibsons „ich hör auf, wenn es sich richtig anfühlt" vier Jahre lang, dann nicht mehr. Aus dieser Falle kommst du nicht mit Geschmack raus. Du kommst mit einer Liste raus.

9. Typische Fallen in den letzten 10 %

• Falle 1: Das Projekt in einer neuen Engine neu starten. Wenn du an der Endgame-Wand hängst, rettet dich Godot nicht. Unity nicht. Unreal nicht. Cadence rettet dich. Die Engine ist nicht das Problem, und der Umzug in eine sauberere Codebase bringt dich nicht über die 90/90-Marke — er setzt dich bei 30 % auf einer anderen Codebase ab.
• Falle 2: Die unendliche Polish-Runde. Wenn jede „finale" Polish-Runde eine Woche neue Polish-Punkte erzeugt, polierst du nicht — du versteckst dich. Stopp. Ship. Polish im Patch. Das Spiel wird nach der fünften „finalen" Runde nicht besser. Du wirst nur müder.
• Falle 3: Das Spiel verstecken, bis es „ready" ist. Das Spiel wird sich in Isolation nie ready anfühlen. Genau das macht Isolation. Zeig es hässlich. Zeig es kaputt. Fremde Augen sind der einzige Weg, dass „ready" wieder ein echtes Wort wird.
• Falle 4: Allein durch den Dread grinden. Wenn das Öffnen der IDE zwei Wochen am Stück schlecht anfühlt, arbeitest du nicht härter — du arbeitest allein. Mehr Stunden Dread produzieren kein geshipptes Spiel. Ein Zeuge am Freitag schon.

Alle vier Fallen haben dieselbe Ursache: Es ist niemand sonst im Raum. Fix: jemanden in den Raum setzen.

10. Was du als Nächstes tun kannst

Wenn du am Vertical Slice vorbei bist und hängst, fang hier an:

• Wie du dein Indie-Game fertig machst: Der komplette Leitfaden — der volle Pillar-Kontext für alles oben.
• Scope Creep tötet dein Spiel — wie du die Ship-Liste und die Someday-Liste schreibst, ohne dich selbst anzulügen.
• Accountability Circles — die Wochenstruktur, die dir einen Freitags-Zeugen gibt.
• Das Vertical Slice Protokoll — falls du tatsächlich früher dran bist, als dieser Post annimmt: beweis erstmal, dass das Spiel funktioniert.
• Warum 90 % der Indie-Games in der Ideenphase sterben — das Geschwister-90%-Problem, das am anderen Ende des Projekts lebt.

Und der ehrliche Teil vom CTA: Die letzten 10 % brauchen nicht mehr Willenskraft. Sie brauchen jemanden, der auf den Freitags-Build wartet. Einen Teammate, der ihn wirklich lädt. Eine Struktur, in der „done heißt" von mehr als einem Kopf durchgesetzt wird. Clowdr ist der Ort, der genau darum gebaut ist — a team, not a family. Strukturierter Takt, behaltene Rechte, Shipped-Credits, die existieren, weil die Spiele geshippt werden.

Wenn das Freitags-Build-Problem dein Problem ist, melde dich bei Clowdr an →. Fünfzig Euro im Monat. Die ersten fünfzig Mitglieder zwei Monate kostenlos. Teammates, die freitags auf dich zählen — die einzige Variable in diesem Post, die die letzten 10 % wirklich bewegt.