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 工具。
这个功能可以将关卡的字符串描述直接转化为彩色可视化地图，一目了然地展示地形布局。
但仅止于查看远远不够，我又塞入了编辑模式：可以直接在地图网格上自由修改区域材质，即时生成新的关卡数据，并一键导出地图数组或字符串。这样一来，后续向游戏中添加新关卡就变得异常灵活。
既然做到了可视化编辑，何不再进一步？我继续集成了一项图片转地图的功能：只需将一张图片拖曳到编辑区域，它便能自动解析颜色并生成对应关卡。
生成后稍作微调，就能得到一个极具创意的新关卡。目前这个编辑器主要供自己使用，后续我会把它开放出来，让大家也能随意自制专属地图。