game-concept
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
Install
npx skills add https://github.com/zenstory-ai/novel-to-game/tree/main/skills/game-concept
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install zenstory-ai-novel-to-game@llmmart
git clone https://github.com/zenstory-ai/novel-to-game.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole zenstory-ai/novel-to-game collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
游戏概念设计
决定做成什么游戏,不写代码、数值表或逐场关卡脚本。
读取 concept-method.md。输入必须包含 SOURCE_BIBLE.md 与
PRODUCT_BRIEF.md;缺任一项就停止并说明缺口,不代替上游补写。
产物语言由 PRODUCT_BRIEF.md 锁定;未锁定时跟随对话语言,不默认产出中文。
决策边界
直接继承 brief 已锁的平台、输入、受众、分级、时长、目标市场和非目标;发现它们与原作明显冲突 时回总入口修订,不在概念阶段静默改值。原作语言、文化语境、目标市场和界面语言分别处理,不从 其中一个自动推出另一个。
互动叙事是成熟玩法,不因以阅读和对白承载就降低标准;它的动词可以是读局面、追问、比对信息、 表态、隐瞒、交出与承担回响。
概念还要判断验证形态:可用成熟交互语法表达时说明“已有语法 + 原作如何改变它”;核心依赖实时手感、 空间、视线、物理或独特操作时明确走自定义灰盒。不要把文本原型当所有体验的统一前置层,也不要因有 模板可用就让模板替原作决定玩法。
比较范围
先列 brief 的锁定维度和仍开放的维度,只比较能揭示真实取舍的方向,不凑概念数量或差异维度。 仅在方向仍开放时考察可信替代;用户已选定方向或不存在有效替代时说明原因,改为验证该方向的风险, 不重开选择。
选择
先按 concept-method 的硬否决逐个淘汰,不计算总分,再按其比较维度选择。quick 自动选证据最强的
方向;director 只对尚未决定的方向给出推荐并等待用户选择。
输出
生成一个 concepts/CONCEPT.md,只含:
- brief 锁定值与开放维度;
- 体验承诺及其可观察现象和失败现象;
- 紧凑先例说明;
- 候选概念卡:主类型、
experienceProfile、借用/拒绝的玩法先例、核心动作与循环、压力、失败、 世界响应;说明玩家身份如何形成反复行动、执行阻力与可观察变化,不要求独立的固定键名。signature_command按方法「身份专属命令」写值或N/A;最后说明原作张力如何由玩家亲手 enact、 招牌画面、最小验证切片、最大风险和否决观察; - 硬否决结果、关键取舍、推荐与选择状态;
- 选定方向的玩家能动性合同、不可妥协体验承诺;
- 最小验证问题与开放问题。
narrative-led 或 hybrid 的叙事层还要选择一种分支结构语法并说明内容预算。交接前确认选定方向
可在 brief 范围内做成完整切片。
Files (novel-to-game)
-
agents
-
openai.yaml 256 B
interface: display_name: "Game Concept" short_description: "Choose the adaptation worth building · 选择最值得做的可玩改编方向" default_prompt: "Use $game-concept to propose, compare, and choose playable game directions for this novel."
-
-
references
-
concept-method.md 2.6 KB
# 概念选择方法 ## 原作如何改变玩法 类型由玩家反复做什么决定,不由原作战斗、恋爱或对白的篇幅决定。先例按设计问题选择, 记录借用与拒绝之处;原作必须改变动作对象、顺序、代价或世界回应,而不只是替换专有名词。 ## 硬否决 以下缺口不能靠综合评分补偿: - 动作不能闭合可参与的循环,选择或操作不改变可观察状态、后续机会或结果; - 原作中心规则、情感或伦理张力只存在于过场和名词,核心循环与它无关; - 删除专有名词后,与通用模板没有动作对象、代价或世界回应上的差异; - 最小切片超出 brief,依赖不可获得的工具、服务、内容量或资产; - 依赖复制其他游戏受保护的角色、地图、界面、文本或素材; - 声称有进展,却只有文本或读数增加,没有兑现本项目承诺的局面、能力或理解变化; - 玩家介入只是花资源放行既定剧情,世界不回读玩家做过的具体事。 不以动词数量、成长阶段或三维画面作为可玩性的替代判据。 ## 玩家能动性与承载类型 每个方向回答:玩家做什么改变事情的原因或方向(因果权),世界怎样具体兑现其后果(结算权)。 短篇或命定结局可以收束结果,但不能因此抹掉玩家介入的意义。 `experienceProfile` 是交接字段: - `system-led`:主要决策来自操作规则; - `narrative-led`:主要决策来自理解局面、人物、信息并承担回响; - `hybrid`:两层各自承载决策且互相影响。 按实际决策来源判断,不按界面上是否出现数值分类。叙事层说明分支结构与内容预算,不强套统一弧线。 ## 身份专属命令 自然语言不是默认输入。只有玩家需要以角色身份组织对象、执行人、条件、期限或知情范围, 且自由表达增加身份感、组合空间或可读后果时,才选择 `signature_command`,否则写 `N/A`。 选中时锁定 `id`、玩家可见 `label` 和候选 `intents`;槽位、验证器与提交项交给世界设计。 说明身份、反复行动、执行阻力和后续变化如何相连。玩家表达只是有限动作候选,世界仍可拒绝、 部分执行、走样、泄露或延期追责,不能把“说了”直接等同于“发生了”。 ## 选择依据 先否决,再比较原作转化、玩家能动性、文化表达与最小验证成本。 推荐能用现有时间、工具和资产证明核心幻想、且否决观察最清楚的方向;相近方案不做伪精确排名。
-
-
SKILL.md 3.4 KB
--- name: game-concept description: "Design game concepts from a novel. From SOURCE_BIBLE and PRODUCT_BRIEF, compare meaningful alternatives on the dimensions still unlocked, then select a playable direction 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, decide whether this novel should become an interactive story. 小说游戏概念设计。根据 SOURCE_BIBLE 与 PRODUCT_BRIEF 比较未锁定维度上的有效替代方案,用硬否决和关键取舍选择可玩方向。用于判断小说适合做成什么游戏、该不该做成互动叙事、比较游戏方案等需求。" --- # 游戏概念设计 决定做成什么游戏,不写代码、数值表或逐场关卡脚本。 读取 [concept-method.md](references/concept-method.md)。输入必须包含 `SOURCE_BIBLE.md` 与 `PRODUCT_BRIEF.md`;缺任一项就停止并说明缺口,不代替上游补写。 产物语言由 `PRODUCT_BRIEF.md` 锁定;未锁定时跟随对话语言,不默认产出中文。 ## 决策边界 直接继承 brief 已锁的平台、输入、受众、分级、时长、目标市场和非目标;发现它们与原作明显冲突 时回总入口修订,不在概念阶段静默改值。原作语言、文化语境、目标市场和界面语言分别处理,不从 其中一个自动推出另一个。 互动叙事是成熟玩法,不因以阅读和对白承载就降低标准;它的动词可以是读局面、追问、比对信息、 表态、隐瞒、交出与承担回响。 概念还要判断验证形态:可用成熟交互语法表达时说明“已有语法 + 原作如何改变它”;核心依赖实时手感、 空间、视线、物理或独特操作时明确走自定义灰盒。不要把文本原型当所有体验的统一前置层,也不要因有 模板可用就让模板替原作决定玩法。 ## 比较范围 先列 brief 的锁定维度和仍开放的维度,只比较能揭示真实取舍的方向,不凑概念数量或差异维度。 仅在方向仍开放时考察可信替代;用户已选定方向或不存在有效替代时说明原因,改为验证该方向的风险, 不重开选择。 ## 选择 先按 concept-method 的硬否决逐个淘汰,不计算总分,再按其比较维度选择。`quick` 自动选证据最强的 方向;`director` 只对尚未决定的方向给出推荐并等待用户选择。 ## 输出 生成一个 `concepts/CONCEPT.md`,只含: 1. brief 锁定值与开放维度; 2. 体验承诺及其可观察现象和失败现象; 3. 紧凑先例说明; 4. 候选概念卡:主类型、`experienceProfile`、借用/拒绝的玩法先例、核心动作与循环、压力、失败、 世界响应;说明玩家身份如何形成反复行动、执行阻力与可观察变化,不要求独立的固定键名。 `signature_command` 按方法「身份专属命令」写值或 `N/A`;最后说明原作张力如何由玩家亲手 enact、 招牌画面、最小验证切片、最大风险和否决观察; 5. 硬否决结果、关键取舍、推荐与选择状态; 6. 选定方向的玩家能动性合同、不可妥协体验承诺; 7. 最小验证问题与开放问题。 `narrative-led` 或 `hybrid` 的叙事层还要选择一种分支结构语法并说明内容预算。交接前确认选定方向 可在 brief 范围内做成完整切片。
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.