Video Game Prototype: A Beginner’s Guide

In this guide, I will go over why it’s crucial to prototype any game idea, the different stages of prototyping in professional game productions, how to prototype games, and examples from AAA studios including ones I personally worked on.

Feel free to use the table of contents to skip to the section that interests you 👇

What is video game prototyping

In game development, prototyping is the process of exploring a game concept and proving its viability. As a result, there are two different kinds: the rapid prototype, designed to prove the game can be fun to the designer – and the draft prototype, designed to pitch the potential to fund the game’s development. Together, these two prototypes explore the game’s mechanics, style, aesthetic vision, and clarify the kind of audiences who will find the game appealing.

What is rapid prototyping

Rapid prototyping is designed to prove that you can link the general fantasy of your game with working mechanics.

You quickly iterate in as cheap a format as possible; index cards, simple notes, lots of shortcuts and bandaids to jump to the playable experience.

The rapid prototype isn’t meant for anyone beyond the designer and friends. It’s full of rough edges but is fleshed out enough to allow the game developers to explore the core mechanics.

It shouldn’t take too much time to setup or play and generally focuses the feedback on situations, agency and outcomes.

Testing is quick, dirty and focused.

What is a draft prototype

Once the rapid prototyping phase is done and the team and designers feel the potential is there, the team will move on to the draft prototype.

The focus of the draft prototype is to prove the game can be intriguing and appealing to the target audience.

This often comes in the form of a mixture of grey-box prototype levels to showcase gameplay, along with a beautiful corner to show the super polished, high-quality art and style the game could have if done to completion.

This prototype, because it’s meant to convince non-developers, is usually in a digital environment, using the actual game engine the studio intends to develop, but is far from bug free, with only certain game mechanics supported.

It doesn’t require everything in the game to be at final quality, but has enough to show that the team can actually deliver as promised.

Why is game prototyping necessary in the game development process

Games are incredibly complex, multi disciplinary beasts. They get more and more expensive to create the further along into development you progress.

As a result, you want to de-risk your game concept by experimenting with high risk ideas as early on in the process as possible.

Doing this while its cheap and dirty will allow you to develop an intuitive sense of whether a feature is worth the cost of delivering it to completion.

I recently worked with a studio which had a major never-done-in-an-action-title feature they wanted to make a centerpiece of their gameplay.

However, they were consistently unable to execute on it when the game was cheap to build.

As they grew further and further in the process, the cost of trying out the idea, let alone building the game around it, became prohibitively expensive.

While developing fun can be taught, creating the right kind of fun for a specific audience takes a quick succession of iterations on your idea and execution of the core mechanic.

It’s not enough to assume your well-thought out idea will succeed. It’s one thing to concept; it’s another to develop it.

The Development Process

It’s important to understand the early stages of game production so you can see how prototyping helps save your wallet AND your development team. If game concepts and a short pitch are the seed, video game prototypes are the sprouts.

It looks something like this:

• Concept – vague idea
• Brief – summary of game idea and audience
• Rapid prototype – playable to prove value to designers (30 sec of fun)
• Draft prototype – prettier playable showing the fantasy with the gameplay (3 mins fun)
• Tech prototype – the draft rebuilt with proper architecture inside your target engine
• Vertical slice – one example of each game feature or system you want (30 mins fun)
• Pre-production – developing the tools and technology needed to produce the rest
• Production – developing the game’s content in a real production schedule
• Pre-alpha – showing about 25% of the game to trusted friends for feedback
• Alpha – showing an improved version of that 25% to NDA trusted strangers
• Beta / Early Access – Showing 25+% of the game to public testers
• Pre-release – a mostly finished section of the game at polished quality for reviewers
• Release – the version that ships to the public
• Post-Release – patches, bug fixes, etc

If you think that looks like a lot of steps, you’re right – it is – and changes in each step become increasingly costly:

As you can see, it’s so important for the game designer to get a playable version of the game up fast, first through paper prototyping, then as a digital prototype to explore the game as much as possible while it’s dramatically cheaper to develop the game.

The prototyping process exists to support development teams, answer questions and test the game concept through play as a first step, rather than a last step.

Furthermore, it’s extra important for game designers to own and drive the prototyping process, as their design choices will dictate where to allocate the studio budget in the form of art, programming and QA resources.

So in essence, game designers make bets with studios’ budget.

Game prototype examples:

For example, when I started developing WoW Pet Battles, the very first thing I did was use the Warcraft vehicle engine to create a proof of concept in the middle of the Stranglethorn Arena.

After a few days of work, I had a sort of rough proof that I could make the characters move, attack and play spell visuals.

However, iterating and improving on it was slow. It would take a month to build more than what I had and it would all be throwaway work.

At that point, Cory Stockton proposed that I try doing a paper prototype instead. A few hours inside of Google Docs, creating some tables, text and very basic numbers, and I was ready to print out cards with abilities.

A quick hour of playtesting at the lunch table with Cory and some fixes and we were ready to make 6 more pets and do a group playtest.

Within a week, we’d done three playtests, had reasonable confidence in the battle mechanics that showed promise, and had two engineers, Darren Williams, Pat MacKellar and their lead Patrick Magruder who had all played the paper prototype and had a clear understanding of what we wanted to build.

It would be almost half a year of work before the game looked like the above, with integrated commands, a unique UI and another year before all of the abilities had visuals, thanks to the hard work of Jeremy Feasel and the pet battle QA team.

If we had waited til we had it in the game to verify the design worked, we wouldn’t have shipped with Mists of Pandaria at launch.

This isn’t a unique story.

The card game that would eventually be known as Legends of Runeterra started out as an in-engine MTG clone known as Bacon.

Not to go too hard on the team, this original prototype was developed before Hearthstone came out and ultimately was shut down, when it became clear Hearthstone had dramatically raised the bar for simplicity, clarity and quality.

The team rebuilt, with Jeff Jew and David Abecassis developing new concepts for the game. One of the pivotal choices was to build their deck as physical cards – something Eric Dodds and Ben Brode did on Hearthstone.

You can read about their Hearthstone journey over here.

This made playtesting fast and easy. I remember sitting down with David and playtesting the new game concept with a Teemo deck, where he defeated me by forcing me to draw too many cards.

The number of iterations the team could achieve in paper playtesting was so much faster, this philosophy would drive most future iterations of the game.

So much so in fact, that new cards were tested quickly in an excel style sheet allowing designers to rapidly test cards against existing decks without having to put any code into the game engine.

You can see their example spreadsheet above.

The final quality version, on the other hand, was full of visual effects, sounds, beautiful art and well-iterated game designs.

On Ori, they would have animators draw simple environments, using animated boxes, solid colors to showcase how abilities in the game would control or feel, without building it in the game engine.

Through about 50-75% of the game’s development, Ori 2’s levels were simple black and white spaces, with brown for platforms you could jump through and bright red or blue elements for ice and spikes.

I have even more examples of game prototypes that I still can’t talk about yet, but notice the theme between the successful ones:

• Simple to build
• Fast to execute
• Focuses on the core experience

When you’re building your own prototype, you should do the same. Find the minimum amount of work possible to explore your idea. There are a number of tools you should start with, as they are quick and easy to learn:

Game mechanics prototyping tools:

• Paper & pencil
• Tabletop Simulator
• Google Sheets
• Simple blockouts in engine with basic shapes as characters
• Game rules done via blueprints/game maker for unity

Additional video game prototyping tools:

• Twine – Narrative design
• Any level editor – Level design
• Machinations – Systems and economy design
• Wireframes (Miro) – UI design

How to prototype a game?

Way to ask the million-dollar question.

The goal of game prototypes is to build up your skills and prove your ideas, not prove yourself.

In general, follow these steps when you’re prototyping:

1. Establish your connective fantasy vision
2. Come up with at least three game ideas, pick the simplest one to execute.
3. Find a way to express or chase down that game design that doesn’t have extra barriers to entry, such as coding or mastering a game engine.
4. Start with something as simple and immediately playable as building a pencil and paper game or in a Google Sheet, or even mocking up a simple idea in Tabletop Simulator – see examples in the next section.
   • Focus on building testable game mechanics, content to challenge those mechanics, and then rewards and feedback to make the game appealing.

5. Playtest it with people and see if it has any evidence of fun and player engagement.
   • If so, move forward to the next step and start making iterations.
   • If it’s not, scrap and go back to step 1 and prototype the next idea.

6. Start iterating and layering on higher commitment prototypes mentioned earlier such as draft prototype, tech prototype, vertical slice, pre-production, etc.
   • Make sure to follow the discipline to keep playtesting each round to prove whether it’s worth the continued time and resource investment.

However, if you feel paralyzed and don’t know where to start, take the Build a Game Challenge, where you put together a simple prototype, playtest, collect feedback and iterate with the support of others who’ve done it before.

Game prototyping mistakes

Make sure you avoid these two common mistakes when building a prototype.

Mistake 1: Try to build your dream game first, even if it’s a billion-dollar MMO when you never built anything before.

If you think about it, if you can’t even build a game as simple as pong yet, how can you build a grand vision that takes a team of experienced game devs to execute?

That’s like trying to win your first professional boxing bout before you ever even sparred in the gym.

Instead, level-up your knowledge and skills on smaller projects first before you go after more grand visions.

Mistake 2: Leap right away into a game engine and begin plugging away.

However, unless you are experienced and proficient with the tools, this can be incredibly difficult, demoralizing and distract you from your core vision.

Game engines simply have too much to offer and unless you have a razor-sharp focus on delivering the minimum, you will be distracted by features and details that are not key to the rapid prototype.

Implementing the input, rules and game logic alone will take enough time as it is, which defeats the whole purpose of rapid prototyping!

Even major AAA studios will first try to figure out the game in a paper playtestable format before jumping into engine development.

Game Prototyping tips:

1. Move fast, especially with the rapid prototype phase
   • Remember you’re rapid prototyping to discover the problems – not solve them

2. Minimize scope and polish early for the draft prototype
   • Remember, you’re demonstrating the essential core and quality of your team
   • Polish early means remove things that consistently undermine the experience

3. Focus on only building what you need to create problems for the player and solve those problems
   • One or two cool mechanics that aren’t fully thought out are fine
   • However, they will lean very heavily on polish if the game content doesn’t support them

4. Build-to-test, make iteration a key part of your feedback loop
5. The goal of tests is to prove out the unknowns and increase team confidence
   • If you aren’t achieving either, you aren’t testing effectively

6. Paper prototypes will save you hundreds of hours
   • Consider at least three different options on paper before writing code

7. Time and willpower are the real costs
   • You will eventually always run out of both

8. Enjoy the process – you will soon realize it’s the easiest and most enjoyable phase because there is less stakes

How to get better at prototyping game design ideas?

Ultimately, becoming a better prototyper is a matter of experience. Prototype often, prototype fast, become comfortable throwing away work and old ideas.

My first time prototyping on my own, I was too focused on building a good toolchain for myself, instead of proving out the fun. A year later, I had a great editor for a shitty game. If I instead start building for fun, instead of convenience, I would have been in a better place.

When prototyping go through all of these stages without skipping steps:

1. Create three unique ideas, then pick the best parts from all three
2. Write a one page game brief for the idea.
3. Write out a short version of the challenges, actions and rules of the game.
4. Build an MCP (Minimal Crappy Prototype)
5. Playtest it solo and iterate once
6. Playtest it again with others
7. Collect feedback, examine the game idea and either revise or start over

I’ve written a workshop on this exact process, with video instructions, example template documents and step-by-step examples on how to do this.

Then this workshop is supported by the Funsmith.club Discord, where you can find other game designers, playtest and grow together.

We handle the coordination, you just have to build the game, sign-up and show-up.

Video Game Prototyping Frequently Asked Questions

Do you have any game prototyping templates?

Yes, we have a bunch of templates for each step in the process which you can sign up for free over at the Build a Game Challenge.

How can physical game prototyping help in video games?

Physical prototyping can be built fast. Use some note cards, coins, pencils and rapidly sketch out the experience. Physical prototypes force you to minimize what you build and focus on the decisions that matter within the game.

Because you can’t rely on the computer to cover up the poor game design math, it reveals the rough spots and forces you to reduce your game down to just the parts that matter to the player. Everything else is just noise or flavor.

How to know when a game development company is prototyping a game?

Any company in the early stages is prototyping for funding. Any company in the mid stages is prototyping new ideas to sustain. The only time a game development company isn’t prototyping is when they are shipping.

When is a prototype good enough to move to the next step?

It depends heavily on the phase.

The rapid or rough prototype stage moves on once the game designer is convinced the game will be fun and ideally, can see others playing it and enjoying it (which results in longer player retention).

The draft prototype is good enough when you have a few minutes of solid gameplay that a publisher or investor can enjoy without game design expertise.

Tech prototypes are good enough when you know what code needs to be written to support the feature – including tools – but may not have written them yet.

Note: Preproduction shouldn’t be exited before the core tools for design are implemented and iterated on.

When to stop prototyping a game?

You should know from the start what fantasy you’re trying to chase down.

Fail fast!

When you can see the game you’re building doesn’t work for the fantasy and another one doesn’t immediately speak to you, put down this prototype and try another idea.

Similarly, if you realize your team cannot hit the quality level needed to get funding in the draft prototype phase, or that the technical hurdles are too challenging or expensive for the funding you have in the tech prototype phase – a serious conversation should be had around proceeding.

I know teams that made the mistake of writing their own game engine from scratch with no experience, that realized too late that none of the tech they built supported the game loop their prototypes could have discovered had they built them in a lower-risk way first.

It’s okay to return to the investors and admit defeat. It’s better to give back half the money than none of it. Alternatively, they may be able to offer resources and guidance to overcome the problem.