最近忙着修 bug，打印了十来页，这些 bug 一半是小潘帮忙测试，一半是拾点科技的功劳。

小潘是在核聚变认识的玩家，他是《师傅》的速通世界纪录保持者。认识小潘是因为他在现场给我演示了 CATO 的操作邪道，至今我都感到不可思议。

不得不说速通玩家对帧率的敏感是天赋，所以我请小潘帮忙内测游戏。在合作过程我不得不在帧层面观察 CATO 的物理行为，在他帮助下我把 CATO 的鲁棒性提升了一个等级。

有时一些 bug 我已经无法从代码逻辑层面入手 debug，而是让小潘通过多个帧率、多个 case 来观测现象，以此推理出 bug 的来源，这个探案过程真的非常有趣（但这些都是我写的代码😂）。

我觉得 bug 就是一种代码复杂度的涌现，而当运气好的时候，bug 就会变成 feature。CATO 的邪道就是这么来的，这绝对不是我有意设计。仔细想想除了因为我太爱 2D 平台游戏，无意识地给这个角色控制器做一些没必要的手感细节，还因为 CATO 的操控确实不常见：可以无限跳、可以分离角色，光是这两点就足以涌现新的可能性。

拾点科技是机核请来的 QA 团队，最近这波帮我们交叉验证了五十来个 bug。团队的流程专业严谨，通过文档我就能很快定位 bug，排序工作优先级。感恩。

在修 bug 过程中，我发现了几个技巧：

- 高帧率和低帧率很容易测出 bug，所以需要一个便捷的方式切换帧率，快速测试同一个 case。

- 我在 Unity Editor 工具栏写了一个帧率按钮，一键循环切换 15、30、60、120FPS。

- 在 debug console 写了帧率作弊指令，QA 团队也能使用。

- 平台跳跃框架 Corgie Engine 无法承受高帧率，帧率超 120 FPS 就会出现奇怪的 bug，建议锁 120 FPS。

- 写一个 Slow motion 按钮，可以长按快捷键把游戏放慢到 10%，方便观察发生得过快的物理现象。而且这在预告片素材录制上也帮了大忙。

物理模拟项目真的很锻炼能力，代码没法像 gamejam 时候一样「能用就行」，所以现在锻炼得严谨了不少。少了一些能力焦虑，少了一些过度预判，我也越来越愿意走出舒适区挑战更高复杂度的东西。感觉物理模拟已经变成我的技能，后面新项目要想办法发挥优势。感谢 QA 朋友们的帮助使我进步🙏。