clowdr.devWie du dein Indie-Game fertigstellst: Der komplette Guide
Indie-Game fertigstellen ist strukturell, nicht Willenssache. Der komplette Guide: Scope, Perfektionismus, die letzten 10 % und wann du shippst.
Ein Indie-Game fertigzustellen ist ein strukturelles Problem, kein Willensproblem. Die meisten Devs steigen aus, weil sie es allein machen, nicht weil sie faul oder unbegabt sind. Dieser Guide benennt die Muster, die Projekte killen, und die strukturellen Fixes, die Spiele tatsächlich ans Ziel bringen.
Inhaltsverzeichnis
- Fertigstellen ist strukturell, keine Moralfrage
- Plane den Scope für den Menschen, der du wirklich bist
- Bau erst ein Skateboard, dann ein Fahrrad
- Halte das Spiel an jedem Arbeitstag spielbar
- Perfektionismus ist, was Isolation belohnt
- Beerdige deine Zombie-Projekte
- Der Drang, neu anzufangen, ist das Unbehagen des Fortschritts
- Konstanz schlägt Inspiration
- Setz dir eine echte Deadline (und sag es jemandem)
- Die letzten 10% sind die 90%, vor denen dich niemand gewarnt hat
- Fertigstellen ist eine Entscheidung, kein Zustand
- Fragen, die Indie-Devs zum Fertigstellen stellen
- Du musst nicht allein fertig werden
Fertigstellen ist strukturell, keine Moralfrage
Wenn du dein Indie-Game einfach nicht fertigbekommst, liegt es vermutlich nicht an Disziplin oder Talent. Es ist strukturell. Du versuchst einen Job zu machen, der nie dafür ausgelegt war, allein gemacht zu werden, und die meisten Ratschläge, die dir sagen "sei einfach disziplinierter", benennen das Symptom, nicht die Ursache.
Fang bei den Daten an. Eine empirische Studie zu 23.485 Steam-Releases fand, dass 48 % aller Spiele verspätet erschienen sind, wobei sich das Verspätungsmuster quer durch die Genres hielt (Queen's University, 2022; abgerufen 2026-04-10). Und das sind nur die Spiele, die es tatsächlich rausgeschafft haben. Niemand zählt die, die still und leise in irgendjemandes projects/-Ordner gestorben sind, weil diese Devs nie ein Release-Datum angekündigt haben.
Ein Indie-Gründer hat in Game Developer über "mehr als ein Dutzend Projekte in fünf Jahren ohne ein einziges veröffentlichtes Release" geschrieben und das auf ein "Elster-Mindset" zurückgeführt: den Drang, bei jedem Projekt aufs Nächste zu springen, sobald das aktuelle anfing, sich nach echter Arbeit anzufühlen (2023; abgerufen 2026-04-10). David Maletz hat es im selben Magazin direkter formuliert: "die große Mehrheit der Indie-Game-Entwickler schafft es nicht, ihre Spieleprojekte fertigzustellen". Keine Minderheit. Keine unglückliche Untergruppe. Die Mehrheit (abgerufen 2026-04-10).
Über hunderte Indie-Dev-Geschichten hinweg, die wir studiert haben (Reddit-Threads, Post-Mortems, Live-Build-Updates, GDC-Talks), zeigt sich dasselbe Muster. Solo-Devs rennen in dieselben Wände, und zwar ungefähr in denselben Wochen. Nicht, weil sie einen gemeinsamen Charakterfehler haben, sondern weil sie dieselbe Situation teilen. Niemand wartet auf ihre Arbeit. Niemand fragt nach. Niemand benennt das Driften, wenn es anfängt. Das ist das strukturelle Problem. Alles andere in diesem Guide ist entweder ein Muster, das in diesem Vakuum entsteht, oder ein Fix, der wieder ein bisschen Struktur einzieht.
Und der Teil "es dauert viel länger, als du denkst" hat auch einen Namen. Tom Cargill von den Bell Labs hat es in der "Neunzig-zu-Neunzig-Regel" auf den Punkt gebracht: "Die ersten 90 Prozent des Codes brauchen die ersten 90 Prozent der Entwicklungszeit. Die restlichen 10 Prozent des Codes brauchen die anderen 90 Prozent der Entwicklungszeit" (abgerufen 2026-04-10). Das ist kein Witz. Das ist Abschnitt 10 in diesem Guide.
Wenn du aus diesem Abschnitt nur eine Sache mitnimmst: die 90-%-Ausfallquote ist kein Versagen einzelner Devs. Sie ist ein Versagen der Struktur drumherum.
Plane den Scope für den Menschen, der du wirklich bist
Plane den Scope für den Menschen, der du wirklich bist, nicht für den, der du an deinem besten Tag sein willst. "Mach kleinere Spiele" ist der meistwiederholte Ratschlag in der Indie-Szene und der nutzloseste, weil alle nicken und dann eine leicht verkleinerte Version von Stardew Valley bauen. Echte Scope-Disziplin geht nicht um kürzere Spielzeit. Es geht darum, ganze Kategorien von Arbeit zu streichen.
Jedes System, das du einbaust, muss am Ende so gut sein wie das entsprechende System in dem Spiel, mit dem deine Spieler es vergleichen. Baust du eine Farming-Sim, muss dein Inventar mindestens so gut sein wie das in vergleichbaren Farming-Sims. Deine Dialoge müssen halten. Deine NPCs müssen Tagesabläufe haben. Deine Pflanzen müssen wachsen. Das ist nicht ein Spiel voll Arbeit. Das sind zwölf Spiele voll Arbeit, und du musst alle gleichzeitig tragen.
Jetzt stell dir ein Spiel vor, das eine ganze Achse entfernt. Downwell ist ein Spiel über Fallen und Schießen. Keine horizontale Bewegung. Diese eine Einschränkung hat ganze Kategorien von Designproblemen eliminiert, und ein einzelner Entwickler konnte jeden Screen wirklich polieren. Mini Metro startete mit zwei selbst auferlegten Regeln: keine animierten Charaktere, keine handgebauten Level. Beide Regeln haben Wochen an Arbeit gestrichen, bevor eine einzige Zeile Code geschrieben war. Beide Spiele sind erschienen. Beide haben Geld verdient.
Der strukturelle Fix: Entscheide, was dein Spiel nicht haben wird, bevor du entscheidest, was es haben wird. "Keine Charaktere zum Animieren." "Keine Cutscenes." "Kein Tutorial." "Nur ein Screen." "Keine Maussteuerung." Schreib die Einschränkungen auf einen Zettel und kleb ihn an deinen Monitor.
Und dann sei ehrlich über deine tatsächliche Aufmerksamkeitsspanne. Wenn du aus Erfahrung weißt, dass Projekte in deinem Leben tendenziell in Woche sechs sterben, darfst du kein Zehn-Monats-Spiel planen. Plan ein Vier-Wochen-Spiel. Es wird sechs Wochen dauern. Das ist die Mathematik.
Scope ist der Punkt, an dem Scope-Creep dein Projekt auffrisst. Der Fix fängt an, bevor du die erste Zeile Code schreibst.
Bau erst ein Skateboard, dann ein Fahrrad
Es gibt ein berühmtes Produktentwicklungs-Diagramm. Der falsche Weg, ein Auto zu bauen, ist: erst ein Rad, dann zwei Räder, dann ein Chassis, dann eine Karosserie. Der richtige Weg ist: erst ein Skateboard, dann ein Roller, dann ein Fahrrad, dann ein Motorrad, dann ein Auto. Jede Stufe ist etwas, das ein Mensch tatsächlich benutzen kann. Dein Indie-Game sollte genauso funktionieren.
Viele Devs verbringen Monate damit, Systeme zu bauen, bevor sie ein Spiel bauen. Die prozedurale Generierungs-Engine, die Save/Load-Architektur, das Inventar-Framework, den Dialog-Compiler. Brillanter Code. Nichts zum Spielen. Dann schauen sie sich eines Tages an, was sie gebaut haben, merken, dass niemand es noch tatsächlich erleben kann, und die Motivation bricht zusammen.
Der Fix heißt Vertical Slice: ein dünner, aber kompletter Querschnitt deines Spiels. Nicht alle Systeme ohne Art. Nicht alle Art mit kaputten Systemen. Ein Schnitt, in dem der Core Loop funktioniert, ein bisschen Sound da ist, es halbwegs aussieht und jemand, der es noch nie gesehen hat, sich hinsetzen und zwei Minuten spielen kann. Das ist dein Skateboard. Es ist nicht das Auto. Aber es bewegt sich, und es ist echt.
Juha Vainio hat es im Game Developer-Magazin gut formuliert: "MVP ist ein Mindset, eine Art zu erkennen, was im Spiel wichtig ist und was nicht" (2015; abgerufen 2026-04-10). Keine Feature-Liste. Eine Art zu sehen.
Ein Dev, der schon viele kleine Spiele veröffentlicht hat, hat die Kosten der anderen Variante ungeschönt formuliert: "Wenn du übst, Dinge nicht fertigzustellen, wirst du richtig gut darin, Dinge nicht fertigzustellen. Siehst du, wie das funktioniert?" Jeder Monat, den du im Nicht-spielbar-Modus verbringst, ist ein Monat, in dem du Identität als Person aufbaust, die nicht released. Bau das Skateboard in Woche eins. Dann expandiere nach außen.
So wendest du das an. Deine Woche-1-Frage ist nicht "welche Technik brauche ich?". Sie ist "kann der Spieler das eine Ding tun, um das es in meinem Spiel geht?" Wenn die Antwort nicht ja ist, baust du in der falschen Reihenfolge.
Halte das Spiel an jedem Arbeitstag spielbar
Jeder Arbeitstag sollte damit enden, dass das Spiel in einem Zustand ist, in dem ein Fremder es in die Hand nehmen und spielen könnte. Nicht poliert. Nicht fertig. Einfach lauffähig. Wenn das Spiel wochenlang nicht mehr vorzeigbar ist, verlierst du zwei Sachen gleichzeitig, und beide killen Projekte.
Das Erste, was du verlierst, ist Feedback. Ein Spiel, das man nicht spielen kann, kann man nicht testen, was bedeutet, dass du driftest. Du kannst einen Monat damit verbringen, die "bessere" Version eines Systems zu bauen, das vorher schon gut war, weil keiner da war, der sagt "eigentlich war das Alte besser". Das Zweite, was du verlierst, ist der psychologische Treibstoff, der darin liegt, dein Spiel als Spiel zu erleben. In Code-Dateien starren ist nicht dasselbe wie zu sehen, wie ein Mensch an deinem Ding rumprobiert und lächelt.
Das ist der Moment, in dem viele Devs anfangen zu spüren, wie ihnen das Projekt aus den Händen gleitet, ohne sagen zu können, warum. Es fühlt sich wie Burnout an. Eigentlich ist es Disconnection vom Erlebnis des Spiels. Du bist in den Maschinenraum gewandert und bist seit sechs Wochen da unten.
Der strukturelle Fix ist simpel. Bevor du mit einer Aufgabe anfängst, die das Spiel länger als einen Tag kaputtmacht, branche. Commite eine laufende Version. Wenn du gleich das Save-System refaktorierst, sorg dafür, dass "der Build von letzter Woche" nur einen Befehl entfernt ist. Behandle "das Spiel läuft von vorne bis hinten" als nicht verhandelbare tägliche Bedingung, genauso wie ein echtes Engineering-Team "die Tests laufen" behandelt.
Und plan Playtests ein. Wöchentlich, wenn du sie bekommen kannst. Auch informelle. Auch mit einer Person. Allein dass der Playtest existiert, zwingt dich, den Build spielbar zu halten, weil du schon jemandem gesagt hast, dass er am Donnerstag vorbeikommen kann. Das ist Struktur. Das ist, was wir meinen, wenn wir sagen, Fertigstellen ist strukturell: Vorab-Verpflichtungen, die du nicht um 1 Uhr nachts still und leise mit dir selbst neu verhandeln kannst.
Perfektionismus ist, was Isolation belohnt
Perfektionismus sieht aus wie hohe Ansprüche, ist in einem Solo-Projekt aber meistens etwas anderes: die einzige Form von Fortschritt, der niemand widersprechen kann. Wenn keiner da ist, der sagt "das ist fertig, geh weiter", greift dein Gehirn zu der einen Aufgabe, die es immer weitermachen kann: an dem Ding zu feilen, das vor dir liegt. Das ist kein Charakterfehler. Das passiert mit jedem, der einen Monat allein ohne externes Signal verbringt.
In der Praxis sitzt du eine Stunde da und justierst das Timing eines Partikeleffekts. Du justierst, previewst, justierst wieder. Irgendwann fängst du an, es wieder in Richtung des Ausgangszustands zu schieben. Eine Stunde weg, null echter Fortschritt, und es fühlt sich an, als hättest du gearbeitet. Wiederhol das Muster über zwölf Systeme und vier Monate, und du hast ein Projekt, das beschäftigt wirkt und sterbend ist.
Die Mathematik ist brutal. Bei 80 % Qualität bringt jede zusätzliche Stunde Arbeit sichtbare Verbesserung. Bei 95 % Qualität bringt eine weitere Stunde eine Veränderung, die so klein ist, dass kein Spieler sie bewusst bemerken wird. Und irgendwann nach 97 % fängst du an, rückwärts zu gehen: du hast die Perspektive verloren, deine Augen sind glasig, und die "Fixes", die du machst, sind einfach nur anders.
Der Fix ist eine Regel. Geh bei jedem Durchgang bei 80-90 % weiter, und heb Polish für den Zeitpunkt auf, an dem das ganze Spiel existiert. Du kannst immer zurückkommen. Du kannst die Monate nicht zurückbekommen, die du damit verbrennst, eine Villa auf einem Fundament zu polieren, das nie gegossen wurde.
Ein Devpod-Mitglied hat die Arbeitsdefinition klar ausgesprochen: "Ich hab Angst, dass es kaputtgeht, aber 99 Prozent der Zeit funktioniert es, einige Leute mögen es und es ist gut genug, um es rauszubringen." Das ist die Stimme, die du im Kopf brauchst. Es ist nicht die Stimme von jemandem mit niedrigen Ansprüchen. Es ist die Stimme von jemandem, der schon released hat und weiß, dass die nächste Version dieses Dings nur dann besser werden kann als diese, wenn diese überhaupt existiert.
Selbst der Code hinter Doom ist voll von Hacks und Workarounds. Carmack weiß das. Carmack hat trotzdem released. Das ist der Move.
Beerdige deine Zombie-Projekte
Ein Zombie-Projekt ist eins, das du nicht offiziell aufgegeben hast, das du aber seit Monaten nicht mehr angefasst hast. Offiziell ist es dein "aktuelles Projekt", weil du keine Entscheidung getroffen hast, aber die Projektdatei ist seit März nicht mehr geöffnet worden. Es ist nicht lebendig. Es ist nicht tot. Es saugt mentale Energie auf eine Art, wie ein vollständig beerdigtes Projekt es nicht täte, und es hindert dich stillschweigend daran, dich auf etwas Neues einzulassen.
Die meisten Indie-Devs haben mehrere davon. Es gibt ein Wort, das die Leute für ihren Stapel benutzen: Friedhof. Ein Dev auf r/gamedev hat seinen laut aufgezählt: "Hier ist mein Friedhof: Incremental Game, Vampire-Survivors-Klon, FPS-Arena mit Wave-Modus..." Du hast wahrscheinlich auch so eine Liste. Manche auf GitHub, manche in einem projects/old/-Ordner, den du absichtlich nicht aufmachst. Alles davon spukt in deinem Kopf.
Die Kosten der Zombies sind nicht der Festplattenplatz. Sie sind, dass ein unbewusster Teil deines Gehirns immer noch auf sie reserviert ist und leichtes Schuldgefühl erzeugt, jedes Mal wenn du etwas Neues anfängst. Was, wenn ich zu dem zurückgehen sollte? War es falsch, es aufzugeben? Was, wenn ich einfach noch ein Wochenende reinstecke? Das ist kein strategisches Denken. Das ist ein offener Loop, der sich nie schließt, und er stiehlt Fokus von dem Projekt, an dem du gerade angeblich arbeitest.
Der strukturelle Fix ist klar: Beerdige sie bewusst. Nicht "pause". Nicht "on hold". Tot. Mach eine Liste mit jedem Projekt, an dem du "technisch gesehen" noch arbeitest, sei ehrlich darüber, welche du seit 90 Tagen nicht angefasst hast, und kill alles bis auf eins. Das, das du behältst, sollte das sein, das du realistisch releasen kannst, was oft bedeutet: das kleinste, nicht das ehrgeizigste.
Und dann, und das ist wichtig, sag jemandem, dass du sie beerdigt hast. Post es. Verkünde es. Externe Zeugen machen aus einem privaten Gedanken eine öffentliche Verpflichtung, was genau der Grund ist, warum r/INAT einen laufenden Witz über Devs hat, die sagen: "Ich werde dich in ungefähr 2 Wochen ghosten, sobald alle das Interesse verlieren." Ghosten ist der Default-Zustand von Solo-Arbeit. Ein Projekt laut zu beerdigen ist eine Möglichkeit, das zu durchbrechen.
Der Drang, neu anzufangen, ist das Unbehagen des Fortschritts
Irgendwann mitten in einem nicht-trivialen Projekt kommt ein aufdringlicher Gedanke: "Ich hab so viel gelernt seit dem Anfang. Wenn ich bei null neu starte, könnte ich es so viel besser machen." Dieses Gefühl ist kein Signal, dass du neu anfangen solltest. Es ist ein Signal, dass dein Projekt komplex genug geworden ist, um unbequem zu sein, und dein Gehirn dir eine dopamin-förmige Fluchttür anbietet mit der Aufschrift "fang neu an".
Ein Entwickler hat dasselbe Spiel dreimal neu gebaut. Ein bis zwei Monate pro Neustart. Bei der dritten Version hat er sich die erste nochmal angeschaut und gemerkt, dass er sie eigentlich am liebsten mochte. Drei Monate, direkt umgewandelt in Reue. Varianten dieser Geschichte tauchen in dutzenden Indie-Post-Mortems auf, und der rote Faden ist nie "ich bin froh, dass ich neu angefangen habe". Der rote Faden ist "ich wünschte, ich hätte weitergemacht".
Chaotischer Code ist normal. Jedes laufende Spiel hat ihn. Dein Betriebssystem hat ihn. Die Apps auf deinem Handy haben ihn. Jede Codebase, die du je angefasst hast, wurde von Hacks, Workarounds und Architekturentscheidungen zusammengehalten, die in Monat eins noch okay aussahen und in Monat acht tragisch. Das ist kein Versagen. Das ist die Form von etwas Echtem, das entsteht. Eine saubere, elegante Codebase bedeutet meistens "noch ist nichts wirklich passiert".
Der strukturelle Fix ist eine Warteregel. Wenn du den Drang spürst, neu anzufangen, warte eine Woche. Diskutier nicht mit dem Gefühl. Rechtfertige es nicht. Schreib "erwäge Neustart" mit Datum in eine Notiz und mach weiter. Der Impuls geht meistens in sieben Tagen vorbei. Wenn er nach einer Woche noch da ist, schreib spezifisch auf, was ein Neustart fixen würde, als nummerierte Liste, und frag dann für jeden Punkt: "Kann ich das fixen, ohne neu anzufangen?" Neun von zehn Mal: ja.
Es gibt eine Variante, in der ein Neustart gerechtfertigt ist: ein fundamentaler Engine-Wechsel, ein kompletter Design-Pivot nach Playtest-Daten. Das ist selten. Die meisten Neustarts werden vom Unbehagen komplexer Systeme und vom Kick des Neuanfangs getrieben. Wenn dein Grund für den Neustart-Wunsch "der Code ist jetzt schwer zu bearbeiten" ist: Das ist kein Grund. Das ist der Job.
Konstanz schlägt Inspiration
Das Muster, das Projekte wirklich killt, ist nicht zu wenig Arbeit. Es ist Oszillation. Solo-Devs lieben die Ein-Mann-Armee-Fantasie, die heroische Woche aus Achtzehn-Stunden-Tagen, die im Alleingang den Rückstand aufholt. Was die Fantasie in der Praxis produziert, ist ein Burst, ein Burnout, zwei Wochen schuldbehaftetes Vermeiden, ein halber Tag erzwungene Rückkehr und der nächste Abbruch. Wiederhol das monatelang, bis das Projekt an akkumuliertem Vermeiden stirbt.
Inspiration ist super für Anfänge. Sie ist nutzlos für Enden. Konstanz ist nicht aufregend, aber sie ist das Einzige, das Spiele zuverlässig released.
Konstanz heißt nicht Acht-Stunden-Tage. Sie heißt auftauchen, auch an Tagen, an denen du keinen Bock hast, auch wenn du nur zehn Minuten machst. Der Zehn-Minuten-Trick ist echt und funktioniert: sag dir, dass du nur für zehn Minuten arbeitest, nicht länger. Das ist alles, worauf du dich festlegst. Meistens bricht die Trägheit und du arbeitest am Ende eine Stunde. Manchmal sind es wirklich nur zehn Minuten, und das ist okay, weil zehn Minuten Fortschritt nicht null sind und die Serie am Leben bleibt.
Ein Indie-Dev-Coach hat die Diagnose sauber formuliert: "In neun von zehn Fällen, wenn jemand zu mir kommt und es als Prokrastination wahrnimmt, ist es eigentlich ein anderes Problem in Verkleidung." Dieses andere Problem ist fast immer entweder "ich weiß nicht, was ich als Nächstes tun soll" oder "ich hab mir keine echte Deadline gegeben". Beide sind strukturell. Beide sind lösbar. Keins von beiden löst man, indem man sich mehr anstrengt.
Und dann gibt es die Kehrseite, die widersprüchlich klingt, aber keine ist. Plan deine Downtime. Ungeplante Pausen erzeugen Schuldgefühle. Schuldgefühle erzeugen Vermeidung. Vermeidung killt das Projekt. Geplante Pausen dagegen sind Teil des Prozesses: du erholst dich ohne Schuldgefühl, du kommst mit Energie zurück, und der Rhythmus hält. Nach einem großen Meilenstein plan den freien Tag bevor du ihn dir verdient hast, damit du nicht das Gefühl hast zu fliehen.
Ein r/gamedev-Post bringt es direkt auf den Punkt: "Das echte Leben gewinnt häufiger, und das wöchentliche Gesamtpensum schrumpft." Das echte Leben wird immer gewinnen, wenn du die einzige Person bist, die merkt, wenn es gewinnt. Deshalb ist die Solo-gegen-Team-Debatte selten die echte Frage. Die echte Frage ist, ob bis Freitag irgendjemand auf deine Arbeit wartet.
Setz dir eine echte Deadline (und sag es jemandem)
Eine Deadline ist der Unterschied zwischen "ich arbeite an einem Spiel" und "ich release am 12. Juni". Das Erste ist ein Zustand. Das Zweite ist ein Countdown. Irgendwas an einem Countdown, vor allem wenn andere davon wissen, verdrahtet die Art um, wie du Entscheidungen triffst. Du hörst auf, Dinge hinzuzufügen. Du fängst an zu streichen. Du hörst auf, die Ränder zu polieren, und fängst an, die Essentials rauszubringen. Du hörst auf zu fragen "was könnte ich noch ergänzen?" und fängst an zu fragen "was kann ich streichen und trotzdem den Termin halten?"
Interne Deadlines (die nur du kennst) funktionieren kaum, weil du um 2 Uhr nachts mit dir selbst neu verhandeln kannst und es niemand bemerkt. Externe Deadlines (angekündigt in einem Dev-Log, zu einem Festival eingereicht, auf einer Steam-Seite gepostet) haben Zähne. Andere Leute erwarten etwas. Dieser Druck ist produktiv, auch wenn er unangenehm ist.
Die strukturelle Einsicht, die die meisten Devs übersehen: Eine Deadline ist keine Produktionsquote. Sie ist eine Entscheidungserzwingungs-Funktion. Ihr Job ist, Entscheidungen zu erzwingen. "Ich hab keine Zeit, das einzubauen" ist ein Feature, kein Versagen. Ohne Datum ist jede Entscheidung ein "vielleicht später". Mit Datum wird jede Entscheidung zu "ja oder nein, jetzt".
Ein Devpod-Host hat es brutal direkt gesagt: "Prokrastination ist eigentlich, etwas aufzuschieben, das eine Deadline hat. Wenn du dich nicht auf eine Deadline festgelegt hast, prokrastinierst du nicht einmal. Du driftest einfach." Driften ist schlimmer als prokrastinieren, weil Prokrastination zumindest ein Ziel impliziert.
So wendest du das an.
- Wähl ein Release-Datum. Kein "Ziel-Fenster". Einen spezifischen Tag. Schreib es auf.
- Sag es Leuten. Dev-Log, Discord, E-Mail-Liste, ein Freund. Mindestens eine Person sollte an diesem Tag etwas erwarten.
- Rechne rückwärts. Was muss in Monat 5 wahr sein, wenn du in Monat 6 releasen willst? Was fällt weg, wenn du zurückfällst? Die Cuts vorab zu entscheiden hält dich am Ende aus dem Panikmodus raus.
Und wenn du das Datum später nach hinten schieben musst, schieb es. Ein Datum zu haben, von dem du verschiebst, ist komplett anders als gar kein Datum zu haben.
Die letzten 10% sind die 90%, vor denen dich niemand gewarnt hat
Wenn du noch nie ein Spiel released hast, werden dich die letzten 10 % der Entwicklung überrollen. Es ist nicht das Polieren der schönen Sachen. Es ist ein Berg aus unlustiger, release-kritischer Arbeit, über die niemand redet, bis sie mittendrin sind. Tom Cargill von den Bell Labs hat es vor Jahrzehnten festgehalten: "Die ersten 90 Prozent des Codes brauchen die ersten 90 Prozent der Entwicklungszeit. Die restlichen 10 Prozent des Codes brauchen die anderen 90 Prozent der Entwicklungszeit" (abgerufen 2026-04-10). Das ist kein Witz. Das ist ein Zeitplan.
Über die Post-Mortems, die wir gelesen haben, sieht die dunkle Arbeit ungefähr so aus:
- Jeden einzelnen Sound-Effekt finalisieren: Menü-Klicks, Treffer, Schritte, UI-Feedback
- Die komplette Settings-UI bauen: Lautstärke-Regler, Tastenbelegung, Auflösung, Accessibility-Optionen, ein Credits-Screen
- Icons in fünf verschiedenen Größen für fünf Plattformen
- Splash-Screens in fünf verschiedenen Größen für dieselben Plattformen
- Die Steam-Seitenbeschreibung, Kurzbeschreibung und Tags schreiben
- Screenshots machen, die das Spiel auch wirklich gut aussehen lassen (schwerer, als es klingt)
- Einen Launch-Trailer aufnehmen und schneiden
- Den Publisher-Account einrichten und dutzende Formularfelder ausfüllen
- Lokalisierung (selbst das Englisch-Korrekturlesen dauert länger, als du glaubst)
- QA auf unterschiedlicher Hardware: Tastaturen, Controller, GPUs, Auflösungen
- Schwierigkeits- und Economy-Balancing, Pacing der Progression
- Accessibility-Features: Farbenblind-Modi, Untertitel-Größen, reduzierte Bewegung
- Legal: EULA, Datenschutz, Altersfreigaben via IARC
Nichts davon ist sichtbar. Nichts davon ist lustig. Nichts davon sieht im Screenshot beeindruckend aus. Es ist alles dunkle Arbeit: Aufwand, der keinen sichtbaren Fortschritt erzeugt, aber für einen echten Release absolut notwendig ist. Devs, die nicht wussten, dass das kommt, werden davon zermalmt, weil sie schon sechs Monate drin sind, schon müde sind, und plötzlich ein öder Berg zwischen ihnen und der Ziellinie liegt. Das ist der häufigste Ausstiegspunkt für fast fertige Spiele. Der Friedhof ist voll mit Spielen, die "fast fertig" waren.
Und der Kontext um diesen ganzen Aufwand: SteamDB hat ungefähr 17.889 bis 19.000 Game-Releases auf Steam in 2024-2025 verzeichnet, wobei fast die Hälfte weniger als zehn User-Reviews bekam (abgerufen 2026-04-10). Das ist das Lärm-Level, durch das deine dunkle Arbeit durchdringen muss. Ein halbfertiger Trailer schafft das nicht.
So wendest du das an.
- Bevor du dein Spiel startest, mach die Store-Seite eines erschienenen Indie-Games auf und zähl jedes Element darauf. Das ist deine To-do-Liste, die in Monat 8 auf dich wartet.
- Plan mindestens so viel Zeit für die letzten 10 % ein, wie du für das letzte große Feature gebraucht hast. Wahrscheinlich mehr.
- Heb dir die dunkle Arbeit nicht fürs Ende auf, wenn du es vermeiden kannst. Bau das Settings-Menü früh. Richte die Steam-Seite ein, sobald du darfst. Verteil den Schmerz über die ganze Timeline, statt ihn am Ende zu stapeln.
Wenn du weißt, dass die 90-90-Regel existiert, kannst du die letzten 10 % einplanen, statt von ihnen überrascht zu werden.
Fertigstellen ist eine Entscheidung, kein Zustand
Spiele sind nie "fertig". Sie werden auf einem Qualitätslevel verlassen, mit dem du leben kannst. Klingt zynisch, ist aber der befreiendste Satz in diesem Guide. Es gibt keinen Moment, in dem ein Alert aufpoppt und sagt "Spiel komplett, 100 %, jetzt releasen". Diesen Moment gibt es nicht und gab es nie. Es wird immer ein Feature geben, das du dir wünschst, hinzugefügt zu haben, ein System, das du verfeinern willst, einen Polish-Pass mehr.
Das heißt, Fertigstellen ist nichts, was dir passiert. Es ist eine Entscheidung, die du an einem bestimmten Tag triffst, und die Entscheidung ist auch strukturell. Du kannst dich selbst so aufstellen, dass du sie triffst, oder du kannst dich so aufstellen, dass du sie für immer verschiebst.
Ein Setup, das funktioniert: Schreib vor dem Entwicklungsstart eine "Fertig"-Liste. Die konkreten Features und Inhalte, die, wenn sie alle existieren, ein veröffentlichbares Spiel ergeben. Schreib sie als Feature-Liste, nicht als Qualitätsmesslatte. Qualitätsmesslatten verschieben sich. Du wirst Dinge immer "noch ein bisschen besser" haben wollen. Feature-Listen kann man festhalten: dieses Level ist drin, diese Mechanik ist drin, dieser Boss ist drin, und alles andere ist Post-Launch-Content.
Und während der Entwicklung, jedes Mal, wenn du dich dabei erwischst, "nur noch eine Sache" hinzuzufügen, check sie gegen die Fertig-Liste. Wenn sie nicht drauf steht, kommt sie nicht in den 1.0-Build. Sie kommt auf eine separate "vielleicht später"-Liste. Du kannst sie in einem Patch nachreichen. Du kannst sie in 1.1 nachschieben. Du kannst sie nur nicht jetzt dazupacken, weil "jetzt" der Weg ist, mit nichts am Ende dazustehen.
Manche Devs verstecken sich für immer in der Endlosentwicklung, weil ein unveröffentlichtes Spiel nicht kritisiert werden kann. "Es ist noch nicht bereit" ist ein Schild. Aber der Preis des Versteckens ist enorm: dein Spiel erreicht nie die Menschen, für die du es gemacht hast, und du bekommst nie das eine Ding, das die ganze harte Arbeit wirklich wert macht, nämlich zuzusehen, wie ein Fremder dein Spiel spielt und darauf reagiert.
Selbst Halo 2 ist mit der Hälfte der geplanten Inhalte gestrichen released. Destiny ist nach einem Seitwärts-Redesign released. Wenn Bungie ein unperfektes Spiel shippen kann, kannst du es auch. Der französische Dichter Paul Valéry hat es lange vor uns allen gesagt: "Ein Werk ist nie fertig, nur verlassen." Verlass deins bewusst. Verlass es an einem bestimmten Datum. Verlass es für die Leute, die darauf warten, es zu spielen. Das ist Shippen.
Fragen, die Indie-Devs zum Fertigstellen stellen
Ein paar Fragen tauchen in Indie-Dev-Kreisen immer wieder auf, die Art, die nicht sauber in einen der obigen Abschnitte passt, aber trotzdem dauernd gestellt wird. Kurze, direkte Antworten unten.
Was zählt als "fertig" für ein erstes Indie-Game?
Ein erstes Indie-Game ist fertig, wenn (a) der komplette Core Loop von Anfang bis Ende funktioniert, (b) ein Fremder das Spiel installieren, starten, spielen und beenden kann, ohne hängenzubleiben, und (c) eine Version deiner "Fertig"-Liste, die du vor dem Entwicklungsstart geschrieben hast, komplett abgehakt ist. "Fertig" heißt nicht "perfekt". Es heißt "releasbar". Wenn es läuft und auf deiner vorab geschriebenen Fertig-Liste steht, geht es raus.
Wie lange sollte es dauern, ein Indie-Game fertigzustellen?
Kürzer, als du denkst, länger, als du geplant hast. Ein realistisches erstes Indie-Game sind zwei bis sechs Monate fokussierte Arbeit, nicht zwei bis sechs Jahre. Wenn deine geschätzte Timeline länger als ein Jahr ist und das dein erstes veröffentlichtes Spiel wäre, stimmt dein Scope fast sicher nicht. Streich Features, bis die ehrliche Schätzung in sechs Monate passt, und schlag dann 50 % drauf, weil Menschen schlecht darin sind, Zeit einzuschätzen.
Soll ich ein Projekt begraben, das ich hasse, in das ich aber schon viel Zeit gesteckt habe?
Wahrscheinlich ja. Das Gefühl "ich hab doch schon so viel investiert" ist der Sunk-Cost-Fallacy im Kostüm der Verantwortung, und ein Projekt zu beenden, das du hasst, ergibt selten ein gutes Spiel. Bessere Frage: "Würde ich dieses Projekt heute, mit dem, was ich jetzt weiß, überhaupt anfangen?" Wenn die Antwort nein ist, beerdige es bewusst (siehe Abschnitt 6) und fang etwas Kleines an, das du wirklich fertigstellen kannst.
Wie erkenne ich, ob ich prokrastiniere oder wirklich feststecke?
Wenn du den nächsten konkreten Schritt kennst und ihn nicht gehst, prokrastinierst du. Meistens, weil der Schritt langweilig, beängstigend oder auf einer Detailtiefe unklar ist, die du dir selbst noch nicht eingestanden hast. Wenn du den nächsten konkreten Schritt nicht kennst, steckst du fest, und der Fix ist, den Schritt kleiner zu machen, bis er offensichtlich ist. Feststeckende Devs brauchen eine kleinere Aufgabe. Prokrastinierende Devs brauchen eine Deadline.
Welcher Anteil der Indie-Games wird tatsächlich auf Steam veröffentlicht?
Es gibt keine saubere Zahl, weil unveröffentlichte Spiele nicht gezählt werden. Was wir wissen: 48 % von 23.485 untersuchten Steam-Spielen hatten einen verschobenen Erst-Release, und fast die Hälfte der rund 18.000 Spiele, die 2024-2025 auf Steam erschienen sind, bekamen weniger als zehn Reviews (beides abgerufen 2026-04-10). Das sind die, die es geschafft haben. Die echte Zahl der "versucht, aber abgebrochen" ist viel höher und liegt in Ordnern, über die niemand postet.
Ist es besser, ein kleines mittelmäßiges Spiel fertigzustellen oder ein großes gutes?
Immer das kleine fertige Spiel. Ein fertiges kleines Spiel bringt dir mehr über das Shippen bei als drei unfertige große zusammen. Du lernst in den letzten 10 % Dinge, die du auf keine andere Weise lernen kannst. Du baust außerdem Identitätskapital auf als jemand, der shippt, was später viel wert ist, um von potenziellen Teammates ernst genommen zu werden, wenn es um dein zweites Spiel geht. Niemand rekrutiert aus einem Portfolio von Prototypen.
Du musst nicht allein fertig werden
Alles in diesem Guide ist schwerer, wenn du es allein machst. Scope-Disziplin ist schwerer, wenn niemand deine Ideen in Frage stellt. Konstanz ist schwerer, wenn niemand merkt, dass du einen Tag ausgelassen hast. Deadlines sind optional, wenn nur du davon weißt. Dunkle Arbeit ist seelenzerstörend, wenn du die einzige Person bist, die sich durchschlägt. Und zu entscheiden zu releasen ist furchterregend, wenn du der einzige Mensch bist, der die Entscheidung treffen muss.
Schau zurück auf die Muster in diesem Guide. Zombie-Projekte. Neustart-Spiralen. Woche-6-Drift. Perfektionismus-Loops. Das leise Zusammenbrechen des spielbaren Builds. Die Oszillation zwischen Burst und Burnout. Jedes einzelne wird in Isolation schlimmer, und die meisten werden besser, sobald eine weitere Person mit dir im Loop ist.
Die Entwickler, die konstant Spiele fertig bekommen, haben tendenziell eine strukturelle Eigenschaft gemeinsam: Sie machen es nicht allein. Nicht unbedingt in einem großen Team. Oft einfach mit einer weiteren Person. Ein Co-Dev. Ein Accountability-Partner. Jemand, der darauf zählt, dass das Leveldesign bis Freitag fertig ist. Jemand, der merkt, wenn sie leise werden. Jemand, der am Donnerstag den spielbaren Build sehen muss, weil er versprochen hat, ihn zu testen.
Das ist keine neue Idee. Das ist die Idee, die der Rest der Spieleentwicklung längst kennt. Studios existieren nicht, weil Studiobesitzer gern Lohnabrechnungen machen. Sie existieren, weil ein Spiel fertigzustellen meistens kein Job ist, der im Vakuum erledigt wird. Die Frage für Indie-Devs war schon immer: Wie bekommst du die strukturellen Vorteile eines Studios, ohne deine IP, deine kreative Kontrolle oder deine Abende und Wochenenden aufzugeben?
Genau diese Frage will Clowdr beantworten. Es ist ein begleitetes Setup, in dem Indie-Devs sich mit echter Struktur zusammentun (ein Playbook, echte Accountability, klare schriftliche Vereinbarungen) und Spiele auch wirklich fertig bringen. Kein totgelaufenes Discord-Projekt, bei dem in Woche 3 alle das Interesse verlieren. Ein Ort, der ums Fertigwerden herum gebaut ist. Mitwirkende behalten die vollen Rechte an ihrer Arbeit. Künstler und Komponisten werden früh als kreative Partner dazugeholt, nicht als Dienstleistungs-Theken am Ende eines Projekts. Jede Vereinbarung wird schriftlich festgehalten, bevor jemand etwas beisteuert.
Ein r/gamedev-Post-Titel fasst zusammen, wie es sich von innen anfühlt: "cursed to work alone" (verflucht, allein zu arbeiten). Das ist kein Charakterzug. Das ist, was passiert, wenn du lange genug versuchst, einen Mehr-Personen-Job allein zu erledigen.
Du bist nicht faul. Du bist nur allein.
Wenn du bis hierhin gelesen hast, kennst du die Muster schon. Du hast die meisten davon wahrscheinlich selbst durchlebt. Jetzt geht es darum, sie zu durchbrechen, und der sauberste Weg, sie zu durchbrechen, ist, aufzuhören, das hier allein zu versuchen.
Trag dich auf die Clowdr-Warteliste ein und bring das nächste Projekt mit Leuten fertig, die bis Freitag auf deine Arbeit warten.