我是白天的软件工程师。自七月以来，我在业余时间制作 Gopher It，一款第一人称游戏，你是办公室实习生：同事叫你过去，你去拿他们需要的东西并完成任务，通常是咖啡、复印件或生日卡，在办公室里传递。
单人或在线最多 4 名玩家，使用 Godot 制作。AI 代理编写了所有代码，我负责设计、搭建并迭代工作流程，并审阅决定。
AI 让开头非常快。最后 20% 的时间花在了大量的细微调整、反复试玩上，持续了几个月。

工作流

除了通用的代理开发工具（工作树、使用 GitHub 问题作为跟踪并分派子代理工作、代理测试游戏等），我认为最有帮助的三件事是：

  1. 从第一天起，我做的每个设计决定都会写入带日期的 DECISIONS.md 文件。现在已有 400 多条。代理在修改游戏玩法前会先阅读它，因此不会回退我两个月前做的决定。它们不得在未经我同意的情况下覆盖任何决定。最初包括游戏类型、风格、整体设定，后来发展到更细节的内容，例如“点击对话气泡的最后一页会使其消失，即使该同事也在呼唤你”。

  2. 尽可能使用系统测试，而不是过度拟合的单元测试（见下一节）。

  3. 每次会话结束后，准备包含更改内容和前后对比截图的 artifact，供我审阅并验证或否定代理所做的决定或对我的指令的解读。

测试

  • 合作：每个任务都有头less测试，模拟主机+客户端进行游戏，并检查两者最终状态一致。

  • 全流程：机器人会模拟整个游戏日，因此在第5天出现的错误会在到达前就被发现。

  • 碰撞：调试视图会绘制所有碰撞框。发现桌子旁的一个不可见框阻止了行走。

  • 门ways：每个门都在两侧和墙体内部有一个明确的碰撞框，框内的任何东西都会导致碰撞或仅可见网格（装饰没有碰撞，这导致书架阻塞了门）。还会检查两名玩家能否在任何门道中相互通过。

  • 卡住的点：两个物体之间不能正好留下等于玩家宽度的间隙。

  • 可达性：所有可点击的对象必须能够从玩家实际能站立的位置被点击。

  • 坐姿同事：双腿不能穿过桌子或椅子。

  • 墙面物品：时钟和看板始终面向房间内部。

  • 隐藏文本：没有标签或牌子在墙内或被遮挡，导致无法阅读。

  • 真实点击：无头 Godot 不会向菜单发送鼠标点击，因此窗口化测试会真实点击每个按钮。

  • 手柄：所有菜单仅使用手柄进行。

  • 翻译：任何未翻译的字符串会导致构建失败，且会检查文本在纸张、牌子或按钮上是否合适，涵盖全部 17 种语言。

  • Z-撕裂：渲染测试会在玩家看到之前发现闪烁的表面。演示视频：https://youtube.com/shorts/VbAwHNMBc-o

它不替代我亲自玩游戏，但能在出现之前捕捉大多数愚蠢的问题（在提出 5 次后，我感到厌倦并制定了更好的测试）。

Gopher It 在 Steam 上

你使用哪些检查让你的代理能够发现自己的错误？