Scope Creep killt dein Spiel: Praktischer Leitfaden zum Features streichen

Scope Creep in der Spielentwicklung sieht aus wie ein zusätzliches Feature, dann noch eins, dann sechs Monate Arbeit an Systemen, die niemand verlangt hat. Dieser Leitfaden gibt dir ein Fünf-Fragen-Framework, mit dem du entscheidest, was rausfliegt, ein Backlog-System, das Ideen festhält, ohne sie zu killen, und eine Diagnose, mit der du Scope Creep von der Iteration unterscheidest, die Spiele tatsächlich besser macht.

Was du vorher brauchst: deine ehrliche Liste der Features in Arbeit, ein Spreadsheet oder Board, das du wirklich nutzt, und die Bereitschaft, bei etwas falsch zu liegen, was du schon gebaut hast.

1. Diagnostiziere das eigentliche Problem: Du bist nicht undiszipliniert, du bist unkontrolliert

Die meisten Scope-Creep-Ratgeber fangen mit einer Motivationsrede über Willenskraft an. Falsche Diagnose.

Du hast das Crafting-System, den Dialogbaum und die Fraktions-Reputation nicht eingebaut, weil dir die Disziplin fehlt. Du hast sie eingebaut, weil niemand zwischen dir und „wäre es nicht cool, wenn ..." stand. Tim Ruswick hat es in einem Vortrag über Over-Scoping klar gesagt: „Warum scopen Leute ihr Spiel zu groß? Sie wollen glauben, dass das die richtige Entscheidung ist ... sie wollen glauben, dass mehr Zeit in etwas zu stecken es besser macht."

Das ist der Trick, den dein Hirn mit dir spielt. Du willst, dass das Spiel erfolgreich wird. Das Wollen fühlt sich in dem Moment genauso an wie ein weiteres Feature wird es erfolgreich machen. Also baust du eins ein. Dann noch eins. Drei Monate später wachst du auf und starrst auf einen unmöglichen Berg.

Du bist nicht faul. Du bist ohne Backup. Scope Creep ist keine schlechte Planung — es ist das, was passiert, wenn niemand deine Arbeit prüft. Ein Solo-Dev hat keinen, der sagt: „Das hatten wir besprochen, steht nicht im Plan." Woche 3 bis 6 von jedem Solo-Projekt sehen gleich aus: Die ursprüngliche Idee funktioniert, der Prototyp ist spielbar, und dann trudeln die „Was wäre wenn"-Ideen schneller ein, als du sie bauen kannst.

Das ist dasselbe Muster, das wir bei warum 90% der Indie-Spiele in der Ideenphase sterben diagnostiziert haben. Scope Creep ist die Art, wie es dich erwischt, wenn du Woche eins überlebt hast.

Der Fix ist nicht mehr Willenskraft. Der Fix ist Struktur: eine Entscheidungsregel, die du bei jedem Feature durchläufst, ein Backlog, damit keine Idee verloren geht, und idealerweise jemand, der bis Freitag auf deine Arbeit zählt.

2. Trenne Scope Creep von gesunder Iteration, bevor du etwas streichst

Bevor wir zum Streichen kommen, müssen wir etwas klarstellen, bei dem das Internet ständig danebenliegt.

Nicht jedes Scope-Wachstum ist Scope Creep. Spiele entstehen iterativ. Ein Feature, das auf dem Papier spannend klang, kann im Prototyp flachfallen. Ein „nur noch eine Sache"-Nebenexperiment kann sich als der Diamant herausstellen, der dein Spiel verkauft.

Einem Dev, von dem ich gehört habe, baute ein komplettes Kampfsystem in ein ursprünglich simples Axt-Wurf-Spiel ein. Lehrbuchbeispiel für Feature Creep, oder? Bis das Playtesting zeigte, dass das ursprüngliche Design furchtbar langweilig war und das Kampfsystem zum stärksten Verkaufsargument des Spiels wurde. Es zu streichen hätte das Spiel gekillt.

Das Team von CD Projekt Red hat eine Variante davon öffentlich gelernt. Senior Level Designer Miles Tost hat gesagt, dass Features und Scope zu streichen „ein ganz normaler Teil der Entwicklung" ist: Dual-Wielding, U-Bahnsysteme, Wall-Running, alles aus Cyberpunk 2077 rausgeflogen. Aber nicht jeder Cut ist Schadensbegrenzung, und nicht jedes Hinzufügen ist Creep.

Der Unterschied liegt darin, ob du es bewusst tust.

Ist Scope Creep immer schlecht? Nein. Scope Creep ist unkontrollierte Iteration: Features, die eingebaut werden, weil sie cool klingen, ohne Abgleich mit dem Kern deines Spiels. Gesunde Iteration ist das Gegenteil. Du baust ein, playtestest, misst gegen deine Design-Pillars und behältst oder streichst basierend auf dem, was der Playtest gezeigt hat. Gleiche Handlung, komplett anderer Prozess.

Feature Creep in der Indie-Spielentwicklung killt Projekte, wenn er sich unbemerkt einschleicht. Der Test ist nicht, ob du ein Feature eingebaut hast. Der Test ist, ob du laut erklären könntest, welchen deiner Design-Pillars das Feature dient und was es verdrängt. Wenn du das nicht kannst, hast du Scope Creep. Wenn du es kannst, hast du Iteration.

Der Rest dieses Leitfadens geht davon aus, dass du an dem Punkt bist, an dem die ehrliche Antwort „Ich weiß es nicht mehr" lautet. Hier ist, was du tun kannst.

3. Prüfe jedes Feature mit einem Fünf-Fragen-Entscheidungsframework

Die meisten Scope-Cutting-Ratgeber hören bei „gnadenlos streichen" auf. Hier kommt das Wie.

Zieh deine Feature-Liste hervor. Für jeden Eintrag, auch die, die du schon halb gebaut hast, läufst du diese fünf Fragen durch.

1. Verbessert es das Erlebnis der Spielerin, oder nur deins?

Nicht „wären andere Devs beeindruckt?" Nicht „macht es Spaß zu bauen?" Hat die Spielerin tatsächlich was davon?

Tim Ruswick erzählt, wie er ein aufwendiges Crafting-System für eines seiner Spiele baute. Rezepte, Zutaten, Power-Kombinationen, technisch alles beeindruckend. Andere Entwickler liebten es. Für Spielerinnen war es unnötige Komplexität. Er hat es rausgeworfen, und das Gesamterlebnis ist besser geworden.

2. Nimmt das Einbauen etwas anderem weg?

Jarrel Seah, der an einem Taktikspiel arbeitete, hat es gut formuliert: „Es geht nicht nur darum, ob du etwas Cooles hinzufügst, sondern ob das, was du hinzufügst, etwas anderem etwas wegnimmt."

Er gab einer normalen Einheit dieselbe Mörser-Fähigkeit wie dem Boss. Die Einheit war für sich cool. Aber sie ließ den Boss, der der dramatische Höhepunkt des Gefechts sein sollte, weniger besonders wirken. Die Einheit musste raus, weil sie Wirkung von etwas Wichtigerem gestohlen hat.

Jedes Feature lebt in einem System. Eins einzubauen verändert das Gleichgewicht der anderen. Wenn das, was du bauen willst, etwas anderes in deinem Spiel weniger interessant macht, tauschst du, du addierst nicht.

3. Fördert es das Verhalten, das du wirklich willst?

Noch eine Lektion aus demselben Taktikspiel: Der Dev packte Loot in zerstörbare Kisten. Klang auf dem Papier super. In der Praxis wurde die optimale Strategie, Gegner herumzulotsen und systematisch jede Kiste zu zerschlagen. Spielerinnen spielten das Spiel auf die langweiligste mögliche Art, weil das System ihnen leise genau das nahelegte.

Frag, was das Feature anreizt, nicht was du hoffst, dass es anreizt. Wenn die Antwort „das Gegenteil vom Spiel, das ich bauen will" lautet, raus damit.

4. Würdest du es nochmal bauen mit dem, was du jetzt weißt?

Sunk Cost lügt. Wenn du heute neu anfangen würdest, mit allem, was du aus dem Playtesting und dem aktuellen Stand des Spiels gelernt hast: Würde dieses Feature auf der Liste stehen?

Wenn die Antwort nein ist, behältst du es, weil du es gebaut hast, nicht weil es dazugehört.

5. In welchen Eimer gehört es: Showstopper, Game-Changer oder Filler?

Sortiere jedes Feature in eine von drei Kategorien:

• Showstopper. Das Spiel wäre ohne es kein Spiel. Ein Platformer braucht irgendwas, das springt. Ein Taktikspiel braucht ein Zugsystem. Streiche das und du hast kein Produkt mehr.
• Game-Changer. Das neuartige Element, das dein Spiel von jedem anderen in seinem Genre unterscheidet. Echte Investition wert.
• Filler. Netter Feinschliff, sorgt für Atmosphäre, aber nicht tragend. Fliegt immer zuerst.

Sei ehrlich, in welchen Eimer Sachen tatsächlich gehören, nicht in welchen du willst, dass sie gehören. Die meisten Devs merken, dass die Hälfte ihrer „Game-Changer" eigentlich Filler ist, an dem sie hängen.

Alles, was bei Frage 1, 2 oder 3 scheitert oder im Filler-Eimer landet, kommt auf die Cut-Liste. Wie Jarrel sagt: „Es ist komisch, dass etwas zu streichen das Spiel tatsächlich besser machen kann, aber genau so ist es."

4. Streiche das Feature, in das du am meisten Arbeit gesteckt hast (ja, genau das)

Jetzt der harte Teil.

Das Feature, an dem du drei Wochen gebaut hast, auf das du heimlich am stolzesten bist, ist wahrscheinlich das Erste, was du streichen musst.

Tim Ruswick hat als Teenager jahrelang ein riesiges Sci-Fi-Universum gebaut: Lore, Fraktionen, Planeten, alles dabei. Jahre später, als er ein völlig anderes Spiel machte, konnte er das Universum nicht loslassen. Er presste es in Projekte, die nichts damit zu tun hatten. Es hat gedauert, bis er gemerkt hat, dass das Universum nicht dem Spiel diente. Er diente dem Universum.

„Manchmal ist das, woran wir am härtesten gearbeitet haben, das Letzte, was im Spiel sein sollte, und das habe ich auf die harte Tour gelernt." — Tim Ruswick

Hart an etwas zu arbeiten heißt nicht, dass es dazugehört. Dein Hirn hat einen eingebauten Bias, Dinge zu schützen, in die du Aufwand gesteckt hast. Genau deshalb ist Sunk Cost der schlechteste Grund, ein Feature zu behalten. Die Frage ist nicht wie viel hat das Bauen gekostet. Die Frage ist gehört es ins fertige Spiel, ja oder nein.

Es gibt noch eine heimtückischere Version davon: „Es ist noch nicht fertig" als Versteck benutzen. Endlose Entwicklung ist eine Art, die beängstigenden Teile zu umgehen. Marketing. Launch. Reviews. Echte Spielerinnen, die dir sagen, was sie denken. Wenn das Spiel nie released wird, kann nichts davon passieren.

Sei ehrlich: Behältst du das Feature, weil das Spiel es braucht, oder weil du es brauchst?

5. Nutze subtraktives Design: Streiche Kategorien, nicht Zählwerte

Hier ist der Fehler, den die meisten Devs machen, wenn sie „macht kleinere Spiele" hören. Sie machen dasselbe Spiel mit weniger Leveln.

Das ist nicht kleiner. Das ist kürzer. Andere Probleme.

Ein kleineres Spiel ist ein Spiel mit weniger Arbeitskategorien. Die Indie-Spiele, die shippen und verkaufen, nutzen etwas namens subtraktives Design: Sie streichen absichtlich ganze Kategorien von Features, um den Rest auf höherem Niveau zu polieren. Wie es ein Creator formuliert hat: „Eine gute Idee ist eine, mit der du mit weniger mehr machen kannst. Eine, mit der du Sachen aus dem Spiel rausnehmen kannst, ohne dem Spiel etwas wegzunehmen."

Hier sind drei konkrete Moves.

Weniger Charaktere oder gar keine.

Charaktere sind teuer. Sie brauchen Animation, Dialog, Verhalten, Interaktionssysteme. AAA-Studios haben ganze Teams, die sich mit der Beziehung zwischen Charakter, Controls und Camera beschäftigen: den „drei C's". Du bist nicht AAA.

Clevere Indies finden Wege drumherum. Gone Home erzählt eine reiche Geschichte über eine Familie durch Dokumente und Artefakte. Keine Charaktere auf dem Bildschirm. Portal steckt dich in eine verlassene Anlage, wo die Abwesenheit von Menschen die Stimmung ist. Dredge macht ein Boot zum Hauptcharakter. Pacific Drive gibt dir ein lebendiges Auto. Autos und Boote sind einfacher zu animieren als Menschen. Bau dein Spiel um das herum, was du tatsächlich bauen kannst.

Kleinere Welten oder gar keine Level-Geometrie.

Cyberpunk 2077 kam mit 10 Level Designern raus. Elden Ring hatte 16. Assassin's Creed Valhalla hatte über 40. Wenn du solo oder zu zweit versuchst, eine Open World zu bauen, trittst du mit einem Bruchteil der Ressourcen dagegen an. Du wirst verlieren.

Überleg stattdessen Formate, die keine weitläufigen Umgebungen brauchen. Coffee Talk und VA-11 Hall-A schaffen reiche Spielwelten, die du nie physisch erkundest. Charaktere kommen zu dir. Papers, Please macht aus Dokumentenprüfung überzeugendes Gameplay ohne einen einzigen begehbaren Level. Exit 8 schickt Spielerinnen durch denselben Korridor im Loop und macht den Loop selbst zur Mechanik.

Weniger Mechaniken oder „Genre-Descoping".

Nimm ein Element aus einem größeren Genre und mach es zum ganzen Spiel:

• Tower Defense ist entstanden, indem Echtzeitstrategie auf reines Basebuilding runtergeschrumpft wurde
• Backpack Hero nimmt das Inventarmanagement aus Dungeon Crawlers und macht es zum ganzen Spiel
• Vampire Survivors reduziert das Action-RPG auf seinen ursprünglichsten Loop

Du bekommst immer noch den thematischen Reiz des größeren Genres, aber du hast ganze Feature-Sets rausgeschmissen, indem du dich auf eine Sache konzentrierst. Wie es die Schule des subtraktiven Designs formuliert: „Du nimmst ein genussvolles Element aus einem größeren Spiel und bläst es auf, bis es das ganze Spiel ist."

Eine gute subtraktive Entscheidung nimmt etwas von deiner Arbeitslast weg und fügt dem Spielerlebnis etwas hinzu. Das ist das Ziel. Wenn der Cut das Spiel schlechter macht, war es kein subtraktives Design. Es war nur ein Cut.

6. Baue ein Backlog, damit gestrichene Features warten können

Features zu streichen klingt brutal. Muss es nicht sein. Das Problem mit den meisten „streich es einfach"-Ratgebern ist, dass sie nicht sagen, wohin die gestrichene Idee geht, und wenn die Antwort „in den Müll" lautet, findest du Gründe, nicht zu streichen.

Bau ein Backlog. Hier ist die Version, die tatsächlich funktioniert:

1. Ein Spreadsheet oder Board. Jede Idee kommt drauf. Keine Idee wird im Moment abgelehnt. Keine Idee wird im Moment committed. Jedes Feature, jeder Vorschlag, jedes „wäre es nicht cool, wenn ...". Alles auf die Liste.
2. Tagge jeden Eintrag mit dem Design-Pillar, dem er dient. Kerngameplay? Polish? Narrative? Immersion? Wenn er sich keinem Pillar zuordnen lässt, ist das schon mal eine rote Flagge.
3. Arbeite in Zeitblöcken. Nenn sie Sprints, Cycles, Monate, was auch immer. Jeder Block hat ein klares Thema und eine feste Menge Zeit.
4. Zu Beginn jedes Blocks ziehst du aus dem Backlog. Basierend auf dem Thema und deiner verbleibenden Entwicklungszeit. Alles, was du nicht ziehst, bleibt auf der Liste als „noch nicht". Nicht „nein".

Das funktioniert aus drei Gründen.

Erstens gehen Ideen nicht verloren. Dieser „verrückte" Vorschlag von vor drei Monaten sieht vielleicht im Rückblick brillant aus, und das Backlog erinnert sich daran.

Zweitens, wenn du mit Teammates arbeitest, zerstört das sofortige Ablehnen von Ideen die Moral. Ein Dev hat das erklärt: „Wenn du jede Idee blockst, machen die Leute zu und hören auf, überhaupt Ideen zu bringen." Ein Backlog ersetzt „nein" durch „noch nicht, wir evaluieren es zu Beginn des nächsten Blocks". Das ist keine Ablehnung. Das ist ein Prozess.

Drittens schützt es dich vor dir selbst. Wenn eine neue Feature-Idee um 1 Uhr morgens auftaucht und sich wie das Wichtigste auf der Welt anfühlt, fängt das Backlog sie ab. Das Du von morgen, mit klarerem Kopf, entscheidet, ob sie in den nächsten Block gehört.

Hier wird ein zweites Paar Augen auch tatsächlich wichtig. Ein Backlog ist tausendmal stärker, wenn jemand, der nicht emotional an deinen 1-Uhr-Ideen hängt, mit dir draufschaut. Wenn du abwägst, ob der Solo-Grind noch funktioniert, geht Solo-Dev vs. Team die Tradeoffs durch.

7. Wähle ein Ship-Date und plane rückwärts

Hier steht oder fällt Scope Management in der Indie-Entwicklung. Und es ist die Umkehrung davon, wie die meisten Devs planen.

Die Standard-Planung ist Feature-first: „Hier sind die Features, die ich will. Wie lange dauern die? Das ist mein Ship-Date." Das Problem ist, dass das Ship-Date eine Variable ist, was bedeutet, dass es eine Lüge ist. Es gibt immer ein weiteres Feature, einen weiteren Polish-Durchgang, einen weiteren Bug. Das Datum verschiebt sich. Und verschiebt sich. Und irgendwann stirbt das Spiel.

Der Fix ist, es umzudrehen. Wähl zuerst das Ship-Date. Arbeite rückwärts. Was in das Fenster passt, ist das Spiel.

Derek Yu, der Schöpfer von Spelunky, hat argumentiert, dass die beste Metrik, um ein Projekt zu scopen, nicht dein Skill-Level ist. Es ist der Scope deiner bisher fertiggestellten Spiele. Wenn das größte Spiel, das du bisher released hast, drei Monate gedauert hat, scope dein nächstes auf vier, nicht achtzehn.

Das Dead State Postmortem erzählt die andere Hälfte der Geschichte. DoubleBear weigerte sich, große Features zu streichen, und hat dafür mit einem vollen Jahr Verspätung bezahlt. Scope zu schützen hat Kosten. Ihn zu streichen hat Kosten. Die Frage ist, welche Kosten du lieber trägst und wann.

Und für die Extremversion der Scope-Lähmung: Jason Schreiers Reportage über Anthem zeigt, dass BioWare fast sieben Jahre an dem Spiel gearbeitet hat, aber erst in den letzten 18 Monaten in die echte Produktion eingestiegen ist. Sieben Jahre Unentschlossenheit, dann 18 Monate Panik. Das passiert, wenn niemand die Autorität oder die Nerven hat zu sagen: „Das ist das Spiel, das ist das Datum, das passt rein."

Noch ein praktischer Trick: Bau zuerst das Ende. Rosstin Murphys Regel, aus einem „Finish Your Game"-Beitrag für Game Developer, ist direkt: „Wenn eine Person vom Anfang deines Spiels bis zum Ende kommt, ohne dass das Spiel abstürzt, ist dein Spiel fertig." Kommt so schnell wie möglich zum Endzustand des Spiels. Jetzt hast du ein komplettes Spiel, auch wenn es hässlich ist. Jedes Feature danach ist ein Upgrade eines funktionierenden Produkts, keine Wette auf ein imaginäres.

Wähl das Datum. Bau das Ende. Plane rückwärts. Das Spiel shipped.

Typische Fallstricke

Ein paar Fallen, die Devs erwischen, die technisch gesehen alle obigen Ratschläge gelesen haben und trotzdem bei einem zu großen Spiel landen.

Features streichen, aber Content behalten. Von 40 Gegnern auf 10 kürzen ist kein subtraktives Design. Das ist dasselbe Spiel mit dünnerem Content. Du hast nicht das Feature gestrichen, du hast den Feinschliff gestrichen. Streiche die Kategorie.

Die schwersten Systeme behalten und die ship-kritischen streichen. Dev-Hirne lieben schwere Probleme. Ergebnis: Die prozedurale Generierung bleibt, das Speichersystem wird zu „machen wir später". Dann kann das Spiel nicht shippen, weil es buchstäblich nicht speichern kann.

Das Backlog als Friedhof behandeln. Wenn nichts jemals aus dem Backlog ins Spiel wandert, ist es ein Mülleimer mit schönerem Namen. Review es zu Beginn jedes Cycles. Dinge wandern rein und raus.

„Kleiner" mit „kürzer" verwechseln. Kürzere Spiele sind immer noch große Spiele, wenn sie dieselbe Anzahl Systeme haben. Kleiner heißt weniger Teile, nicht weniger Content.

Was jetzt zu tun ist

Drei Dinge ab hier.

1. Öffne deine Feature-Liste und laufe die fünf Fragen bei jedem Eintrag durch. Überspring nicht die, die du liebst. Die sind genau die, für die das Framework da ist.
2. Starte heute ein Backlog. Spreadsheet, Trello, Notion, Linear, was auch immer du morgen tatsächlich öffnest. Der erste Eintrag ist jede Idee, die du im Kopf mit dir rumgetragen hast.
3. Wähl ein Ship-Date. Schreib es irgendwohin, wo du es jeden Morgen siehst. Arbeite rückwärts.

Und wenn das eigentliche Problem nicht dein Scope-Instinkt ist, sondern dass niemand deine Arbeit prüft, ist das eine andere Art von Fix.

Du bist nicht faul. Du bist ohne Backup. Scope Creep stirbt, wenn jemand bis Freitag auf deine Arbeit zählt. Clowdr ist ein Team: eine strukturierte Gruppe von Indie-Devs, Artists und Komponistinnen, die gemeinsam Spiele shippen. Du behältst alle Rechte an deiner Arbeit. Jemand wartet auf deinen Freitags-Build. Scope-Entscheidungen hören auf, ein privater Kampf mit deinem eigenen Kopf zu sein.

Trag dich in die Clowdr-Warteliste ein und shippe ein kleineres Spiel mit einem Team, das durchzieht.

Mehr darüber, was die letzten 10% erfordern: der komplette Leitfaden, um dein Indie-Spiel fertigzustellen.