board-game-designer

Board Game Designer Skill

Everyone has a board game idea; almost nobody has a prototype, because the gap

between theme ("it's about deep-sea heists!") and game (what do I DO on my

turn?) is where ideas stall. This skill forces the designer's questions in the

order working designers ask them — loop before theme-decoration, tension before

content, cardboard before art — and ships the user toward a playtest this week

with ugly components and honest kill criteria.

What This Skill Produces

• A design one-pager: hook, core loop, tension source, end condition,

player count/length targets

• A prototype spec buildable tonight: index cards, dice, cubes — counts and

what's written on each; zero art

• Balance starting-points: first-pass numbers with the reasoning, labelled

as guesses to tune, never as solved math

• A 3-session playtest protocol with what to watch, what to ask, and kill

criteria — the honest thresholds for pivot-or-persevere

Required Inputs

Ask for (if not already provided):

• The idea as they'd pitch it to a friend, plus what inspired it
• The feeling the best turn should produce (clever? tense? gleeful betrayal?)
• Target: players, minutes, audience (family? hobbyists? their own group?)
• If mid-design: what's working, and where it drags

Process

1. Find the loop. One sentence: "On your turn you [verb] to get [resource]

to [convert] toward [goal]." No loop sentence, no game yet — iterate here

before anything else.

1. Name the tension. Every game that works has a recurring painful choice

(this OR that, now OR better-later, me OR blocking-you). Identify the one

this design offers; if every option is good, there's no game in the loop yet.

1. Steal structure honestly. Name 2–3 existing games whose mechanisms

neighbour this design and what each does with them — designers study prior

art; note where this design genuinely differs (its one new twist) and where

it shouldn't bother differing.

1. Spec the ugliest playable version. Index cards and cubes, tonight. Every

component count written down. The rule: nothing gets art until it survives

five plays.

1. First-pass the numbers. Costs, income, end-trigger pacing — pick values

with stated reasoning ("end triggers around turn 8 so the engine peaks once"),

marked TUNE. Balance comes from plays, not spreadsheets; the spreadsheet just

picks where to start.

1. Protocol the playtests. Session 1 (solo, all seats): does the loop

function? Session 2 (friendly table): where does attention die? Watch for the

tells — checking phones, analysis stalls, kingmaking, runaway leader. Session

3 (someone who owes you nothing): would they play again unprompted? Kill

criteria stated up front: if the same drag survives two fixes, the mechanism

goes, however loved.

Output Format

## Design one-pager
[Hook · loop sentence · the tension · end condition · count/length targets]

## Neighbouring designs
[2-3 games, the mechanism borrowed/varied, the one honest twist here]

## Prototype spec (build tonight)
[Component list with counts and card text · setup · turn structure v0.1]

## Numbers v0.1 (all marked TUNE)
[Table of starting values + one line of reasoning each]

## Playtest protocol
[3 sessions: goal, what to watch, questions to ask AFTER not during]
Kill criteria: [the honest thresholds]

Quality Checks

• [ ] The loop fits in one sentence and contains a decision, not just an action
• [ ] The tension is a recurring choice, named concretely
• [ ] Prototype is buildable from household stationery in an evening — if it

needs printing services, it's overdesigned for v0.1

• [ ] Every number carries reasoning and a TUNE flag — no false precision
• [ ] Kill criteria exist and are specific enough to actually trigger

Anti-Patterns

• [ ] Do not start with theme, art, or a Kickstarter plan — loop, tension,

cardboard, in that order

• [ ] Do not claim the idea is original without the prior-art pass, and do not

copy a game wholesale with the theme swapped — name the twist

• [ ] Do not present first-pass numbers as balanced — playtesting owns balance
• [ ] Do not let the designer explain rules during playtests — confusion IS the

data

• [ ] Do not promise market outcomes ("this would sell!") — the promise is a

playtest by Friday