Das Vertical-Slice-Protokoll: So beweist du, dass dein Indie-Game funktioniert, bevor du es skalierst

Öffne deinen „Friedhof-Ordner". Du weißt, welchen ich meine. Ein Incremental Game, etwas im Stil von Vampire Survivors, ein wellenbasierter FPS-Arena-Shooter. Zwölf Projekt-Ordner, jeder mit einer README aus Woche eins, die versprochen hat: Dieses Mal wird's anders.

Keines dieser Projekte hat den Punkt erreicht, an dem die Core Loop von Anfang bis Ende funktioniert, mit echten Assets in der Szene und Musik im Hintergrund. Sie sind in der Mitte stehengeblieben. Systeme waren „fast verdrahtet". Das zweite Level war „geblockt". Du wolltest „nächste Woche" playtesten.

Was ein fertiges Indie-Game von einem Zombie-Projekt trennt, ist selten Talent. Es ist, dass die fertigen Projekte einen bestimmten Checkpoint erreichen: den Vertical Slice — einen polierten Querschnitt des Spiels, von Anfang bis Ende, der beweist, dass das Ganze machbar ist. Die fertigen Projekte behandeln den Slice als Deadline. Die toten behandeln ihn als Wunsch.

Dieser Artikel ist Clowdrs Vertical-Slice-Protokoll: sieben Schritte, um zu beweisen, dass dein Spiel funktioniert, bevor du es skalierst — und der eine strukturelle Grund, warum Solo-Entwickler meistens daran scheitern.

Prototyp vs. Vertical Slice vs. MVP

Die meisten Indie-Projekte sterben, weil der Entwickler das falsche Artefakt gebaut hat. Rami Ismail, Mitbegründer von Vlambeer, bringt es am klarsten auf den Punkt: Prototypen fragen, ob du das Spiel machen solltest, und Vertical Slices fragen, ob du es kannst.

Drei verschiedene Fragen, drei verschiedene Antworten:

Artefakt	Frage	Fidelity	Zielgruppe
Prototyp	Sollten wir das machen? Macht die Loop Spaß?	Hässlich. Überall Platzhalter.	Du und ein, zwei Playtester.
Vertical Slice	Können wir das machen? Ist es in Qualität baubar?	Nahe am Shipping. Eine polierte Version jeder Disziplin.	Mitstreiter, Publisher, Backer.
MVP	Verkauft es sich? Lohnt sich das ganze Spiel zu shippen?	Feature-minimal, von Anfang bis Ende spielbar.	Spieler.

Wenn du Art polierst, bevor deine Loop Spaß macht, baust du einen Slice, wo du einen Prototypen gebraucht hättest. Wenn du sechs Monate an einem Level arbeitest, bevor du weißt, ob der Rest des Spiels zusammenpasst, baust du einen Slice, wo du ein MVP gebraucht hättest. Die meisten Indie-Tode lassen sich auf einen dieser beiden Fehler zurückführen.

Was ein Vertical Slice wirklich ist

Ein Vertical Slice sind 10 bis 30 Minuten deines Spiels in etwa der Qualität, in der du es shippen würdest. Der Publisher-Standard, den Xsolla auf seinen Funding-Seiten nennt, ist exakt diese Spanne.

Das entscheidende Merkmal ist „vertical" — der Slice schneidet durch jede Disziplin. Nicht nur Code, nicht nur Art. Er enthält:

• Ein funktionierendes Stück der Core Loop — nicht das Tutorial, nicht den Endboss, sondern einen Abschnitt, der repräsentativ für Minute 12 ist
• Echte Art-Assets in der Qualität, die du shippen willst, für genau diesen Abschnitt
• Musik und Sound, die den Ton setzen
• UI im finalen Stil
• Jeweils ein Exemplar jedes Gegnertyps, jeder Item-Klasse oder jedes Systems, das der Slice braucht

Was er nicht ist: eine Feature-Liste. Ein Slice ist ein Querschnitt. Wenn du dir vorstellen kannst, den Rest des Spiels in dieser Fidelity zu bauen, hast du einen Slice. Wenn der Slice aus zehn Korridoren ohne Kampf besteht, hast du keinen.

Die Methode geht auf Mark Cernys DICE-Talk von 2002 zurück — von dem viele Indies gehört haben, ohne ihn gelesen zu haben. Ein Indie-Dev-Panel hat Cernys Punkt so zusammengefasst: Kann ich einen Fünf-Minuten-, Drei-Minuten-, Ein-Level-Schnappschuss davon machen, wie sich das Spiel anfühlen würde, wenn es wirklich komplett fertig wäre? Solange du das nicht hinbekommst, ist es Zeitverschwendung, beim Rest des Spiels „in die Breite zu gehen".

Was du brauchst, bevor du anfängst

Drei Voraussetzungen. Wenn eine fehlt, fang mit dem Slice noch nicht an.

1. Ein Prototyp, der beweist, dass die Loop Spaß macht. Du hast „Sollten wir das machen?" schon beantwortet. Wenn nicht, bau zuerst den Prototypen.
2. Ein Mensch am anderen Ende einer Deadline. Nicht du selbst. Ein Teammitglied, eine Playtest-Gruppe, ein Peer-Review-Call, ein Publisher-Pitch.
3. Die Bereitschaft, den Slice wegzuwerfen. Teile davon werden Fakes sein. Teile werden neu gebaut, sobald du das ganze Spiel verstehst. Wenn der Slice zu Production-Code werden muss, wirst du vorab optimieren und am Ende nichts shippen.

Das Vertical-Slice-Protokoll

Sieben Schritte. In dieser Reihenfolge.

Schritt 1: Benenne das eine Risiko, das du eliminierst

Ein Slice tötet ein Risiko. Wähle es, bevor du anfängst. Typische Risiken:

• Production-Feasibility. Kann ein Ein- bis Drei-Personen-Team diese Qualität für ein ganzes Spiel shippen?
• Signature-Mechanik. Skaliert das eine einzigartige Ding auf 15 Stunden Gameplay?
• Art-Pipeline-Durchsatz. Kannst du tatsächlich genug Assets nach Plan produzieren?
• Tonale Kohärenz. Fühlt sich das Spiel an wie das, was du auf die Serviette geschrieben hast?

Schreib das Risiko an den Anfang deines Slice-Plans. Wenn der Slice es nicht eliminiert, baust du keinen Slice. Du baust eine Demo.

Schritt 2: Wähle den Querschnitt

Nicht das Tutorial. Nicht den Endboss. Einen Abschnitt, der repräsentativ für den durchschnittlichen Moment deines Spiels ist — die Zone, in der die Main Loop mit voller Kraft läuft, der Spieler sein Core-Toolkit hat und die Mechaniken so interagieren, wie sie es im ganzen Spiel tun werden.

Wenn du nicht beantworten kannst, „was passiert in Minute 12 meines Spiels?", bist du nicht bereit für Schritt 2. Zurück zum Prototypen.

Schritt 3: Setze eine Deadline mit einem Menschen am anderen Ende

Das ist der Schritt, den jeder andere Vertical-Slice-Guide überspringt — und der, der das Protokoll zum Funktionieren bringt.

Eine Deadline für dich selbst ist ein Wunsch. Publisher wissen das — sie setzen die Deadline für dich. AAA-Producer wissen das — sie setzen sie durch. Solo-Indies, die glauben, dass das Datum auf ihrem Trello-Board real ist, wissen es noch nicht.

Finde einen Menschen. Ein Teammitglied, eine Playtest-Gruppe, einen Peer-Review-Call, ein Kickstarter-Vorschauvideo, einen Konferenz-Demo-Slot. Sag ihnen, dass du ihnen den Slice an einem bestimmten Tag zeigst. Jetzt hast du einen Vertical Slice. Ohne diesen Schritt hast du ein offenes Polier-Hobby.

Schritt 4: Deckle den Scope mit einer Subtraktionsliste

Schreib auf, was du nicht machst. Jedes System, jeder Gegner, jedes Item, jedes Level, jeder Modus, jedes Feature, jeder Sound — jeder bekommt eine Zeile und das Label „nicht im Slice".

Wayline benennt das Fehlermuster „dein Slice wird zu einem Mini-Game": Du startest mit einem Gegner, fügst einen Boss hinzu, eine Waffe, ein ganz neues System. Der Slice ist jetzt ein komplettes Projekt — nur schlechter geplant.

Die Subtraktionsliste ist tragend. Jedes Mal, wenn du etwas hinzufügen willst, checkst du zuerst die Liste. Wenn das Neue auf der Liste steht, ist die Antwort Nein. Die Liste ist das Einzige, was dich vor dir selbst schützt.

Schritt 5: Fake die Systeme, die du nicht eliminierst

Echte Systeme brauchen echte Zeit. Du eliminierst ein Risiko (Schritt 1). Fake alles andere.

• Hardcode Gegner-Stats, statt ein Data-System zu bauen
• Eine gescriptete Cutscene statt eines Cutscene-Tools
• Platzhalter-Inventar-UI statt des finalen Item-Systems
• Ein Korridor mit zwei Abzweigungen statt einer prozeduralen Map

Label jeden Fake. Schreib // FAKE in den Code, „PLATZHALTER" in die Szene, „ROUGH" auf die Audio-Tracks. Geoff Ellenor benennt die Falle klar: „Wir faken oft die präsentierten Systeme, weil die Content-Stichprobe super klein ist und wir damit durchkommen. Das ist ein Fehler." Das Labeling macht die Fakes sichtbar, damit du sie nicht mit echtem Fortschritt verwechselst, wenn du die Produktion planst.

Schritt 6: Shippe den Slice an eine Zielgruppe bis zur Deadline

Egal, in welchem Zustand der Slice am Deadline-Tag ist — du shippst ihn.

Nicht „wenn er bereit ist". Nicht „noch eine Woche". An dem Datum, das du einem Menschen zugesagt hast. Der Slice ist fertig, wenn die Deadline getroffen wird. Das ist die Definition.

Playteste ihn live, wenn du kannst. Zeichne die Session auf, wenn nicht. Sammle Reaktionen. Schreib sie auf. Wenn deine Zielgruppe ein Teammitglied ist, lass es spielen. Wenn es ein Publisher-Call ist, schick den Build. Wenn es eine Peer-Gruppe ist, screen-share.

Der Slice existiert, um Feedback zu produzieren. Wenn du nicht shippst, gibt es kein Feedback. Ohne Feedback sind die nächsten sechs Monate Rätselraten.

Schritt 7: Geh durch das Gate

Der Slice ist keine Feier. Er ist ein Entscheidungspunkt. Du hast drei Optionen:

• Das Projekt beerdigen. Der Slice hat bewiesen, dass das Spiel in Shipping-Qualität keinen Spaß macht, oder dass die Pipeline den vollen Scope nicht tragen kann. Geh weg. Das ist der Slice, der seine Arbeit macht.
• Den Scope pivoten. Der Slice hat gezeigt, dass das echte Spiel kleiner, kürzer oder anders geformt ist als der Plan. Kürzen, umschreiben, neu planen.
• In die Breite gehen. Der Slice funktioniert. Jetzt baust du den Rest auf dieser Qualitätsstufe aus.

Volition hat den Slice auf der GDC 2015 genau als diese Art von Gate beschrieben: ein Werkzeug, um zu entscheiden, ob das Team bereit ist, von der Pre-Production in die Production zu wechseln. Kein Deliverable. Eine Entscheidung.

Wenn du das Gate überspringst und standardmäßig in die Breite gehst, hat der Slice dir nichts erspart. Er war nur eine teure Demo.

Fünf Wege, wie der Slice dein Projekt tötet

Selbst Entwickler, die dem Protokoll folgen, werden von bestimmten Fehlermustern erwischt. Wayline katalogisiert die meisten davon:

1. Illusion des Tempos. Du hast ein Level in acht Wochen gebaut, also sollte das Zehn-Level-Spiel achtzig Wochen brauchen. Wird es nicht. Der Slice hatte begrenzten Scope und keine Tech-Debt. Die Produktion hat beides. Plane mit dem Drei- bis Fünffachen der extrapolierten Zeit.
2. Polish ohne Beweis. Du hast drei Wochen auf eine Sprunganimation verwendet. Die Loop ist immer noch nicht validiert. Der Slice sieht shipbar aus und beweist nichts. Ein Slice, der kein Risiko eliminiert (Schritt 1), ist Dekoration.
3. Eingebauter Hero-Mode-Crunch. Der Slice ist nur fertig geworden, weil du zwei Wochen im Büro geschlafen hast. Dieses Tempo ist jetzt „der Plan". Die Produktion wird entweder jeden Milestone verfehlen oder das Team verbrennen.
4. Falsches Artefakt. Du hast einen Slice gebaut, wo du einen Prototypen gebraucht hättest (macht es Spaß?) oder ein MVP (verkauft es sich?). Check Schritt 1. Wenn das Risiko Fun ist, bau einen Prototypen. Wenn das Risiko Market-Fit ist, bau ein MVP.
5. Slice-förmige Architektur. Du hast Pipelines und Engine-Systeme rund um die schmalen Bedürfnisse des Slice gebaut. In die Breite zu gehen bedeutet, sie wieder rauszureißen. Volition hat das explizit markiert: Der Slice ist ein Gate, kein Fundament.

Warum Solo-Entwickler daran scheitern (und was es wirklich löst)

Es gibt einen Grund, warum Ron Gilbert, der Monkey Island geshippt hat, Vertical Slicing „eines der dümmsten Dinge nennt, die die Spieleindustrie je erfunden hat." Er sieht zu, wie Solo- und Kleinteam-Indies versuchen, es anzuwenden, und sich dabei zerstören.

Er hat recht mit dem, was er sieht. Er irrt sich, warum es passiert.

Vertical Slicing ist eine Team-Disziplin. AAA nutzt sie, um jahrelange Todesmärsche zu verhindern. Dort funktioniert sie, weil am anderen Ende eines Datums immer ein Producer, ein Publisher, eine Führungskraft oder ein Milestone-Review steht. Die Deadline ist nicht intern. Jemand wartet.

Solo-Indies kopieren die Technik und lassen genau diesen Teil weg. „Den Vertical-Slice-Ansatz auf die Solo-Entwicklung anzuwenden war viel schwieriger als erwartet", schrieb ein Solo-Entwickler nach dem Versuch. Natürlich war es das. Der Slice ist dafür gebaut, unter einer bestimmten Art von Druck zu funktionieren. Nimm den Druck weg, und die Methode bricht zusammen.

Die Lösung ist nicht, den Slice zu überspringen. Die Lösung ist, den Teil wiederherzustellen, den Solo-Entwickler weggelassen haben.

Du bist nicht faul. Du bist ohne Rückhalt. Slicing scheitert, wenn am Freitag niemand wartet. Slicing funktioniert, wenn jemand wartet.

Das kann ein bezahltes Teammitglied sein, ein Mitgründer, eine verbindliche Playtest-Gruppe, eine Peer-Accountability-Partnerschaft. Es muss ein echter Mensch mit einem Kalender und einer Erwartung sein. Unser Artikel über wie du zuverlässige Teammitglieder für dein Indie-Game findest erklärt, wie du das aufsetzt. Unser Artikel über Solo-Dev vs. Team erklärt, wann der Solo-Weg dich mehr kostet, als er spart.

Wenn du noch niemanden hast, ist das das strukturelle Stück, das fehlt. Nicht Motivation. Nicht Willenskraft. Ein Teammitglied, das auf deinen Freitag zählt.

Was du als Nächstes tun solltest

Wähle eine von drei Aktionen, je nachdem, wo du gerade stehst:

• Noch kein Prototyp. Lies Warum 90 % der Indie-Games in der Ideenphase sterben und Der komplette Guide, um dein Indie-Game zu Ende zu bringen. Bau zuerst den Prototypen.
• Prototyp funktioniert, Scope läuft aus dem Ruder. Lies Scope Creep killt dein Spiel. Kürze den Slice, bevor du Schritt 1 anfängst.
• Bereit zu slicen, aber niemand wartet auf dich. Trag dich auf die Clowdr-Warteliste ein und hol dir bis Freitag ein Teammitglied, das auf deinen Slice zählt.

Du bist nicht faul. Du bist ohne Rückhalt. Das Vertical-Slice-Protokoll hat sieben Schritte — und Schritt 3 ist der, den die meisten Indie-Entwickler nie aufsetzen. Fix Schritt 3, und der Rest des Protokolls fängt an zu funktionieren.