为什么我的游戏在长路线测试里每分钟卡一下？

规律性正是这次卡顿有意思的地方，也是它容易被误读的地方。较长测试路线上大约每分钟一次的卡顿，看起来不像某个沉重的单个资源或一次性的尖峰，而像某个按周期运行的东西，日志说团队最初也是顺着这个判断追下去的。同一轮开发还在让飞船更像一个玩家真正身处其中的地方，而不只是一台相机穿过房间：第一人称下可见的腿、手与影子、过肩第三人称视角、行走、奔跑、坐下与站立各自不同的表现，以及与移动结合得更紧密的脚步声。驾驶舱围绕坐姿视点重建，有可操作的开关、放在操纵装置上的手和更清晰的飞行 HUD，较新的检查点还加入了按形状区分空间站、舰船、岩石与行星的全息雷达，带基础的目标锁定与导航控制。这些背景都不能证明卡顿的原因；它之所以重要，是因为它说明了追查卡顿时周围正在改什么，也因为身体的意义正在于让尺度可读：机库、驾驶舱座椅与周围的机械，应该由站在其中的身体来衬托出大小。

这个案例最诚实的部分，是那个没有落地的修复。早期追踪指向定时着色器缓存清理，这与每分钟一次的形态吻合得很好，很容易让人接受：周期性的清理、周期性的卡顿，一个干净利落的故事。但关掉这个周期会导致内存泄漏，于是改动被撤回。这句话值得比平时更多的注意，因为它区分了“找到了嫌疑对象”的团队和“查了拿掉嫌疑对象要付出什么代价”的团队。泄漏不是更安静的卡顿，而是一种随游戏运行不断增长的代价；接受它，等于用一个可见的、有规律的问题换一个更慢、更不易察觉的问题。最终落地的修复走了另一个方向：改了 HUD 线条渲染，并恢复了引擎默认值。日志没有超出这句描述去展开 HUD 改动的更深层机制，本文也不编造，并且不会把 HUD 改动说成比日志所呈现的更确凿的根本原因。日志报告的，是这次改动、 先前改动的撤回，以及随后的耐久测试结果。

日志给出的证明很窄，而且是日志自己先把这一点说出来，而不是留给读者去发现。最终报告记录：同一台开发电脑上 32.6 分钟的耐久测试里，没有一帧超过 33 毫秒。要按字面读这句话：同一台机器、一个构建、一次长跑、33 毫秒的帧时间门槛。这是一次真实的测量，而 32.6 分钟也足够长——如果卡顿仍以原来的频率在这台机器上出现，早就该出现很多次了。但它不是关于其他硬件、其他驱动或其他路线的结论，日志也明确说结果仍需上手审核并在其他硬件上测试。日志列出的近期优先事项也指向同一个方向：打包并审核较新的驾驶舱改动、继续测量性能、通过上手试玩来评判身体、雷达与飞行控制。一组干净的耐久数字只是这条路上的一个检查点，不是终点。

范围纪律是这篇日志的另一半，即使你永远不碰 HUD 线条也值得照搬。这篇日志没有宣布公开构建，而且按作者自己的表述，把“已尝试的”“原型里已起作用的”与“仍需证明的”分开讲。环境、经济数值与表现仍是原型素材。全息雷达仍处于开发验证阶段，而不是已打包的实测结果，尽管它的设计意图说得很明白：玩家应该能在船舱内读懂附近的空间，而不让驾驶舱变成装饰性的覆盖层。AI 辅助的披露也属于同样的纪律。日志说创意方向、审核与最终决定仍由作者掌握，本文原样重复这一说法，既不淡化，也不把它当作对作品的评判。这样读者才能按其本来面目来权衡一个原型结果：开发者在自己的机器上给出的报告，数字旁边就印着限度。

下面的步骤不是 Interstice Foundry 在已述步骤之外做过的事，而是把这些步骤推广到你自己项目的清单。能复用的思路是一串顺序，而不是单个花招：先注意到周期，再一次只测一个嫌疑对象，然后检查测试本身付出了什么代价。周期性卡顿会引出周期性嫌疑对象，但看起来对的嫌疑对象还不是修复，而一个引入不断增长代价的修复只是交易，不是解法。恢复默认值也是一种正当的修复，不是认输：一个必须靠忍受泄漏来辩护的自定义周期，可能还不如它取代的默认值值钱。而一台机器上的长跑只是证明的开始，不是证明本身：跑得要够长，长到如果旧卡顿还在就一定会反复出现；要在同一台机器上重复，证明不是一次运气好的跑法；然后还要在其他硬件上站得住，才能说卡顿修好了。