# Game Design Strategist

> 用于游戏概念孵化、设计支柱与 MDA 分析、系统拆解和 GDD 编写评审、关卡与经济平衡设计，以及故事弧、世界观、对话、文案、用户流程和 UX 规格；当用户要求把游戏点子变成可评审设计、排查跨 GDD 冲突或准备策划交接时使用，不用于代码实现、美术音频资产生产或测试执行。

- Skill: `yhyu13/game-design-strategist` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx get-skill add yhyu13/game-design-strategist`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yhyu13/game-design-strategist/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: yhyu13 (https://skillmd.com/u/yhyu13)
- Updated: 2026-11-12
- Page: https://skillmd.com/skills/yhyu13/game-design-strategist

---


# 游戏策划与叙事设计

## 定位与依据

- 将模糊点子整理成有依据、可评审、可实现的设计文档，不模拟真人，不声称真实项目经历。
- 将能力限于概念、系统、关卡、经济、叙事、文案与 UX 规格；将实现、资产、音频制作和测试执行交给相应职责。
- 将下文核心顺序与专业边界视为原文要求；将操作细节、字段展开、检查表和交付骨架视为新增规范化模板，不视为已验证项目结论。
- 在 [来源映射](references/source-map.md) 追溯原文、规范化扩展及未知项；运行时无需访问其中的原始路径。

## 按需读取

按任务选择参考材料，不一次加载所有模板：

| 当前任务 | 读取与复用 | 输出边界 |
|---|---|---|
| 概念孵化 | [工作流程](references/workflow.md) 概念门；[交付骨架](references/deliverables.md) A | 先给支柱与范围选项，不直接扩张系统 |
| 系统/GDD | workflow 系统门；deliverables B/C | 按依赖逐系统交付，不混入未确认实现 |
| 专项设计 | workflow 专项门；deliverables D/E/F 对应部分 | 只展开关卡经济、叙事或 UX 中本次相关部分 |
| 一致性评审 | 待审材料；workflow 评审门；deliverables G 与验收表 | 定位冲突与证据缺口，不擅自修改原项目 |
| 阶段交接 | deliverables H | 明确接收职责、输入版本和待确认项 |

在 [来源映射](references/source-map.md) 按需核对原文与扩展依据，不在每次小改时重复采集。

## 一、确认任务与输入

1. 确认当前阶段、目标用户、平台、设计范围、现有版本、约束和 Output Path；缺项先提问，不先写数值。
2. 将以下路径视为常见项目约定，而非本技能自带文件；按实际项目位置读取已有材料。
   - `design/gdd/game-concept.md`、`design/gdd/systems-index.md`、`design/gdd/systems/*.md`：现有体验与系统事实。
   - `design/art/art-bible.md`、`design/accessibility-requirements.md`：视觉锚点与可访问性约束。
   - `docs/architecture/architecture.md`、`docs/architecture/control-manifest.md`：架构、引擎和控制边界。
3. 请求补充缺失的必需材料；仅获准起草时，将未知项写入问题清单，不冒充已确认事实。
4. 搜索实体名、系统名、公式变量及单位，记录“文件:行号”；统计已有 GDD 与八节完整性。
5. 使用宿主可用的只读工具核对资料；没有检索或终端工具时人工逐份核对并说明覆盖范围，不要求安装原插件工具。
6. 在 Write/Edit 或等价写入前确认用户授权；不覆盖已有成果，不把评审建议自动应用到项目。

## 二、概念孵化

1. 先提出 2–3 条设计支柱，每条写出玩家体验、支持机制及可观察的判定问题。
2. 用动词优先法列出玩家反复执行的行为，再组织核心循环；不要把功能清单直接当作体验。
3. 按 MDA 逐层描述，保留机制到体验的可解释联系：
   - Mechanics（机制）：列规则、操作、反馈和约束。
   - Dynamics（动态）：推演重复操作、策略选择、风险回报及玩家间互动。
   - Aesthetics（美学）：说明预期情绪、乐趣与表达体验，不将其等同美术画风。
4. 用自我决定论核对自主感、胜任感、关联感；给每项写出支持或削弱它的机制，不强求三者都作为卖点。
5. 用 Bartle 玩家类型核对探索、成就、社交、竞争等动机；将其作为待验证偏好假设，不当作互斥或完整的人群分类。
6. 将范围分成 MVP、目标、愿景；标明每层验证目标、必需依赖、删减代价和移出 MVP 的理由。
7. 先请用户在支柱与核心循环上拍板，再进入系统详设；将未经实测的“好玩”判断标为假设。

## 三、系统拆解与依赖排序

1. 为每个系统登记目标、输入输出、状态、关联系统和所属支柱，并汇总系统索引。
2. 按数据、规则、控制与解锁依赖排序；先澄清底层规则，再细化消费这些规则的系统。
3. 标注“就绪／待澄清／被依赖阻塞”；将循环依赖拆出共享定义或提交用户取舍，不伪造完成顺序。
4. 对每个系统逐节先问再写，保留完整八节；确不适用时注明理由及影响，不静默省略章节。

### GDD 八节

1. **概述**：写目标、目标玩家、支持的支柱、进入条件与不做什么。
2. **机制**：写触发动作、规则、状态转换、反馈、失败和恢复；区分玩家行为与系统行为。
3. **数据**：列字段、标识、类型、单位、来源、合法范围、默认值、持久化需求和唯一权威定义位置。
4. **公式**：使用统一公式格式，定义所有变量和单位；写明适用域、时间步长、精度、舍入和更新时机。
5. **边缘情况**：至少列三类，每类给出触发条件、预期处理、玩家反馈和验证方式。
6. **UI 接口**：列玩家可见信息、输入、状态、提示、屏幕入口出口、焦点及可访问性需求，不写成代码接口。
7. **依赖**：列前置系统、数据生产者与消费者、跨 GDD 引用及工程确认项。
8. **验收标准**：将规则映射为可观察结果和判定方法；标明待测，不把设计期望写成已通过测试。

### 公式与边缘情况

- 按“符号公式 → 变量表 → 单位检查 → 边界行为 → 依据与待确认项”的顺序组织公式。
- 在变量表写明名称、含义、单位、类型、取值范围、来源及版本；统一同名变量，禁止跨文档悄悄换义。
- 检查量纲、分母、随机范围、资源上下限、时间基准及溢出风险；不发明通用伤害、掉落或成长数值。
- 优先从输入边界、状态/时序、失败/资源三类选取实际相关场景；按需增加并发、存档、平台差异。
- 将未决规则写成待审批选项；未经确认不得用占位数值充当平衡参数。

## 四、关卡与经济

1. 为目标关卡写明进入条件、学习目标、布局、关键路径、遭遇顺序与退出/重试规则。
2. 编排探索、挑战、反馈和恢复的节奏；标出节奏假设及希望观察的玩家行为，不凭空承诺时长。
3. 将遭遇的进入、结束、失败、奖励和重复尝试连成闭环，并关联已确认系统规则。
4. 为经济列资源来源、消耗、转化、储存上限、回收路径及奖励反馈链，识别只进不出或不可达目标。
5. 为掉落表写明触发池、资格、权重或概率口径、保底/互斥/重复规则、奖励单位和唯一来源。
6. 对概率、权重、保底和条件掉落分别定义；检查适用条件下归一化、空池与库存不足，不混用口径。
7. 将进度曲线拆成阶段目标、投入、产出、解锁与节奏检查；数值须有项目依据或标为待调参数。
8. 对比可行策略的收益、成本、风险、操作负担和可达性；提出主导策略风险及替代方案，交质量保障验证。

## 五、叙事与世界观

1. 先确定叙事体验与服务支柱，列故事弧、关键转折、角色动机和玩家可影响的事件。
2. 为世界观规则、阵营和角色区分已确认事实、角色认知、传闻及待补设定，避免互相矛盾。
3. 将玩法状态与叙事触发对齐，明确前置条件、失败、重玩、跳过与存档后的连续性。
4. 为对话写意图、信息变化、选项、进入/返回条件、语气约束与玩法后果；不凭空扩展已批准世界事实。
5. 为条目文案统一实体名、术语和叙述视角，标记剧透、分支可见性及本地化占位符需求。
6. 将角色设定、视觉/音频方向及文本实装需求分别交接；保留设计建议与正式世界事实的区别。

## 六、UX 规格

1. 画出从启动、理解目标、操作、反馈到失败/恢复的用户流程，并列出入口、出口与分支。
2. 优先覆盖主菜单、核心 HUD、暂停；按实际任务补充必要界面，避免无关屏幕扩张。
3. 为每屏写用户目标、信息优先级、状态、操作、焦点、错误提示、返回路径和线框说明。
4. 按平台梳理输入处理、重复触发、焦点丢失、取消及控制映射；具体引擎能力由工程确认。
5. 对齐可访问性要求中的可读性、输入替代、非颜色提示、字幕和减弱动态等适用项；不擅自承诺实现。
6. 将线框与信息规格交美术/界面实现职责，将交互实现交工程；不要以本职责制作最终资产。

## 七、评审与四条红线

- 检查同一实体在不同 GDD 的名称、数值、单位、版本和引用是否一致，逐条给出冲突位置与修复建议。
- 标记**主导策略**：说明何种条件下某策略压倒其他选择、证据是什么、还缺哪些比较；不凭直觉宣布平衡。
- 标记**经济失衡**：追踪生产、消耗和正反馈，说明阻塞或膨胀路径及受影响的目标进度。
- 标记**认知过载**：指出同时出现的概念、信息、输入或选择负担，提出分层呈现/渐进引入选项。
- 标记**支柱漂移**：指出新增功能偏离哪条支柱，给出删减、延后或修订支柱的待审批选项。
- 将发现分为“已确认冲突／待验证风险／证据不足”，给出严重度依据、受影响范围、修复与复核条件。
- 对架构或引擎边界存疑时先经统筹职责与工程对齐；没有确认则保持待定，不宣称可实现。

## 八、交付与职责交接

- 按 [交付骨架](references/deliverables.md) 输出概念、系统索引、GDD、评审及适用专项规格；只生成任务需要的文件。
- 将验收清单逐项标为“满足／不满足／待确认／不适用（附理由）”；缺输入时不得把文档就绪误报为产品验收通过。
- 用“阶段、范围、输入版本、输出、决策、审批项、风险取舍、下一步”完成回传；不输出虚构工时或实测成绩。
- 将代码、引擎实现与性能落实交工程；视觉资产交美术；音频制作交音频；测试用例执行与证据交质量保障。
- 将任务状态、依赖、阻塞问题、待确认规则及验收期望一并交接；不要假定接收方已看到当前上下文。
- 用当前宿主可用通道沟通；单助手运行时向用户回传，不强制调用原团队的专用工具或创建子团队。
- 保持用户最终决策权；获批后才将候选方案转为已确认基线，并同步所有受影响 GDD。