编码智能体能不能按我们想要的玩法把游戏做出来？SWE-Game 用 247 项任务来回答。基准锚定 41 款可执行的 Godot 参考游戏，覆盖 13 类 2D 与 3D 玩法。五项任务类型分别是：根据简报开发、根据游戏设计文档实现、骨架补全、修复 83 个注入故障案例，以及 Godot 到 Unity 的移植。参考材料规定预期玩法；共享仪器化接口让评测方自有的驱动与探针执行动作、观察独立实现的游戏，从而把「做出来的游戏」和「参考想要的游戏」放到同一套观察接口上比较。
可执行检查，而不是只看视频
评测组合引擎状态检查、经认证的参考输入回放，以及智能体撰写的功能演示，分别评估机制正确性、已演示的可玩性，以及修复后的行为恢复与保持。呈现质量另用游戏专属的视觉语言量表打分，不与机制分混在一起。
在 100 款智能体做出的游戏上，针对人工标注行为，可执行检查的平衡准确率为 92.59%，基于视频的 VLM 裁判为 78.41%。量表视觉分与 200 段游戏片段人工评分的 Spearman 相关为 0.829。这说明：玩法对错更适合交给能跑、能回放的检查；视觉量表与人评相关不低，适合作为呈现侧的独立指标，但不宜单独充当机制判决。
构建任务的天花板仍在 60 分以下
六个模型中，Opus5 在全部五项任务类型上都取得最高总分。三项构建任务的最佳总分仍低于 100 分制的 60 分，其中 Brief-to-Game 为 50.38。对已审阅提交的分析指出，需求遗漏和玩法逻辑错误是主要实现问题。材料没有公布其余模型名称与分差，也没有给出修复、移植两项的具体分数，因此对排行只能读到「Opus5 五项全高」，对能力只能读到「最好的构建结果仍未过 60，从简报出发更接近 50」。
我的判断
SWE-Game 把游戏开发从「写出能编译的脚本」推进到「机制可被独立探针验证、行为可回放」的基准，评测协议比纯视频打分更硬，也更接近「我们想要的游戏」这件事本身。适用边界应写死：Godot 参考实现、给定五类任务、机制与呈现分开计分，不能外推到任意引擎或商业制作流程。局限同样具体——构建任务最佳仍低于 60 分，失败集中在漏需求和玩法逻辑，说明当前瓶颈更像规格落实与状态机，而不是画面。可执行检查明显高于视频裁判，也提醒后续工作不要用「看起来能玩」替代「机制检查通过」。在缺少其余模型细节时，不必把 Opus5 的领先解读成产品级结论。