独立游戏开发中被忽视的隐性劳动

大家好，我是 Rashel！本文是我在 2025 年 8 月参加于美国威斯康星州麦迪逊市举办的“玩·做·学国际会议”（Play Make Learn Conference，PML）时，在会议上做的一场演讲。PML 是一个致力于协作与探索的平台，聚焦游戏化学习的设计、研究与实践，关注学习型游戏及其积极社会影响、创作与创客空间、STEAM 教育和艺术教育等领域。

我的分享题为《从测试到迭代：揭示独立游戏开发中被忽视的隐性劳动》（From Playtesting to Iteration: Unveiling the Hidden Labors of Indie Game Development），内容涉及一些独立游戏开发的幕后故事，并讨论了那些常常被忽略的环节——游戏测试、调试和迭代（Playtesting, Debugging, and Iteration）——其实恰恰是整个创作过程中最关键、也最重要的部分。

首先简单介绍一下我自己：我是一名游戏设计师和媒体艺术家，同时也写与游戏、艺术相关的文章，并策划相关的展览与活动。由于同时具有游戏开发者与策展人双重身份，我逐渐意识到，当项目进入深度开发阶段时，测试、调试与迭代其实比最初的设计本身更为重要。但大多数玩家、媒体与策展人看到的，往往只是打磨完成的最终成果，很少能看见其背后经历过的无数次重建与反复修改。

什么是游戏测试？

那么，第一个问题是：什么是试玩，或游戏测试（Playtesting）？

这里我分享三张截图，它们来自去年最受关注的独立游戏之一《小丑牌》（Balatro）。

第一张图片由 Localthunk 截取于 2021 年 12 月，也就是游戏开发刚开始几周的时候，当时他仍在测试最核心的玩法机制。到 2022 年 8 月，也就是第二张图中，游戏的主要机制和计分原型已经成型，但仍然使用的是非常基础的扑克牌组。最后一张图来自 2024 年 2 月的正式版本，已经加入了经过打磨的更复杂、也更有特色的牌组系统，例如小丑牌、塔罗牌和星球牌包等。

图片：@LocalThunk

游戏设计师特蕾西·富勒顿（Tracy Fullerton）将游戏测试形容为设计师在工作中所从事的最重要、但同时也是他们了解最少的活动。游戏用户研究科学家麦克·安拜德（Mike Ambinder）也曾指出：每一项游戏设计本质上都是一个假说，而游戏测试就是实验。游戏测试的目标，并不是验证设计是否“正确”，而是尽可能收集信息，从而做出最充分、最理性的设计决策。

案例分享

下面我分享三个案例研究——其中两个来自朋友的游戏项目，一个来自我自己的作品——来展示游戏测试是如何帮助我们不断修正与调整我们的“设计假说”的。

第一个案例是由杨静和关子维开发的《遗忘工程师》（Forgetter）。它的故事设定于一个未来世界：婴儿可以继承已故艺术家的意识，而玩家扮演一名受雇的“大脑清洁工”，负责抹除这些艺术家的不健康记忆。2 人团队全职开发，历时 9 个月完成项目，其中大约有 1 个月专门用于游戏测试。

他们在游戏测试中获得的最有价值的反馈是在视觉传达方面。负责技术与美术的关子维非常喜欢用黑暗来传达孤独与悲伤的情绪，但对许多玩家来说，这种黑暗更容易被解读为恐怖氛围，让人担心会出现跳吓，甚至引发他们的眩晕不适。团队最终不得不在美学选择上做出妥协，但也正是通过这一过程，他们深入理解了玩家是如何解读和感受视觉风格的。

我喜欢把 Debug，也就是调试，称为“捉鬼”，因为它往往真的很像在破解超自然谜团。《遗忘工程师》里就发生过这样一个“鬼故事”：一位具有探索精神的测试玩家在地图中走得太远，远离了开发团队设计的可玩区域，深入到背景的沙漠深处，结果掉进了一道巨大的裂缝。从录屏来看，就像坠入地狱，却完全无法判断具体发生在地图的哪个位置。团队花了很长时间在地图中反复“行走”排查，最终才发现那其实是地形碰撞体之间的一道缝隙。最后，他们通过缩小可行走区域，修复了这个问题。

第二个案例是《一个人的火锅局》（Hot Pot for One），由 Rachel Li 和 Qin Yin 开发。游戏讲述了一位中国留学生在纽约的平安夜故事：原本要赴约的朋友都临时取消，她只好独自一人过节。作为当时全职在读的硕士生团队，他们花了一年半时间开发这款游戏，其中几乎一年都用于游戏测试。

大部分测试时间都花在了筷子操作上——即用筷子夹起食材并投入火锅中的机制。通过游戏测试，团队能够观察到不同玩家在点击、夹取和释放食材时的行为差异，从而更好地理解不同用筷习惯的玩家在游戏里的操作体验。

他们的“鬼故事”则来自一个意想不到的漏洞：有玩家发现，居然可以穿过房间四周的墙壁！团队之前花了很长时间布置房间并测试，甚至连窗外的城市景观和飘落的雪花都经过精心设计，但却忘记给墙壁添加碰撞体。在专注于烹饪剧情的过程中，他们从未预料到玩家会尝试离开房间。

接下来是我的《冲啊小土璇！》（Go Groundshel!）。游戏讲述了一只土拨鼠女孩的冒险故事：她一边寻找失踪的伴侣，一边寻找可用的厕所——伴侣在失踪前没来得及修好家里的厕所。开发过程大约持续了两年，到目前为止，我们已经投入了差不多 9 个月进行游戏测试。现在我们仍在制作美术资源、测试功能，一旦这些都完成，游戏测试在总开发时间里所占的比例将会变得更大。

由于这个项目一开始是凭着直觉驱动的顺势而为的作品，最初由我独自承担所有美术工作。在测试过初版 Demo 后，一些玩家指出像素贴图分辨率不统一，看起来不像来自同一个世界。于是，我招募了一位美术实习生，我们一起在 Miro 白板上测试不同的分辨率和尺寸组合，最终找到了最合适的搭配。

开发过程中，我们也遇到了不少“鬼故事”。有一次，玩家解开谜题后，却撞上了一堵看不见的墙。调试后发现，这是因为浴室的碰撞体被过早地触发，并且由于设置时我没有调节墙体的深度，导致它阻挡了还处于楼下的玩家的移动。

还有一次，主角在从场景 1 移动到场景 2 时突然消失。调试后发现，是因为主角的贴图没有随控制器和摄像机一起被成功传送——而这是由玩家一个微妙而特定的操作行为引发的。

这也正是为何开发游戏时我们要依赖持续的游戏测试——只有不断优化流程、打磨机制、调整难度，才能真正让玩家投入其中。同时也引出了一个问题：我们该如何有效地进行游戏测试与迭代？

如何有效地进行游戏测试与迭代

第一个关键，是根据你的具体需求组织合适的测试形式。

主要的测试类型包括：Discord 活动、公开的试玩活动、展示会以及发布 Demo。

不同的测试形式适合开发的不同阶段，选择合适的渠道能够显著提升反馈质量和开发效率。基于 Discord 的测试最适合早期到中期开发阶段，此时游戏机制、节奏或界面仍在不断调整。你可以在自己的 Discord 服务器上举办测试，或与特定类型游戏的服务器或活动合作（例如 thinky-puzzle-games、Wholesome Games、Interactive-Narrative 等 Discord 服务器），以招募本来就会对你项目类型感兴趣的测试者。在正式开始试玩之前，这类测试需要高度组织化：提供清晰的测试版本、设定短期测试目标（例如“关注战斗可读性”），并设计结构化的反馈形式，例如引导式问题或简短的测试后问卷。

《冲啊小土璇！》在芝加哥游戏空间 Night City Games 的“试玩星球 2025”活动中亮相

相比之下，Discord 测试让开发者有更多时间和精力去观察玩家，而公开的试玩活动、展示会和发布 Demo 则更适合在游戏开发后期阶段，当核心体验已经稳定，需要更广泛的玩家反应、需要提高可见度或获取市场信号时进行。同时，社交媒体和邮件列表可以帮助你吸引更多合适的玩家。

我最近采访了《Consume Me》的设计师 Jenny 和 AP。他们曾参加 NYU 的 Playtest Thursday，类似于每周一次的工作室开放访问日。但考虑到需要更长且不被打断的测试时间，后来，他们直接邀请玩家做了独家试玩会，并提供午餐，以确保每位玩家有足够长的时间进行深入测试。

另外，设计问卷时要有明确的目标，这也非常重要。如果你希望收集关于游戏玩法的反馈，就不要去问无关的界面设计问题；如果你在功能 A 和 B 之间犹豫不决，可以通过 A/B 测试收集有意义的、可靠的反馈。

第二，你需要选择性地倾听。许多玩家并不了解游戏是由小团队制作，自然会拿它与 AAA 大作相比；也有玩家非常热情，期望自己的意见被采纳，因此表达会非常直接。这种情况下，无需纠结于字面上的每一句话，关键是关注反馈背后的情绪，从中判断真正需要改进的地方。

有时，测试环境本身也可能不理想。比如我的游戏在柏林艺术游戏节（AMAZE Berlin）展出时，许多参观者希望在现场尽可能多地试玩游戏，这就不是一个适合解谜类游戏获得深入、思考性测试反馈的场景。

第三，即便挑选出了有用的建议，也不可能全部采纳——所以要学会选择真正亟需改动的部分！

看似妥协的调整，其实对一款游戏来说可能是进化。举个例子，下图是《冲啊小土璇！》在一次重大更新前后的对比。右侧版本中，可互动物体被高亮显示。我个人非常喜欢“大家来找茬”类的游戏和复古 RPG，会乐此不疲地探索每一个角落，因此我们之前的版本几乎没有什么关于谜题的视觉提示。

但在测试过程中，几乎所有玩家都提出了抱怨，甚至我们的程序员也表示需要一些高亮提示——因为就连他在调试时都会偶尔因为记不起线索而无法顺利解谜。于是我加入了高亮提示，并进一步调整了不可互动物体的颜色，使线索更清晰。这自然能让更多玩家感到满意，但也要记住——你不可能让所有人都满意，尤其是在时间和资源有限的情况下。

不过，你可以利用游戏叙事、机制或关卡设计来弥补资源有限的问题。比如在《一个人的火锅局》中，团队没有时间制作宿舍以外的场景，但“独自在家”的故事设定让这一限制显得自然、合理。

另外，不必过于担心诸如“画风太像草稿”的批评。以下图片来自《一个人的火锅局》的早期 Demo——其中的手绘图像和简单菜单只是作为临时展示用的占位符而已。在 Demo 阶段，使用低保真的美术是对的，因为早期开发的重点应当放在核心玩法上。

结语

今天就这里！我想鼓励每一个独立团队——包括我自己——在开发过程中都要享受乐趣。即便某个项目最终未必成功，你也会在过程中获得经验，这也许就能成为下一个项目的灵感。