为什么我的网页版游戏只有在玩家不断合成之后才会崩溃？

游戏开发里最危险的测试结果，就是只在一台机器上通过的那种，而这篇日志正是为什么危险的一个简洁例子。Rock Paper Overkill 是一款 roguelite 构筑游戏，讲的是把床底下的日常物品合成为连招，而合成在其中不是支线活动。游戏页面描述为“什么都能合成”，有 241 张合成卡可收集，试玩版包含完整的第一幕，大约 90 分钟的游玩时间。一款核心循环就是合成的游戏，会被每一个上手的玩家一次又一次地合成。在作者的 Mac 上，这个循环跑得好好的；上传到网页版并实测时，却崩了几次。日志没有给出崩溃次数，也没有浏览器或设备清单，本文不会把它包装成一个测得的故障率。实测里几次崩溃就已经够重要了，因为崩溃不是一次本来不错的会话上的瑕疵，它会终结这次会话。

作者报告的模式，即使没有内部机制，也已经缩小了搜索范围。以前合成越多，内存泄漏就越多，于是应对办法是把卡牌与合成的整个绘制方式重做。这句话同时做了两件事。第一，它把泄漏与玩家会反复做的动作绑在一起，意味着泄漏应该随游玩而增长，而不是在某个固定时刻出现；而只玩一小会儿的测试可能永远看不到它。第二，它把修复范围限定在卡牌与合成的绘制上，而不是整款游戏——即使细节没有公开，这也是一种有用的纪律：去改泄漏动作所经过的那条路径，而不是同时到处乱找。本文不会去补上缺失的中间环节。日志没有说对象释放不正确、没有说缺少对象池、也没有说某种特定结构在累积，所以这些解释无论对 Godot 开发者听起来多么熟悉，都不会出现在这里。

随合成而增长的泄漏有一种可以测试的形态，而这种形态是这个单薄案例里最容易带走的部分。如果泄漏确实随合成累积而增长，那么短会话与长会话看起来应该不同，合成少的会话与合成多的会话看起来也应该不同；而一个只对短会话有帮助的修复，根本没有触及所报告的模式。作者的报告是：重做已经解决了问题，游戏现在应该很流畅，并邀请玩家报告任何问题。这句邀请比看起来更重要：对于一款故障只在上传与实测之后才出现的网页版游戏，下一轮证据将来自作者所没有的机器与浏览器上的玩家，而作者恰恰为这种证据留了门。在这样的报告到来之前，诚实的状态就是作者的状态：已修复、应该流畅，并等待着只有发布才能提供的更广泛的测试。

这个故事里的网页版部分值得单独强调，因为它正是修复之后最容易被遗忘的部分。在开发者的 Mac 上跑得好的游戏，只通过了一个环境，而不是玩家将要使用的环境；而网页版游玩带来了桌面测试从未触及的约束：玩家实际加载的构建、浏览器在长会话里的内存表现，以及只有反复执行核心动作才会产生的累积。这次更新的文件就是一个网页版构建，游戏页面还说玩家进度保存在浏览器里，这让一次会话中途的崩溃不只是烦人：它打断了一次玩家预期会存续的会话。这些都不会把这篇单薄的日志变成一份厚重的技术复盘。它没有数字、没有机制、没有测量，本文也没有编造其中任何一项。它提供的是一种干净而小巧的模式：桌面端正常、网页版崩溃、泄漏随合成增长、绘制被重做、作者报告已流畅、并邀请报告。

下面的步骤不是 frostyshotss 在已述重做之外做过的事；这份清单是给读者自己项目的通用网页版测试做法，不是作者的步骤，并且始终停留在这个定位里。能复用的思路是：用玩家实际会加载的构建、按玩家实际会玩的时长、按玩家实际会做的频率去做核心动作，来测试。桌面端通过不等于网页版通过，短测试通过不等于长测试通过；而一个修复，也不能靠“在当初就没发现问题的同一段短测试里不再崩溃”来证明。如果问题随重复动作而增长，那么证明修复的测试就必须把这个动作重复到超出旧问题曾经出现的位置，而结案的报告应该说明测试跑了多久、在什么上面跑、跑的时候观察了什么。