Three people on a four-person team say the vertical slice is nearly done. The programmer means the player can move, jump and hit things. The artist means one room is finished to final quality. The designer means the whole first level plays start to finish. They are all telling the truth, and none of them are describing the same milestone. Two weeks later the "slice" is a pile of disconnected branches that has never been built, installed and played by a stranger.
A vertical slice is the cheapest honest answer to one question: does this game work? It only answers that question if you define it before you start building it.
What a vertical slice actually is
A vertical slice is a short piece of your game that passes through every layer of the stack at close to shipping quality. Vertical means top to bottom: input, movement, combat or core verb, level geometry, art, audio, UI, save, pause, and a build that installs and runs on a machine that isn't yours.
The opposite — and the most common mistake — is a horizontal slice: all forty levels blocked out in grey boxes, every system half-wired, nothing finished. A horizontal slice tells you how big your game is. A vertical slice tells you whether it is any good.
Use the layer test. Write down your stack, then mark what the slice must include:
| Layer | In the slice | Notes |
|---|---|---|
| Input & controls | Yes, final bindings | Including rebinding if you ship it |
| Core verbs | Yes, all of them | If the game has 3 verbs, all 3 are in |
| Content breadth | No — one instance each | 1 level section, 2 enemy types, 1 boss at most |
| Art quality | Yes, for slice content only | Final shaders, lighting, VFX on screen |
| Audio | Yes, minimum viable set | ~8–12 SFX, 1 music loop, 1 ambience bed |
| UI | Yes, real HUD and pause | Main menu can be a placeholder button |
| Save / progression | The mechanism, not the content | One checkpoint that actually reloads |
| Build pipeline | Yes, non-negotiable | Packaged build, installed by someone else |
| Options, credits, settings | No | Later milestone |
The rule of thumb: content is narrow, quality is deep. Anything you cut, you cut by removing instances, never by removing layers.
Scope it in minutes, not features
Pick a duration first and derive the content from it. For most small teams, three to five minutes of play is right — long enough to show the loop twice, short enough to finish.
A worked example for a 2D action platformer, three minutes of play:
- 1 playable character with 3 verbs: run, jump, dash-attack
- 4 connected rooms, final art, final lighting
- 2 enemy types with distinct behaviours, plus 1 mini-boss encounter
- 1 collectible type that feeds 1 upgrade, to prove progression hooks exist
- 1 checkpoint, 1 death and respawn flow
- Full HUD: health, resource, upgrade indicator
- 10 SFX, 1 music loop, 1 ambience layer
- Target: stable 60 fps on your declared minimum spec machine
- Shipped as an installable build, tested on a second computer
Notice what is missing: no inventory screen, no dialogue system, no second biome, no cutscenes. If the core loop needs a dialogue system to be fun, then the dialogue system is a layer, not content, and it goes in — but only one conversation.
Write that list down as a milestone definition rather than a conversation. In GameDesignerX this is a natural fit for the Milestones module: one milestone, with the slice's exit criteria attached as checkable items, linked to the mechanics and level entries they depend on. The point is that "done" stops being a matter of opinion.
Exit criteria must be binary
Vague criteria are how slices slip for a month. Rewrite each one until a stranger could mark it pass or fail without asking you a question.
Weak: "Combat feels good." Better: "A new player can defeat the mini-boss within three attempts without being told the dash cancels its charge."
Weak: "Performance is acceptable." Better: "Frame time stays under 16.6 ms through the full 3-minute path on the minimum spec, measured twice."
A good slice spec is five to twelve criteria of that kind. More than twelve and you have written a demo, not a slice.
What is allowed to stay fake
Teams lose weeks because nobody said which placeholders were acceptable. Decide up front and write it in the same document.
| Element | Final in slice | Fake is fine |
|---|---|---|
| Player character art and animation | ✅ | — |
| Enemy art for the 2 slice enemies | ✅ | — |
| Any enemy outside the slice | — | ✅ Does not exist |
| HUD layout and readability | ✅ | ✅ Icons can be rough |
| Main menu | — | ✅ A button that starts the game |
| Localization | — | ✅ English only, but keep strings in a table |
| Story and dialogue text | — | ✅ Placeholder lines, final length budget |
| Settings and accessibility options | — | ✅ Unless an option is a core pillar |
One exception worth guarding: if accessibility or readability is a design pillar, it is a layer, and it ships in the slice.
Sequence the work backwards
Pick the date, then schedule backwards from it, because integration always takes longer than anyone's estimate.
A six-week slice, as an example shape:
- Week 1 — spec and spike. Finish the slice definition. Prototype the one thing nobody is sure about, in grey boxes.
- Weeks 2–3 — systems. Verbs, enemies, checkpoint, HUD wired with placeholder art. Playable end to end, ugly.
- Week 4 — content pass. Rooms built, encounters tuned, audio hooked up.
- Week 5 — quality pass. Final art, lighting, VFX, game feel tuning.
- Week 6 — integration and hardening. Build, install elsewhere, fix crashes, performance pass, external playtest. No new features.
Two habits make this hold. First, the game must be playable end to end from week 2, even when it looks terrible — a slice that only comes together in the last week is a slice that does not come together. Second, treat week 6 as sacred; the most common slice failure is spending the hardening week adding a feature someone fell in love with.
Running this as two or three sprints on a task board, with each sprint's tickets tagged to the milestone's criteria, makes the drift visible. If the burndown is flat for a week, you learn it in week 3 and not in week 6.
The slice review
The slice exists to produce a decision, so hold a review with a decision on the agenda.
Run it like this: a packaged build on a machine you did not configure, five people who have not seen the game, no explanation beforehand, you watching silently. Afterwards ask three questions:
- What were you trying to do?
- What was the most interesting thing you did?
- Would you keep playing? Why or why not?
Then, with your team, answer the only question that matters: do we build this game, change the design, or stop? Write the answer and the reasoning into your decision log. In six months someone will ask why combat works the way it does, and the slice review is the honest record.
Four failure modes to watch for
- The horizontal slice. Lots of grey boxes, no finished anything. It proves scale, not quality.
- The infinite slice. Every review adds a criterion. Freeze the spec; new ideas go to the idea log, not the milestone.
- The slice that proves nothing. It demonstrates the parts you were already confident about. Point the slice at your biggest unknown.
- The publisher slice. Built to impress a meeting, not to be played. Two audiences, one build: make it honest first, then make the capture look good.
After the slice
Keep the spec, the criteria and the review notes together; they become the template for every milestone that follows, and for the demo build later. Throw away any slice code you wrote knowing it was a cheat, and mark it as throwaway on the day you write it rather than discovering it a year later.
Most of all, keep the number. You know how long three minutes of finished game took your actual team, on your actual tools. That single figure is the most useful planning input you will get all year — far better than any estimate made before anything was finished.