board_game_design v1.0.0

name: "board_game_design" description: "Design a playable board game: core loop and player decisions first, component and economy math on paper, blind playtesting with a fix log, and rules writing that a stranger can learn from without the designer in the room. Use when someone wants to design, prototype, balance, playtest, or write rules for a board or card game."

Board Game Design

Purpose

Take a board game idea from a pitch to a prototype strangers can learn and finish without help. The order matters: decisions first, math on paper second, cheap prototype third, playtests with a written fix log fourth, rulebook last. Most failed designs reverse that order and polish art for a loop that was never tested.

Workflow

1. Name the experience before the parts. Use the MDA frame from Hunicke, LeBlanc, and Zubek (2004): Mechanics are the rules you write, Dynamics are the behavior those rules produce in play, Aesthetics are what players feel. You build in that order, players feel it in reverse. Pick one or two target feelings from their eight (Sensation, Fantasy, Narrative, Challenge, Fellowship, Discovery, Expression, Submission) and write them at the top of the design. Every later cut gets judged against them.

1. Write the core loop in one sentence. Format: on my turn I choose, then I pay or place, then I gain or change, then we check the end trigger. Fill the loop and decision worksheets in references/worksheets.md. A loop earns its place only if the repeated decision is real: two or more options a reasonable player might pick, with different tradeoffs. Test it with Salen and Zimmerman's meaningful play bar from Rules of Play (MIT Press, 2003): outcomes must be discernable (the player sees the result) and integrated (the result changes later play).

1. Do the economy math on paper before building anything. List every resource with its source, its sink, starting amount, and income early and late. Price items in turns of income, not in feelings. Run the numbers with scripts/economy.py:

• python3 scripts/economy.py dice 2d6 prints the exact distribution and expected value. Summed dice cluster in the middle (2d6 averages 7, a 7 comes up 6 in 36 rolls, a 2 only 1 in 36). A flat die spreads evenly (1d12 averages 6.5, every result 1 in 12). Choose based on whether the roll feeds planning or drama.
• python3 scripts/economy.py ev "0.5:4,0.5:0" gives expected value 2 per attempt. Compare actions by expected value before arguing about feel.
• python3 scripts/economy.py draw --pool 100 --targets 20 --draws 3 gives the exact chance of at least one target when drawing without replacement (49.2 percent here). Decks and bags shrink, so odds shift as they empty. Small pools swing hard, large pools run steady.
• python3 scripts/economy.py income --turns 8 --start 3 --per-turn 2 --costs "5,8" shows the turn a normal player can first afford each cost. If the best item arrives on turn 1 or never arrives, reprice before anyone plays.

1. Hunt the three balance failures on paper. A dominant strategy (one line of play beats the rest and ends choosing), a runaway leader (early gains compound until the result is settled early), and a catch-up rule so strong it punishes leading (players learn to hang back). For each, write how your design blocks it or why it cannot arise. Prefer catch-up built into a core action, such as last place choosing or reserving first, over a bonus handed to whoever trails. Log wins by strategy and starting seat once testing starts. Patterns need logged games, not impressions.

1. Prototype as cheap as the loop allows. Paper, card sleeves, borrowed tokens, a board drawn on one sheet. Include a component list with counts that a stranger could build from. Cut any component no rule references. Do not commission art, print on thick stock, or 3D print pieces until the loop has survived three full plays, because good looking parts protect bad rules from being cut.

1. Playtest in phases, one question per phase. Full protocol, questionnaire, and fix log format are in references/playtest-protocol.md.

• Phase 1, solo: can the game finish at all. Fix breaks only.
• Phase 2, guided: teach it, watch for dominant strategies, give one tester the suspected broken strategy on purpose.
• Phase 3, unguided: hand over box and draft rules, answer nothing, log every question and every rule played wrong.
• Phase 4, blind: a group that does not know you learns from the box alone and answers the written questionnaire. Watch behavior over praise. Polite players say a weak game is fine. Bored posture, phone checking, and no request to play again say more.

1. Fix from the log, one change at a time. Log each issue in the testers words or as observed behavior, grade it (breaks game, hurts game, polish), name the root cause (rule, price, component, or wording), make one fix, and retest that fix. An issue in two separate groups is a fix. A prettier prototype is polish and goes last. Change three prices at once and you learn the game changed, not why.

1. Write the rulebook for a stranger, last. Structure: overview and goal, components with counts, setup in numbered steps in play order, gameplay in turn order, end of game and scoring with the exact tie break. Write in direct commands addressed to the player ("Take 2 cards"), keep one name for each component and use it everywhere, define each term once, and add a worked example for any rule testers got wrong. Add a player aid with turn options and the one rule players forget most. In Stonemaier Games practice, player aids come first and the full rulebook is written as blind testing approaches, because early rules change too fast to polish. A page spent explaining a minor rule is a signal that rule may cost more than it adds.

1. Ship the done test, not a feeling. The design is ready to show a publisher or a wider group when two blind groups in a row finish it from the rules alone, play it as intended, and report a close finish or a clear reason the loser lost. Worked end to end in references/worked-example.md: Night Market, a trading game taken from pitch through solo, guided, unguided, and blind tests, with its prices set by the calculator and three logged fixes.

Output Contract

Deliver, for any design you work on with this skill: the one sentence core loop, the target feelings, a filled economy table (source and sink per resource) with prices justified in turns of income, the probability numbers for each random element with the calculator command that produced them, a component list with counts, a playtest log with at least the current phase and its open issues graded by severity, and a rulebook draft in the structure above. If a piece does not exist yet, say which phase the design is in and what test comes next instead of filling the gap with a guess.

Operating Rules

1. No invented numbers. Every probability, expected value, and timing claim comes from scripts/economy.py, a hand count you show, or a cited source. If you cannot compute it, label it an estimate and say why.
2. Decisions before theme dressing. A theme can suggest mechanics, but no theme detail survives a test showing it adds rules without adding a decision.
3. Never call a game balanced from designer taught plays. Balance claims require logged plays, and learnability claims require at least one unguided or blind group.
4. Fix wording before fixing rules when strangers play a rule wrong. Two groups making the same mistake means the text failed first.
5. Keep the fix log as the single record. Fixes made from memory get lost and get remade. Log first, change second.
6. Cut exceptions. Each exception is a rule players must remember for a rare case. If an exception fires less than once a game, fold it into the main rule or remove it.
7. Respect player time. State the length target, test against real clocks including setup, and treat setup over 10 minutes for a mid weight game as a design problem, not a player problem.