Concept

concept

Turn a one-line prompt into a structured, differentiated design concept and record it in a new manifest.

Inputs

• A one-line prompt (e.g. "a neon endless runner").
• The existing manifests/ directory — read it to avoid near-duplicate concepts.

Outputs

• A new manifest at manifests/<id>.json with a populated concept block and status = "concept".

Steps

1. Read existing manifests. List manifests/*.json and skim each concept.genre + name. If the prompt would produce a near-duplicate of an existing title, say so and propose a differentiating twist before continuing.

2. Derive the concept. From the prompt, decide:

   • theme — decide this FIRST, before anything visual. The one modality-neutral world the whole title expresses, recorded as concept.theme: premise (what the game is about as a world — e.g. "a cozy autumn-woodland folktale of a small forest spirit foraging glowing seeds"), tone (the emotional register — e.g. "warm, gentle, a touch melancholy"), mood_keywords (2–4 tags every modality can key off — e.g. ["cozy", "organic", "storybook", "calm"]), and setting (the place/time — e.g. "dappled autumn forest at golden hour"). This is the cross-modal anchor: visuals, audio, and (at M2) the store icon all express it, so the title reads as one coherent world rather than three independent interpretations. Be specific — a vague theme is the upstream cause of a cross-modal cohesion failure (visuals say one thing, audio another).
   • genre — short noun phrase (e.g. "endless runner", "match-3", "top-down shooter").
   • core_loop — one or two sentences describing the second-to-second loop AND its difficulty curve (e.g. "tap to jump, avoid obstacles, score climbs with distance; starts gentle and ramps speed every ~10s up to a cap"). Naming the curve gives builder something to tune toward. State the player's moment-to-moment decision — answer "what is the player choosing each second?" A loop with no live decision plays as "brainless" even when it runs correctly (POC run-003: an auto-firing shooter). If simplifying controls for mobile removes the decision (auto-aim, auto-fire), restore one another way (a dodge/dash, a targetable special, limited ammo that forces aim, a risk/reward pickup).
   • TRADEOFF GATE — the #1 cause of "weak but functional" games. A described decision is not a real one. Naming a choice is worthless if one option dominates: the loop is then solved, and it plays as going-through-the-motions no matter how well it runs or how much juice it has. The high-value action MUST sacrifice something the player also wants, so the optimal play is never obvious. Apply the test before writing core_loop: state the single move a skilled player makes each beat; if that move is both the most rewarding AND the safest (or otherwise strictly best), there is no decision — reject the design and add a cost. Two shipped POC games failed exactly here: shopkeep-0001's "triage a patient queue" was pure icon-matching with no penalty for serve order (best = serve anyone), and match3-survival-0003's "score-vs-survive sacrifice" was inert because purging the threat also scored 5× a normal clear (reward and safety aligned). Encode the tension in core_loop as an explicit clause — "doing X gains A but gives up B" — where A (reward) and B (safety / a competing reward / a future resource) genuinely pull in opposite directions. Common engines for this: push-your-luck (bank now vs. risk the haul for more), resource contention (one pool feeds offense OR defense, never both), opportunity cost (the high-score move exposes you / costs tempo), or time pressure (the thorough move is the slow move). If you cannot name B, the design is not ready for builder.
   • mechanics — a short list of the concrete mechanics the builder must implement (e.g. ["jump", "obstacle spawning", "score", "game over + restart"]). Keep it minimal but complete — every item here is something builder must wire up. Include at least one progression or reward beat beyond bare survival (e.g. milestone pickups, a combo/streak, or speed tiers that change the visuals) so the loop has somewhere to go.
   • art_direction — a coherent primitive-art direction that builder can execute, not just a palette. Specify: a named palette + shape language, a background treatment (so there's no dead space — e.g. parallax lines/stars/gradient), and at least one motion/feedback beat (e.g. "screen flash + shake on death, score pulses on milestone"). Example: "neon vector on near-black; bright cyan/magenta shapes with additive glow; faint parallax grid scrolling behind; white flash + shake on crash." Be specific — vague art direction is the top cause of bland output. art_direction is the visual expression of theme — it must not contradict it (a "spooky" theme cannot have a "cheerful pastel" art_direction; a "cozy storybook" theme must not render as "hard neon arcade"). Derive it from the theme you just set.
   • target_platforms — ["android"] for the POC.
   • differentiation_notes — one line on how this avoids being a clone of a saturated title.

3. Allocate an id. Use <genre-slug>-<NNNN>, zero-padded, incrementing past any existing id with the same prefix (e.g. runner-0001). The slug is a short kebab form of the genre.

4. Create the manifest skeleton:

   node tools/manifest.mjs create <id> "<Title Name>"
   

5. Write the concept block:

   node tools/manifest.mjs merge <id> "{\"concept\": { ...the fields from step 2... }}"
   

   (On Windows PowerShell, prefer writing the JSON to a temp file and passing its contents, or use single quotes around the JSON to avoid escaping pain.)

6. Validate:

   node tools/manifest.mjs validate <id>
   

   Expected: <id> OK. The manifest is now at status = "concept" — hand off to builder.

Hybrid / combination concepts (when the prompt blends two genres)

A combination prompt ("match-3 + survival", "runner + shooter") is handled by the same steps above — but a blend has one extra failure mode: the two genres coexist instead of fusing, so it plays as "genre A with something random happening at the same time" (POC run-004). The concept is where the fusion is won or lost. Make it explicit, in this priority order:

• Prefer state/space fusion — the strongest lever. The most cohesive blends make both genres act on the same objects or the same space, so a single action serves both at once. Don't bolt genre B on as a separate region of the screen running on its own clock — that produces a periodic interrupt, where the genres alternate (puzzle → defend beat → puzzle) instead of fusing into one continuous decision (POC run-005). Instead, put the threat inside genre A's world: e.g. for match-3 + survival, enemies corrupt gems on the grid, the advancing line eats grid rows, or threatened columns must be cleared to survive — so every match is simultaneously a puzzle move and a defense move. State in core_loop how a single player action pays off in both genres at once.
• Align the tempos. If the two genres' natural tempos differ (a deliberate puzzle vs. a real-time threat), reconcile them in the concept — slow the real-time side toward puzzle tempo, or make matching faster/continuous — or they will read as two games sharing a screen no matter how well-linked they are. Note the intended tempo reconciliation in core_loop.
• Name the forcing function (supplement, not the mechanism). State what makes the second genre's pressure continuously reshape the player's choices in the first. Answer: "what stops the player from just playing genre A and ignoring genre B?" A periodic telegraphed event (run-005) is a useful supplement, but on its own it only buys alternation — lead with state/space fusion above, then add a forcing function for spikes of tension.
• Tie them through one shared resource or decision. The strongest blends route both genres through a single resource the player must split (run-004: matches that could fuel offense OR defense). Put that contention in core_loop and mechanics.
• Make the blend — not either genre — the differentiator. differentiation_notes should explain why the combination is the hook, not just that it's "genre A but also B."
• Honest caveat: some genre pairs are intrinsically hard to fuse (orthogonal puzzle + real-time is the hardest). If a pairing resists state/space fusion, say so in differentiation_notes and pick the most fusable shared object available — don't ship a hollow blend.

Notes

• Do NOT invent assets here. Art is the builder's job (deliberate primitives); this skill only sets art_direction to steer it.
• The differentiation check is lightweight — a sanity gate, not market research.