与塔啦啦携手：没有编辑器的关卡编辑
精华03/31100 浏览开发心得 包含 AI 合成内容
做《觅光》的时候我遇到了一个很现实的问题：游戏需要多个关卡，但taptap制造只有对话框，没有没有TiledMap 之类的手动关卡编辑器，怎么办呢？后来我摸索出了一套"文档驱动"的关卡制作流程——我在 Markdown 文件里画 ASCII 网格当地图，写个表格摆放火把、敌人、钥匙，然后让 AI 把这些文档转成游戏能跑的代码。改关卡的时候也不用碰代码，直接说"把第三关的torch_01 移到 (25, 8)"就行。靠这套流程，我做完了《觅光》的 11 个关卡。
先简单说下背景吧，顺便给自己打个广告![[表情_猫咪举手]](https://img-tc.tapimg.com/market/images/a3c0b426c5410082eae426404982cc0e.png)
。《觅光》是一款 2D 平台解谜游戏，玩家在黑暗洞穴里靠火把生存，核心玩法是点亮火把、在火把之间穿梭、收集钥匙开门通关。
。《觅光》是一款 2D 平台解谜游戏，玩家在黑暗洞穴里靠火把生存，核心玩法是点亮火把、在火把之间穿梭、收集钥匙开门通关。而作为基于瓦片地图框架的2D游戏，每个关卡本质上就两样东西：
- 一张瓦片地图——哪里是地面、哪里是平台、哪里是空气
- 一堆实体——玩家出生点在哪、火把放哪、敌人在哪巡逻、钥匙和门的位置
如果纯靠自然语言和图片描述让塔啦啦理解我的关卡设计，那效率太低了，而且不够精准。
核心思路：一个关卡，三种文件
我的做法是让AI对每个关卡同时维护三种文件形态，各有分工：
level_protocol_*.md — 这是关卡的"存档"，用 JSON 格式记录精确、完整的数据，主要用于存档和备份。它可以转换成可视化的 edit 文件，也能从 edit 文件反向生成。
level_edit_*.md — 这是我日常编辑关卡的入口，包含 ASCII 可视化网格和实体坐标表格，让人一眼就能看出地图长什么样。它可以从 protocol 文件生成，也能转换成游戏运行的代码。
levels.lua — 这是游戏实际运行时引擎直接读取的代码，由 AI 从 protocol 或 edit 文件生成。
这三种文件之间可以随时互相转换。我改了 edit 文件，就让 AI 同步到 levels.lua；如果在代码里直接改了数据，也可以让 AI 重新导出 edit 文件。level_protocol_*.md作为改坏了的存档点。
地图怎么表示：一个字符一格瓦片
觅光的地形非常简单，只有四种瓦片：
- 0 代表空气，无碰撞，玩家可以自由穿过。
- 1 代表实体方块，包括地面和墙壁，有碰撞，玩家无法穿过。
- 2 代表木质平台，有碰撞，玩家可以站在上面，通常用于跳跃平台或浮空地形。
- 3 代表装饰块，无碰撞，纯视觉效果，不影响玩家移动，用于丰富场景细节。
所以一个关卡的地形就是一个字符串数组，每行字符串代表一行瓦片，肉眼就能看出地图结构。经过处理以后的地形数据长这样：
markdown文件可预览效果
level_edit 文件：我的"可视化编辑器"
光看数字可能还是不够不太直观，所以我让 AI 生成了带坐标标尺的可视化版本。这就是 level_edit
文件，它长这样：
markdown文件可预览效果
下面跟一个实体表格：
markdown文件可预览效果
第一步：用自然语言或者字符串表格描述基础设计
你可以自己先在脑内构思好，甚至在像画图一样把关卡用约定好的字符串画出来，直接把参考文件作为项目文档发给塔啦啦。或者使用模糊一点的描述：
右侧山体作为终点屏障，门置于山顶形成目标感；左侧开阔区域降低初始压迫感，出生点设于此引导玩家向右探索；中间平台层创造垂直移动节奏；两支火把形成接力关系，亮着的火把暗示安全路径；钥匙位置需要小幅绕行，增加一点探索感；底部深坑通道提供备选路线，敌人巡逻制造动态障碍。
描述的精细度可以灵活控制。模糊构思时，只需说明结构层次和核心挑战；明确想法时，再指定关键坐标。AI 会自主补足尺寸、地形细节和具体位置。总之，先构思关卡的大致内容——地形结构、起点终点、障碍与收集品——再让 AI 落实具体数据。
第二步：预览，发现问题
生成之后构建游戏，实际玩一遍。通常会发现一些问题：
- 这个平台跳不上去，太高了
- 钥匙太容易拿了，想藏得更隐蔽一点
- 这个火把的距离不对，不能很好的衔接上另一个火把
- 这段暗区太长了，LP 扛不住
第三步：微调——最高效的部分
这就是这套流程最舒服的地方了。微调的时候完全不需要碰代码，直接用自然语言说改什么就行。
移动一个实体：
"Level3 的 key_01 从 (15, 9) 移到 (8, 12)"
改地形：
"Level3 的 y=10 行，x=25 到 x=30 的实体块挖空改成空气"
增删实体：
"Level6 新增一支火把 torch05，放在 (15, 18)，初始状态灭"
"Level9 的 enemy02 删掉"
改参数：
"Level3 的 torch_02 改成初始点亮"
一次改多个：
Level8 做以下修改：
1. 地形：y=7, x=3~x=7 改成平台
2. 实体：torch03 移到 (25, 15)
3. 实体：新增 key04 在 (30, 8)
4. 实体：删除 enemy_02
AI 收到后直接改 levels.lua里对应关卡的数据，重新构建就能看到效果。
文档同步：代码和文档保持一致
改完关卡后，我会让 AI 把最新数据重新导出为文档：
"把 Level3 的最终版本重新导出为 level_edit 和 protocol 文件"
AI 读取 levels.lua里的数据，重新生成带坐标标尺的可视化网格和 JSON 协议文件。这样三种文件始终保持一致。
反过来也行。如果改动比较大，我也可以直接编辑 level_edit
文件——在 ASCII 网格里加几行实体、在表格里改坐标——然后告诉 AI：
"我修改了 leveleditlevel8.md，请读取它并更新 levels.lua"
甚至可以批量操作：
"把所有关卡（Level3 到 Level9）重新导出为 level_edit 文件"
从零到完成一关的完整流程
把上面说的串起来，做一个关卡的完整过程是这样的：
第一步：描述设计
"帮我做第三章，48×22，右边是山，门在山顶……"
↓
第二步：AI 生成三个文件
· level_protocol_level3.md (JSON 存档)
· level_edit_level3.md (可视化编辑视图)
· levels.lua 里的对应数据 (运行代码)
↓
第三步：构建 & 试玩
发现钥匙太好拿、深坑太窄……
↓
第四步：口头微调
"key_01 移到 (8, 12)；深坑通道拓宽到 x=22~x=31"
↓
第五步：再次构建 & 试玩
满意 → 进入下一关；不满意 → 重复第四步
↓
第六步：同步文档
"把 Level3 重新导出为 edit 和 protocol 文件"
实际做起来比写出来快得多。一个中等复杂度的关卡，只要自己提取构思好地图，用字符串从生成到最终定稿大概就是"说三句话 + 玩两遍"的事。
这套流程好在哪
回头看，这套"文档驱动"的做法有几个我很喜欢的点：
1. 零工具依赖
不需要 TiledMap、不需要 LDtk、不需要任何图形化编辑器。一个文本编辑器 + AI 就是全部工具链。Markdown 文件谁都能打开。
2. 改关卡不碰代码
最常用的微调方式就是说一句话："torch_01 移到 (25, 8)"。不用找代码、不用数数组索引、不用担心改错格式。
3. 设计意图和数据分离
我描述的是"右边有座山，门在山顶"这种设计语言，AI 负责翻译成具体的在我限制范围内的网格数据。我不需要关心每个格子是 0 还是 1。
4. 改动可追溯
三种文件形态互相备份。protocol 是精确的 JSON，edit 是人类可读的可视化，levels.lua 是运行时代码。任何一个出了问题，都可以从其他两个恢复。
5. 批量操作很高效
一句"所有关卡重新导出 edit 文件"就能批量同步。做完一轮大改之后刷新所有文档，很方便。
总结
回顾做觅光这 11 个关卡的过程，最大的感受是：关卡编辑器不一定是一个软件，它可以是一套约定好的文档格式 + 一个能理解这套格式的 AI。
这套流程的核心就三件事：
- 定义清楚数据协议（哪些字符代表什么瓦片、哪些字段代表什么实体）
- 让文档可视化（ASCII 网格 + 坐标标尺，一眼看出地图结构）
- 用自然语言驱动修改（"移到 (25, 8)"比在代码里找到对应行改数字快十倍）
有问题欢迎交流！也欢迎试玩我的《觅光》！
