Here is a failure pattern most small teams will recognise. Three weeks go into a crafting system: recipe data, an inventory grid, drag-and-drop, tooltips, a discovery log. Then the first playtest shows that players open it once, shrug, and never come back — because nothing in the game ever made them need a crafted item. The missing piece wasn't code quality. It was that nobody asked whether players would want the loop, and that question could have been answered in forty minutes with forty index cards.
Paper prototyping is the cheapest tool in design, and the one small teams skip most often, usually because it feels unserious. It isn't. It's a way to buy information about your systems at a hundredth of the cost of building them, and the teams that do it well ship fewer dead features.
What paper can and can't answer
Paper is a simulator for decisions. It is useless for anything that lives in your hands or your eyes. Before you cut cards, sort your open questions into the right bucket.
| Question | Test on | Why |
|---|---|---|
| Is this choice interesting more than once? | Paper | It's a decision, not a sensation |
| Do these three resources create tension? | Paper | Arithmetic and scarcity, nothing else |
| Is the economy solvable/degenerate? | Paper | You can brute-force it by hand |
| Does the player understand the rule from the UI? | Build | Needs real presentation |
| Does the jump feel good? | Build | Needs frames, not turns |
| Is 0.2s of hit-stop too much? | Build | Pure game feel |
| Is this level the right length? | Greybox | Needs space and traversal |
The rule of thumb: if the answer would change because of an animation, a sound or a 100ms delay, paper will lie to you. If the answer would change because of a number, a cost or an ordering, paper will tell you the truth faster than your engine will.
Turn-based games are the easy case — a tactics or deckbuilding system is nearly a board game already. But real-time games have decision layers too: build order in an RTS, loadout choice in a shooter, which upgrade to take in a roguelike run. All of those are paper-testable, because the player is doing arithmetic under scarcity, not reacting in frames.
Four rigs that cover most systems
You don't need a new prototype format for every idea. Four rigs handle the large majority of indie systems, and each takes under an hour to assemble from a stationery drawer.
The card rig — economies, crafting, deckbuilders
Index cards, one per item/recipe/ability, with cost on the top-left and effect in the middle. Draw from a shuffled stack, pay with poker chips or dried beans. This is the rig for anything that looks like Slay the Spire or a crafting tree: you're testing whether the costs produce interesting refusals.
Write the numbers in pencil. You will change the cost of one card ten times in a session, and a pen makes you reluctant.
The grid rig — tactics, stealth, movement systems
Graph paper, or a whiteboard with a drawn grid. Into the Breach fits its entire tactical system on an 8×8 board; your first stealth prototype can live on 12×12 squares with coins for guards and a paperclip for the player. Guard vision becomes "three squares in a cone", which you check by eye. This is how you discover that your patrol routes have a hole, or that your dash distance of 3 makes every encounter trivially skippable, before anyone writes a navmesh.
The dice rig — randomness, loot, detection
A d6, a d20 and a lookup table on a sheet of paper. If your loot table is "60% common, 30% rare, 10% legendary", that's 1–12 / 13–18 / 19–20 on a d20, and you can roll 50 drops in five minutes to see what a bad streak actually looks like. Rolling randomness by hand is the fastest cure for designers who underestimate variance: nobody who has personally rolled four blanks in a row argues against pity timers.
The sticky-note rig — progression, quests, dialogue structure
One note per node, arranged on a wall or a table. Arrows in marker. This is the rig for unlock orders, quest dependencies and dialogue shapes — anything where the question is "can the player reach a dead end?" rather than "how does this feel?". Walking the graph with your finger finds unreachable content and soft-locks in minutes.
Once a sticky-note graph survives a session, move it into something structured before it falls off the wall — a dialogue-tree or objectives module is where that graph belongs (GameDesignerX has both). Note the direction of travel: paper first, tool second. Formalising a structure you haven't tested just makes a tidier version of the wrong thing.
Run the session like a playtest, not a conversation
The common failure mode isn't a bad rig. It's three designers leaning over a table talking about what would happen. Impose a little ceremony:
- One person plays, one person is the computer. The player may not touch the rules sheet. The "computer" resolves everything the game would resolve and answers no design questions.
- Write the question on the table before you start. One sentence: "Does the player ever choose the cheap upgrade over the expensive one?" If you can't write it, you're not ready to test.
- 25 minutes per variant, three variants per session. Short rounds force you to change one number at a time instead of redesigning mid-game.
- Change one thing between variants. Upgrade cost 5 → 8, or hand size 7 → 5. Not both.
- Log the state every turn. Resources held, choice made, turn number. A column per resource on a sheet of A4 is enough.
- Stop when the player stops hesitating. Hesitation is the signal that a choice is live. A player who answers instantly every turn is telling you the system has a dominant strategy.
That last one is the real deliverable of a paper session. You are not looking for fun — a cardboard version of your game is never fun, and judging it on fun is how good systems get killed. You're looking for hesitation, regret and recalculation. If the player ever says "wait, let me count", the system has tension in it. If they say "obviously I take the sword", you've found a balance bug for the price of an index card.
Get the numbers off the table before they evaporate
A paper session produces three things worth keeping, and all three are gone by Thursday if you don't write them down.
- The numbers that worked. The costs, rates and caps from the variant that produced the most hesitation. These are your first-pass values — drop them straight into a balance or economy sheet so the implementation starts from tested figures instead of guesses.
- The rules you had to invent on the fly. Every time the "computer" had to make a ruling, you found an undefined edge case. Those rulings are mechanics-spec content, and they're the ones that generate bugs later.
- The decision and its reason. "We dropped the third currency because players ignored it in all three variants" belongs in a decision log, with the session date attached. In nine months, someone will propose the third currency again, and a one-line record is the difference between a two-minute answer and a re-argued afternoon.
A worked example of what step 1 buys you: a survival loop where wood pays for repairs and fuel. At 4 wood per repair and 2 per night, the player gathers wood and does nothing else. At 2 and 1, they ignore gathering and the mechanic is decorative. The interesting zone is 3 and 1 with a 20-wood carry cap that forces return trips. Three tuned constants in an afternoon with chips and a notebook — in code, each would have cost a build, a playtest and a day of waiting.
When to stop
Paper has a hard ceiling, and staying past it is its own failure. Stop when the open questions stop being arithmetic: when what's left is readability, pacing, feel, or whether the thing is legible at a glance. Stop also when the rig takes longer to resolve than it takes to play — if the "computer" needs ninety seconds per turn, you've modelled too much, and either simplify the rig or go build a grey prototype.
The target was never a beautiful cardboard game. It's a page of numbers you trust, a list of edge cases you've already ruled on, and one or two features you now know not to build.