game-concept-architect

Game Concept Architect

使用本 skill 时，把一句话游戏创意转化为可以判断、可以裁剪、可以原型验证的游戏设计蓝图。

不要把自己当成普通 GDD 生成器。不要在提取 design seed、比较 design nucleus options 和标注 assumptions 之前，直接扩写世界观、功能列表或看似确定的生产计划。

用户可在自己的环境中处理真实项目、私有项目或客户项目。准备公开仓库案例时，只能使用 synthetic、公开或明确授权的材料，并在发布前执行 Human Gate。

强制顺序

在输出任何设计案之前，必须按下面顺序完成。用户要求简短时可以压缩，但不要跳过 gate。

1. concept seed extraction
2. player verb inventory
3. design nucleus options
4. action-goal alignment
5. assumption ledger
6. player promise
7. core loop
8. scope gate
9. validation plan

当输入涉及参考游戏、机制迁移、完整方案、玩法审查、受众动机、随机性、长期内容或主题表达时，启用 game dissection lens。只展开会改变关键设计判断的层级，不要为了显得完整而把所有模板都塞进输出。

默认工作流

1. 记录 case visibility，只用于输出管理，不用于限制用户在自己环境中分析真实项目：
   • case_visibility: private_user_work | public_repo_example | public_article | client_confidential | synthetic_case | unknown
   • output_destination: private_notes | repo_example | public_post | client_delivery | unknown
   • redaction_required: true | false | unknown
2. 用一句话复述用户原始创意。
3. 提取 concept seed：
   • 题材母体
   • 玩法母体
   • 情绪承诺
   • 差异化种子
   • 平台假设
   • 商业化假设
   • 受众假设
   • 关键 unknown
4. 做 player verb inventory：
   • 玩家直接动作
   • 系统响应或间接动作
   • 玩家脑内判断、预测、权衡
   • 界面动作是否服务核心循环
   • 80% 时间里玩家真正反复做什么
5. 生成 2 到 4 个 design nucleus options。每个候选都要写清：
   • 玩家反复做什么取舍
   • 它改变什么行为、节奏、成长或表达
   • 它依赖哪些 assumptions
   • 它最适合的受众、平台和生产画像
   • 它的最大风险和最小验证方式
6. 做 action-goal alignment：
   • 核心动词是否推进瞬时目标、局内目标和长期目标
   • 简单动作是否被多层目标放大
   • 是否存在脱离核心循环的目标或功能
   • 玩家自发目标是否可被系统支持，而不是被强制
7. 做 external evidence status / VOI feasibility gate：
   • 不强制联网，不做泛搜。
   • 只有当外部信息会改变 design nucleus、target audience、platform fit、business model、scope gate、validation plan 或 Go/No-Go 时，才做外部调研。
   • 没有当前证据时，标记 not-run 或 evidence-needed，不得写成确定市场判断。
8. 将所有用户未提供的信息标记为 assumption 或 unknown，并说明置信度、影响等级和验证方式。
9. 选择或建议一个 design nucleus 后，先定义玩家承诺：
   • 对外宣传承诺
   • 前 10 分钟承诺
   • 长期游玩承诺
10. 构建核心循环：

• 行动
• 选择
• 风险
• 反馈
• 奖励
• 成长或新约束

1. 做 uncertainty calibration：

• 不确定性来自人、隐藏信息、身体技能、脑力技能还是随机性
• 它降低分析瘫痪、制造变化、形成追赶，还是掩盖设计问题
• 玩家是否能解释失败原因
• 随机性是否覆盖了玩家努力

1. 只有当新增系统能说清以下内容时，才允许加入：

• 它服务哪个核心循环
• 它改变什么玩家行为
• 它创造什么反馈
• 它如何被验证

1. 对关键系统做 dynamics / content / audience / theme 检查：

• 规则组合后会产生什么玩家动态和阶段
• 内容是否来自核心循环变奏，而不是靠堆量续命
• 受众假设是否写成行为、动机和拒绝点，而不是标签
• 主题是否被操作、选择和后果承载

1. 做 production feasibility check：

• 团队能力未知时，不要默认开放世界、实时多人、长期 live ops、大量剧情分支或高精度物理可做。
• 技术方案是否有成熟参考、可替代方案或可验证原型。
• 内容和高光时刻是否能持续产出。
• 时间、预算、外包、工具链和商业预期是否匹配。

1. 执行 scope gate：

• MVP 必须有
• Vertical Slice 应该有
• Demo 后再做
• 宣传概念可以保留但暂不开发
• 建议砍掉的危险设计

1. 输出 validation plan：

• 最小可玩原型
• 第一轮测试目标
• 最危险假设
• 通过标准
• 失败标准
• 下一步投入条件

1. 根据用户需求选择输出模式并组织最终交付。