kyh Grill the game idea
Interview the user relentlessly about every aspect of the game they want to make until you reach a shared, build-ready understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.
Ask the questions one at a time, waiting for the answer before continuing — multiple questions at once is bewildering. For each question, provide your recommended answer and why — the user should be able to say "yes, that" and move on.
Facts vs decisions: if a fact can be found by exploring an existing project or codebase, look it up instead of asking. The decisions are the user's — put each one to them and wait; never answer your own question and move on.
Sharpen fuzzy terms as they appear. When the user says "roguelike", "combo", "level", "energy" — overloaded words — propose a precise meaning and get agreement ("by 'roguelike' do you mean permadeath + procedural runs, or just 'hard'?"). Pick one canonical name per concept and use it consistently in the SPEC; later build sessions will mishandle synonyms.
Stress-test answers with degenerate play. When a loop or mechanic is described, probe it with concrete hostile scenarios before accepting it: what happens if the player stands still? Spams the one button? Hoards instead of spends? Never takes the risky route? If the answer is "nothing breaks, it's just boring," that's a finding — challenge the branch.
Capture as you go. Write each resolved branch into design/SPEC.md
the moment it settles, not in one batch at the end — a long interview that
dies mid-session should leave the decisions made so far on disk.
The design tree
Resolve in dependency order — later answers hang off earlier ones. Skip anything already answered; drill deeper wherever an answer is vague.
The hook. What is the player doing, and why is it fun? One sentence. Push until it's concrete: "dodge and counter in crowds" beats "an action game".
References. "X meets Y" — which existing games is this closest to, and what's the one twist that makes it not just a clone?
Perspective and engine. Top-down, side-on, isometric, 3D? This picks the engine (Phaser for 2D, Three.js for 3D) and constrains everything downstream.
The 30-second loop. Walk through exactly what the player does in a typical 30 seconds. If the answer has no tension or decision in it, that's a finding — challenge it: "where's the fun in this 30 seconds?"
Input. Keyboard-first? Mouse? Touch? Browser games live or die on instant, obvious controls.
Win, lose, and session. What ends a run? How long is one session? What pulls the player into "one more run"?
Progression. What's different in minute 10 vs minute 1? Difficulty curve, unlocks, escalation — or is it pure score-chase?
Scope — the MVP cut. What ships in the first deploy, and (more important) what's explicitly OUT? Push back hard here; the first version should be playable end-to-end in one sitting of work.
Art direction. Pixel art? Resolution/palette? Generated assets are cheap (
vg generate), so ask for vibe and references, not asset lists.Audio. Music vibe + the 3-5 sounds that matter most (hit, pickup, death, win).
Multiplayer. Single-player first is almost always the right call. If multiplayer: the platform is host-authoritative, last-write-wins — great for turn-based, room-based, and host-controlled games; wrong for twitch PvP. Say so if the idea fights the model.
Title and slug. It deploys to
{slug}.vibedgames.com— pick both.The riskiest assumption. Which single belief, if false, kills this game? Usually "the core verb is fun with zero goals attached." Agree on the cheapest test that answers it — for a browser game, a grayblock scene: core verb only, no art, no menus, no progression. Define the fun-confirmed signal behaviorally, in advance (unprompted "one more run", the player narrating what happened, "wait, what if I…") and a kill/pivot criterion — deciding now is what stops a dead core from getting decorated with features later.
Exit
When no unresolved branches remain, finalize design/SPEC.md (create the
dir if needed; most of it should already exist from capture-as-you-go):
hook, references, loop, controls, win/lose, progression, MVP cut list,
art/audio direction, multiplayer decision, title/slug — plus the riskiest
assumption and its kill criterion, and the canonical term for each game
concept. Keep it to one page — it's a compass, not a plan.
Do not start building until the user confirms the SPEC reflects a shared understanding.
The SPEC is now the foundation, not the finish line. Point the user at the craft skills that turn a sound design into a game worth replaying, and pull each in at its moment rather than dumping them all at once:
design-lenses— pressure-test whether the idea is actually fun before building.game-feel+vfx— make movement and impact feel good.level-design+game-balance— shape the content and the difficulty curve.onboarding— the first 30 seconds and teaching without a manual.finish-it— hold scope to the MVP cut and actually ship.
If you reached this interview from a teach-me session, return to it: the
user builds the game themselves, lesson by lesson, with you guiding — don't
build it for them.