AI技术还原经典坦克大战并3D化升级

上一篇文章提到，借助 Claude Fable 与 Codex 的强大能力，经典游戏《坦克大战》被成功移植到 3D 世界——网页版与桌面版都能流畅运行，整体效果也颇为逼真。

不过说实话，玩了若干局之后，还是发现了一些值得改进的细节。拿 Fable 自动生成的 2D 版本来对比，问题立刻就变得明显了。

这是 AI 生成的图片：

为了进行公平对比，我还专门启动了模拟器，将《坦克大战》NES 原版调了出来。

截取原版地图后，效果如下：

一对比，两个核心硬伤随即暴露：地图布局与原始版本完全不一致，而且子弹对砖墙的破坏逻辑也存在差异。

具体来说，原版中靠近基地的砖墙需要两发子弹才能摧毁一整块；而在我的版本中，一枪就彻底碎裂。结果导致自家大本营脆弱得像纸一样，游戏整体难度被大幅提升。

坦白讲，这两点不修改，游戏依然可以正常游玩，也能带来快乐。但既然已有良好的基础，何不再进一步，让体验更趋完美？

因此，今天的任务分为三个部分：第一，将第一关的地图布局完全还原至原版；第二，修正砖墙的破坏逻辑；第三，顺手打造一个地图编辑器。

这三项功能完成后，又投入了整整一天的时间。细节调整虽然费时费力，但最终的打磨过程积累了非常宝贵的实战经验。

游戏链接与在线试玩地址放在文末，先详细回顾一下改动的过程。

1、修改地图

修改地图这件事，最大的难点其实只有一个——如何让 AI 准确理解你的意图。

一开始我想得很简单：给它一张游戏截图、一份原版平面图，它自己应该能搞定吧？事实证明，这件事远比想象中复杂。

需求大致是这样描述的：

它的回复看起来理解了，但实际结果却仍有不小差距。

地图确实有改动，但细节差得很远。我又尝试用画红框的方式让它定点修改，结果却越来越偏离预期。

Opus4.8 平时修改网页表现强劲，但面对这张 3D 地图，它似乎完全困惑了。来回折腾了几次，5 小时的配额直接耗尽——这条路走不通。

不过遇到障碍就换个思路。我让它先别着急改图，而是帮我分析一下地图的底层结构。

原来地图是通过这种网格字符串表达的：

row0.............row1.b.b.b.b.b.b.row2.b.b.b.b.b.b.row3.b.b.bsb.b.b.← 中央 2×2 钢，上方留凹槽入口row4.b.b.b.b.b.b.row5.....b.b.....← 中央两块孤立小砖row6ss.bbb.bbb.ss← 左右边墙嵌钢 + 中部横墙row7.............row8.b.b.bbb.b.b.← 下半柱 + 中央 H 横梁row9.b.b.b.b.b.b.row10.b.b.b.b.b.b.row11......b......← 基地正上方引导墙row12.............← 基地及护墙由 ringTiles 生成

默认地图是 13×13 的网格。原版第一关中一半是钢板一半是砖墙，为还原这一格局，直接升级到 26×26 网格。复杂度瞬间翻了数倍。

既然已经是网格，那必然具备坐标。于是让 Opus 把所有坐标都标注在地图上，按坐标精准定位修改。

光是让这个 3D 视图与坐标完美对齐就花了不少时间——第一次因为 3D 透视未校准，坐标标注全部偏移。调整修正后，终于实现完美贴合。

接着我对整个坐标系统下发指令，告诉它「把第某号格改成什么」。这一下，终于做到了指哪打哪。

不过这张坐标图信息量实在太大，截图出来约 6 MB，压缩后还有 2 MB。看得久了眼睛都酸痛。

2、优化射击效果

地图问题解决后，接下来处理第二个核心缺陷。

在原版中我仔细观察过：大本营附近的砖墙厚度大约是普通砖块的一半，每发子弹消耗的是“一半的一半”——也就是说，一枪只能打掉四分之一，需要四枪才能完全摧毁一整块墙。

但我们的版本完全不是这个逻辑——一枪直接啃掉一半，基地砖墙只能扛一枪，与原版差距很大。

要修复这个问题，必须将整个系统再升级一层：从 26×26 一路扩到 52×52，复杂度呈现指数级增长。

更麻烦的是，如何把这个需求准确传达给 Opus4.8。

我试探性地问了一下可行性：

它分析完直接列出了需要修改的地方，并给出了两个方案：

两种实现思路：​方案A：只给砖加 2×2 子块 mask（推荐） — 只有 BRICK 引入子块，钢/水/树/冰/空仍整格（原版钢板也是整块炸）。改动集中在 4 个函数 + 一个子块数据结构，范围可控，性能可接受。​方案B：把整个 map 升到 52×52 — 概念上最简单（N=26→52、TILE=16→8，一切天然半格），但渲染 cube 数 ×4（最多 2704 个）、很多硬编码坐标（护墙 ringTiles、BASE、出生点、各种 clearTiles）都要重算，性能和风险都更高。复杂度结论：属于中等偏大的改动，不是小修小补，但范围可控——核心难点就是让「子块状态」在破坏、碰撞、渲染三处保持一致。推荐方案A（砖块 mask），1 次专注重构能做完，且不碰地图数据格式和编辑器。​要做的话告诉我，我按方案A来。​

坦白说，我对 3D 游戏底层架构并不十分熟悉，它提到的概念也并非全部理解。但方案A显然是更优选择——改动范围小、不影响帧率、且不破坏现有地图编辑与渲染逻辑。

我决定就按它的方案推进。不过心里多少还是有点忐忑——毕竟它自己也说这是“中等偏大”的改动难度，而我又不是什么游戏引擎专家。

但这个问题不解决不行，就算硬着头皮也得做下去。

然后，经典的一幕出现了：没有意外，必然会发生意外。

修改完成后，射击的破坏力度确实对了。但是——墙上直接被打出了一个坑。

这就尴尬了：坦克要怎么在上面移动？

我该怎么向它表达「射击力度是摧毁四分之一，但坦克垂直的那一面宽度为一单位；如果坦克稍微偏移位置，那就应该摧毁二分之一」？

自然语言编程最大的难点就在这儿——你根本不知道该如何精准描述你想要的细节。

好在这回 Opus4.8 理解了。

最终调整完毕后，效果基本上完美了。

《坦克大战》第一关的地图布局和子弹伤害逻辑，已经高度还原。

至于后面的关卡——目前全部由最强的 Fable 自动生成。我仅刷到第 10 关，设定里总共有 35 关。后面的关卡长什么样，我也还一无所知。

3、地图编辑

为了弄清楚每个关卡的具体结构，并能够可视化编辑它们，我干脆又做了一个 Map 功能。

这个功能能够将关卡的字符串数据直接转换成可视化的图片。

光看还不够，我顺便把编辑功能也加了进去。可以直接在地图上点选修改、增删砖块和钢板，修改完成后一键导出为地图数组或字符串。

这样一来，以后要更新游戏的地图就方便太多了。

既然都已经实现可视化编辑，那干脆再加一个「图片转地图」的功能吧。

把任意关卡的截图拖进去，系统会自动生成对应的地图。

生成后稍微手动调整一下，就是一个全新的、富有挑战性的关卡。

这个功能目前还以自用为主，稍后会分享出来，让大家都能自己编辑地图。毕竟地图编辑器的存在，才能让游戏真正的生命力彻底释放出来。