game-design-review

AlterLab GameForge —— 设计文档审查工作流

游戏设计文档是一份不断演进的契约，连接着你的雄心与执行能力。糟糕的 GDD 不是格式不佳，而是让团队自信地朝错误方向开发数周，直到有人发现问题。Team Cherry 能让《空洞骑士》的设计文档发挥作用，是因为他们让文档简明、可证伪，并始终聚焦于三个支柱。大多数 GDD 之所以失败，是因为它们只描述游戏，却没有为游戏设限——什么都能做，结果什么都做不好。

这不是一份核对清单式的审查。核对清单只能确认各章节是否存在，而这项审查要确认各章节写得是否出色——内容是否前后一致、是否有心理学依据、是否诚实评估范围，以及是否足够具体，能够指导实现决策。《极乐迪斯科》的系统与叙事整合并非偶然，而是因为设计文档明确规定了每项技能检定如何与每条对话分支相连。这项审查要求的正是这种具体程度。

目的与触发条件

在以下情况下使用此工作流：

• 设计师说“审查一下我的 GDD”或“给我的设计文档一些反馈”时
• 开始实现之前，趁问题还容易修复时及时发现
• 设计发生重大变更后，重新验证内容是否前后一致
• 游戏测试暴露出问题，且你怀疑根源在设计中时
• 团队成员对游戏应该是什么样意见不一时

此工作流旨在解决以下问题：

• 不服务于任何设计支柱的机制（孤立功能）
• 目标美学与实际机制相矛盾（MDA 不匹配）
• 脱离现实的范围估算（把盲目乐观当成计划）
• 只描述游戏却不为游戏设限的设计文档（什么都能做 = 什么都做不好）
• 以非预期方式相互作用的系统（涌现式冲突）
• 缺失的章节会在实现过程中引发困惑

关键规则

1. 先通读全文，再发表评论。 上下文很重要。第 3 节中看似孤立的机制，可能会在第 7 节的成长系统中得到合理解释。先读完所有内容，再开始分析。

2. 区分问题的严重程度。 并非所有发现都同等重要。缺少核心循环定义属于严重问题，而艺术风格参考不明确则属于轻微问题。请明确标注严重程度，让设计师知道该优先投入时间处理什么。

3. 具体说明，不要含糊其辞。 “战斗系统可以做得更好”是毫无用处的反馈。“战斗系统描述了玩家的攻击，却从未说明敌人的行为模式，因此无法调整难度”则具有可操作性。指出问题，标明章节，并提出修正方案。

4. 提出建议，而不是发号施令。 提供有理由支撑的替代方案，而不是强制要求。设计愿景由设计师负责。你的工作是识别问题并提出方向——“《极乐迪斯科》通过将技能检定与对话而非战斗关联来解决这个问题”能启发思考；“直接照搬《极乐迪斯科》”则很敷衍。

5. 引用理论依据。 指出问题时，要将其与 docs/game-design-theory.md 中已有的设计原则联系起来。“这违反了心流理论，因为第 3 关的难度陡增之前没有循序渐进的技能培养过程”比“第 3 关太难了”更有说服力。

6. 检查全文各处是否一致。 GDD 最大的问题往往不是缺少章节，而是章节之间相互矛盾。设计支柱强调“玩家自由”，关卡设计章节却描述线性走廊，这是严重矛盾。

工作流

步骤 1：文档收集

阅读完整的设计文档。记录其结构、长度和整体组织方式。 确定 8 个必需的 GDD 部分中包含了哪些：

REQUIRED GDD SECTIONS
-------------------------------------------------
1. Game Overview (concept, genre, platform, audience)
2. Core Mechanics (player actions, systems, interactions)
3. Game Flow / Core Loop (30-sec to full-game timescales)
4. Level / World Design (spaces, progression through space)
5. Art Direction (visual style, references, asset requirements)
6. Audio Design (music, SFX, adaptive audio approach)
7. UI / UX Design (menus, HUD, accessibility considerations)
8. Technical Requirements (engine, platforms, performance targets)

OPTIONAL BUT VALUABLE
- Narrative Design (story, characters, dialogue systems)
- Monetization Model (if applicable)
- Multiplayer Design (if applicable)
- Accessibility Plan
- Competitive Analysis
-------------------------------------------------

步骤 2：支柱契合度审查

这是最重要的评估维度。如果游戏定义了设计支柱，每个机制和系统都必须能追溯到至少一个支柱。如果没有定义支柱，则将其标记为严重问题。

PILLAR ALIGNMENT MATRIX
-------------------------------------------------
Mechanic/System        | Pillar 1 | Pillar 2 | Pillar 3 | Orphan?
-------------------------------------------------
[combat system]        | Yes      | --       | Yes      | No
[crafting system]      | --       | --       | --       | YES - flag
[dialogue choices]     | Yes      | Yes      | --       | No
[inventory management] | --       | --       | --       | YES - flag
-------------------------------------------------

Orphan mechanics are red flags. They either:
a) Should be cut (they serve no pillar, so they dilute focus)
b) Reveal a missing pillar (add a pillar that justifies them)
c) Are described poorly (clarify how they connect to pillars)

步骤 3：MDA 一致性审查

检查所描述的机制是否确实能带来目标体验。这需要理解 docs/game-design-theory.md 中记录的 MDA 框架。

MDA CONSISTENCY CHECK
-------------------------------------------------
Target Aesthetic | Required Dynamics        | Mechanics That Deliver | Gap?
-------------------------------------------------
Discovery        | Exploration, revelation  | Fog of war, hidden areas | OK
Challenge        | Skill testing, escalation| [none described]         | GAP
-------------------------------------------------

Common MDA misalignments:
- Target "Discovery" but linear level progression (no exploration mechanics)
- Target "Challenge" but no difficulty scaling or mastery curve
- Target "Expression" but no player-facing creative tools
- Target "Fellowship" but single-player-only design

步骤 4：玩家心理审查

从自我决定理论和心流理论的角度进行评估。

SDT 检查——设计是否支持三种基本心理需求？

SDT ASSESSMENT
-------------------------------------------------
Need         | Evidence in Design       | Threats in Design     | Rating
-------------------------------------------------
Autonomy     | [choices described]      | [forced linearity]    | [A/B/C/F]
Competence   | [skill expression]       | [unfair difficulty]   | [A/B/C/F]
Relatedness  | [social features]        | [isolation by design] | [A/B/C/F]
-------------------------------------------------

心流检查——玩家能否保持心流状态？

FLOW ASSESSMENT
-------------------------------------------------
Flow Element  | Present? | Notes
-------------------------------------------------
Clear goals   | Y/N      | [does the player always know what to do next?]
Immediate feedback | Y/N | [does every action produce visible response?]
Challenge/skill balance | Y/N | [does difficulty scale with player growth?]
Sense of control | Y/N   | [does the player feel agency?]
Loss of self-consciousness | Y/N | [can they forget they are playing?]
Time distortion | Y/N    | [does the design support losing track of time?]
-------------------------------------------------

步骤 5：内部一致性审查

查找文档不同部分之间的矛盾。

CONSISTENCY CROSS-CHECK
-------------------------------------------------
Check                        | Status | Finding
-------------------------------------------------
Pillars vs. mechanics        | OK/CONFLICT | [detail]
Core loop vs. progression    | OK/CONFLICT | [detail]
Art style vs. tone          | OK/CONFLICT | [detail]
Difficulty curve vs. target audience | OK/CONFLICT | [detail]
Feature scope vs. team capacity | OK/CONFLICT | [detail]
Platform vs. control scheme  | OK/CONFLICT | [detail]
-------------------------------------------------

步骤 6：范围可行性审查

按照所述资源，实际能否制作出这款游戏？

• 统计所描述的独特系统数量
• 估算内容规模（关卡、敌人、物品、对话）
• 将其与团队规模和时间线进行比较
• 标记任何需要团队尚未证明能够实现的技术的系统
• 检查“隐藏复杂性”——听起来简单、实际却会带来工程难题的功能（寻路、程序生成、多人游戏网络代码、基于物理的玩法）

步骤 7：边界情况覆盖

玩家做出意料之外的行为时会发生什么？

• 如果玩家打破预期流程，会发生什么？
• 如果玩家耗尽设计中假定可再生的资源，会发生什么？
• 如果玩家拒绝参与设计中视为必需的系统，会发生什么？
• 如果两个系统以非预期的方式交互，会发生什么？
• 极端情况下会发生什么（最高等级、零资源、不可能的速度）？

步骤 8：新手引导评估

新玩家能否在没有外部帮助的情况下学会这款游戏？

• 是否描述了教程方案？
• 复杂度提升曲线是否与教学顺序相匹配？
• 是否只在玩家掌握基础机制后才引入高级机制？
• 是否为跳过教程的玩家提供“直接开玩”的入口？
• 游戏是通过游玩来教学，还是靠大段文字说明？

步骤 9：竞争差异化

独特卖点真的独特吗？《Hollow Knight》的卖点并非“银河恶魔城”——当时这一类型已经竞争激烈。它的卖点是游戏氛围：忧郁的昆虫文明、扎实的战斗手感，以及奖励耐心探索的世界。其差异化体现在体验，而非类别。

• 找出最接近的 3 款可比游戏
• 对每款可比游戏，说明这款游戏在体验层面（而非功能层面）有何不同
• 检查差异点属于机制层面还是外观层面（外观差异不是真正的差异——“我们的僵尸是蓝色的”不算卖点）
• 评估独特卖点是否足够突出，能否在 30 秒预告片中传达出来

输出格式

此工作流会生成一份设计审查报告：

# Design Review Report
**Document:** [GDD title]
**Version:** [if specified]
**Reviewer:** GameForge Design Review
**Date:** [date]

## Executive Summary
[2-3 sentences: overall assessment, biggest strength, most critical issue]

## Section Completeness
| Section | Present | Completeness | Notes |
|---------|---------|-------------|-------|
| Game Overview | Y/N | [%] | |
| Core Mechanics | Y/N | [%] | |
| ... | | | |

## Findings

### Critical (must fix before implementation)
- **[CRIT-01]** [Title]: [Detailed finding with specific references to the document]
  **Recommendation:** [specific suggested fix]

### Major (fix soon, will cause significant problems if ignored)
- **[MAJ-01]** [Title]: [Detailed finding]
  **Recommendation:** [specific suggested fix]

### Minor (improve when convenient)
- **[MIN-01]** [Title]: [Detailed finding]
  **Recommendation:** [specific suggested fix]

### Suggestions (not problems, but opportunities)
- **[SUG-01]** [Title]: [Idea for improvement]

## Pillar Alignment Matrix
[From Step 2]

## MDA Consistency Report
[From Step 3]

## Strengths
[What the document does well -- always include positives]

## Recommended Next Actions
1. [Priority action]
2. [Second action]
3. [Third action]

## Suggested Workflows
- [ ] [e.g., game-brainstorm to develop underdeveloped areas]
- [ ] [e.g., game-balance-check for tuning concerns]

质量标准

成功的设计审查需满足以下所有条件：

• 每项发现都引用被审查文档中的具体文本或章节
• 严重程度评级有理有据，且与问题相称
• 对每个已描述的机制都进行支柱契合度检查
• 至少有一项发现与玩家心理相关（SDT 或心流）
• 审查指出优点，而不只是问题
• 建议具体到可以立即采取行动
• 范围评估以现实开发工作量为依据
• 发现并清楚解释内部矛盾
• 区分设计质量和文档质量（出色的设计也可能记录不佳，反之亦然）

示例用例

1. “开始编码前，先帮我审查一下 GDD。” 完整审查 9 个步骤。着重指出必须在编写第一行代码前解决的关键问题。

2. “我们的试玩效果很差。问题出在设计上吗？” 重点审查步骤 3（一致性 MDA）、步骤 4（玩家心理）和步骤 7（边界情况）。 试玩反馈会指明需要重点审视哪些方面。

3. “我觉得我们的范围太大了。你能确认一下吗？” 重点审查步骤 6（范围可行性）。统计系统数量、估算内容量、对照团队产能，并给出坦诚的结论。

4. “我们正在争论要不要加入制作系统。帮我们做个决定。” 重点审查步骤 2（支柱契合度）。如果制作系统服务于某个支柱，就应该加入。 如果不服务于任何支柱，那它就是披着功能外衣的范围蔓延。

5. “我一口气写完了这份 GDD。有哪些地方是我遗漏的？” 完整审查，并着重检查步骤 1（章节完整性）和步骤 5（内部一致性）。仓促写成的文档往往存在隐含假设，需要明确说明；也可能存在需要解决的矛盾。