Game prototype or vertical slice: what to build first and when it is done

A prototype answers one question as cheaply as possible, usually whether the core idea is fun or whether a risky piece of technology works. A vertical slice is a short section of the game built to finished quality, with every main system working together. Build prototypes first, keep them rough and expect to throw most of them away. Build the slice once the core loop is proven, because it is the evidence that the full game can be made the way you plan.

#What separates a prototype from a vertical slice

	Prototype	Vertical slice
Purpose	Answer one question, such as whether a mechanic is fun or a technique works	Show the game at its intended quality in a small space
Quality	Rough: placeholder art, hard-coded values, debug controls	Final or near-final art, audio, interface and feel
Scope	One mechanic or one technical risk	A complete stretch of play, such as one level or one match
Code	Often thrown away	Built on the architecture the full game will use
Audience	The team	The team, publishers, investors or early players

The name describes the shape: a thin cut through every layer of the game. The opposite approach is a horizontal build, where one system is finished across the whole game before the next one starts.

Mixing the two is a common source of trouble. A prototype polished for weeks becomes expensive to throw away, and a slice built on prototype code carries its shortcuts into production.

#What to test first

Order prototypes by risk. The question that would stop the project if the answer were no goes first.

• The core loop. This is the action a player repeats most of the time: fight, collect, upgrade and go again, or plan, build and watch. If it is not enjoyable with grey boxes, art will not save it. Put it in front of people who did not design it and watch what they do.
• Feel. Movement, camera, input response and the feedback when something is hit. Feel needs fast iteration on numbers, so expose those values in the editor or a debug menu instead of burying them in code.
• Risky technology. Netcode for a multiplayer game, physics at scale, procedural generation, performance on the weakest target device, or a platform you have not shipped on before. Build the smallest test that proves or disproves it, for example two clients moving and shooting over a real network with realistic latency.
• The production pipeline. If the game needs a lot of content, measure how long one piece takes to make, from the modelling tool to the engine.

Keep each prototype small. Write down the question it was meant to answer and what it showed, because the notes outlive the code.

#Greyboxing and scope cuts

Greyboxing, also called blockout, means building levels from simple shapes with no final art. A designer can test layout, sight lines, distances and pacing, and every change stays cheap. A grey box standing in for a wall moves in seconds, while a finished wall costs an artist's time.

Cut scope while it is still cheap:

• List every feature and mark the ones the core loop needs. Everything else waits until the slice proves the loop.
• Replace systems with the simplest version that serves the test: a fixed set of enemies in place of a spawning system, one weapon in place of an inventory.
• Drop a mechanic that tests poorly instead of polishing it. Polish rarely fixes a design problem.
• Decide on the amount of content separately from the number of features. A slice needs one good level, and five average ones prove less.

#What done means for a vertical slice

Agree the definition in writing before work starts, so the team and any outside reviewer judge the same thing. A useful definition includes:

• A complete stretch of play from start to finish, such as one level, one mission or one full match.
• Every main system in its intended form: controls, camera, the core mechanic, interface, audio, saving, and online features if the game has them.
• Art and audio at the target quality for that stretch, so it shows how the whole game will look and sound.
• Performance on the target hardware at the frame rate you intend to ship with.
• Builds that a person outside the team can install and play without help.
• A record of how long each part took, which becomes the basis for estimating the rest of production.

That last point is often the most valuable result. A slice turns guesses about production into measured effort for one representative piece, and the estimate for the full game grows from there.

#When to add online services

If multiplayer is part of the design, the netcode risk belongs in an early prototype and the real networking belongs in the slice. Adding server authority to a codebase written for one player usually means rewriting the game logic, so decide early whether the server or the client owns the game state.

Other online services can come later, in order of need:

• Before the slice: the network model and a test server, if the game is multiplayer.
• In the slice: the systems the slice shows, such as accounts, sessions or matchmaking for one match type.
• After the slice: leaderboards, progress across devices, in-game economies, analytics and the tools for live operations.

Single-player games with optional online features can leave all of this until the core game is proven. The article on what a multiplayer game backend needs covers these systems in detail.

#How PN Scripts can help

PN Scripts builds games and prototypes in Unity, Unreal, Godot and WebGL with Three.js, including multiplayer and online services. If you have a concept to test or a slice to plan, the game development page explains how a project starts.