Prototypes & Vertical Slice

One thing that I've found surprising is the amount of indie developers that seems to mix up the purposes of the Prototypes & the Vertical Slice. Many seem to believe that the goal of Prototypes is to prove to themselves whether they can make a specific game, and that the primary importance of a Vertical Slice is to help pitch the game.

I would argue the following instead: the Prototypes are to help you figure out whether you should make a game, and the Vertical Slice is to help you figure out whether you can make it. I'll explain why I think this is a healthier approach, but before we start, let's quickly establish the most common timeline for game development, and one that can keep your production relatively straightforward to navigate:

• Ideation - coming up with ideas
• Prototyping - testing your ideas
• Vertical Slice - testing your production pipeline
• Production - producing the game
• Alpha (Feature Complete) - ensuring all features are functional
• Beta (Content Complete) - ensuring all content is implemented
• Release Candidate - the submission build
• Release - the release build

Ideation is an enormous topic that is impossible to summarize, so we're going to assume you already have a game idea. Every idea is just that, though: an idea. The problem with ideas is that our brains are incredibly good at filling in the blanks in an idea in ways that seem adequate. If I tell you that there's a battle between a knight and a dragon, your brain will be able to fill in the blanks - but your brain and my brain will disagree at those details: is the dragon blue? Is the knight wearing armour? Is the battle in a castle? Is the castle floating in the clouds?

All of these examples are from the declarative layer of your game, but the same can be said for the mechanical layer. What does "fight" mean? What buttons does the player press? What verbs do those buttons trigger? What loops do those verb take place in? What do those mean to the player, and why would they engage with it? Some of those questions are going to be relatively straight-forward, but initially, some of them might have nothing but question marks as an answer.

Should you make the game?

That's what the prototypes are for: to answer the question marks in your idea. They're usually small, scrappy, and messy - isolated features or visual ideas, sketches, drafts, anything to make sure your assumptions are founded in reality. And prototypes exist in almost every creative discipline: for writing, you'd think of an outline, for design you can paper prototype or prototype, for code you'd write a prototype, for art you could kitbash or sketch, do mockups or target renders, and for sound you could jam, or make a draft.

You might notice that I keep using the plural, prototypes: that is because in many cases, you'll be creating several isolated prototypes to test out the different question marks in your ideas - or, in complex cases, you might stitch different prototypes together to test whether things work together coherently.

Your Prototypes should not be made to be high-quality, structured well, or reusable. They should focus on nothing but their goal of answering a question quickly: if you need custom assets to prove out something, add them, but if not, use content from previous games, assets from other games, freely available assets, or primary shapes. The main goal is for them to be fast, cheap, and precise.

As early ideas take shape, they resemble an amorphous "blob" in the endless possibility space of creation, a shape that can endlessly adjust and reconfigure to fit your thoughts, worries, and ideas. That shapelessness makes ideas very exciting and adaptable, but that same quality is very dangerous for any practical development: hitting a moving & undefined target is much harder than hitting a stable one. In each case, the Prototypes place a flag in the ground that becomes (mostly) immovable, and as your Prototypes help you make decisions, the "blob" has certain points it now has to adhere to - from which the "blob" cannot stretch too far away.

Each discipline in your team can prototype their part of the project, which has the added benefit of aligning your team in a grounded vision that you can discuss, disagree about, and agree upon. Ideas that are only spoken or written are often far less clear than you think, and a lack of clarity will often create chaos & tension later on if you're working with a team - and can (and does!) routinely sink entire projects halfway through production. Production allows each part of your team to define their part of the work in the "language" they speak best: the work that they specialize in.

Reducing the possibility space by creating more defined in that amorphous blob creates focus, confirming the functionality and coherence of the design and style creates definition, and the act of creating these Prototypes creates alignment.

The Prototypes, then, prove whether you should create a game.

Can you make the game?

The Vertical Slice is often misunderstood as an advanced prototype - simply the next step, bringing everything together, and testing whether that works. But the Vertical Slice is not a design prototype, but a production prototype. After your prototypes, you should be confident that the game should be made - you would not need an additional prototype for that.

The Vertical Slice, instead of proving out that the game works, proves that you can create that game. This is why funding sources like publishers & investors are generally so enamoured with the Vertical Slice: it's a further distillation of your prototypes, sure, but it's also the one that proves you can make the game.

To make a good Vertical Slice, you build some one of each thing (thing being vaguely defined, as every game has different needs) at a fidelity that approaches or convincingly simulates the shipping quality. Our goal is to run through the entire cycle from idea to implementation at least once, to see if there are any blockers, issues, or unforeseen complications in the creation of one slice, one functional segment of the game.

How "thin" that slice is is really up to you: for a platformer, you could make one level, or you could make one tricky jumping section. For a shooter, it could be a tiny arena or an entire level. For a racing game, it could be a NASCAR track in the middle of nowhere or a super-complex city race with intersections and everything.

When you've completed the Vertical Slice, you should typically have identified a number of production issues in your pipelines, and taken steps to resolve them. You should also be clear on what the production process will look like going forward.

Before you head into the Production stage, there's one final thing the Vertical Slice can help you with: if you know how long it takes to make one thing, it is always a good idea to make a second thing. For the Vertical Slice, you're usually still messing around with a lot of pipelines and the implementation of the processes that add content or code to the game. The second time around, things should go much faster - the time it takes you to make the second thing is the time you can divide your development timeline by to get an idea of how many of that thing you can make. Or, conversely, you can multiply it by how many of that thing you want to make, and make an estimated timeline (which you should then, as always, add margins to!).

The difference in time and production smoothness between the first and second time around can also give you a good idea of whether your production revisions from the Vertical Slice did help out.

When to Pitch

A question I often get is when you should start pitching. After all, most Publishers want a Vertical Slice from you. Personally, I believe pitching is something that you can (& should!) start doing after the prototype, as long as you have a number of mockups available to communicate the atmosphere of your work.

The reason is simple: if the Prototypes are what define whether the game should be made, it's a very good way to see if anyone is interested in the game in the first place. In the worst case, everyone says "come back with a Vertical Slice" - in which case you can now commit the several months it takes to create one. In the best cases, everyone either says "No" or someone says "Yes".

Keep in mind that for larger games, the Vertical Slice might not actually be attainable for higher-budget games: you simply might lack the (human) resources to create content at the level of fidelity you're aiming for. This situation is obviously a red flag for both yourself and the publisher, but there are absolutely realistic scenarios in which this can occur - and it's another reason to pitch after Prototypes, not after completing your Vertical Slice.

To a publisher, their interest in a game idea does not actually change much between the Prototypes and the Vertical Slice - the only thing that changes is their belief in your ability to produce it. Because of that, a lot of publishers can tell you whether it is worth investing those month of your life into a Vertical Slice right about at the time you have defined that the game should be made, and defined how it plays, looks, and sounds.

If the answer is a resounding "no" from everyone, it's time to move on. Since you've only spent the time on the Prototypes, and you hopefully created them quickly, the game idea can go in your Big Archive Of Game Ideas To Maybe (But Probably Not) Revisit Later without you losing many months of your life and money. If the answer is a "maybe", you're going to have to make a call on whether it's worth pursuing. And if the answer is "Yes", you can move on to the Vertical Slice already (partially) funded.

Actionables

1. Try to be strict with yourself and your team, and don't allow things that aren't needed to answer questions in. Your biggest risk when prototyping is to spend too much time on it. A prototype is meant to be fast, cheap, and disposable. Allow shortcuts, don't care about fidelity, allow copyright infringement (I've used sounds, music, sprites, and models from other games a frightening amount of times), allow whatever proves things out as fast as possible. Do not use the code or content of your prototypes after the prototyping phase - especially not if you've used content you're not allowed to use from other games.
2. Evaluate your processes and confirm that you're using the Vertical Slice for production purposes. The Vertical Slice typically costs several months to create, and can frequently cost over half a year of work. This tends to be work that is self-funded, and as such is more risky than work that is funded by an external partner. As such, always ensure that you're using the Prototypes to confirm that the idea should be made - make them quick and cheap, then validate your ideas by seeing if there's interest in the game, and then use the Vertical Slice to ensure that you can make it - taking the proper time.
3. Practice communicating your game idea using only materials available to you after your prototype stage. Even if you're already past this stage in development, it's worth training this ability. Using a combination of screenshots or gifs from your prototype, a few target renders/mockups, and potentially a quick version of the prototype with some graphics smashed on top of it, try seeing if you can communicate the value and Unique Selling Points of your game to both someone who'd work on it, and someone who might invest in it. What would've been good to have? What wasn't useful? Use the answers to those questions to become more precise.