game-prototype

AlterLab GameForge —— 基于假设的原型制作

原型是实验，不是演示。每个原型都旨在回答一个问题：“这值得开发吗？”一旦你开始打磨原型，就不再是在制作原型，而是在开始开发——而且你可能正在开发错误的东西。Undertale 最初的演示粗糙又简陋，却恰好证明了一件事：弹幕射击与 RPG 结合的机制值得做成一款完整游戏。Hollow Knight 最初是一个游戏创作活动原型，它验证了在充满氛围的 2D 世界中，紧凑的战斗体验确实可行。Celeste 始于一个 PICO-8 原型，它证明了一个想法：在 8x8 像素分辨率下，精准的空中冲刺平台跳跃体验令人惊叹。此工作流将贯彻同样的原则：提出假设，构建最小可行测试，观察真实玩家，并根据证据做出非此即彼的淘汰或晋级决定。

目的与触发条件

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

• 团队成员提出了一个新机制，此时应该回应“先证明它可行”，而不是“直接发布”
• 设计文档中有一项假设，从未经过真实玩家测试
• 两种相互竞争的机制设计需要正面对比，以确定哪一种体验更好
• 某个功能纸面上听起来不错，但团队没有直观感受，无法判断它是否有趣
• 投产前需要验证核心循环，再决定是否投入工程资源
• 正在考虑转型，而新方向需要快速确认可行性

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

• 该机制已广为人知，并且已在类似游戏中得到验证（直接按规范开发即可）
• 你需要制作一个供利益相关者展示的垂直切片（那是演示，不是原型）
• 问题涉及内容而非机制（内容问题需要游戏测试，而不是原型制作）

关键规则

1. **每个原型只验证一个假设。**如果你要测试两件事，那就需要两个原型。把多个假设合在一起会污染结果——测试失败时，你就无法知道究竟是哪一部分失败了。
2. **设定时限，否则就放弃。**每个原型都必须有严格的时间限制：最多 1-3 天。如果无法在此期限内测试该假设，说明范围太大，应进一步拆解。
3. **原型代码属于生物危害。**它绝不能进入生产环境。假设得到验证后，正式实现必须从头开始，并采用恰当的架构。让原型代码流入生产环境，就会埋下技术债。Celeste 的 PICO-8 原型与最终游戏没有共享任何代码——它验证了体验，然后正式开发从干净的代码开始。
4. **粗糙才是正确的。**角色用彩色矩形表示。音效用占位内容。美术用程序生成。标签用 Comic Sans 字体。如果有人评论原型的视觉质量，说明他们误解了原型的目的。Hollow Knight 的游戏创作活动原型使用了简单的剪影——氛围是后来才加入的，首先验证的是体验。
5. **观察行为，而非听取观点。**玩家会告诉你他们认为你想听的话。观察他们的实际行为。一个玩家说“嗯，还不错”，却身体前倾、连续玩了 20 分钟，这些行为所传达的信息与他们的言语不同。
6. **果断淘汰，不要带有感情。**如果证据表明假设不成立，就淘汰这个原型。无论创意多巧妙、你个人多喜欢，或你投入了多少时间，都不重要。Supergiant 经常淘汰原型——他们在 GDC 演讲中透露了数十种未能通过测试阶段的废弃机制，因为团队相信证据，而不受个人执念左右。
7. 提出有关玩家体验的假设时，始终参考 docs/game-design-theory.md 中的共享理论框架（MDA、心流理论、SDT）。

工作流

步骤 1：定义假设

严格按以下格式写出假设：“我们认为，当[特定条件]下，[机制/系统]会带来[玩家行为/情绪]。” 然后定义证伪标准——哪些证据会推翻这个假设？这是最重要的部分。如果你无法定义失败是什么样子，那么你的假设就不可证伪，因此也无法测试。

有力假设示例：

• “我们相信，保留动量的抓钩会让玩家在连续摆荡至少三次且不触地时，感受到畅快刺激的移动体验。”
• “我们相信，非对称合作角色（一名玩家建造，另一名玩家防守）会促成自发交流，因为建造者能看到防守者看不到的威胁。”
• “我们相信，带有可视恢复效果的耐力系统会营造战术紧张感，因为玩家面对两名敌人时，若不休息就无法同时击败他们。”

薄弱假设示例（及其原因）：

• “战斗会很有趣”——不可证伪。什么算有趣？在什么条件下？对谁而言？
• “玩家会喜欢这种美术风格”——这是内容问题，不是机制问题。你不需要为此制作原型。
• “加入多人游戏会让游戏更好”——范围太宽。具体是哪种多人互动？“更好”如何量化？

将假设映射到 docs/game-design-theory.md 中的 MDA 框架：你要追求哪种审美体验（感官、幻想、叙事、挑战、情谊、探索、表达、沉浸）？这能让假设立足于成熟理论，也有助于你明确成功的标准。

步骤 2：严格控制范围

问自己：“测试这个假设所需的绝对最小实现是什么？”然后把它再砍掉一半。

你不需要：

• 菜单系统。直接在测试场景中启动原型。
• 多个关卡。一个房间、一次遭遇、一种情境就够了。
• 存档/读档功能。没人会玩这个超过 10 分钟。
• 音频。除非假设涉及音频（例如，测试基于节奏的机制）。
• 除了让玩家理解核心交互所需的内容之外的任何 UI。
• 动画。在状态间插值。直接切换到目标位置。必要时就传送。
• 边缘情况处理。如果玩家在原型中发现了 bug，那就恭喜他们——他们正在探索。记下来，然后继续。

你需要：

• 以全速运行的核心输入到反馈循环。如果假设涉及某个机制的实际感受，那么输入延迟和响应时序必须具有代表性。
• 足以测试假设的游戏状态。如果你要测试资源管理带来的紧张感，就至少需要一个能造成资源稀缺的简化经济系统。
• 一种快速重置的方式。测试者会玩多轮。每次重启要花 30 秒，就会拖慢测试进度。

创建一个恰好包含三列的范围清单： | 必须具备（用于测试假设） | 最好具备（提高测试清晰度） | 范围之外（留待正式开发） |

如果“必须具备”列超过 5 项，就说明范围还不够精简。回去拆解。

步骤 3：快速搭建，先求可用

这是你职业生涯中唯一一次写烂代码才是正确选择的时候。

• 所有内容都写死。到处都是魔法数字。不用配置文件。完全不采用数据驱动方式。
• 尽量只用一个脚本文件。不做架构，不分离关注点，不用设计模式。
• 复制粘贴，而不是抽象。你写的代码 72 小时后就会删除。
• 采用最快的可玩实现路径，即使这意味着忽略你知道的每一条最佳实践。
• 如果你的引擎有可视化脚本系统（Blueprints、Bolt、VisualScript），就用它——用来实现一次性逻辑，迭代更快。
• 不要向主仓库提交任何内容。原型代码应放在用完即弃的分支或独立文件夹中，决策完成后将其删除。

构建阶段占用的时间不得超过总预算的 60%。如果你花 3 天中的 2 天构建，就只剩 0.5 天测试和 0.5 天分析。这远远不够。目标是按 40/30/30 分配：40% 构建、30% 测试、30% 分析。

步骤 4：结构化评估 不要独自测试。你对自己原型的评估，是你能收集到的价值最低的数据。

最低可行测试：找 3-5 名不属于开发团队的人试玩原型，你只需在一旁静静观察。

观察流程：

• 只静默观察。 不要解释、帮忙、提示或做出反应。如果玩家感到困惑，记录让他们困惑的地方和原因。如果他们卡住了，记录卡住的位置，并让他们至少挣扎 60 秒后再提供任何指导（同时记录你不得不介入这一点——这本身就是一项发现）。
• 记录一切。 至少录制屏幕。如果条件允许，也录下玩家的面部。若玩家愿意，可以采用口述思考法。
• 记录带时间戳的事件： 明显感到挫败的时刻、明显感到愉悦的时刻、感到困惑的时刻、停下来思考的时刻（策略性投入），以及失去投入的时刻（查看手机、移开视线）。
• 结束后的问题（最多 3-5 个问题）：
  1. “你刚才想做什么？”（测试他们是否理解核心机制）
  2. “有没有哪个时刻让你感觉特别好？”（找出愉悦的高峰）
  3. “有没有哪个时刻让你感到挫败？”（找出阻碍点）
  4. “你还会再玩一次吗？”（直接反映留存情况——回答时的肢体语言比话语更重要）

运用 docs/game-design-theory.md 中的心流理论视角：玩家是否似乎进入了心流状态？挑战与技能的平衡是否处于合适区间？他们是否感到焦虑（挑战过高）或无聊（挑战过低）？

第 5 步：淘汰或推进决策

这是一个二选一的决定。没有“也许”，也没有“我们再迭代一下原型”。假设要么得到验证，要么没有。

淘汰标准（满足任意一项即可）：

• 5 名测试者中，表现出目标行为/情绪的人数少于 2 人
• 即使核心交互运行正常，也无法带来预期感受
• 玩家需要大量解释才能理解机制（这表明它无法自然地引导新玩家上手）
• “乐趣”来自次要交互，而非你正在测试的交互（关于什么会让人投入的假设是错的）
• 玩家发现了退化策略，使预期交互变得毫无必要

推进标准（必须全部满足）：

• 5 名测试者中，至少 3 人在没有提示的情况下表现出目标行为/情绪
• 核心交互能够稳定地产生预期感受，而非偶尔奏效
• 至少有一名测试者主动说了类似“我可以再玩一次吗？”的话
• 没有发现能让核心挑战变得毫无难度的退化策略
• 该机制符合至少一项设计支柱（对照项目的愿景文档进行检查）

淘汰原型时：

• 记录你学到的东西。失败的实验也有价值——它排除了一种可能性。
• 与团队分享发现。失败的原型可以避免后续团队重复测试同一条死路。
• 删除原型代码。不要归档，而是删除。它的使命已经完成。

推进原型时：

• 为正式实现撰写设计简报。说明原型验证了什么，以及还有哪些设计工作待完成。
• 正式实现从零开始。不要沿用任何原型代码。
• 找出原型未能解答的开放问题（总会有一些），并规划试玩测试来解决它们。

输出格式

## Prototype Report: [Prototype Name]
## Date: [YYYY-MM-DD]
## Time Budget: [X days allocated, Y days used]

### Hypothesis
[Full hypothesis statement in the required format]

### Falsification Criteria
[What evidence would disprove this hypothesis]

### MDA Alignment
- Target Aesthetic: [which MDA aesthetic this tests]
- Relevant Design Pillar(s): [which project pillars this serves]

### What Was Built
[2-3 sentence description of the prototype]
[Screenshots or video links]

### Scope Decisions
| Must Have | Nice to Have | Out of Scope |
|-----------|-------------|--------------|
| [items]   | [items]     | [items]      |

### Observation Notes
| Tester | Key Observations | Delight Moments | Friction Points | Flow State? |
|--------|-----------------|-----------------|-----------------|-------------|
| P1     | [notes]         | [moments]       | [points]        | [Y/N/Partial] |
| P2     | [notes]         | [moments]       | [points]        | [Y/N/Partial] |
| ...    |                 |                 |                 |             |

### Evidence Assessment
**For the hypothesis:**
- [Observation supporting the hypothesis]
- [Observation supporting the hypothesis]

**Against the hypothesis:**
- [Observation contradicting the hypothesis]
- [Observation contradicting the hypothesis]

### Decision: [KILL / PROMOTE]
**Reasoning:** [2-3 sentences explaining the decision based on evidence]

### Lessons Learned
- [Insight 1 -- applicable beyond this prototype]
- [Insight 2]
- [Insight 3]

### Next Steps
- If KILL: [What alternative approaches might work, or what to test next]
- If PROMOTE: [Design brief summary for production implementation, open questions remaining]

质量标准

• 假设清晰度：陌生人阅读假设后，能否准确理解正在测试什么？如果需要背景知识或术语才能理解，说明假设还不够清晰。
• 范围控制：原型是否在预算时间的 60% 以内完成，从而留出充足时间进行测试和分析？
• 证据质量：观察到的是行为（玩家做了什么），而不是态度（玩家说了什么）？行为证据的价值是态度证据的 5 倍。
• 决策可信度：停止/推进的决定是否合乎证据逻辑？你能否仅凭观察数据向持怀疑态度的人为这个决定辩护？
• 经验提炼：报告中是否至少包含一条适用于特定原型之外的洞见？每次实验都应让你对游戏、玩家或游戏设计本身有所了解。
• 规避反模式：报告应明确指出流程中是否触发了任何反模式（范围蔓延、忍不住打磨、原型向正式产品泄漏）。

假设与 MDA 映射参考

使用这份速查表，确保你的假设针对 MDA 框架（docs/game-design-theory.md）中的特定玩家审美体验。无法映射到某项已命名审美体验的假设，通常要么过于模糊，要么测试的是技术问题而非设计问题。

MDA 审美体验	原型测试内容	假设信号示例
感官	瞬间体验——爽感、游戏手感、反馈响应速度	玩家身体前倾，未经提示便评论某种体验“感觉”如何
幻想	角色代入——玩家是否觉得自己就是角色？	玩家使用“我”来描述感受：“我这样做时觉得很强大”
叙事	故事理解与投入程度	玩家询问接下来会发生什么；玩家根据故事逻辑做出决定
挑战	难度校准、公平失败	玩家毫不沮丧地立即重试；说“我差一点就成功了”
社群	多人游戏中的社交互动质量	玩家自发交流；出现欢笑与协商
探索	探索动机与奖励	玩家主动偏离关键路线
表达	玩家创造力与个性化	玩家做出体现自身个性的选择，而非只追求优化
沉浸	放置式参与、低风险重复行为	玩家进入安静、有节奏的状态；肢体语言放松

如果你的假设映射到多种审美体验，说明你把多个问题合在了一起。请拆分假设。

需要警惕的反模式

“我先稍微整理一下原型。” 不行。你不是在整理它，而是在对注定要丢弃的代码投入感情。停下。如果假设得到验证，你会从头开始好好构建；如果没有得到验证，你只是在浪费时间打磨注定要被扔掉的东西。

“原型能用了，我们直接发布吧。” 不行。原型架构无法扩展。原型代码没有错误处理、没有边界情况处理、没有无障碍支持、没有本地化接口、没有存档系统，也没有遥测功能。发布原型，就是造出一个理论上能运行、但一旦尝试添加内容或修复漏洞就会崩溃的游戏。

“我再给原型加一个功能。” 不行。你在不断扩大范围。假设已在第 1 步中明确。如果要测试该假设，却需要你未曾预料到的功能，那么要么是你的假设范围界定得不好，要么你测试的问题与最初的问题不同。回到第 1 步。

“我们需要更多数据——找 20 个人测试吧。” 不行，在原型阶段不需要。3-5 名测试者就足以获得明确的信号。如果 5 个人玩过后结果仍然模糊，答案可能就是“砍掉”——即使样本很小，强有力的机制也会显而易见。

“虽然没成功，但我觉得再多花点时间……” 沉没成本谬误是游戏开发中代价最高的偏见。如果 3 天都无法验证这个假设，再花更多时间也无济于事。要么假设错了，要么范围太大。重新拟定假设，并尝试聚焦更明确的方向。

原型保真度级别

并非每个原型都需要做成数字形式。选择能最快回答假设的保真度级别：

级别	方法	最适合的场景	耗时	真实感
纸面原型	桌上的索引卡、骰子、代币	回合制机制、经济系统、卡牌游戏循环、棋盘式结构	数小时	低——但迭代速度快
桌面数字原型	电子表格模拟或掷骰脚本	平衡性测试、概率分布、成长数值计算	1-2 小时	数值方面为中等，体验方面为零
一次性数字原型	单个场景、硬编码数值、程序美术	实时手感、输入到反馈的循环、空间机制	1-3 天	手感方面为高，内容方面为低
打磨版原型	加以整理的一次性原型，使用占位美术资源	干系人评审、投资者演示、团队士气验证	1 周	高

决策规则： 从能测试假设的最低保真度级别开始。体力系统的经济性可用电子表格在 30 分钟内验证。抓钩的手感则需要数字原型。如果纸面原型足以验证，却跳过它直接制作数字原型，就会浪费 80% 的时间预算。

竞争方案对比测试协议

当存在两种相互竞争的设计时，应同时测试，而不是依次测试。依次测试会引入时间变量（测试者的心情、团队对该领域的熟悉程度、外部事件）。同时测试则能隔离设计变量。

准备工作：

1. 将两种实现都构建到足以测试假设的最低范围。
2. 将测试者分成两组（每组至少 3 人，因此测试者总数至少为 6 人）。
3. 每组只体验一个版本——同一场测试中，不让任何测试者体验两个版本。
4. 对两组使用相同的观察流程和复盘问题。
5. 研究人员在复盘时不应知道测试者体验的是哪个版本（尽可能采用盲评）。

分析：

• 首先比较行为数据（心流状态持续时间、犹豫次数、情绪高峰）。口头反馈为次要依据。
• 如果某个版本产生的行为信号明显更强，无论团队偏好哪个设计，都应判定它胜出。
• 如果结果无法得出结论（两个版本的得分相近），说明假设区分度不足。完善两种设计后重新测试。
• 记录每个版本验证了什么，即使是落败的版本也要记录——落败的版本往往比胜出版本更有启发。

**反模式警示：**观看测试者体验后，不要让团队投票决定哪个版本更好。团队偏好会受到创作者偏见的影响。让行为数据来决定。

单人开发者的调整方法

单人开发者面临一个结构性问题：你无法客观地观察自己体验自己制作的原型。可以采用以下变通方法：

1. **错时测试。**制作原型后，等待 48 小时再亲自体验。记忆会有所淡化，让你能更像新玩家一样体验。这并不理想，但比刚制作完就测试要好。
2. **录下自己的体验过程。**开启屏幕录制后进行游戏。第二天以观察者冷静客观的视角观看录像。把录像当作是另一个人在玩。你会看到游玩时未曾注意到的内容。
3. **至少找 3 名外部测试者，例外情况除外。**单人开发者的身份不能成为跳过外部测试的借口。即使是 3 名来自家人、朋友或本地独立游戏开发者社区的测试者，也比自我测试更有参考价值。你的游戏最终必须由其他人来玩。
4. **在线测试平台。**进行远程测试时，可使用 OBS + Discord 屏幕共享，或 itch.io 私密访问链接等平台。远程测试者无法提供摄像头画面数据，但能提供真实的冷启动行为。
5. **采用 30% 的单人开发缓冲。**单人开发者制定原型时间预算时，应预留 30% 的额外时间（而非 20%），因为你要承担所有环节的工作量：设计、构建、测试组织和分析。对单人开发者来说，一个“3 天原型”实际上相当于 2.1 天专注工作的有效时间。

构建前检查清单

在编写一行原型代码之前，请确认已满足以下条件。如果有任何一项未满足，请先停下来解决：

• 已按规定格式写下假设：“我们认为，当[条件]成立时，[机制]会产生[行为／情绪]。”
• 已定义证伪标准：你至少能说出两个可观察的信号，证明假设是错误的。
• 已确定 MDA 美学目标：你知道这项测试针对八种美学中的哪一种。
• 已设定时间范围：你有明确的结束日期，而不是“感觉做完了再说”。
• 已完成范围检查清单：“必须具备／最好具备／范围之外”三列均已填写具体内容。
• 已安排测试者：开始构建前，你已确定至少 3 位外部玩家的姓名和测试时间。
• 已测试录制设置：原型尚未完成之前，你已通过测试录制确认屏幕捕获软件能够正常运行。
• 已创建原型分支：你没有在 main 上构建。这是落实“原型代码不会毕业”的实际保障。

这份清单之所以存在，是因为构建阶段是原型制作中最诱人的部分。在假设尚不明确时就开始构建的冲动很强烈，而且几乎总会导致范围蔓延和结果模糊。花 20 分钟完成这份清单，可以省下 2 天的无用功。

示例用例

1. “我想测试平台游戏中的回溯机制是否令人满意。请帮我制定原型假设和范围。”
2. “我们的战斗系统有两种相互竞争的设计——带有动作元素的回合制，以及可暂停的实时制。请帮我为两者设计一场原型对比测试。”
3. “我们的 GDD 假设玩家会喜欢在地牢探险之间进行基地建设循环，但团队里没人测试过这个假设。请带我逐步完成原型制作。”
4. “我为抓钩机制制作了一个原型，并邀请 4 个人进行了测试。以下是我的笔记——请帮我分析结果，并决定是砍掉还是保留。”
5. “我们在上个冲刺周期验证了核心战斗循环。现在我需要为进度元层制作原型。请帮我明确假设和范围。”
6. “我是一名独立开发者。上周我制作了一个原型，刚找了 3 位测试者体验。其中两人似乎觉得无聊，另一人似乎感到困惑。请帮我判断这是该砍掉，还是有条件地保留。”
7. “我们需要验证两种相互竞争的经济系统设计——固定成本制作系统和可变成本竞价系统。请带我逐步设计一场纸面原型对比测试。”