From game idea to prototype: write a one-page brief and a task list

A one-page brief beats a forty-page design document

For a prototype, a long design document goes stale before it has been used. A one-page brief fits in your head, can be reread in two minutes and can be handed to a teammate or a coding agent. It doesn't describe the whole game: it explains what you are testing, why, and what you are deliberately leaving aside.

1. The six lines of the brief

Write: the intent (what the player should feel), the mechanic to test, the useful references, the constraints (time, tools, scope), what is out of scope and the question to check. For Dicebound: "Test whether locking a die creates an interesting decision. References: Dicey Dungeons, Slice & Dice. Constraints: one character, one enemy, two evenings. Out of scope: progression, sound, menus. Question: do testers reroll voluntarily?"

2. Break it into tasks of under half a day

Each task should fit in a single work session. For Dicebound: show three dice and an enemy; let the player lock a die; reroll the unlocked dice; split the results between attack and defense; show the enemy's intent; a fight-end screen. A vague task such as "build the fight" hides several decisions. Split it until you can finish it without another meeting with yourself.

3. Give each task an observable result

Describe what can be seen or done once the task is finished: "I click a die, it locks and does not move on the next roll." This sentence serves as the review criterion, whether you, a teammate or an agent coded the task. Add a line about what is not part of the task to prevent silent additions.

4. In Impstash: from kept idea to task

Mark the idea as kept, then create the task from the idea: its title and text serve as a starting point and the task stays linked to the idea. Complete the description with the brief, then place the tasks in the Kanban columns. For each task, a version can be submitted for review with a note and links, and a member accepts it or asks for a redo.

5. End with a test task, not a feature

The last task of the batch is always: "Have three to five people try it and write down what they did." Without it, the prototype serves to build a game rather than to answer your question. After the test, update the brief: keep, adjust or drop, then write the next bet.

A prompt to adapt to your game

Here is a kept idea for Dicebound: lock a die, reroll the others and split the results between attack and defense. References: Dicey Dungeons, Slice & Dice. Constraints: one character, one enemy, two evenings. Write a one-page brief with intent, mechanic to test, references, constraints, out of scope and question to check. Then propose six tasks of under half a day, each with an observable result. End with a test task involving five people. Flag the points where you are making an assumption.

Replace the references and constraints with your own. The AI’s answers are leads to review; the choice remains yours.

References and communities to keep going

• Dicey Dungeons — Dice values turned into decisions: study equipment constraints.
• Slice & Dice — Visible enemy intents: compare risk, rerolls and dice teamwork.
• Dicey Dungeons — Creator notes and videos
• r/gamedesign — To discuss mechanics, rules, and design trade-offs.
• r/gameideas — To share a structured idea and explore its possibilities. Check the rules before publishing.