Paper Prototyping 101

An in-depth guide to understanding, building, testing, and iterating a game in paper prototype form.

Paper Prototyping 101

So you have an idea for a game you might want to build - exciting! But where do you begin? Starting with a simple paper prototype can help you explore an idea, uncover and preempt production headaches, and even start finding the fun early.

Before firing up your game engine of choice or even doing concept art, paper prototyping can help you quickly hone in on what your game is, why it's special, and can help you refine ideas with much less work than adjusting coded in-production game systems. In short, it's the absolute best place to start, and it will save you tons of time.

Paper prototyping is exactly what it sounds like; you use simple materials to create an approximate, pared-down, playable version of your game idea. This way, you're able to quickly test how rules and mechanics interact, without worrying too much about visuals or code.

Simply put, for every hour spent paper prototyping, you save yourself dozens of hours of future work in production. It's one of the most useful skills I've encountered and honed over my career, so it felt like a fitting first resource to post!

This post will deep-dive into why paper prototyping shouldn't be skipped, how to plan a paper prototype, ways to prototype various game mechanics, making and testing a prototype, and will conclude with thoughts on moving from a paper prototype to production.

Get guides like this & more, delivered right to your inbox. Subscribe for free!

Importance & Function

Section 1

Why Paper Prototyping Matters

Think back to a time when you were really sure of something, that ended up not working as planned. Maybe it was the addition of a dubious ingredient to a recipe, or a spontaneous trip that was planned without first checking the weather. Had the details of the whole been considered a little more fully, simple mishaps can be avoided. However, unlike a ruined recipe or a rainy beach trip, changing early decisions in game development can often lead to headaches, delays, and bugs.

For many game developers, myself certainly included, ideas about mechanics, characters, plot points, and even elements of worldbuilding might need some refining to really fit. But how do you figure out mechanics, hooks, and things of that nature without first building them?

Behold: the magic of paper prototyping

In short, paper prototyping is the practice of making a playable rough draft of your game, either in part or in whole, using simple materials such as paper, post-its, miniature figures, etc.

While typically thought of as a part of pre-production, paper prototyping can be brought in at any stage of a project's lifecycle to test things out quickly, without needing to write code or create art.

By taking things a bit slower in the beginning and not jumping right into code or art production, and instead making a playable rough draft, you also save yourself tons of future headaches. For example, paper prototyping gives you an opportunity to spot conflicting game mechanics, major balance issues, and even "dead ends" where players have no viable ways to progress.

A Creative Forcing Function

Imagine you've got a game idea in your head. You intuitively feel that all the parts and pieces will come together, and you just know it's going to be a slam dunk. It can be really tempting to jump right into coding or 3D modeling with just an exciting idea in your head.

The willingness to take an idea and document how it works is the quickest and easiest test to see if your exciting idea is, in fact, ready to be a game.

However, it can be really convenient to avoid putting your ideas to the test. After all, until your concept is tested in some way, it can exist as an exciting utopia where nothing can go wrong. By testing an idea, you're in some ways accepting that making a game will be filled with challenges, surprises, and probably miscalculated assumptions... right? Well, not entirely.

Games are important because fun is important. The act of testing your game idea with a paper prototype is actually an incredibly kind thing to do for yourself. It's you acknowledging that games are tough to make, and that you want to spot the most challenging stuff early. In many ways, deciding to test your idea early signals that you really care about your idea actually reaching launch, so that the all the fun that's contained in your concept actually gets out to bring some joy to the world.

In the same way that journaling can help us process the day's events, or how talking to a therapist can help you process complex life events, the act of simply getting your thoughts out is a profound and somewhat magical way to examine every angle of an idea to spot things you might not have noticed at first.

It's why rubber ducking code challenges is so effective, and why the weight of the world might feel a little less imposing after talking to a friend about what's going on in life. As humans, getting stuff out of our heads into the world is, for whatever mortal reason, really useful.

So, with an early game idea in hand, let's jump right into planning and making a paper prototype.

Prototype Planning

Section 2

Getting Started

Taking an idea and creating something tangible from it can be a daunting task to undertake! Thankfully, the entire point of making paper prototypes is to reduce expectations, lower scope, and in some ways, even celebrate the janky early stages of a game's concept. After all, when everything's made from paper, you can literally cut out the parts that aren't working, and tape new things in.

However, before you go on a crusade to the nearest craft store, you should think about how you're going to prototype your various mechanics, and which things might be best left for a post-prototype phase, when you've learned what you can from the paper stage.

Playable vs Static Prototypes

While most of the details I'll be getting into are focused on making playable prototypes, it's completely valid to just sketch out rough ideas on paper, as simple drawings, to prototype a concept.

Not all prototypes need to be playable. It's still super valuable to look at a sequential collection of images that represent a journey through a gameplay moment to help refine and adjust your idea in the paper stage.

Static prototypes might resemble storyboards, comic books, or even mood boards in the most abstract sense. The core value remains similarly grounded: you're getting gameplay ideas out, in some organized fashion, into the world, with the smallest scope possible.

For those who want to actually play a concept in the paper stage, the rest of this post should be helpful.

Planning for Various Playable Tests

If your game involves moving characters, AI, or procedural generation, it might seem impossible to create any prototype out of merely paper. However, there's thankfully a number of ways to get started testing your game's mechanics and core hooks, whether you're making a first-person puzzle game, an RPG, or even a 4X strategy game.

Overall Structure

Depending on your concept's genre, certain board game parallels might be immediately clear. For other genres, there might not be anything that offers a structural approximation to adapt.

Tabletop games offer a particularly great medium to draw inspiration from. Sometimes involving tokens, cards, game boards, and dice, tabletop games are an imaginative genre of games that are wildly innovative with how you can assemble a few physical objects, give them rules, and create a game.

If you're struggling to think how to design the overall structure of your game, it might be useful to take a look at some of the more imaginative tabletop games out there, to try and spot mechanical parallels that you could adapt.

Rules & Documentation

Maybe one of the most important things to document at this stage is the hard rules you're testing in your prototype. This will help ensure you don't impart flexibility to the rules while testing, and to ensure that you can articulate the mechanics of the game as a hard-copy.

Even if it makes total sense in your head, being able to document your emotional understanding of your game's rules might help you practically refine them into a state that can be understood, used, and played by another person.

It's also helpful to make a small rule sheet to have handy while testing a prototype. That way, if you or someone who's helping you test your game forget what to do, there's something to refer to with certainty.


There's a variety of ways to test movement mechanics. Whether your game involves a character walking around, a robot that moves like a slingshot, or turn-based tactical formations, prototyping movement is totally reasonable.

Whether your game is real-time or turn-based, it can be helpful to paper prototype in turn-based format. If your mechanics are well-rounded and easy to understand, you can progress through turns quite quickly; while still allowing yourself to pause between turns to consider how to move forward. Reflecting on what parts of your prototype caused you to pause is an effective way of spotting where there's potentially unclear mechanical interactions.

  • For testing real-time movement, using a metronome set to 40-60 BPM can help you consciously measure if you're moving any given gameplay object fairly; and not sneaking in extra distance-per-second.
  • Moving a coin, token, or miniature figure around a sheet of paper, with optional beverage cans or desk supplies representing buildings, obstacles, and terrain. This can be done in real time, or turn-based.
  • Using a rubber band to fling small wads of paper can help you prototype player-initiated aiming/firing mechanics, or in the case of my game Harlow, the core movement mechanic. This method is applicable to real-time concepts, as well as actions that happen during the turns of a turn-based games.
  • Turn-based movement is the easiest to test, since you only need to commit to a ruleset to prototype. If your movement is freeform and based on distance, a simple length of string can let you text maximum movement distances. If your movement is based on a grid, even better; just define the rules for how many squares can be traversed in a single turn.
  • If you're able to, using your whole body can help test some things in a first-person perspective. For puzzle games that take place in first-person especially, making paper version of the puzzles you're asking players to solve can really help ensure you've considered context, sight lines to clues, and spatial complexity.

Artificial Intelligence

The easiest and most fun way to test artificial intelligence, in my opinion, is to clearly define the rules of the AI and then get a friend to act as the AI during a prototype playtest.

However, there's plenty of ways to test concepts that involve AI without involving anyone else.

  • First, decide how and when an AI can act. Do they take actions after you? At the same time as you? What kinds of actions can they take? Etc.
  • Dice rolls have been sustaining DnD campaigns for decades – and for good reason! Rolling some dice is a great way to quickly generate random outcomes. For example, you can write down that if a "4" is rolled during a given situation, the AI would decide to do something in particular, such as hiding behind a wall; whereas rolling a "5" might determine that the AI wants to walk towards the player.
  • Flipping a coin can add a little entropy, at a smaller scale than rolling dice, for simple AI decisions. For example, if you're creating a strategy game about capturing tiles on a board, a coin flip might determine whether or not the AI captures a tile to the right or left of their current position.
  • If you're pulling in the help of friends to test a prototype, ensure they have some sort of clearly written copy of the rules, and their available decisions as an "AI". Don't just throw them into the deep-end and expect them to swim. Onboard them to the mechanics, frequently ask if they have questions, and ensure they're comfortable with what you're testing.

Procedural Generation

Algorithmically generating entire planets, dungeons, and caves is awesome, but how the heck can you do that with just paper? Tons of ways, that's how!

  • If you're testing procedural generation of landscapes, use same/similar sized pieces of paper and create chunks of your world that can be shuffled and reassembled.
  • If you're testing procedural generation of quests, dialogue, or simple narrative arcs, first decide on a format, such as "Person X will request Task Y with Condition Z". For each variable in your format, write up a bunch of potential outcomes on slips of paper, and organize them into respective piles. Then, to test your random generation, mix up each pile face-down, and assemble a full-format quest statement with one slip from each. This was how I prototyped building Sharpen, the world's largest design prompt generator, early on.
  • If you're testing procedural generation of vehicles, buildings, or creatures, you can use a method similar to the above outline for generating quests. A great example of procedural creature generation is Bears vs Babies by Elan Lee and Matthew Inman.


In the early prototype phase, I've found combat best-prototyped in one of two ways: either focusing on movement, or focusing on formulas.

If you're making a Soulslike, a shooter, or even a fighting game, combat ultimately comes down to movement and decision timing. Whether you're fluidly coasting around the landscape, or scuttling from cover-to-cover, your core focus on staying alive and finding an advantage against your enemy comes down to how you move, where you can move, and when you decide to strike. Prototyping your movement mechanics can offer insight, even if large-scale firefights aren't well-scoped for prototyping in paper.

If you're making an RPG, an RTS, a 4X game, or a turn-based tactical game, you can effectively prototype combat by tracking how much health individual things have, and how much damage is done during an attack. Coins, paper wads, beads, and other small objects are a quick and visual way to keep track of health of various characters or buildings.

Building & Testing

Section 3

Creating a Task List

Once you have a general direction for how your prototype will be tested, it can be useful to create a checklist of all the work required. Considering what needs assembling or how certain things will be calculated can ensure that when you get to your first playtest of a prototype you're not left caught off-guard by missing pieces.

By virtue of creating a task list, you also create a high-level inventory of what materials are needed to construct your prototype. Lots of materials don't need to be bought anew; the back of used paper, the inside cardboard from cereal boxes, and mismatched figurines from different board games can all be thrown together into an effective prototype. The point is testing mechanics, not visual cohesion.


Once you've gathered the materials needed for your prototype, get to building! The most important thing to remember during this stage is that nothing needs to look polished. Everything can be rough sketches, uneven cuts, misaligned tape, etc. As long as you can clearly identify one game element from another, you're good to go!

As you assemble the pieces for your paper prototype, you might notice opportunities to refine, change how certain things work, or simplify concepts even more in the prototype stage. That's completely fine – this early stage of a project is the best time to adjust, redefine, or reimagine how mechanics, scale, and hooks work.

Initial Prototype Testing

When getting ready to test your initial prototype, there's a few things that can help ensure your first steps are as well-placed as possible:

  • A timer, so you can measure how long a session lasts. This can help you measure whether or not you're simplifying the game with future iterations.
  • A note pad, so you can jot down thoughts in real-time. This is super useful to capture moments where mechanics might feel weird, new ideas for fun enhancements, or general self-reflections. You should also capture information about whether or not a given prototype test was successful.
  • Spare game pieces, in case something gets damaged during testing. Drinks tip over, stray salsa might ruin a game token, you never know.
  • A clear idea of the win / stop condition, so future iterations can be adequately measured against each other.

With all those parts and pieces set, you can jump into playing and testing your paper prototype with confidence.

Iterative Testing

Once you complete your first test of a playable prototype, take a moment to reflect on how things went. Write down any notes that are fresh in your mind, and think about any hiccups that happened during testing.

If things went awry and your concept ended up being difficult, not fun, or confusing, don't worry! That's why prototyping is important! Think about all the time you saved yourself finding out things were confusing using only paper, instead of building everything in code and art assets!

It can be tempting to change a whole handful of things between tests, and by all means, if you strongly think large chunks of a prototype need an overhaul, go for it. But small changes can make big impacts too. Consider tweaking a rule, or revising how a mechanic works, and then doing a small test to see how things feel. By limiting the number of things that change between tests of a prototype, you gain clarity in deciphering what changes resulted in what outcomes.

Keep testing and adjusting your prototype a few times. When jumping into a session is a fun, clear, engaging experience, you can rest assured you're on to something.

Finding the Fun

Ultimately, the goal of any game is to be a fun experience. As you test and iterate, you might observe that certain things are where the "fun" or "frustration" of your prototype is centralized. Noticing when those moments happen can be an incredibly impactful part of your journey in making a completed game.

As you move between paper prototype versions, and eventually into full production, knowing where the fun and frustration are concentrated can help you provide motivation, incentive, and encouragement to players to get through the difficult bits; while also providing them celebration, acknowledgement, and satisfaction during the fun segments. Later in production, a lot of attention on "juice" (satisfyingly heightened emphasis of gameplay moments) during these moments can further amplify their emotional impact on players.

So, as you test, keep a running list of notes about what's the most fun, why it's fun, and what parts are a little frustrating. This can also help create points of comparison for future work on your project, to see how the end gameplay matches up with – or diverts from – the fun of the prototype.

To Production And Beyond

Final Section

Moving On From Paper

So you built and tested an awesome paper prototype, and you're happy with how it plays. How do you move on to actual production from here?

If you're making a video game, this probably means translating some of your game ideas into code. If you're making a tabletop game, it might mean taking a step towards using the more finalized materials you're hoping to use. For the purposes of this post, I'll be focusing on video game production – though many of the same considerations remain similar.

The first way to move from prototype to production, and perhaps the most practical way, is to create a prototype milestone. (A future post will go in-depth into planning, using, and sticking to a development milestone schedule.)

If you haven't worked with milestones before, they're basically large to-do lists that span weeks or a few months. From that perspective, your first milestone might revolve solely around translating and iterating the prototype from paper to code. Instead of just tracking it as a single large to-do list item called "Make the prototype", you should identify and write out each of the parts of the prototype as its own dedicated task.

For example, if your game consists of a map, a movement system, and puddles of lava to jump over, you'd probably want to track how each of those things comes together, so you can be thoughtful in your choices.

Another benefit of making itemized milestone lists is that it helps you iterate. You might've paper prototyped a turn-based movement system, but later decided a real-time movement system is more fun. Tracking somewhere when and why you made a decision can help you debug things in the future, and is especially useful if other people are ever brought into the project.

Another way to move from prototype to production is to do a deep-dive into your own prototype's mechanics as documentation, examining the ways you'll want it to stay the same or change, once rebuilt in code. By looking at your prototype in a retrospective fashion, you're acknowledging that everything in the paper phase that needed to have changed has in fact changed and been tested, and can offer you confidence that you've done all you can before moving on. If that's a difficult call to make, it might be useful to go back and test a bit more.

Lastly, as you move from your initial paper prototypes into production, you might notice that new ideas pop up for things to test. That's totally ok! Keep track of new ideas, inspirations you want to explore, and new mechanics that seem interesting. You can always try new things out in future paper prototypes, even mid-production, to quickly determine whether something is worth building in code.

In Closing

Paper prototyping is awesome. It's the most flexible and easiest to adapt stage of game development, and it can save you a ton of headaches in the future. It's one of the easiest, most accessible, and cheapest ways to test an idea out as well!

With this guide in hand, you're ready to jump into prototyping your game:

  • Document your game's core concept in 1-2 sentences.
  • Write out what parts of your game's mechanics you're planning to prototype.
  • Explore ways to translate those mechanics into simple physical versions.
  • Build those simple mechanics from craft materials and don't stress the fidelity or polish.
  • Test those simple mechanics by yourself or with a friend.
  • Capture how the test went in notes, and what you might want to change.
  • Iterate based on your notes, and tweak any parts of the gameplay rules needed.
  • Test, capture, iterate, and repeat until your prototype is clear, fun, easy to play, and flows well.
  • Identify which parts of your prototype will need to change when building a coded version, and which parts will remain the same.
  • Plan a detailed milestone to-do list for building a second version of your prototype in code.

Enjoy this guide?

Heya! 👋🏼 You made it to the end of the paper prototyping guide – awesome! I hope it was useful.

If you enjoyed this guide, consider subscribing (it's free) by clicking here. I'll be doing more guides like this one around accessibility, pitching to publishers, and more. I'll also be releasing some useful gamedev tools I've built just for subscribers.

As always, if you need to reach me, you can say hi on Twitter.

Cheers and good luck with your prototyping!

Want a guide on a specific topic? Let me know!