与塔啦啦携手：没有编辑器的关卡编辑

精华03/30153 浏览开发交流包含 AI 合成内容

做《觅光》的时候我遇到了一个很现实的问题：游戏需要多个关卡，但taptap制造只有对话框，没有没有TiledMap 之类的手动关卡编辑器，怎么办呢？后来我摸索出了一套"文档驱动"的关卡制作流程——我在 Markdown 文件里画 ASCII 网格当地图，写个表格摆放火把、敌人、钥匙，然后让 AI 把这些文档转成游戏能跑的代码。改关卡的时候也不用碰代码，直接说"把第三关的torch_01 移到 (25, 8)"就行。靠这套流程，我做完了《觅光》的 11 个关卡。

先简单说下背景吧，顺便给自己打个广告 [表情_猫咪举手]

。《觅光》是一款 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)"比在代码里找到对应行改数字快十倍）

有问题欢迎交流！也欢迎试玩我的《觅光》！

#聚光灯游戏开发心得接力

TapTap 制造应用

9.8

前往论坛