From Paper Prototype to Playable Build in Two Weeks

Every finished game started as something unplayable: a sketch on an index card, a handful of dice, a spreadsheet pretending to be an economy. Prototyping is the discipline of testing ideas at the cheapest possible fidelity, and it is the single biggest predictor of whether an indie project ships or stalls. Teams that prototype ruthlessly kill weak ideas in days; teams that skip it discover the same problems after months of production.

Two weeks is enough to go from a written concept to a playable build that answers the only question that matters at this stage: is the core loop fun? Here is a realistic schedule that solo developers and small teams can actually hold.

Days 1–3: paper first, engine later

Resist the urge to open your engine on day one. A paper prototype — cards, tokens, a hand-drawn board, or even a slide deck with clickable buttons — exposes broken rules and dull decisions at almost zero cost. If your game is about positioning, cut out paper units. If it is about economy, run the numbers with coins and a notepad.

The goal of the paper phase is a written one-page ruleset that another person can run without you in the room. If a friend cannot moderate your game from the sheet alone, the design is not yet clear enough to code.

Days 4–9: the ugly playable

Now build the core loop — and only the core loop — with placeholder everything. Grey boxes, free icon packs, text labels instead of art. The industry calls this a "greybox," and its ugliness is a feature: nobody falls in love with placeholder art, so nobody is afraid to throw the build away.

• Scope the loop, not the game. One level, one enemy type, one weapon. If the loop is a minute long, you can playtest it fifty times a day.
• Timebox features in hours, not days. Anything that cannot be built in four hours gets cut or simplified for the prototype.
• Log one metric. Even a simple timer or death counter gives you something objective to argue about later.

Days 10–14: test, decide, document

Put the build in front of three to five people who have never seen it. Watch them play in silence, note where they hesitate, and resist explaining anything — confusion you explain away in the room is confusion a store page cannot fix. After the sessions, write a one-page verdict: keep, change, or kill.

The deliverable of a prototype is not a demo — it is a decision. A two-week prototype that kills a bad idea saves six months of production. A prototype that survives testing gives you something even more valuable: proof, in writing, that the fun is real before you spend a year building around it.