game-playtest

AlterLab GameForge -- 结构化游戏测试分析

游戏测试不是询问玩家玩得开不开心，而是有条理地观察玩家行为，找出设计成功和失效之处。玩家嘴上说的不一定是真话，但双手不会。任天堂几十年来深谙此道：宫本茂以静默观察玩家闻名，相信他们困惑时的表现，而不是赞美之词。Larian 在《博德之门 3》的抢先体验期间开展了数千场社区游戏测试，每一项重大系统改动都源于行为数据，而非论坛投票。本工作流提供了一套严谨的行为观察框架，可将原始游戏测试过程转化为可执行的设计洞见。

目的与触发条件

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

• 构建版本已准备好接受外部测试，你需要结构化反馈，而不只是玩家的反应
• 需要解答具体的设计问题，例如“玩家是否理解制作系统？”，而不是“游戏好玩吗？”
• 需要验证新手引导流程——新玩家能否在没有教程的情况下学会核心机制？
• 需要评估难度曲线——玩家处于心流通道中，还是在无聊和挫败之间摇摆？
• 新功能已集成，但其对整体体验的影响尚不明确
• 发布前的润色阶段需要了解哪些粗糙之处对玩家影响最大
• 竞争分析需要与一款参考游戏进行并排比较

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

• 你需要单独测试未经打磨的机制（请改用 game-prototype）
• 构建版本存在严重问题，测试者的大部分时间都会耗在遇到错误上（先修复关键错误，再进行游戏测试）
• 你想要营销引言或正面评价（那是公关，不是游戏测试）

关键规则

1. 邀请测试者之前，先定义问题。 每场游戏测试都要回答具体问题。“好玩吗？”不是问题——那是祈祷。“玩家能否在死亡次数不超过两次的情况下通关第一个地牢？”才是问题。《蔚蓝》的游戏测试曾提出“玩家能否在前三个场景内学会冲刺机制？”——具体、可观察、可执行。
2. 主持人不得参与游戏。 你要观察并做笔记，不要提供帮助、解释、建议或作出反应。你的扑克脸就是科学仪器。
3. 每场至少测试 5 名测试者。 少于 5 名，你收集到的只是轶事，而非数据。小样本会被个别玩家的习惯主导。达到 5 名或以上，模式才会显现。
4. 绝不让开发团队参与测试。 他们知道得太多。他们的肌肉记忆、心智模型和背景知识，让他们无法像新玩家一样体验游戏。任天堂会刻意让内部测试团队远离开发讨论，让他们每次测试时都能以全新视角参与。开发人员已经习以为常，因此看不到新手引导中的任何问题。
5. 行为数据优先于口头反馈。 如果玩家说“操作手感挺好”，但你观察到他们在 10 分钟的测试中 11 次按错按钮，那么应以行为数据为准。始终如此。Larian 追踪了《博德之门 3》测试者的输入行为，了解他们在选择对话选项前悬停在哪些选项上；这些犹豫数据为第一幕的重写提供了依据。
6. 将观察与解读分开。 测试过程中只记录发生了什么，测试结束后再解读其含义。实时混合两者会造成确认偏误。
7. 分析玩家投入度和情绪反应时，请参考 docs/game-design-theory.md 中的心流理论和 MDA 框架。

工作流

步骤 1：游戏测试前的准备

定义测试目标。写下本次游戏测试要回答的 3-5 个具体问题。每个问题都应当：

• 可观察（你能通过观察得出答案，而不只是询问）
• 可执行（答案能直接为设计决策提供依据）
• 范围明确（可在单次游戏测试中回答） 好的测试问题：
• “玩家能否在前两次遭遇中自然而然地发现闪避翻滚机制？”
• “在成长曲线的哪个阶段，玩家会不再主动探索，转而开始直奔目标？”
• “第 2 幕的资源匮乏会带来紧张感，还是挫败感？”

准备观察记录表。针对每个测试问题，确定：

• 哪些具体玩家行为表明测试成功（积极信号）
• 哪些具体玩家行为表明测试失败（消极信号）
• 在游戏过程中应重点观察哪些时段（关键观察时段）

创建每位玩家的跟踪表单：

Player ID: ___
Session Date: ___
Session Duration: ___
Test Build Version: ___

Timestamped Observations:
[MM:SS] [Observation] [Category: Action/Hesitation/Confusion/Emotion/Verbal]

Post-Session Survey Responses:
Q1: ___
Q2: ___
Q3: ___

设置录制设施：

• 录制带音频的屏幕画面（必须——实时观察时会漏掉一些细节，录制内容却能捕捉到）
• 如果条件允许，开启面部摄像头（面部微表情能反映投入、困惑和挫败感，而玩家绝不会用语言表达这些）
• 如果你的引擎支持输入记录，则启用该功能（生成热力图，显示玩家点击的位置、死亡地点和停留时间）
• 确保录制内容带有时间戳并保持同步，以便将玩家表情与游戏事件交叉对照

准备测试环境：

• 所有测试者使用相同的硬件配置（不同的帧率和输入设备会干扰测试结果）
• 移除开发者叠加层、调试菜单和控制台访问权限
• 禁用所有开发者快捷键和无敌模式开关
• 准备好干净的存档状态，确保每位测试者都从同一位置开始
• 第一位测试者到场前，先进行一次模拟测试，确认录制设置正常

向主持人说明注意事项（如果有助手）：

• 他们唯一的职责是观察和记录，不要帮忙、解释或作出反应。
• 如果测试者问“我该做什么？”，正确的回答是：“你觉得应该做什么？”
• 如果测试者在非关键路径上完全卡住超过 90 秒，他们可以给出一句中立提示（“你试过和发光的物体互动吗？”）。将此记录为关键发现。
• 主持人不应紧挨玩家就坐。意识到有人在旁观察会改变玩家的行为。应坐在玩家身后侧方。

步骤 2：游戏测试期间——静默观察流程

这一阶段最需要遵守纪律。你是一名科学家。在这一阶段，你对游戏的个人感受无关紧要。

实时观察类别：

行为——玩家在做什么？

• 记录玩家每时每刻的决策。不要只写“玩家与 Boss 战斗”，而要写“玩家在攻击前绕着 Boss 转了 15 秒，似乎在寻找弱点或鼓起勇气”。
• 跟踪玩家的导航路线。玩家去了你预期的地方吗？他们实际去了哪里？非预期的探索路线能揭示环境实际传达了什么，以及你认为它传达了什么，两者之间的区别。
• 记录输入模式。狂按按钮（惊慌或无聊）、有意识地按下按钮（策略性投入）、反复输入但未成功（操作困惑）。

犹豫——玩家在哪里停顿？

• 玩家在门前停顿，说明他们在猜测门后有什么（很好——你营造了紧张感）。
• 玩家在菜单前停顿，说明他们不理解选项（不好——你的 UI 不够清晰）。
• 玩家在战斗中停顿，说明他们可能在制定策略（好），也可能不知所措（不好）。观察他们的面部表情和接下来的行动，就能分辨是哪种情况。

困惑——玩家在哪里产生了误解？

• 记录“预期不符”的时刻——玩家明显预期会出现一种结果，实际却出现了另一种。这是任何游戏测试中最有价值的发现。
• 留意玩家错误地使用某个机制，却认为自己用对了的情况。这表明你的反馈系统没有清楚地传达当前状态。
• 观察玩家是否反复阅读同一条工具提示或标牌——这意味着信息不够清楚，或者他们不相信自己已经理解了。 情绪——玩家有什么感受？
• 愉悦指标：身体前倾、睁大眼睛、自发大笑、发出「酷」或「哇」之类的感叹、把屏幕给身边的人看
• 挫败指标：叹气、身体后仰、双臂交叉、点击动作更用力、喃喃自语、翻白眼
• 投入指标：忘记时间、无视手机通知、结束时询问「我还能继续玩吗？」
• 分心指标：查看手机、环顾房间、注意力不集中地玩、询问「还要多久？」
• 心流状态指标：专注安静、输入操作有节奏、听到时间结束的提醒时感到惊讶、难以回忆具体时刻（他们当时「完全沉浸其中」）。据报告，《Hades》的游戏测试中，玩家会连续玩 30 多分钟而不看时钟——这是确认心流状态的黄金标准

将情绪反应对应到游戏中的具体时刻。这会为游戏体验绘制一张情绪热力图——高潮和低谷分别在哪里？将其与你在设计文档中预期的情绪曲线进行比较。

口头观察（如采用边玩边说协议）：

• 不加筛选或纠正，记录玩家实时讲述的内容。
• 标记玩家说的话与其实际操作相矛盾的时刻——这些信息非常宝贵。「这很简单」之后却连死三次，就暴露出玩家感知技能与实际技能之间的差距。

步骤 3：会后复盘

保持简短，最长 5–7 分钟。趁体验记忆犹新时，玩家的注意力最有价值，但游戏结束后疲劳很快就会显现。

复盘核心问题（按以下顺序提问）：

1. 「这款游戏是关于什么的？」——测试核心幻想和主题是否清晰传达
2. 「大部分时间里，你想做什么？」——揭示玩家是否理解主要目标和核心循环
3. 「有没有哪个时刻特别棒，让你印象深刻？」——从玩家角度找出愉悦高潮（与观察结果交叉核对）
4. 「有没有哪个时刻让你感到困惑或挫败？」——从玩家角度找出阻碍
5. 「如果可以改一件事，你会改什么？」——揭示玩家最先想到的痛点

可选的深入问题（仅在时间允许，且答案有助于测试问题时提问）：

• 「你觉得自己是否始终清楚有哪些选择？」——测试决策是否清晰
• 「你觉得难度合适、太简单还是太难？」——主观难度评估（与行为数据交叉验证）
• 「有没有什么事情是你想做，但游戏不让你做的？」——揭示可供性方面的缺口

不要问：

• 「你喜欢这款游戏吗？」——毫无用处。社交压力会让玩家给出肯定回答。
• 「你会买吗？」——现阶段无关紧要，而且会让玩家进入评估心态，抑制坦诚反馈。
• 引导性问题：「你注意到洞穴里的灯光变了吗？」——你是在向玩家灌输自己想要的观察结果。

步骤 4：游戏测试后的分析

最后一场测试结束后，至少等待 2 小时再进行分析。立即分析会受到近因偏差影响——最后一位测试者的体验会主导你的思路。

识别跨玩家模式：

• 将观察结果整理成矩阵：行表示游戏时刻／功能，列表示玩家
• 标出 3 名以上玩家表现出相同行为的时刻——这些是系统性发现，而非个体特例
• 找出分歧点：玩家分成不同的行为群体的时刻（这揭示了一种设计分歧，可能需要解决或接纳）

发现分类： 按严重程度对每项发现进行分类：

严重程度	定义	所需操作
关键	破坏核心体验。玩家无法继续推进，或预期情绪发生逆转（感受到挫败，而非胜利）。	必须在下一次试玩前修复。
主要	严重降低体验质量。玩家可以继续推进，但体验质量明显下降。	应在当前里程碑中修复。
次要	尚有改进空间。玩家会注意到，但不会受到显著影响。	方便时修复，或纳入后续润色。
观察记录	有趣的行为记录，不代表存在问题，但可能为未来的设计决策提供参考。	记录以供参考。无需采取行动。

生成建议： 针对每个关键和主要发现，生成具体、可执行的建议：

• 要改什么（具体明确——例如“将房间 3 的敌人数量从 5 个减至 3 个”，而不是“降低难度”）
• 为什么有帮助（将建议与观察到的行为联系起来）
• 预期影响（如果修复有效，下一次试玩中应出现什么变化）
• 潜在副作用（此修复是否会在其他地方引发新问题？）

纵向比较： 如果存在以往的试玩数据，请比较不同迭代的结果：

• 上次试玩中发现的问题有哪些已得到处理？修复是否有效？
• 哪些问题在尝试修复后仍然存在（这些问题可能源自结构，而非表面）？
• 整体趋势是否在改善？修复的问题是否多于引入的问题？

步骤 5：生成并分发报告

将分析汇总到标准化的试玩报告格式中（见下方的输出格式）。向整个团队分发报告，并在顶部附上 2 句话的执行摘要——主设计师和制作人需要无需阅读 10 页内容就能了解要点。

输出格式

## Playtest Report: [Build Name / Version]
## Date: [YYYY-MM-DD]
## Facilitator: [Name]
## Testers: [Count] ([demographic notes if relevant])
## Session Duration: [Average across testers]

### Executive Summary
[2 sentences: What was the most important finding? What is the recommended priority action?]

### Test Objectives
1. [Question 1] -- [Answered / Partially Answered / Unanswered]
2. [Question 2] -- [Answered / Partially Answered / Unanswered]
3. [Question 3] -- [Answered / Partially Answered / Unanswered]

### Findings Matrix

| ID | Finding | Severity | Players Affected | Game Moment | Recommendation |
|----|---------|----------|-----------------|-------------|----------------|
| F1 | [desc]  | Critical | 4/5             | [moment]    | [action]       |
| F2 | [desc]  | Major    | 3/5             | [moment]    | [action]       |
| F3 | [desc]  | Minor    | 2/5             | [moment]    | [action]       |

### Emotional Response Map
[Timeline showing emotional peaks and valleys across the session, with game moments annotated]

Opening -> [emotion] -> [event] -> [emotion] -> [event] -> [emotion] -> Close

### Onboarding Assessment
- Core mechanic understood without explanation: [X/5 players]
- Time to first successful use of primary mechanic: [average time]
- Tutorial/hint engagement: [how many players read vs. skipped]
- First death/failure cause: [most common reason]

### Flow Analysis (per docs/game-design-theory.md)
- Estimated flow channel adherence: [percentage of session time in flow]
- Anxiety spikes (challenge > skill): [moments]
- Boredom dips (skill > challenge): [moments]
- Flow entry points: [moments where players appeared to enter flow state]

### Player Behavior Patterns
- **Navigation**: [Where did players go? Where did they NOT go? Where did they get lost?]
- **Combat/Core Loop**: [How did players engage with the primary mechanic?]
- **Exploration**: [What did players investigate voluntarily?]
- **Resource Management**: [How did players handle scarcity/abundance?]

### Comparison to Previous Playtest
| Previous Finding | Status | Notes |
|-----------------|--------|-------|
| [Finding from last time] | Fixed / Improved / Unchanged / Regressed | [details] |

### Prioritized Action Items
1. [Highest priority action] -- addresses findings [F1, F3]
2. [Second priority action] -- addresses finding [F2]
3. [Third priority action] -- addresses finding [F4]

### Raw Observation Notes
[Attached or linked per-player observation sheets]

### Recording Index
| Player | Recording File | Key Timestamps |
|--------|---------------|----------------|
| P1     | [filename]    | [MM:SS notable moments] |
| P2     | [filename]    | [MM:SS notable moments] |

质量标准

• 问题具体性：每个测试目标都可观察、可执行且范围明确。规划阶段不得保留“有趣吗？”这类模糊问题。
• 观察严谨性：至少 80% 的发现以行为数据为依据（玩家做了什么），而非口头数据（玩家说了什么）。口头数据是辅助证据，而非主要证据。
• 模式有效性：归类为系统性问题（主要或关键）的发现，必须得到至少 5 名测试者中的 3 名的观察结果支持。单个玩家的观察应归类为次要或观察记录。
• 建议具体性：每个关键和主要发现都有具体、可实施的建议——不是“做得更好”，而是“将房间 3 的敌人数量从 5 个减至 3 个，并在遭遇战前添加一个生命值补给物品。”
• 纵向跟踪：如果存在以往的试玩，报告应至少包含与上一次试玩的比较，并跟踪以往发现是否已处理，以及修复是否有效。
• 情绪映射：报告应包含情绪反应图，展示试玩时间线中愉悦和挫败情绪出现的位置，并关联到具体的游戏事件。
• 主持人中立性：报告应记录主持人介入的情况（解释、帮助、提示），并标记这些时刻可能受到数据污染。

AI 游戏测试 Agent

人工游戏测试仍然是评估玩家体验的黄金标准，但 AI 游戏测试 Agent 可以补充人工测试，通过提供覆盖测试、回归测试和通宵压力测试来完成一些人工测试员难以实际执行的工作。

nunu.ai 模式： 用通俗的英语定义测试目标（例如，“不死亡地完成教程”、“在第 3 关找到并击败 Boss”、“尝试绕过锁着的门，打破关卡顺序”）。AI 机器人通宵执行测试，并生成会话录像和行为日志。可用于：

• 平衡性调整后的回归测试（这个补丁是否影响了教程完成率？）
• 覆盖测试（关卡设计中是否存在任何会导致软锁的路径？）
• 压力测试（在多人环境中，100 个 Agent 同时游玩时会发生什么？）

modl.ai 模式： 自主测试机器人会在没有特定目标的情况下探索游戏，绘制可达状态图，并找出机器人会卡住的区域。可用于：

• 寻路验证（导航网格中是否存在缺口？）
• 状态机完整性（机器人是否会进入无法恢复的状态？）
• 内容覆盖（有多少比例的关卡几何结构实际上可以到达？）

AI 测试无法替代的内容：

• 情绪反应测量（愉悦、挫败、投入）
• 美学评估（感觉好吗？）
• 多人游戏中的社交动态（AI 无法复现人类社交行为）
• 第一印象测试（AI 没有可被打破的预期）

使用 AI 测试进行覆盖和回归测试。使用人工测试评估体验和情绪。绝不要互相替代。

结构化会话规划模板

开始任何游戏测试会话前，请填写此规划模板，以确保测试重点明确且结果可复现：

SESSION PLAN
Date: [YYYY-MM-DD]
Build Version: [version string]
Session Type: [First Impression / Targeted Feature / Regression / Full Playthrough]
Duration: [planned session length per tester]
Tester Count: [number of testers scheduled]

Test Questions (max 5):
1. [Specific, observable, actionable question]
2. [Specific, observable, actionable question]
3. [Specific, observable, actionable question]

Focus Areas:
- [Game section or feature under scrutiny]
- [Specific interaction or flow to observe]

Recording Setup:
- Screen capture: [tool and settings]
- Face camera: [available / not available]
- Input logging: [enabled / not available]

Facilitator Notes:
- [Any special instructions for this session]
- [Known issues to ignore during testing]

游戏测试重点：四个问题

时间有限或需要快速获取测试人员反馈时，可将复盘内容精简为以下四个问题。它们按顺序排列，旨在尽量减少测试人员的疲劳，同时找出价值最高的见解：

1. “什么让你感到困惑？” —— 找出新手引导中的问题、机制说明不清之处以及沟通差距。困惑是最具可操作性的发现，因为它能直接指向需要重新设计的具体时刻。
2. “你什么时候感到无聊？” —— 找出节奏上的空档、奖励缺失以及无法吸引玩家的内容。仅凭观察更难发现无聊，因为无聊的玩家往往会出于礼貌继续玩下去。
3. “你什么时候想停下来？” —— 找出挫败感高峰、疲劳瓶颈以及游戏自然的单次游玩时长。“我想在 Boss 战时停下来”和“我想在管理物品栏时停下来”之间的差异，能揭示哪些系统造成了阻碍。
4. “你会把什么展示给朋友看？” —— 找出愉悦感高峰和游戏天然的营销亮点。测试人员愿意展示给朋友看的内容，就是预告片应该重点呈现、商店页面应该着重强调的时刻。

会话时间受限时，可以用这四个问题替代较长的复盘。但它们不能替代会话期间的完整行为观察。

远程游戏测试设置

大多数独立开发者无法持续开展线下测试。远程游戏测试是现实可行的默认选择，但有一些具体要求：

录制基础设施：

• 请测试者安装 OBS，或使用操作系统内置的录制功能（Windows 上的 Xbox Game Bar，macOS 上的 QuickTime）。提前提供书面设置说明——不要把测试时间花在排查录制软件问题上。
• 如果测试者同意，请求录制正面摄像头画面。大多数人都会同意。即使画质不高，摄像头也能捕捉到情绪反应，而这类反应最有助于发现高价值问题。
• 使用 Discord、Zoom 或 Google Meet 进行语音通话。观察期间将自己的麦克风静音。测试者听到你的呼吸声会改变他们的行为。
• 使用私密的 itch.io 链接、Steam 抢先体验密钥或直接下载来分发测试版本。切勿通过电子邮件发送可执行文件——它们会被安全软件标记，还会影响测试者的第一印象。

测试环节安排：

• 预留 90 分钟：10 分钟用于设置，60 分钟用于游玩，20 分钟用于复盘。测试时间拖得太长，测试者自然会压缩复盘的质量。
• 使用共享文档或表单记录复盘内容，避免实时转录。Google Forms 适合标准化问题；共享 Google Doc 适合开放式回答。
• 对于异步远程测试，请提供结构化的观察提示词：“完成后，请写下：一个让你感到意外的时刻、一个让你感到困惑的时刻，以及一个让你特别投入的时刻。不要想太多——未经修饰的反应比深思熟虑后的回答更有价值。”

远程测试无法捕捉的内容：

• 没有摄像头时，无法捕捉真实的面部微表情（有些测试者会拒绝开启摄像头）
• 物理环境的背景信息（干扰因素、硬件质量、声音环境）
• 如果测试者看过截图或预告片，就无法观察真正的初次接触行为

远程测试适用于开发中期的游戏测试，目标是找出具体的阻碍点。如果条件允许，对核心引导流程进行第一印象测试时，最好安排有主持人在场的线下测试。

确定发现的证据门槛

不要因为某位测试者反应强烈，就把一个发现定为“严重”。分类前，请先应用以下证据门槛：

严重程度	最低证据标准
严重	5 名测试者中有 4 名或更多表现出该行为，或 1 名测试者遇到导致测试环节彻底终止的问题（崩溃、软锁、无法继续）
主要	5 名测试者中有 3 名或更多表现出该行为，并且有行为证据佐证（不能只有口头报告）
次要	5 名测试者中有 2 名口头提到该问题，或 1 名测试者表现出行为证据
观察项	任何较小但值得记录以供日后参考的信号

证据不明确时（例如，2 名测试者表现出某种行为，另有 3 名没有），请在报告中明确说明这一分歧。2/5 的信号还不足以立即采取行动——应在下一轮游戏测试中继续观察。如果下一轮测试中再次出现，就将其升级为主要问题。

示例用例

1. “我们刚完成首个可玩版本。请帮我规划一场结构化的试玩测试——我应该问哪些问题？如何设置观察环节？”
2. “我上周进行了一场试玩测试，记录了 6 位玩家的情况。以下是我的原始观察记录——请帮我分析数据，并生成一份按优先级排序的发现报告。”
3. “玩家总是在第 3 关的同一个位置阵亡。我觉得这是难度突然提升导致的，但不太确定。请帮我设计一场有针对性的试玩测试，找出问题所在。”
4. “我们根据上个月试玩测试的反馈更改了控制方案。请帮我设计一场后续测试，看看这些改动是否真的解决了我们发现的问题。”
5. “我们的游戏有一段 20 分钟的新手引导流程，我怀疑玩家还没体验到核心循环就流失了。请帮我设置一场首次用户体验试玩测试，并制定要跟踪的具体指标。”
6. “我是独立开发者，无法开展线下测试。请帮我用 Discord 和 OBS 为我的动作 RPG 设置一场远程试玩测试。”
7. “过去 2 个月里，我收到了 3 场不同测试的 6 份试玩测试报告。请帮我找出哪些发现持续出现在多场测试中，哪些只是偶然观察到的。”