“自研编辑器”这个词听起来像是一个大工程但真正做下去以后才发现难的不是“画地图”而是把“画地图”这件事拆成可以批量复用的系统。这次要分享的项目是我为了重画《火焰之纹章 暗黑龙与光之剑》初代全部 25 张地图自己写的一套瓦片地图编辑器。它不是游戏引擎也不是通用地图工具而是专门为“复刻/重绘 SRPG 场景”设计的轻量级编辑平台。核心特点可以简单概括为瓦片化地图编辑、图层自由管理、数据组织可复用、鼠标操作直观、支持批量导出地图快照并且整套流程只依赖浏览器和本地脚本就能完成。文章里我会按实际的开发顺序把需求拆解、数据模型、渲染交互、工作流、踩坑记录和工程化建议全部展开。如果你是做游戏工具链、了解瓦片编辑器、或者对 SRPG 地图重绘过程感兴趣的开发者这篇文章可以直接收藏。1. 核心能力速览能力项说明项目类型自研瓦片地图编辑器面向 SRPG 场景复刻输入数据原版地图截图/参考图、自定义瓦片集 PNG 或像素数据输出格式JSON 地图数据、PNG 缩略图、批量地图快照核心功能网格绘制、图层管理、瓦片刷子、选区填充、坐标校验前端运行环境浏览器端运行无需安装数据库或编译环境服务端依赖仅需本地静态文件服务和可选的数据导出脚本是否支持批量支持地图数据以可读 JSON 存储可脚本化批量导出是否支持接口不提供对外 API但所有数据接口都是文件级 JSON适合场景SRPG 地图复刻练习、瓦片编辑器原型、地图数据管理不适合场景商业游戏资产生产、在线协作编辑、自动生成地形需要强调一点整篇文章里的代码是通用实现思路不会绑定某一个特定框架。你可以用原生 JavaScript 实现也可以用 Vue、React 或者 Python 的 PySide 快速验证。项目里最难的不是界面而是地图数据模型的设计这个模型一旦定好后面 25 张地图都只是“重复工作”。2. 为什么不用现成工具适用场景与边界2.1 直接拿图片软件拼图为什么不行火纹初代的地图看起来就是 20 多列、十几行的方格理论上用 Photoshop 或者 Aseprite 也能拼。但实际动手以后会发现几个问题地图元素是分层的地面、单位、建筑、装饰不是一张静态图就能表达清楚。25 张地图里有很多复用瓦片手动复制粘贴改坐标很容易错。每张地图需要导出统一格式的预览图和标记图手动做非常耗时。后期如果发现某种瓦片绘制错了期望所有地图里的同类型瓦片都能跟着改而不是逐张改。这些需求指向的不是“画图软件”而是一套带有数据结构的地图编辑工具。所以自研编辑器真正的价值在于把地图从“图片”变成“数据”。2.2 这个工具适合谁想复刻或者重绘旧 SRPG 地图但不想用复杂游戏引擎的开发者。研究瓦片编辑器、网格地图数据结构的同学。做桌游地图、战棋关卡设计需要批量管理关卡文件的人。想把地图数据用于自己的程序渲染器、AI 寻路测试、关卡生成对比的人。2.3 主要边界与合规提醒《火焰之纹章》是任天堂的版权作品。自研编辑器本身是技术学习项目地图数据也只应该用于本地学习、个人技术研究、像素画练习不要用于任何商业发布更不要把原版地图素材二次打包分发。文章里的代码与数据结构是通用的 SRPG 瓦片方案你也可以完全换成自创地图题材来练习。3. 需求拆解一个“地图重绘编辑器”到底要什么动手前我给编辑器列了一份需求清单这也是整个项目最有价值的部分。3.1 用户操作层面的需求支持鼠标点选瓦片左键刷到地图上右键擦除。支持多图层至少包含地形层、装饰层、边框层。支持选区批量填充方便铺草地、铺墙壁。支持撤销/重做因为手动重绘地图时误操作非常多。支持打开背景参考图半透明显示在原版截图下方方便对齐格子。3.2 数据层面的需求地图尺寸必须可以配置例如 20 列 x 18 行。瓦片集要用独立编号每个瓦片有唯一 id。地图数据保存为 JSON每个格子包含type和layer信息。导出时需要附带地图元信息地图名、尺寸、瓦片集版本、创建时间。提供“校验功能”检查是否有格子未被填充、是否有不合理的装饰层例如墙体上放树。3.3 批量层面的需求所有地图文件放在同一目录结构一致。提供一个批处理脚本把所有 JSON 地图批量缩略图导出方便快速检查 25 张图整体效果。支持从一个模板地图复制基础边框再手动修改内部地形节省重复铺边框的时间。到这里功能边界已经清楚了。下一步就是设计数据结构和渲染界面。4. 地图数据模型把 25 张地图变成可管理的 JSON自研编辑器的核心不是 UI而是数据模型。我最终采用了一套非常简单的架构整数瓦片 id 二维数组 图层字典。4.1 瓦片集定义瓦片集是一张 PNG 图片切成若干等大小瓦片也可以用 JSON 描述每个瓦片的可读名称。下面是瓦片集的简化结构{ tileset_name: fe1_tiles, tile_width: 16, tile_height: 16, tiles: [ { id: 0, name: grass, color: #4a7a3b }, { id: 1, name: wall, color: #5b4a3f }, { id: 2, name: floor, color: #c9b99a }, { id: 3, name: tree, color: #2d5e2b }, { id: 4, name: water, color: #3967b1 }, { id: 5, name: mountain, color: #6b6b6b } ] }实际项目中瓦片数量会远远大于 6 个但结构是一致的。每个瓦片都有稳定的id地图数据只存 id不存图片路径这样不同瓦片集之间还能做映射转换。4.2 单张地图的数据结构每一张地图我使用一个包含图层字典的 JSON 文件{ map_id: chapter_01, name: 第一章测试地图, cols: 22, rows: 16, tile_size: 16, tileset: fe1_tiles, layers: { ground: [ [0, 0, 0, 0, 0, 0], [0, 1, 1, 1, 0, 0], [0, 1, 0, 1, 0, 0], [0, 0, 0, 1, 0, 0] ], decor: [ [-1, -1, -1, -1, -1, -1], [-1, 4, 4, 4, -1, -1], [-1, 4, -1, 4, -1, -1], [-1, -1, -1, 4, -1, -1] ] } }这里有一个重要设计-1表示“该层此位置没有瓦片”。这个约定比空字符串更高效因为所有图层都是数字数组序列化之后体积很小运行时判断也快。绘制的时候程序遍历ground和decor先画地面再画装饰形成层次感。4.3 地图边界自动生成初代很多章节地图都有“地图边框”或“不可通行区域”。如果每张图都手动铺边界效率太低。我实现了一个辅助函数在地图创建时自动把最外圈格子填上指定瓦片def add_border(layer, cols, rows, border_tile_id): for x in range(cols): for y in range(rows): if x 0 or y 0 or x cols - 1 or y rows - 1: layer[y][x] border_tile_id return layer这样做的好处是先批量生成所有地图的边框再手动编辑内部区域。即使后期地图尺寸改了也能重新跑一遍边界函数不会破坏内部地形。5. 渲染与交互在浏览器里画出网格地图编辑器采用浏览器端实现主要考虑是调试方便而且 canvas 可以快速绘制网格和瓦片。渲染逻辑分成三部分底图渲染、瓦片渲染、网格叠加。5.1 Canvas 渲染主循环function renderMap() { ctx.clearRect(0, 0, canvas.width, canvas.height); // 地面层 for (let y 0; y map.rows; y) { for (let x 0; x map.cols; x) { const tileId map.layers.ground[y][x]; if (tileId 0) continue; const tile tileset.tiles.find(t t.id tileId); ctx.fillStyle tile.color; ctx.fillRect(x * tileSize, y * tileSize, tileSize, tileSize); drawTileIcon(ctx, tile.id, x * tileSize, y * tileSize); } } // 装饰层 for (let y 0; y map.rows; y) { for (let x 0; x map.cols; x) { const tileId map.layers.decor[y][x]; if (tileId 0) continue; const tile tileset.tiles.find(t t.id tileId); ctx.fillStyle tile.color; ctx.fillRect(x * tileSize, y * tileSize, tileSize, tileSize); } } drawGrid(); }这段代码的性能足够支撑几十行、几十列的地图。如果地图尺寸扩展到几百格就需要把 canvas 换成离屏缓冲只重绘变化区域。但当前需求用不到这点所以我没有过早引入复杂优化。5.2 鼠标交互点击绘画和右键擦除监听画布的click和contextmenu事件根据鼠标坐标算出格子坐标再朝当前图层写入瓦片 idcanvas.addEventListener(click, (e) { const rect canvas.getBoundingClientRect(); const px e.clientX - rect.left; const py e.clientY - rect.top; const gx Math.floor(px / tileSize); const gy Math.floor(py / tileSize); setTile(gx, gy, currentTileId); renderMap(); }); canvas.addEventListener(contextmenu, (e) { e.preventDefault(); const rect canvas.getBoundingClientRect(); const px e.clientX - rect.left; const py e.clientY - rect.top; const gx Math.floor(px / tileSize); const gy Math.floor(py / tileSize); setTile(gx, gy, -1); renderMap(); });这里的setTile会先判断gx、gy是否越界再把当前图层数组的对应元素改成目标 id。整个交互非常像像素画软件但因为是 SRPG 地图格子天然的网格属性让对齐问题直接消失了。5.3 参考图对齐把原版地图放到底图重绘地图时必须参考原版地图的布局。我实现了一个半透明底图功能导入一张原版截图根据地图边长进行缩放以一定透明度画在 canvas 底部之后用户直接在上面绘制。这个功能节省了大量“截图切格子”的时间。function drawReference() { if (!referenceImage) return; ctx.save(); ctx.globalAlpha 0.35; ctx.drawImage(referenceImage, 0, 0, canvas.width, canvas.height); ctx.restore(); }6. 编辑器功能细节图层面板、撤销重做和校验6.1 图层面板界面右侧固定一个图层面板用列表展示ground、decor、border等图层。点击图层名可以切换当前可编辑图层并控制该图层是否可见。图层的顺序决定了渲染时谁在上层。实际使用时我固定了这样的规则ground草地、地板、道路、水面、山壁地面。decor树木、建筑、装饰物与单位无关的静态物件。border地图外围不可通行区域。units本来打算放出生点单位后来发现手绘重制阶段不需要就直接不在 JSON 里启用但数据结构预留了这个位置。6.2 撤销重做撤销重做在手动地图编辑中是刚需。实现方案不复杂每次setTile都往历史栈里推入“坐标、图层、旧值、新值”。const historyStack []; const redoStack []; function setTile(gx, gy, tileId) { if (gx 0 || gy 0 || gx map.cols || gy map.rows) return; const layer map.layers[currentLayer]; const oldId layer[gy][gx]; if (oldId tileId) return; historyStack.push({ x: gx, y: gy, layerName: currentLayer, oldId, tileId }); layer[gy][gx] tileId; redoStack.length 0; } function undo() { const record historyStack.pop(); if (!record) return; map.layers[record.layerName][record.y][record.x] record.oldId; redoStack.push(record); renderMap(); }这套方案适合单用户、格子粒度操作。如果后面做区域填充应该把一次填充作为一条历史记录而不是每一个格子都记录否则撤销会非常慢。6.3 校验功能25 张地图很多手动编辑时漏掉某个格子是必然的。我实现了一个检查逻辑遍历所有格子规则如下ground层不允许出现-1也就是说每一格必须有一个地面类型。decor层允许-1但不能出现在已经被墙壁遮挡的位置具体情况由命名规则过滤。地图四周必须是border类型防止内部地形泄露到不可通行区域。同一格子不允许两个不透明装饰瓦片叠加。这些规则定义在配置里跑一遍就能输出错误清单直接定位到某张地图的某个格子。7. 重绘 25 张地图的完整工作流工具开发完成以后剩下的工作量就是“地图复刻流水线”。我把整个过程拆成七个步骤。7.1 准备参考素材先把原版 25 张地图的截图整理到同一个目录按章节编号命名。因为原版地图是像素风截图分辨率不高所以参考图只需要能看清地形轮廓不需要高清资源。7.2 创建空白地图模板用脚本一次性创建 25 个 JSON 文件统一尺寸和瓦片集。这时候所有地图都只有边框内部是-1空地形。python create_maps.py --count 25 --cols 22 --rows 16 --tileset fe1_tiles --border-id 1脚本内部会生成chapter_01.json到chapter_25.json每个文件都带上常见的地图元信息。7.3 逐张描绘地形打开编辑器加载背景参考图先画ground把道路、树林、水面等主体地形填完整。这一步最耗时但因为有瓦片刷子和选区工具实际效率比截图里手动拼像素快很多。7.4 添加装饰物件在decor层放置建筑、树、岩石等装饰。装饰层和地面层分开方便批量修改。比如检查发现某种树瓦片装饰效果不好只需要修改整个瓦片集的视觉表现或者在地图数据里批量替换该 id。7.5 校验并修正每完成 3 到 5 张地图就跑一次校验脚本python validate_maps.py --dir ./maps输出格式类似[chapter_01.json] OK [chapter_03.json] ERROR: (5,12) ground missing [chapter_07.json] ERROR: (0,0) border missing错误就是遗漏格子的坐标回到编辑器里定位到对应坐标修复即可。7.6 批量导出预览图为了快速对比整套地图效果我写了一个批量导出脚本把每张 JSON 渲染成一张 PNG 预览图放在previews目录下。这样不用逐一打开浏览器刷新直接看文件夹里的缩略图即可。def export_preview(map_path, output_dir): data load_json(map_path) img render_map_to_image(data) name data[map_id] .png img.save(os.path.join(output_dir, name))7.7 目录存档与备份最终目录结构保持如下maps/ chapter_01.json chapter_02.json ... chapter_25.json tilesets/ fe1_tiles.json fe1_tiles.png previews/ chapter_01.png chapter_02.png ... scripts/ create_maps.py validate_maps.py export_previews.py editor/ index.html editor.js editor.css这个结构把数据、工具、脚本、产物全部隔离任何时候都可以重新生成预览图也可以替换瓦片集颜色后一键重渲染 25 张地图。8. 开发中遇到的典型问题与排查方法重画 25 张地图期间编辑器本身也踩了不少坑。下面整理最常见的问题。问题现象可能原因排查方式解决方案参考图导入后画布空白图片跨域问题或缩放比例不对确认图片本地路径全局搜索报错信息放在同目录下用相对路径打开缩放时按 canvas 宽高计算点击画布后瓦片画偏了没有减去 canvas 的 CSS 偏移打印点击坐标和计算出的格子坐标使用getBoundingClientRect修正坐标偏移地面层漏填校验报错编辑时只画了表面没有画角落格子运行校验脚本定位坐标在编辑器里增加“当前地面层未填充高亮”模式JSON 文件被手动改坏文本编辑器编码或逗号问题控制台查看 JSON 解析报错用脚本统一写入避免手改原始 JSON撤销历史导致内存占用高每次点击都记录整张地图快照观察页面卡顿改用记录变更记录而不是整图快照瓦片 id 对不上颜色瓦片集 JSON 和实际瓦片顺序不一致检查 tileset 文件 id 与图片顺序给每个瓦片增加可读 name不用肉眼查 id批量导出预览图全是空白渲染脚本未加载瓦片色表检查脚本是否读取了 tileset JSON在导出前先加载并校验瓦片配置这些问题大多数是典型的 Web 画布开发问题只要定位到“是数据问题还是渲染问题”解决起来很快。9. 资源占用与渲染性能观察因为是浏览器端瓦片编辑器资源占用非常低。单张地图 22 x 16 格每次渲染最多也就几百个格子canvas 重绘几乎可以忽略不计。在实际开发中我关心的其实是三个方面。9.1 浏览器内存如果一次性加载了全部 25 张 JSON 导入编辑器内存会有少量上升但影响不大。真正占内存的是参考图如果原版截图是 2000px 宽浏览器会保留原始像素数据和缩放后的画布数据。所以我只保留当前编辑地图的参考图切换地图时释放掉上一张。9.2 是否支持更低配置的设备整套工具不依赖 GPU普通的集成显卡也能流畅运行。没有用到 WebGL也没有复杂滤镜。之所以不用 WebGL是因为格子地图的顶点数太少用 canvas 2D 足够而且 canvas 2D 的调试成本低很多。如果你希望把编辑器扩展到 500x500 格的大型地图再考虑用离屏 canvas 或 WebGL 实例化渲染也不迟。9.3 如何降低浏览器卡顿如果画布出现卡顿优先检查是不是在mousemove事件里直接调用了整图渲染。拖动鼠标画地图时每帧都全量渲染会非常浪费。可以加一个防抖或者只重绘鼠标经过的格子canvas.addEventListener(mousemove, (e) { if (e.buttons ! 1) return; // 只绘制当前格子不整图刷新 paintSingleCell(e); });这样连续拖动绘制时性能会提升非常明显。10. 工程化建议与合规使用边界对于想复刻这套工作流的开发者我有几条比较实际的建议。10.1 先做 1 张图再批量复制不要一上来就生成 25 张地图模板然后全都填充完。正确做法是先完整做完一张图包括校验、导出预览、看效果反复调整工作流直到你满意。然后再批量建模板沿用同一套瓦片集和脚本只用一周时间在细节上修修改改。地图重绘最耗时的从来不是铺格子而是工作流中某个环节不符合实时需求。10.2 数据驱动而不是图片驱动一定要把地图作为 JSON 数据来管理而不是把画布内容导出 PNG 后直接保存。只有数据驱动才能做到脚本校验、批量替换、自动导出。地图数据就是产品图片只是渲染结果之一。以后如果想在网页里展示地图或者用代码做寻路测试JSON 数据可以无缝复用。10.3 合法授权与使用边界重申一次不要直接把《火焰之纹章》的地图素材用于商业项目也不要在公开仓库中分发任天堂的版权素材。自研编辑器的意义在于研究地图数据结构、瓦片编辑流程和 SRPG 关卡设计不是为了冲刺商业项目。建议你完全可以用原创的奇幻地图设定来练习工作流一样成立。如果你在团队项目中使用这套编辑器还需要注意输入地图数据的版权来源以及导出素材是否允许被外部使用。任何涉及版权素材的本地数据和工程文件都应该在团队内部做好权限控制。10.4 给未来扩展留出接口这个编辑器当前不做自定义脚本接口但数据格式是开放的。扩展点主要在“地形属性表”每个瓦片增加walkable、defense、avoid等战棋属性。“事件标记层”用额外图层标记村庄、宝箱、敌方初始位置。“生成算法接入”调用外部程序生成随机地图初版再手动精修。“多人协作”把 JSON 放到 Git 仓库中编辑完一个版本提交一次天然支持回滚。这些扩展不一定要现在实现但数据结构上要预留位置。比如我在地图层数上就直接用了对象字典后续加一个events层非常简单。11. 总结与下一步自研编辑器最值得尝试的地方就是它把“重绘 25 张地图”这件事从手工体力活变成了可控的工程流程。如果你也想复刻类似项目最先应该验证的是那三个核心功能瓦片刷子的点击绘制、地图 JSON 的导入导出、背景参考图的半透明对齐。这三个功能通了整个工作流就转起来了。最容易踩的坑是坐标偏移和图层顺序做开发时建议一开始就用统一的坐标换算函数不要让事件监听代码里到处写Math.floor((e.clientX - offset) / tileSize)尽量收敛到一个 helper 方法里。后续可以继续扩展的方向很多接入地图寻路算法验证格子属性、把地图数据转成任一游戏引擎的 Scene 文件、实现自动寻路检查地图可通行性甚至用 AI 辅助批量填充基础地形。但无论如何先把编辑器用熟把数据闭环打通再做高级功能才更稳妥。如果你要复刻这套流程建议先拿一张你看看效果再决定要不要批量推进。工具不复杂但真正把 25 张图从原始截图变成可编辑、可校验、可导出的数据文件那种成就感只有自己跑一遍才能体会。