AI还原3D坦克大战再进化:原版地图与子弹逻辑完美复刻,外加自制关卡编辑器
在上一篇文章中,我们借由 Claude、Fable 与 Codex 的协作,成功让经典游戏《坦克大战》以 3D 形态重生,且网页版与桌面版均已同步发布。但玩过之后总觉得仍有些许遗憾——不妨先用 AI 生成的 2D 参考图做个对比。
这是 AI 绘制的结果:

为了精准对照,我特地找来模拟器,加载《坦克大战》的 NES 原版 ROM,截取了原始画面的第一关:

两相比较立刻能看出:地图布局存在差异,更关键的是消墙逻辑也不一致。原版中攻击基地砖墙需要两发子弹才能摧毁一块,而我的 3D 版却是一枪就击碎,导致大本营极易失守,难度无形中提高了一大截。
这两个问题即使不做调整,游戏的乐趣已经足够。但我还是希望再逼自己一把,让复刻更趋完美。于是今天的目标就定为:精准还原第一关地图、修正射击破坏效果,以及额外制作一个地图编辑功能。

为落地这三大功能,我又投入了整整一天。细节调整最磨人,却也沉淀出大量宝贵的思路与实战经验。游戏成品与体验网址会附在文末,先来回顾修改历程。
一、地图还原:在 26×26 网格上死磕每一个坐标
让 AI 理解我的地图修改需求,是整个过程里最耗神的环节。起初我希望用几句简单描述就完成复原,事实证明这简直难如登天。我先给到一张游戏截图和原版平面图,让 AI 照着还原:

我期望的目标效果大概是这个样子:

它看上去像是理解了,可实际返回的结果仍然差强人意。

地图的确发生了变化,但细节错漏不少。于是我尝试用画红框的方式一步步标注修改区域,结果不仅没有纠正,反而越改越离谱。平时 Opus 4.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..... ← 中央两块孤立小砖
row6 ss.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 视角下坐标难以对齐,调整了一轮才让网格与场景完美贴合。随后我可以直接说出某个编号的修改指令,AI 终于能准确执行了。这张满屏坐标的截图庞大得令人眼花,单张文件就达 6 MB,压缩后依然有 2 MB,信息密度可见一斑。
二、射击破坏效果优化:从 26×26 到引入 2×2 子块遮罩
攻克了地图,马上转向第二个问题——子弹对砖墙的破坏效果。

经过观察,原版的大本营砖墙厚度实际是正常砖块的一半,每次子弹命中也只消耗四分之一厚度的砖体。而我们之前的逻辑是直接打掉整个方块的一半,导致基地的防御力骤降,与原版体验差异明显。为了让逻辑一致,我希望能将整个模拟系统再升一级,从 26×26 的网格进一步细化到 52×52。这意味着复杂度再次指数级上升。
如何把这么精细的需求清楚传达给 Opus 4.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 改动范围小,对性能影响也低。尽管它自己标注“中等偏大难度”,我仍然决定推进——因为这个问题非解决不可。按经验,没有意外的话,它应该能搞定。
然而,“没有意外”往往意味着意外就藏在后头。

子弹威力调整好了,破坏效果也符合预期,但炮弹居然在墙上打出了一个“坑”——坦克纵向对着一堵单格墙射击后,缺掉的不是四分之一,而是直接穿出一个坦克宽的豁口。这让我怎么通过?我该如何向它描述:破坏力度是每击打掉四分之一墙块,但是当坦克正对砖墙的正面时,破坏宽度是一整格,而一旦坦克偏移一点角度,造成的破坏就可能变成半格……这种依靠自然语言传达细微物理逻辑的体验,恰恰是编程中最难的部分。

好在 Opus 4.8 又一次精准理解了我的意图,经过一轮校准,终于达到了理想效果。自此,第一关地图和子弹伤害逻辑已高度还原原版《坦克大战》,额外的关卡地面则完全交给性能最强的 Fable 动态生成。目前我只体验到了第 10 关,完整 35 关的后续内容对我仍是未知地带。
三、独立地图编辑器:从查看到一键图片转关卡
为了彻底摸清每个关卡的全貌,并能够可视化地进行调整,我又动手打造了一个独立的 Map 工具。

这个功能可以将关卡的字符串描述直接转化为彩色可视化地图,一目了然地展示地形布局。
但仅止于查看远远不够,我又塞入了编辑模式:可以直接在地图网格上自由修改区域材质,即时生成新的关卡数据,并一键导出地图数组或字符串。这样一来,后续向游戏中添加新关卡就变得异常灵活。
既然做到了可视化编辑,何不再进一步?我继续集成了一项图片转地图的功能:只需将一张图片拖曳到编辑区域,它便能自动解析颜色并生成对应关卡。

生成后稍作微调,就能得到一个极具创意的新关卡。目前这个编辑器主要供自己使用,后续我会把它开放出来,让大家也能随意自制专属地图。