小说/案件 → 游戏模拟器生成器

Turn any novel, drama, or case brief into a self-contained, double-clickable HTML game where the
player investigates as a chosen detective role. Everything (engine + case data + styling) lives in one
.html file that opens directly in a browser — no server, no build, no dependencies.

When to use

• User supplies a novel/story/case and wants an interactive investigation game.
• User says "生成游戏模拟器，可直接双击开始游戏", "建立案件管理系统并生成游戏", "把这个案子做成游戏".
• Required mechanics usually include: role select + avatar creator, 卷宗/物证/线索合成/审讯,
  step-by-step case progression, multi-branch endings, key-clue breakthrough input.

Hard prerequisite on content

The assistant does not invent the user's copyrighted novel content. If the user has not provided
the actual characters/case, build a original, self-consistent demo case first (clearly labelled),
and expose the entire case as a single const GAME = {...} data object at the top of the script so
the user can swap in real content later. Tell the user explicitly what is placeholder.

Engine design rules (non-negotiable for "double-click" to work)

• One file. All CSS in a style element, all JS in one script element, no external fetches, no CDN.
• file:// safe. No ES modules (type="module" breaks on file://), no fetch() of local files.
• Persistence: localStorage for save/continue (key per game, e.g. case_ID_save).
• The whole case is data. Put roles, cases(卷宗), locations(行动), evidence, clues, recipes(合成),
  suspects(审讯树), milestones, breakKeys(破局关键词), endings into one const GAME object. The engine
  reads only from GAME — changing the story means editing data, not code.
• Win-path must be closed. Every role must be able to reach at least one ending. Verify with the
  bundled checker (see below) before delivering.

Workflow

1. Design the case data. Mirror the structure in assets/template.html (proven, runnable) and
   references/game-data-schema.md. Guarantee a solvable loop:
   - locations unlock by need (clue/evidence ids); visiting grants evidence + clues.
   - recipes combine inputs (clue/evidence ids) → new clue.
   - suspects unlock by need; each question has need/needAny and grant clues; some need a
   specialty clue (化身专属) or pressure clue to open.
   - milestones = prerequisite gates; endings key off milestone sets + flags (e.g. caught the mole).
2. Write the HTML. Start from assets/template.html — it already implements the full engine
   (start screen, role select + avatar creation, tabs for 卷宗/物证/线索合成/审讯/进度/破局,
   localStorage, Toast, ending screen). Replace only the const GAME = {...} block and title/theme.
3. Theme to the case. Adjust CSS variables (--gold/--accent) and copy to match the story mood
   (e.g. 黄色毒网 → amber; 蓝金 → blue-violet).
4. Validate (mandatory). Run scripts/validate_game.js (game.html) to confirm no role softlocks
   and that branch endings are reachable. Fix any "NONE" before delivery.
5. Syntax check. Extract the script element and run new Function(...) on it (node) to catch parse errors.
6. Deliver with present_files and tell the user how to double-click / what is placeholder.

Breakthrough input (关键线索破局)

Provide a text box where the player types a key person or clue (e.g. "周慕云", "红桃K", "化工厂").
Map lowercased keywords → {clue, tip, need} in GAME.breakKeys. On match: reveal the clue (if not
gated by need) and show a tip; if gated, show what's still missing. This lets the player drive the
case by the very names/leads the user provided.

Multi-branch endings

Define endings with cond: { M:[milestoneIds], mole:true|false, role:'jianning'|'ziri', fail:true }.
Evaluation priority (replicate in engine + validator): perfect(mole) → role-specific(lone/ziri) →
leak(!mole) → fog(fail). Give specialty/avatar roles a unique ending so "different identities own
exclusive clues → different endings" holds.

Bundled resources

• assets/template.html — a complete, proven single-file game (黄色毒网·红桃K demo). Copy, then
  replace the GAME block. Engine already handles all six required mechanics.
• references/game-data-schema.md — exact field-by-field schema for GAME with examples.
• scripts/validate_game.js — win-path simulator: extracts GAME, plays every role variant (incl.
  each avatar specialty and a "skip the mole" path), and reports reachable endings / softlocks.

Gotchas

• Keep GAME parseable by eval('('+obj+')') — no trailing commas, no functions inside the data
  object (logic stays in the engine).
• Avoid cross-dissolve/auto-track style issues — that's the video skill; here just keep the timeline
  of clues acyclic (no recipe cycle) or the forward-fix loop hangs.
• If a suspect question needs a specialty clue, set needAny:['c_pressure','c_trace'] so more than one
  role path can open it; otherwise that ending becomes unreachable for most roles.
• The mole thread should be exposable by any thorough role (e.g. once the mastermind falls, the
  inside leak cracks) — not only by one specialty — or the "perfect" ending is unreachable for others.