AI 把 1993 年游戏搬进 Godot，最难保留的不是代码而是手感

作者：林岚｜OC 开发者生态编辑

据《Babylonian Twins》作者发表的移植复盘，他借助 Claude Code，将自己在 1993 年编写的 Amiga 游戏及后来的移动版搬进 Godot 4。原作诞生于巴格达，一台只有 512KB 内存、没有硬盘的 Amiga 500 上；三十多年后，AI 帮助恢复工具链、解析数据并重写行为。故事很容易被概括成“一晚上移植数万行代码”，但作者列出的错误，比速度更有参考价值。

一句话结论：AI 可以显著加快旧软件迁移，但“能编译、能运行、玩起来还是原作”需要三套不同证据。

旧代码不是完整说明书

这次工作包含约 3.4 万行 C++ 移动版和 72,758 行、分布在 26 个文件中的 68000 汇编原版。作者表示，Agent 自己搭建和运行工具，完成大量转换；他负责提出要求、试玩、解释历史选择和决定哪些变化可以接受。这不是无人干预的一键迁移，也不是经过统一条件比较的模型基准测试。

源码保留下来，并不意味着设计意图完整保留下来。一个常量可能补偿旧设备的输入特征，一段看似多余的检查可能防止两个对象覆盖同一块地图。把代码“整理得更现代”，有时正是在删除原作赖以成立的条件。

作者举出的帧率问题很具体：旧 Amiga 版和后来的移动版分别围绕 50Hz 与 60Hz 调整。每帧相乘的摩擦系数，在不同更新频率下会产生不同减速效果。程序不会因此崩溃，但动作会改变。迁移系统保留两套时钟，比强行统一参数更接近保存原有行为。

测试接口，可能比生成代码更有长期价值

这次移植加入了直接载入关卡、设置人物位置、逐帧驱动输入和导出状态的命令行入口。原来只能说“这个跳跃不对”，现在至少有一部分可以转成可重复执行的场景。编译检查、关卡构建、截图和状态输出，也让失败更容易定位。

这类能力的价值不止服务于 AI。一个项目如果只能靠开发者手工走到第三关才能重现错误，任何维护者都会付出高成本。把操作变成可复现的测试路径，是移植过程中留下的基础设施，而不是一次性的提示词技巧。

作者报告，五张关卡地图在处理天空和水面效果后，与参考图实现逐像素一致。但地图一致不能证明碰撞、输入和敌人逻辑也一致。现代移植版的截图仍由人检查，手感也没有被自动测试完整覆盖。不同验证结果应该分别记账，不能把其中一项成功扩大成整个游戏完全等价。

一个守卫能隔着十三格石头打中玩家

复盘里最典型的错误是范围检查遗漏：移植保留了一侧边界，却漏掉另一侧，导致守卫能够攻击远在下方、隔着地形的角色。另一些问题来自输入事件与持续轮询的语义差异。物理常量看起来正确，操作结果仍然不对。

这说明读代码只是证据来源之一。测试者对原版的记忆、老玩家的评价和实际操作，都可能提供源码中难以直接看出的条件。作者与儿子持续试玩，也说明人的角色并没有因为代码生成变快而消失，只是从逐行搬运转向判断行为是否值得保留。

还有一个需要保留的不确定点：作者明确表示，模型对部分二进制差异的解释，他没有亲自核验。因此不能把这份复盘写成“所有旧二进制均已完全复现”。承认局部证据不足，比替一个精彩故事补上不存在的严密结论更重要。

关键事实

• 复盘来自原作者，属于具体项目经验，不是可直接推广的效率基准。
• Agent 处理代码、数据和工具链；作者参与试玩、取舍与发布确认。
• 地图像素对照、构建通过和行为一致，分别覆盖不同层面的质量。
• 移动版已上线，Steam 有免费演示版，完整 Steam 版仍计划于秋季推出。

OC 判断

AI 对旧软件保存的贡献，可能不只是降低重写成本，而是把散落的代码、二进制和人的记忆重新组织成可验证的系统。真正值得复制的方法，是保留原始材料、建立比较基准、暴露测试入口，并让人处理没有明确答案的历史语义。那些“奇怪但能用”的行为，往往正是作品的一部分。

为什么重要

• 对独立开发者：迁移可以更快，但验收预算不应随编码时间一起被砍掉。
• 对维护者：可复现的操作入口能长期降低调试成本。
• 对玩家：保存一个游戏，既要保存画面，也要保存它如何响应人的动作。

参考来源

• Babylonian Twins：把 1993 年 Amiga 游戏移植到 Godot 的作者复盘