The Vertical Slice Protocol: How to Prove Your Indie Game Works Before You Scale It

Open your "graveyard folder." You know the one. Incremental game, Vampire Survivors-style, FPS arena wave-based. Twelve project folders, each with a week-one README that promised this one was different.

None of those projects hit the moment where the core loop worked end to end, with real art in the scene and music in the background. They stalled in the middle. Systems were almost wired up. The second level was "blocked out." You meant to playtest "next week."

The thing separating a finished indie game from a zombie project is rarely talent. It's that the shipped ones hit a specific checkpoint called a vertical slice — one polished cross-section of the game, end to end, that proves the whole thing is possible. The shipped ones treat the slice as a deadline. The dead ones treat it as an aspiration.

This post is Clowdr's Vertical Slice Protocol: seven steps to prove your game works before you scale it, and the one structural reason solo devs usually fail at it.

Prototype vs. Vertical Slice vs. MVP

Most indie projects die because the developer built the wrong artifact. Rami Ismail, co-founder of Vlambeer, has the clearest frame: prototypes ask whether you should make the game, and vertical slices ask whether you can.

Three different questions, three different answers:

Artifact	Question	Fidelity	Audience
Prototype	Should we make this? Is the loop fun?	Ugly. Placeholders everywhere.	You and one or two playtesters.
Vertical slice	Can we make this? Is it buildable at quality?	Near-shipping. One of every discipline polished.	Collaborators, publishers, backers.
MVP	Does it sell? Is the whole game worth shipping?	Feature-minimal, end-to-end playable.	Players.

If you're polishing art before your loop is fun, you're building a slice when you needed a prototype. If you're spending six months on one level before you know the rest of the game fits together, you're building a slice when you needed an MVP. Most indie deaths trace to one of those two mistakes.

What a Vertical Slice Actually Is

A vertical slice is 10 to 30 minutes of your game at roughly the quality you'd ship it. The publisher standard Xsolla lists on its funding pages is exactly that range.

The defining feature is "vertical" — the slice cuts through every discipline. Not just code, not just art. It has:

• A working piece of the core loop — not the tutorial, not the final boss, somewhere representative of minute 12
• Real art assets at the fidelity you plan to ship, for that one section
• Music and sound that set the tone
• UI that matches the final style
• One of every enemy type, item class, or system the slice needs

What it is not: a list of features. A slice is a cross-section. If you can imagine the rest of the game built at this fidelity, you have a slice. If the slice is ten levels of hallway and no combat, you don't.

The method traces back to Mark Cerny's 2002 DICE talk, which a lot of indies have heard about without reading. One indie-dev panel summarized Cerny's point as: can I make a five-minute, three-minute, one-level snapshot of how this game would feel if it was really all done? Until you get that right, it's a waste of time to "go wide" on the rest of the game.

What You Need Before You Start

Three prerequisites. If any are missing, don't start the slice yet.

1. A prototype that proves the loop is fun. You already answered "should we make this?" If you haven't, build the prototype first.
2. A person on the other end of a deadline. Not yourself. A teammate, a playtest group, a peer review call, a publisher pitch.
3. A willingness to throw the slice away. Parts of it will be fakes. Parts will get rebuilt once you understand the full game. If the slice has to become production code, you'll pre-optimize it and ship nothing.

The Vertical Slice Protocol

Seven steps. Follow them in order.

Step 1: Name the one risk you're retiring

A slice kills one risk. Pick it before you start. Typical risks:

• Production feasibility. Can a one-to-three-person team ship this quality for a full game?
• Signature mechanic. Does the one unique thing scale to 15 hours of play?
• Art pipeline throughput. Can you actually produce enough assets on schedule?
• Tone coherence. Does the game feel like the thing you wrote on the napkin?

Write the risk at the top of your slice plan. If the slice doesn't retire it, you're not building a slice. You're building a demo.

Step 2: Pick the cross-section

Not the tutorial. Not the final boss. Somewhere representative of the average moment in your game — the zone where the main loop runs at full strength, the player has their core toolkit, and the mechanics are interacting the way the full game will.

If you can't answer "what's happening on minute 12 of my game?" you're not ready for step 2. Go back to the prototype.

Step 3: Set a deadline with a human on the other end

This is the step every other vertical-slice guide skips, and it's the one that makes the protocol work.

A deadline to yourself is a wish. Publishers know this — they set the deadline for you. AAA producers know this — they enforce it. Solo indies who believe the date on their Trello board is real don't know it yet.

Find a human. A teammate, a playtest group, a peer review call, a Kickstarter preview video, a conference demo slot. Tell them you'll show them the slice on a specific date. Now you have a vertical slice. Without this step, you have an open-ended polishing hobby.

Step 4: Cap the scope with a subtraction list

Write down what you're not doing. Every system, enemy, item, level, mode, feature, sound — each gets one line and a "not in the slice" label.

Wayline names the failure pattern "your slice is becoming a mini-game": you start with one enemy, add a boss, add a weapon, add a whole new system. The slice is now a full project, except scoped worse.

The subtraction list is load-bearing. Every time you want to add something, you check the list first. If the new thing is on the list, the answer is no. The list is the only thing protecting you from yourself.

Step 5: Fake the systems you're not retiring

Real systems take real time. You're retiring one risk (step 1). Fake everything else.

• Hard-code enemy stats instead of building a data system
• One canned cutscene instead of a cutscene tool
• Placeholder inventory UI instead of the final item system
• A hallway that branches twice instead of a procedural map

Label every fake. Write // FAKE in the code, "PLACEHOLDER" in the scene, "ROUGH" on the audio tracks. Geoff Ellenor names the trap cleanly: "We often fake the presented systems, because the sample of content is super small and we can get away with it. This is a mistake." Labeling makes the fakes visible so you don't mistake them for real progress when planning production.

Step 6: Ship to an audience by the deadline

Whatever state the slice is in on deadline day, you ship it.

Not "when it's ready." Not "in one more week." On the date you committed to a human. The slice is done when the deadline hits. That's the definition.

Playtest it live if you can. Record the session if you can't. Get reactions. Write them down. If your audience is a teammate, let them play it. If it's a publisher call, send the build. If it's a peer group, screen-share.

The slice exists to produce feedback. If you don't ship, there's no feedback. Without feedback, the next six months are guesswork.

Step 7: Run the gate

The slice isn't a celebration. It's a decision point. You have three choices:

• Kill the project. The slice proved the game isn't fun at production fidelity, or the pipeline can't sustain the full scope. Walk away. This is the slice earning its keep.
• Pivot the scope. The slice revealed the real game is smaller, shorter, or differently shaped than the plan. Cut, rewrite, replan.
• Go wide. The slice works. Now you build out the rest at this quality bar.

Volition framed the slice as exactly this kind of gate at GDC 2015: a tool to decide whether the team is ready to move from pre-production into production. Not a deliverable. A decision.

If you skip the gate and go wide by default, the slice didn't save you anything. It was just an expensive demo.

Five Ways the Slice Kills Your Project

Even devs who follow the protocol get taken out by specific failure patterns. Wayline catalogs most of them:

1. Illusion of pace. You built one level in eight weeks, so the ten-level full game should take eighty. It won't. The slice had bounded scope and no tech debt. Production will have both. Plan for three to five times the extrapolated timeline.
2. Polish without proof. You spent three weeks on a jump animation. The loop still isn't validated. The slice looks shippable and proves nothing. A slice that doesn't retire a risk (step 1) is decoration.
3. Hero-mode crunch baked in. The slice only got finished because you slept in the office for two weeks. That pace is now "the plan." Production will either miss every milestone or burn the team out.
4. Wrong artifact. You built a slice when you needed a prototype (is it fun?) or an MVP (does it sell?). Check step 1. If the risk is fun, build a prototype. If the risk is market fit, build an MVP.
5. Slice-shaped architecture. You built pipelines and engine systems around the narrow needs of the slice. Going wide requires tearing them out. Volition flagged this explicitly: the slice is a gate, not a foundation.

Why Solo Devs Fail at This (And What Actually Fixes It)

There's a reason Ron Gilbert, who shipped Monkey Island, calls vertical slicing "one of the dumbest things the game industry has ever come up with." He watches solo and small-team indies try to apply it and wreck themselves.

He's right about what he sees. He's wrong about why it happens.

Vertical slicing is a team discipline. AAA uses it to prevent year-long death marches. It works there because there is always a producer, a publisher, an executive, or a milestone review on the other end of a date. The deadline isn't internal. Someone is waiting.

Solo indies copy the technique and leave that part out. "Applying the vertical slice approach to solo game dev work has been much harder than anticipated," one solo dev wrote after trying it. Of course it was. The slice is built to work under a specific kind of pressure. Remove the pressure and the method falls apart.

The fix isn't skipping the slice. The fix is restoring the part solo devs cut.

You're not lazy. You're unsupported. Slicing fails when no one is waiting on Friday. Slicing works when someone is.

That can be a paid teammate, a co-founder, a committed playtest group, a peer accountability partnership. It has to be a real human with a calendar and an expectation. Our post on how to find reliable teammates for your indie game covers how to set that up. Our post on solo dev vs. team covers when the solo path is costing more than it saves.

If you don't have anyone yet, that's the missing structural piece. Not motivation. Not willpower. A teammate counting on your Friday.

What to Do Next

Pick one of three actions based on where you are right now:

• No prototype yet. Read Why 90% of Indie Games Die in the Idea Phase and The Complete Guide to Finishing Your Indie Game. Build the prototype first.
• Prototype works, scope spiraling. Read Scope Creep Is Killing Your Game. Cut the slice down before you start step 1.
• Ready to slice, nobody's waiting on you. Join the Clowdr waitlist and get a teammate counting on your slice by Friday.

You're not lazy. You're unsupported. The Vertical Slice Protocol is seven steps — and step 3 is the one most indie devs never set up. Fix step 3 and the rest of the protocol starts working.