Paper Prototyping

Oh boy! It's time to start a brand new project! Let's jump right into the engine and make it.

[One Week Later]

Wow, I uh... Don't really know where to go from here. I'll have to remake this part.

[Two Weeks Later]

Dang... Uh... This isn't really fun... If only there was a better way to quickly see if something would be enjoyable without doing all that extra work...

I made this layout paper prototype to see how a player might explore a multi-layered open air dungeon.

Hey Boss, Have you Tried Paper Prototyping?

Now, prototyping is something that is incredibly useful for determining if mechanics are fun. A quick sledgehammer coding session will leave you with a playable (if buggy) version of a feature you're wanting to make. But what if instead, you didn't want to code at all?

Paper Prototyping is the process of essentially building a mechanic out as if it was a board game version of whatever you're trying to design. Now, not all features can be easily paper prototyped, but you can walk through all features.

I like to treat paper prototyping like I'm make a sample round of a particularly complex board game. I'll lay out a few game states, and notate how the states flow into each other. When I'm paper prototyping, I tend to actually physically use index cards, but you can easily do the same thing in a paint-adjacent software as well.

Here's a rough paper prototype I did when blocking out a wave-fight arena. I didn't like the direction it was going initially, so I started over with minimal time loss.

Paper Prototyping a Layout

Honestly, layouts are one of the best use-cases for a paper prototype. In this scenario, I'm using layout to refer to any sort of arrangement of elements in a game. That includes level layouts, enemy unit placements, reward locations, and much much more. Essentially, if something is going to be static in your game, a paper prototype is very applicable.

Now, something important is to decide what level quality you want these layout prototypes to be. Sometimes, the purpose of a prototype is just to catch the vibe, and sometimes it's something that will be referenced more than once. In that case, make sure you spend the appropriate amount of time when creating whatever you need. Set your expectations before you jump right into making it.

Paper Prototyping for UI/UX

Making paper prototypes for your user flows is an excellent way to determine if something is clear or confusing. You can go as simple as designing a single UI element to making complex wireframes using something like Figma. It's pretty common that I use paper prototyping to layout how users will get from one screen to the next. Navigation can be frustrating, and conveying information to the user in an easily understandable way can be tough! Using paper prototyping, you can easily put something in front of a potential user to determine if your vision clicks with them, or if you need to go back to the drawing board.

Paper Prototyping an Action Mechanic

Let's do a hypothetical. Let's say I want to paper prototype the classic "barrel roll" mechanic from StarFox 64. If you're unfamiliar, barrel rolling in StarFox 64 is a maneuver where your ship quickly rolls in place, giving you a brief moment to deflect projectiles. Now, this is an action-based mechanic. What I mean by that, is there's timing involved, and so it might be a bit confusing to paper prototype it. In this situation, I'd outline the game states and potential choices a player can make relating to the mechanic:

1. The player is flying.

   • The player is flying through the level in a normal state.

2. An enemy approaches the player.

   • The enemy can shoot at the player.

   • The player is threatened.

3. An enemy shoots at the player.

   • The player will be hit by the projectile.

   • The player can dodge the projectile.

   • The player can Barrel Roll to reflect the projectile.

4. The player Barrel Rolls into the projectile.

   • The player is given invulnerability for a moment.

   • The projectile is reflected back to the attacker.

5. The enemy is hit by its own projectile.

   • The enemy cannot dodge the projectile.

   • The enemy takes damage.

6. The enemy is destroyed.

   • The player receives points.

You can see roughly how this mechanic will play out by laying these states out back to back. What's important is that you capture every unique game state and every situation where a player can make a meaningful choice. The player doesn't do anything when the enemy approaches (2.), but the state of the game does change. The player is threatened by the potential of the enemy shooting. By lining all of these states up, the mechanic makes sense.

Now, you can go as in-depth as you want with paper prototyping, but I generally don't see the need to go much beyond this when it comes to one-off features. If you wanted to, you could go farther down the option of the player dodging when the enemy shoots (3.), but this exercise wasn't really exploring what happens when you dodge.

Final Thoughts

There are a lot of use cases for paper prototyping. You could essentially turn an entire game into a paper prototype or text-based version to check how fun and understandable it is. I often use Twine to quickly block out rough storylines and puzzles that I'd like to explore. Now, these aren't technically paper, but you could absolutely do something like that. Think of paper prototypes as the least amount of effort needed to get try out the mechanic, and you'll be well on your way to laying out some great drafts.