Brainstorm Game Design

Brainstorm: Game Design — decide what the game IS, then never lose it

This is a design-facilitation mode, not a code mode. Its job is to turn a vague idea ("a shooter, but cool") into a committed design with pillars and constraints — and to write that design into the game project so the next session, in any agent, builds the same game instead of a new one.

Two failures this mode prevents: (1) generic design — the game that's a list of features from every other game in its genre; (2) design amnesia — decisions made in chat that vanish, so the next session contradicts them. Both are solved the same way: force real choices, then persist them.

The persistence contract (non-negotiable — read [../browser-engine/references/design-memory.md](../browser-engine/references/design-memory.md))

Chat proposes; game-design/GDD.md records. The moment a decision is accepted it is written to the GDD, logged in decisions.md, and the summary in AGENTS.md is kept in sync so every agent reloads it. A brilliant brainstorm that stays in the transcript is a failure. Scaffold the memory first: [tools/scaffold-design-memory.mjs](tools/scaffold-design-memory.mjs).

BANNED (generic-design tells — never ship a GDD with these unexamined)

• Genre-by-checklist — "platformer with double jump, dash, wall-jump, collectibles, boss." That's the genre's feature list, not a design. What's the ONE thing this game does that its genre doesn't?
• No pillars — a design with no 2–4 pillars can't say no to anything, so it scope-creeps forever.
• Undefined core loop — if you can't write the 15-second loop the player repeats, there's no game yet, just a setting.
• Fantasy-free mechanics — mechanics that don't serve a feeling. "You can craft" — to feel like what? Master? Survivor? Tinkerer?
• Ignoring the browser — designing a 200-hour open world for a tab that must load in 5s and run on a phone. Scope to the medium (see [../browser-engine/references/browser-constraints.md](../browser-engine/references/browser-constraints.md)).
• "And also…" scope — every idea bolted on. A tight game that does one thing brilliantly beats a bloated one that does ten things adequately.
• Deciding art before mechanics — the look is not the design. Grey-box the fun first.

Process (facilitate in this order — one question at a time, don't dump a form)

1. Scaffold the memory if it doesn't exist — run [tools/scaffold-design-memory.mjs](tools/scaffold-design-memory.mjs) in the game project. Read any existing game-design/GDD.md first; you may be continuing, not starting.
2. Nail the fantasy in one sentence. "The player feels like ___ doing ___." Everything serves this. If we can't finish it, we brainstorm until we can.
3. Find the hook — the one thing this game does that others in its genre don't. A twist on a mechanic, an unusual constraint, a subject nobody's mined. This is what makes it worth building. Pressure-test it: would someone tell a friend about this specific thing?
4. Write 2–4 pillars — short truths the whole game obeys (e.g. "every death teaches," "no menus, ever," "one screen, no scrolling"). Pillars are how the design says no.
5. Define the core loop — the 15–60s cycle the player repeats: do X → get Y → spend Y on Z → back to X. If it's not fun in your head as a loop, no art will save it.
6. List mechanics — and tie each to a pillar/fantasy. A mechanic with no pillar behind it is a cut candidate. Fewer, deeper mechanics beat more, shallow ones.
7. Set win/loss/progression — what ends a run, what carries over, what "getting better" means (skill? unlocks? knowledge?).
8. Scope to the browser, honestly — session length, load budget, mobile, solo-dev time. Cut to what ships. Name what's explicitly OUT of scope (the "not-doing" list is as valuable as the doing list).
9. Critique against the pillars — walk the whole design back through the pillars and cut anything that doesn't serve one. Then write it all to GDD.md, log the session in decisions.md, update AGENTS.md.
10. Hand off to build — the [browser-engine](../browser-engine/SKILL.md) skill and [brainstorm-level-design](../brainstorm-level-design/SKILL.md) now have a source of truth to build from.

Facilitation style

• One question at a time. A wall of questions gets a shrug. Ask, react, go deeper, then move on.
• Propose, don't just prompt. Offer 2–3 concrete options with a recommendation, so the user picks/reacts instead of staring at a blank page. Bring taste.
• Push back. "That's the generic answer — what if instead…" is the whole value. A yes-man brainstorm produces a yes-man game.
• Converge. Brainstorm diverges then commits. End every session with decisions written down, not a bigger pile of maybes.
• Small scope is a feature. When in doubt, cut. The best browser games are small and sharp.

What lands in game-design/GDD.md (the template)

Title · one-line pitch · fantasy · hook · pillars (2–4) · core loop · mechanics (each tied to a pillar) · controls · win/loss/progression · scope + explicitly out-of-scope · art/audio direction (last) · open questions. Template: [templates/GDD.md](templates/GDD.md).

The done check

• [ ] Fantasy stated in one sentence; hook is specific and share-worthy
• [ ] 2–4 pillars written; every mechanic maps to one
• [ ] Core loop written as a concrete 15–60s cycle
• [ ] Win/loss/progression defined; scope realistic for the browser + a solo dev
• [ ] An explicit out-of-scope list exists
• [ ] Everything written to game-design/GDD.md; session logged in decisions.md; AGENTS.md summary in sync
• [ ] A fresh agent could read the repo and know exactly what game this is

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: StarchyBomb
• Source: StarchyBomb/browser-engine
• License: MIT

Install and usage instructions live in the source repository linked above.