game-concept

GitHub

基于小说与产品简报设计游戏概念。继承锁定维度,生成三个差异化方案并对比选择。强调同玩法对标、核心动词复用及硬否决机制,产出可验证原型定义。

skills/game-concept/SKILL.md worldwonderer/novel-to-game

触发场景

判断小说适合做成什么游戏 比较不同游戏设计方案 为特定书籍选择游戏方向

安装

npx skills add worldwonderer/novel-to-game --skill game-concept -g -y
更多选项

不安装直接使用

npx skills use worldwonderer/novel-to-game@game-concept

指定 Agent (Claude Code)

npx skills add worldwonderer/novel-to-game --skill game-concept -a claude-code -g -y

安装 repo 全部 skill

npx skills add worldwonderer/novel-to-game --all -g -y

预览 repo 内 skill

npx skills add worldwonderer/novel-to-game --list

SKILL.md

Frontmatter
{
    "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。输入必须包含 SOURCE_BIBLE.mdPRODUCT_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。

玩法取自已被大量玩家玩过的成熟打法,小说只做 IP 皮:创新落在世界、人物、剧情、题材与 美术,不落在动词集。选定方向必须有 ≥2 款「同玩法」对标——核心动词与循环结构就是 它们那一套——并逐条列出共有项;凑不出就换打法,不靠文学契合度豁免。

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

每个核心对标必须回答:

  • 借用层级是「同玩法」还是「仅原则」;标同玩法的,逐条列出共有的核心动词与循环结构, 并附一条可核实的“玩过的人很多”凭据——一个带来源与日期的数字(商店评价数 / 峰值同时 在线 / 公布销量或注册数);“有商店页或维基页”只证明这游戏存在过,不算凭据,列不出 就降为「仅原则」;
  • 它已经证明了哪条玩法原则;
  • 它面向什么语言和文化市场,该市场证据为何适用于本作;
  • 这条原则如何转成当前小说独有的动作或世界规则;
  • 哪些专有系统、文化表达、内容、美术和范围明确不借——核心动词与循环结构不在此列, 它们恒为借用项,写进「不借」就等于自创循环。

每个方向至少指出一个最相关原则,但不为凑数重复研究。市场区隔必须对玩家最可能拿来 比较、玩法语法最接近的一款作答“本作凭什么值得单独玩一遍”——答案只能是 IP、剧情、 内容、题材与美术,不能是换掉动词集;与它玩法同构正是本阶段要的结果,不是缺陷。不得 只挑题材同源但玩法远的作品。对标不是名字装饰,也不能每款各借一条原则拼成一个循环 ——那样拼出来的东西哪一款的玩家都认不出。

三个方向

生成方向前,先列出 PRODUCT_BRIEF 已锁定的维度(可能含玩家身份、主类型、核心幻想、 分级等);违反任一锁定维度的方向不计入三方向,最多压成一段“回总入口修订提案”附注。 三个方案必须在未锁维度中至少三项不同(子类型、压力来源、原著选段 / 切片、镜头、 成长关系、玩家身份、题材与美术方向)。核心动词与循环结构不在可差异化之列——三个 方向都从 PRODUCT_BRIEF 已锁的同玩法先例里取动词集,差异来自取哪一款、取原作的哪一段, 不是各自发明一套动词;要用锁定名单之外的先例,写成"回总入口修订提案"附注,不在本阶段 静默换掉 brief 锁定的类型与同玩法先例。名单里同玩法先例 ≥3 款时,两个方向的先例组完全 相同就是同一个方案的两套衣服,只按一个方向计数;名单只有 2 款时三个方向共用同一组先例 不是缺陷,差异由子类型、原著选段与其余未锁维度承担。可以探索原作身份体验、同世界系统 沙盒和高概念短体验,但不要把它们当固定模板。

每个概念只回答:

  • 主类型、子类型、≥2 款同玩法先例(逐条列出共有的核心动词与循环结构)、一句话核心 卖点、玩家身份和独特幻想;子类型窄到没有已发行作品占据它即不成立,回去换更宽的说法;
  • 核心动词、循环、压力和熟练度差异;
  • 三段弧:探索期在发现什么、成长期什么在复利、成熟期玩家做得到什么新手做不到的事—— 每期必须改变玩家做的事(新动词 / 新可达空间),只有数字变大、或多一个对白选项不算;
  • 本作独有规则转换点:它如何把原作的规则或情感 / 伦理张力变成玩家行动——先例动词集 里的哪一个可重复核心动词让玩家亲手做出这份幻想(禁用 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 文件。

版本历史

  • 470e35d 当前 2026-07-31 13:49

    修复八处缺陷:统一QA问题表述以避免误判;修正先例组计数逻辑防止死锁;补全同玩法动词清单以对齐构建与QA标准;优化子类型匹配与画面时长限制等规则。

  • 827fb80 2026-07-30 20:19

同 Skill 集合

skills/game-world-design/SKILL.md
skills/novel-game-analyze/SKILL.md
skills/novel-to-game/SKILL.md
skills/game-art-direction/SKILL.md
skills/game-build/SKILL.md
skills/game-qa/SKILL.md

元信息

文件数
0
版本
470e35d
Hash
ecfae6bb
收录时间
2026-07-30 20:19

首页 - Wiki
Copyright © 2011-2026 iteam. Current version is 2.155.2. UTC+08:00, 2026-08-01 00:43
浙ICP备14020137号-1 $访客地图$