Game prototype or vertical slice: what are you paying to learn?

By Noe Guerrero III

Choose a game prototype when you need to investigate a specific uncertainty, such as whether a control feels usable or a puzzle rule makes sense. Consider a vertical slice when you need to review a representative, functioning section of the planned game, with its parts working together at an agreed level of finish.

The label alone isn't a useful scope. Before approving either milestone, write down the question it should answer, what you'll receive, and how you'll review it. I'd want that agreement before commissioning more levels or a large set of finished assets.

Start with the question holding the project back

“We need a prototype” leaves plenty of room for different expectations. Try a question that could change the next development decision: can the player distinguish a movable object from the background? Does switching between two characters create an interesting choice? Can the intended device handle the interaction?

Those questions may need different prototypes. A visual mockup can help review readability. A playable interaction can help investigate controls. A technical experiment can examine a difficult system without building the rest of the game around it.

Unity's prototyping guidance emphasizes identifying the core of an experience, trying approaches, and selecting the critical features needed for a functional prototype. The practical implication is to choose the smallest deliverable that can answer your actual question.

Rough visuals can be useful when appearance isn't what you're testing. Epic's level prototyping example uses basic geometry to examine layout, scale, and player movement. If your question depends on recognizing detailed artwork, however, simple cubes won't provide the evidence you need.

Tell the team which shortcuts are acceptable. Placeholder sound might be fine for a movement experiment. A prerecorded animation wouldn't answer a question about a player-controlled action.

Define what the vertical slice needs to represent

A vertical slice is a limited section that lets you experience how selected parts of the game work together. Unity's game-project tutorial describes it as a functioning portion used to test the intended look and play of the larger game.

For a proposal, name that portion precisely. It might be one encounter, a short puzzle sequence, or one complete round. Specify what the player can do, how the sequence starts and ends, and which visual, audio, and interface elements need to represent the intended direction.

Agree on the finish of each part. Does “representative art” mean an approved character design, temporary environment assets, or a fully reviewed scene? Are sound effects selected, custom-made, or placeholders? Teams can use these milestone names differently, so the deliverable list needs to resolve those questions.

One polished section also leaves work outside its boundaries. It may show that the parts cooperate in that scene while leaving additional level design, device coverage, content tools, or online features unexamined. Ask the team to identify those unknowns alongside the build.

Compare two milestones for the same game idea

Imagine a creator in McAllen planning a puzzle game about guiding a delivery robot through a warehouse. The robot can push crates and rewind its last move. This is a hypothetical project, not a client example.

The first uncertainty is whether players can predict what rewind will undo. A focused prototype could provide one plain test room, the two actions, visible feedback, and a reset control. It would let the team investigate that rule before producing a collection of warehouse scenes.

If that interaction is worth developing, a later slice could combine a short sequence of rooms with the proposed robot artwork, instructions, sound, and transitions. The review would examine how the experience holds together.

These are proposed scopes for this example. They aren't required feature counts or a sequence every game must follow. If the biggest uncertainty changes, the next milestone should change with it.

Make acceptance something you can check

Acceptance criteria explain what the team must deliver. Research questions explain what you hope to learn from it. Keep both in the brief, because a useful prototype can reveal that an idea needs changing.

For the robot prototype, I would write delivery criteria such as:

1. The agreed build opens on the named test device without requiring the developer to operate it.

2. The robot can push a crate, rewind the specified move, and reset the test room using the documented controls.

3. Feedback shows which move was undone, including the agreed case where no move is available to rewind.

4. The team supplies the test setup, known limitations, observation notes, and unresolved questions.

5. The review includes a recommendation for the next decision and identifies what evidence supports it.

Then define the learning question separately: what do unfamiliar players expect rewind to do, and where does that expectation differ from the implemented rule? Our first-session playtest guide covers observation and neutral questions in more detail.

For the proposed slice, add criteria for the whole agreed sequence. Can the player enter, complete it, and reach the intended ending? Are the approved assets present? Does the interface support the required actions? Record the device and build used for review. If performance matters to the decision, agree on the device, measurement method, and target before testing.

Replace “make it polished” with reviewable requirements. That makes disagreements easier to resolve without pretending that enjoyment is a single pass-or-fail switch.

Ask what can carry into the next stage

A prototype's code and assets may be reusable, partly reusable, or deliberately temporary. Ask which applies before treating the first milestone as the beginning of a production-ready codebase.

Request a short explanation of what would need rebuilding and why. A shortcut that made an experiment possible might be unsuitable for saving progress, adding more content, or supporting another device. That doesn't make the experiment worthless; it changes the next scope.

For the slice, ask how the team would create another comparable section. Which tools and reusable pieces already exist? Which tasks were completed manually for this demonstration? What dependencies could slow the next stage?

A working section can inform planning, but multiplying its price by the hoped-for number of levels won't account for every remaining system or task. Have the next estimate separate established work, new work, and unresolved assumptions. Agree on a spending limit and review point for that next milestone instead of extending development automatically.

End the review with a decision

Finish the milestone discussion with one of three practical outcomes: continue with a defined next scope, revise a specific part and review it again, or stop pursuing the idea in its current form.

Keep delivery acceptance separate from that decision. If the agreed experiment was delivered and documented, learning that the mechanic is confusing can still be a useful result. If the build is missing the rewind action you commissioned, that's an incomplete deliverable requiring a different conversation.

Neither a prototype nor a slice establishes demand, funding, or the success of a finished game. Their value is the evidence they provide for the decision in front of you. Keep the build, the review notes, and the unresolved questions together so the next stage starts from what you learned.

RGV Web Design's game development services include gameplay prototypes and interactive experiences. Bring the player activity you have in mind and the question you most need answered. Those details are a stronger starting point for a milestone proposal than a request to build a little of everything.