---
name: game-concept
description: "Design game concepts from a novel. From SOURCE_BIBLE and PRODUCT_BRIEF, generate three genuinely different directions on the dimensions still unlocked, then pick the most worthwhile playable prototype using hard vetoes and explicit trade-offs. Use for what game should this novel become, compare game concepts, choose a game direction for this book. 小说游戏概念设计。根据 SOURCE_BIBLE 与 PRODUCT_BRIEF 在未锁定维度上生成三个真正不同的方案，用硬否决和关键取舍选择最值得做的可玩原型。用于判断小说适合做成什么游戏、比较游戏方案等需求。"
---
# 游戏概念设计

决定做成什么游戏，不写代码或功能愿望清单。

读取 [concept-method.md](references/concept-method.md)。输入必须包含 `SOURCE_BIBLE.md` 与
`PRODUCT_BRIEF.md`；缺 `SOURCE_BIBLE` 就停止并说明缺游戏化拆解，缺 `PRODUCT_BRIEF` 就停止
并要求先过需求 intake，不代替总入口推进其他阶段。

产物语言由 `PRODUCT_BRIEF.md` 锁定；未锁定时跟随对话语言，不默认产出中文。

## 行业锚定

产品框架以 `PRODUCT_BRIEF.md` 记录的全部产品维度为准，intake 阶段已锁定，**直接继承，
不重猜、不静默改**；记 N/A 的维度也是锁定值，不自行补默认。受众画像（硬核度 / 性别向 /
玩家动机原型）是决策密度、UI 密度、单局时长与教学强度的标尺，本阶段继承并落地，不在
概念里另起一套。本阶段只在这个框架内把它落成一页可指导取舍的产品定义：玩家是谁、在
既定主类型下的具体子类型、3 条体验支柱、明确非目标和最大未知。体验支柱必须能指导
取舍，例如“预读后改写敌方结果”，不能写“沉浸、史诗、精致”。每条支柱都要配一个可观察
的试玩证据和一个会否决它的失败现象。若发现 `PRODUCT_BRIEF` 的某项与原作适配明显冲突，
回总入口显式修订，不在本阶段擅自更改。

`PRODUCT_BRIEF` 已按"小说语言→对标市场"锁定对标方向与几款参考对标，本阶段以那几款为
起点做 per-direction 深化验证，不推翻已定市场重新来过。整个概念阶段只保留 2-4 款真正
解决过相近设计问题的核心对标，再加一个必要的市场同类或反例。对标事实须先联网核实并在
对标矩阵标注核实状态，方法见 concept-method.md。

对标组合必须同时覆盖玩法问题和文化市场问题：研究原作文化中的题材表达，也研究目标
语言市场的玩家预期、类型惯例、内容敏感点和传播语境。一款游戏可以同时承担两种证据，
不为地域凑名单。区分可迁移的玩法原则与不可照搬的文化符号、笑点、价值关系和商业惯例。

每个核心对标必须回答：

- 它已经证明了哪条玩法原则；
- 它面向什么语言和文化市场，该市场证据为何适用于本作；
- 这条原则如何转成当前小说独有的动作或世界规则；
- 哪些专有系统、文化表达、内容、美术和范围明确不借。

每个方向至少指出一个最相关原则，但不为凑数重复研究。市场区隔必须对玩家最可能拿来
比较、玩法语法最接近的一款作答“本作为什么不是它的低配复刻”，不得只挑题材同源但玩法
远的作品。对标不是名字装饰，也不能把多款游戏的功能列表全部相加。

## 三个方向

生成方向前，先列出 `PRODUCT_BRIEF` 已锁定的维度（可能含玩家身份、主类型、核心幻想、
分级等）；违反任一锁定维度的方向不计入三方向，最多压成一段“回总入口修订提案”附注。
三个方案必须在未锁维度中至少三项不同（子类型、核心动词、循环结构、压力来源、原著
选段 / 切片、镜头、成长关系）。可以探索原作身份体验、同世界系统沙盒和高概念短体验，
但不要把它们当固定模板。

每个概念只回答：

- 主类型、子类型、一句话核心卖点、玩家身份和独特幻想；
- 核心动词、循环、压力和熟练度差异；
- 本作独有规则转换点：它如何把原作的规则**或情感 / 伦理张力**变成玩家行动——**哪一个
  可重复核心动词让玩家亲手做出这份幻想**（禁用 finisher 脚本 / 一次性道具代劳）；
- 最关键的玩法对标，以及只借其中哪条原则；
- 一张最能传播且能看出玩法的画面；
- 最小验证切片（默认 10-30 分钟，且不超过 `PRODUCT_BRIEF` 锁定的单局时长）证明什么、
  明确不做什么、最大风险是什么；brief 时长更长时，写明切片对应完整体验的哪一段、
  切片与全量的范围差、全量何时才做；
- 最小验证问题：只做哪一段可玩内容，就能在试玩中证伪最大风险。

## 选择

先做硬否决检查并给每个方向留一行结果（通过 / 触发第几条），淘汰触发者；再按
concept-method.md 的比较维度比较。不要计算总分。`quick` 选择证据最强的方案；
`director` 给出推荐后等待用户决定。

## 输出

生成一个 `concepts/CONCEPT.md`，含以下小节：

1. 一页产品定义，含选定方向的目标语言与文化市场；
2. 体验支柱 ×3，每条配可观察试玩证据与否决它的失败现象；
3. 行业对标矩阵，含「核实状态」列，未核实条目不得作为选择依据被引用；
4. 三个紧凑概念卡；
5. 比较结论、推荐理由与选择状态，含每方向一行硬否决检查结果；
6. 不可妥协项：只能是体验层承诺，出现调参数字即回改；
7. 最小验证问题；
8. 开放问题。

概念卡不得包含伤害公式、具体数值百分比、敌人血量与逐场关卡脚本——这些归 GAME_DESIGN
所有；概念只声明系统存在性及它必须改变的战术选择（例：“相克在 Boss 战反转”“变化必须
改写可用技能而非只加倍率”）。交接前自检：缺任一小节即未完成，不得交接。不要另写一份
重复的 `decision.md` 文件。