Paper prototypes first
The argument for prototyping on paper is not nostalgia and it is not frugality. It is that paper changes in seconds and code changes in hours, and the first week of a design is entirely made of changes. Anything you build in software during that week you will defend, because you paid for it. Nobody defends an index card.
What follows is a working method rather than a philosophy. It assumes an evening, a table and no budget.
What to make
Cut about forty blank cards from card stock, or use index cards. Draw a grid on a sheet of A3 with a ruler and a pencil, eight by eight if you have no better idea. Find counters: coins, dried beans, buttons, anything with two distinguishable colours. Get a six-sided die, a pad of sticky notes and a pencil with an eraser. That is the whole kit and it will serve for years.
Write nothing on the cards yet. The commonest failure of a paper prototype is that somebody spends two hours making it pretty, and a pretty prototype is one you will not throw away.
The one-page rule
Before laying anything out, write the rules on a single side of one sheet. If they do not fit, the design is not ready to be tested; it is still being invented, and you should keep inventing rather than staging a test that will only tell you the rules are unclear.
The sheet should name the goal, the turn structure, the two or three actions available and the one condition that ends the game. Everything else is detail you can rule on as it comes up. Write your rulings in the margin as you play; the margin is where the real second draft is written.
The four answerable questions
A paper version answers some questions well and others not at all. Being clear about which is what keeps the exercise honest.
Is there a decision? Lay out the opening position and ask yourself what you would do. If the answer is obvious every turn, there is no game yet, only a procedure. This is the single most valuable thing paper tells you, and it tells you in about four minutes.
Does the decision change? Play ten turns. If turn ten presents the same choice as turn two with different numbers, the design has a shape problem that no amount of art will fix.
How long is it? Time the play. Paper runs slower than software, but the ratio between your early game and your late game holds, and a design whose last third takes twice as long as its first two thirds will feel that way in any medium.
Can someone else run it? Hand the sheet and the pieces to a person who has not heard you explain it. What they get wrong is not their error; it is the design telling you which parts are not carried by the components.
What paper cannot tell you
It cannot tell you about feel, timing, or anything measured in fractions of a second. It cannot evaluate a game whose interest lies in execution rather than choice, which rules out most action design. It cannot simulate the pleasure of a system running fast, and it will make anything with hidden information laborious, because you become the machine that hides it.
Where those are the point, prototype in code, but prototype the single mechanism only, in a grey box, with no menus, and be as willing to bin it as you would be to bin a card.
Ending the paper phase
Stop when the one-page rules survive three plays without a margin note that changes the structure. Small numeric changes are fine and will continue forever. Structural notes — a new phase, a removed action, a different ending condition — mean the design is still moving and another evening of paper is cheaper than another week of code.
Keep the sheets. A stack of dated rule sheets is the most useful document a small project produces, because it records not only what the design became but every version it stopped being, and the second is the part you will otherwise forget.