自研战棋地图编辑器：数据结构与批量校验实战解析

第一次把“火纹初代”的地图完整复刻到自己手里时，大多数人会以为最难的环节是“画图”——打开绘图工具，拉好网格，放大像素，一格一格地涂。半小时后，图上终于有了平原、森林和河流的轮廓。可是当你把这张图交给游戏引擎，它只会问你几个非常现实的问题：哪些格子能走？移动消耗是多少？站在森林里回避加成是多少？王座在哪里？踩到哪个格子会触发事件？

这些问题，一张像素图完全答不上来。

这也是这次“火纹初代 25 张地图复刻”项目里，我最先动手写的不是地图，而是一套自研编辑器的原因。真正困难的工作，从来不是把原图描出来，而是把每一张地图重建成一套可编辑、可校验、可导入导出到引擎的地图数据。这篇文章会把这套思路完整拆解：从战棋地图的数据结构，到最小可用编辑器的代码实现，再到批量校验 25 张地图的工程流程，以及这中间最常见的坑和我的实践建议。

1. 复刻战棋地图，难点到底在哪

先给一个判断：复刻老游戏地图，本质不是绘图问题，而是数据结构重建问题。

很多人第一次尝试都会掉进“像素描图陷阱”。传统做法很简单粗暴：用像素绘图软件画一张大图，平原用绿色，森林用深色，河流用蓝色，画完之后再人工写一份“属性对照表”，告诉引擎哪个区域是森林、哪个区域是河流。这样做前两张地图还行，到第 5 张、第 10 张的时候，你会发现两个致命问题。

第一个问题是“位置对不上”。手绘图形里没有网格语义，你只能靠肉眼对齐坐标。今天画偏一格，明天就可能被寻路系统理解成不可通行；本来可以到达的村庄，因为隔了一格墙，整关的胜利条件直接失效。第二个问题是“属性靠人工维护”。森林、山脉、河流、村庄、王座、宝箱、门、单位出生点，这些信息散落在图片和表格里，改一处就要同步另一处，稍不留神就会漏。

所以当我们说到“重画”时，更准确的说法是：把火纹初代每一章的关卡结构，从“一张视觉图”还原成“一套带规则的地图数据”。这也解释了为什么编辑器必须自研——通用绘图工具并不理解战棋地图的规则语义。

2. 火纹初代地图的数据结构：先建语义模型

火纹这类战棋游戏的地图，本质上是一张二维网格表。每一格承载的不仅是颜色，而是三个层面的信息：

• 地形层：这格是平原、森林、山脉、河流、桥梁还是城墙。
• 单位层：当前位置上是否站着我方、敌方或 NPC 单位。
• 规则层：这格对移动力、命中率、回避率、防御值有什么影响，是否可以进入，踩到后是否触发事件。

这就是自研编辑器与像素绘图工具最核心的区别：像素工具记录“看起来像什么”，地图编辑器记录“规则上是什么”。

先看一个简化后的地图数据示例。它不是原版规格，但足以说明一个完整关卡的数据结构应该长什么样。

{ "version": 1, "chapter_id": "chapter_01", "width": 20, "height": 16, "tiles": [ { "x": 0, "y": 0, "terrain": "PLAIN", "unit": null }, { "x": 1, "y": 0, "terrain": "FOREST", "unit": null }, { "x": 2, "y": 0, "terrain": "MOUNTAIN", "unit": null } ], "player_start": [ { "x": 0, "y": 8 } ], "enemy_units": [ { "x": 19, "y": 8, "class": "enemy_leader", "level": 1 } ], "events": [ { "type": "village", "x": 3, "y": 2, "mes": "villager_talk_01" }, { "type": "chest", "x": 17, "y": 1, "item": "vulnerary" } ] }

在这个模型里，地形类型是核心枚举。不同地形不仅颜色不同，在规则上也完全不同。下面是一份常见的地形语义对照表，你可以在自研编辑器里把它做成配置，而不是散落在代码里。

这套“地形即规则”的模型，是所有后续功能的基础。编辑器做的每一个操作，本质上都是在修改这套语义模型；导出的 JSON，才是游戏引擎真正需要的关卡文件。

3. 为什么不用现成地图工具：自研编辑器要解决什么

做自研编辑器之前，很多人会问：市面上不是有 Tiled 这类成熟瓦片地图编辑器吗？为什么不直接用？

我承认 Tiled 是很优秀的工具，它有网格、图层、瓦片集、自定义属性，几乎所有 2D 游戏地图都能画。但把它用于战棋地图复刻时，存在几个很现实的差距。

第一，语义需要额外维护。Tiled 默认解决的是“素材拼接”，它不知道王座是什么、村庄是什么、宝箱是什么。你可以给每个瓦片加自定义属性，但这些属性全靠团队约定，没有强约束，漏配一个格子可能很难发现。

第二，单位与事件没有原生表达。火纹地图里，我方出生点、敌方单位、NPC、对话事件、宝箱物品，这些信息落在图片层之外。Tiled 虽然有对象层，但“对象层 + 自定义属性”的写法需要每位使用者保持一致，这在单人项目里还能忍，一旦地图多了，后期维护成本会迅速上升。

第三，批量校验能力弱。25 张地图做完，要检查每一张的出生点是否连通、宝箱是否可到达、王座是否存在，这类需求 Tiled 本身不提供。你还是得写脚本去解析文件。

我最终选择自研编辑器，核心判断是：自研编辑器未必是为了“造出更好的通用工具”，而是为了把项目里的领域规则固化到代码和校验流程里。编辑器的使用者只需要关心“这关的地形怎么布置、敌人放在哪”，不需要关心 JSON 字段格式、不需要担心漏配属性。工具会帮他兜底。

所以更准确的说法是：如果你只复刻一两张地图，用 Tiled 完全够；但如果你要复刻整套 25 张关卡，并希望后期可以批量修改、批量校验、随时导出给引擎用，自研编辑器的成本会被摊薄，收益会越来越高。

4. 编辑器整体架构与环境准备

4.1 技术选型

这套自研编辑器，我选择了 Python + PySide6 + JSON 的组合。

• PySide6 是 Qt 的 Python 绑定，跨平台，桌面 GUI 绘图成熟，网格和鼠标事件处理都有现成组件。
• 数据格式选择 JSON，几乎任何语言都能读取，方便之后接入游戏引擎；也方便用脚本做批量校验。
• Python 的优势是迭代快，边写边验证，25 张地图的工作流里有大量“改一下数据结构、跑一遍校验”的场景，解释型语言更顺手。

这套思路不绑定 PySide6，你用 Tkinter、Flutter、Electron 或 Godot 编辑器扩展也能迁移。核心是“数据模型驱动渲染”这一层设计，而不是具体 API。

4.2 环境准备

建议使用 Python 3.9 以上环境，具体版本以你本地环境为准。安装 PySide6：

python --version pip install PySide6

安装完成后，确认 import 正常：

python -c "from PySide6.QtWidgets import QApplication; print('ok')"

项目目录结构规划如下：

fire-emblem-map-editor/ ├── models.py # 地图数据结构 ├── editor.py # 地图编辑器 GUI ├── validate_maps.py # 批量校验脚本 └── maps/ # 导出后的地图 JSON 目录

4.3 分层架构

整个编辑器的架构可以分成五层：

• 数据层：ChapterMap、Tile、TerrainType，所有编辑操作最终都会落到这里。
• 渲染层：把数据层绘制成可视化网格，包括地形色块、网格线、单位标记、参考底图。
• 交互层：鼠标左键涂刷地形，右键擦除，拖拽连续绘制，工具栏选择当前地形。
• 校验层：检查地图连通性、王座、出生点、单位配置等。
• 导入导出层：加载 JSON、导出 JSON。

其中最关键的一点是：渲染层永远不直接修改数据层，所有修改都通过数据层的方法完成。这样导出、校验、撤销等功能才有稳定的基础。

5. 最小可用编辑器：核心代码实现

这一节给出一个能直接跑起来的最小版本。它包含三个能力：网格地图渲染、鼠标涂刷地形、JSON 导入导出。把这个流程跑通后，再去扩展矩形填充、撤销重做、单位标记等功能会容易很多。

5.1 地图数据模型

文件路径：models.py

# -*- coding: utf-8 -*- from enum import Enum from typing import List, Dict, Optional, Any class TerrainType(Enum): """地形类型：编辑器里一个格子所承载的规则地形。""" NONE = 0 PLAIN = 1 FOREST = 2 MOUNTAIN = 3 RIVER = 4 BRIDGE = 5 VILLAGE = 6 CASTLE = 7 WALL = 8 HOUSE = 9 RUIN = 10 SEA = 11 ROAD = 12 THRONE = 13 DOOR = 14 CHEST = 15 GATE = 16 DESERT = 17 @property def color(self) -> str: """编辑器使用的调色板，运行游戏时会被真正的资源替换。""" palette = { TerrainType.NONE: "#2b2b2b", TerrainType.PLAIN: "#8fca6a", TerrainType.FOREST: "#2f7d32", TerrainType.MOUNTAIN: "#8d6e63", TerrainType.RIVER: "#42a5f5", TerrainType.BRIDGE: "#d7a86e", TerrainType.VILLAGE: "#ffb74d", TerrainType.CASTLE: "#9e9e9e", TerrainType.WALL: "#5d4037", TerrainType.HOUSE: "#d4a373", TerrainType.RUIN: "#a1887f", TerrainType.SEA: "#1e88e5", TerrainType.ROAD: "#e0d5b7", TerrainType.THRONE: "#fbc02d", TerrainType.DOOR: "#6d4c41", TerrainType.CHEST: "#f9a825", TerrainType.GATE: "#4e342e", TerrainType.DESERT: "#eed9a0", } return palette[self] class Tile: """地图中的一个格子。""" __slots__ = ("x", "y", "terrain", "unit") def __init__( self, x: int, y: int, terrain: TerrainType = TerrainType.NONE, unit: Optional[str] = None, ): self.x = x self.y = y self.terrain = terrain self.unit = unit class ChapterMap: """一张地图 = 二维格子数组 + 关卡配置。""" def __init__( self, chapter_id: str = "chapter_01", width: int = 20, height: int = 16, ): self.chapter_id = chapter_id self.width = width self.height = height self.tiles: List[List[Tile]] = [ [Tile(x, y) for x in range(width)] for y in range(height) ] self.player_start: List[Dict[str, Any]] = [] self.enemy_units: List[Dict[str, Any]] = [] self.events: List[Dict[str, Any]] = [] def set_terrain(self, x: int, y: int, terrain: TerrainType) -> None: if 0 <= x < self.width and 0 <= y < self.height: self.tiles[y][x].terrain = terrain def get_tile(self, x: int, y: int) -> Optional[Tile]: if 0 <= x < self.width and 0 <= y < self.height: return self.tiles[y][x] return None def to_dict(self) -> Dict[str, Any]: """导出为可序列化字典，最终写入 JSON。""" return { "version": 1, "chapter_id": self.chapter_id, "width": self.width, "height": self.height, "tiles": [ { "x": t.x, "y": t.y, "terrain": t.terrain.name, "unit": t.unit, } for row in self.tiles for t in row ], "player_start": self.player_start, "enemy_units": self.enemy_units, "events": self.events, } @classmethod def from_dict(cls, data: Dict[str, Any]) -> "ChapterMap": m = cls( data.get("chapter_id", "chapter_01"), data.get("width", 20), data.get("height", 16), ) for t in data.get("tiles", []): m.set_terrain(t["x"], t["y"], TerrainType[t["terrain"]]) if t.get("unit"): m.tiles[t["y"]][t["x"]].unit = t["unit"] m.player_start = data.get("player_start", []) m.enemy_units = data.get("enemy_units", []) m.events = data.get("events", []) return m

这段代码把第一节讲的所有语义都落到了数据模型里：每个格子有坐标、地形、单位；整张地图有玩家出生点、敌方单位和事件配置。导出 JSON 时，所有内容都直接来自这个模型，不会出现“画的是平原，属性却是森林”的错位。

5.2 画布渲染与鼠标交互

文件路径：editor.py

# -*- coding: utf-8 -*- import json import sys from PySide6.QtCore import Qt from PySide6.QtGui import QColor, QPen, QPixmap from PySide6.QtWidgets import ( QApplication, QComboBox, QFileDialog, QGraphicsRectItem, QGraphicsScene, QGraphicsView, QLabel, QMainWindow, QMessageBox, QToolBar, ) from models import ChapterMap, TerrainType TILE_SIZE = 32 class TileCanvas(QGraphicsView): """地图画布：绘制网格、地形色块、参考图，并处理鼠标笔刷。""" def __init__(self, chapter_map: ChapterMap, parent=None): super().__init__(parent) self.chapter_map = chapter_map self.scene = QGraphicsScene(self) self.setScene(self.scene) self.current_terrain = TerrainType.PLAIN self.show_grid = True self.reference_pixmap = None self._redraw() def _redraw(self): self.scene.clear() for row in self.chapter_map.tiles: for tile in row: rect = QGraphicsRectItem( tile.x * TILE_SIZE, tile.y * TILE_SIZE, TILE_SIZE, TILE_SIZE, ) rect.setBrush(QColor(tile.terrain.color)) if self.show_grid: rect.setPen(QPen(QColor("#666666"), 1, Qt.SolidLine)) else: rect.setPen(QPen(Qt.NoPen)) self.scene.addItem(rect) if tile.unit: unit_text = self.scene.addSimpleText(tile.unit) unit_text.setPos(tile.x * TILE_SIZE + 4, tile.y * TILE_SIZE + 6) # 参考底图：半透明显示，用于对照原始地图结构 if self.reference_pixmap is not None: ref = self.scene.addPixmap(self.reference_pixmap) ref.setOpacity(0.4) def _to_tile(self, event): pos = self.mapToScene(event.position().toPoint()) return int(pos.x() // TILE_SIZE), int(pos.y() // TILE_SIZE) def mousePressEvent(self, event): tx, ty = self._to_tile(event) if event.button() == Qt.LeftButton: self.chapter_map.set_terrain(tx, ty, self.current_terrain) self._redraw() elif event.button() == Qt.RightButton: self.chapter_map.set_terrain(tx, ty, TerrainType.NONE) self._redraw() super().mousePressEvent(event) def mouseMoveEvent(self, event): # 按住左键拖动时连续涂刷 if event.buttons() & Qt.LeftButton: tx, ty = self._to_tile(event) self.chapter_map.set_terrain(tx, ty, self.current_terrain) self._redraw() super().mouseMoveEvent(event) class MainWindow(QMainWindow): def __init__(self): super().__init__() self.map_data = ChapterMap("chapter_01", 20, 16) self.canvas = TileCanvas(self.map_data) self.setCentralWidget(self.canvas) self.setWindowTitle("自研火纹地图编辑器 - 最小可用版") self._build_toolbar() self.resize(20 * TILE_SIZE + 60, 16 * TILE_SIZE + 90) def _build_toolbar(self): toolbar = QToolBar("地形工具栏") self.addToolBar(toolbar) toolbar.addWidget(QLabel(" 地形: ")) self.terrain_combo = QComboBox() for terrain in TerrainType: self.terrain_combo.addItem(terrain.name, terrain) toolbar.addWidget(self.terrain_combo) toolbar.addAction("加载参考图", self._load_reference) toolbar.addAction("导入JSON", self._open_json) toolbar.addAction("导出JSON", self._export_json) self.terrain_combo.currentIndexChanged.connect( lambda _: setattr( self.canvas, "current_terrain", self.terrain_combo.currentData(), ) ) def _load_reference(self): path, _ = QFileDialog.getOpenFileName( self, "选择参考底图", "", "Images (*.png *.jpg *.bmp)" ) if path: self.canvas.reference_pixmap = QPixmap(path) self.canvas._redraw() def _export_json(self): path, _ = QFileDialog.getSaveFileName( self, "导出地图", self.map_data.chapter_id + ".json", "JSON Files (*.json)" ) if not path: return with open(path, "w", encoding="utf-8") as f: json.dump(self.map_data.to_dict(), f, ensure_ascii=False, indent=2) QMessageBox.information(self, "完成", f"已导出 {path}") def _open_json(self): path, _ = QFileDialog.getOpenFileName( self, "打开地图", "", "JSON Files (*.json)" ) if not path: return with open(path, "r", encoding="utf-8") as f: self.map_data = ChapterMap.from_dict(json.load(f)) self.canvas.chapter_map = self.map_data self.canvas._redraw() if __name__ == "__main__": app = QApplication(sys.argv) win = MainWindow() win.show() sys.exit(app.exec())

这段代码中，真正容易踩坑的地方有两个。

第一个是_redraw()每次都scene.clear()然后重新绘制。演示规模没问题，但当地图变大、参考图变多时，这种全量重绘会明显卡顿。工程化时建议只刷新被修改的格子，或者把地形层缓存成一张大位图。第二个是mouseMoveEvent里只在按下左键时连续涂刷，这保证了拖动绘制时不会误操作。

5.3 如何运行

在项目目录下执行：

python editor.py

你会看到一个 20x16 的网格窗口。从工具栏选择地形，在画布上左键涂刷、右键擦除。加载参考图后，可以半透明叠在原图上做位置对齐。画完一张地图后，点击“导出 JSON”，关卡数据就会写入maps目录。

验证方式很简单：用任意编辑器打开导出的 JSON，确认地形字段、坐标、单位配置都存在，并且没有飘红的语法错误。这说明编辑器已经具备了最基本的“地图数据重建”能力。

6. 批量校验：25 张地图不能只靠人眼

地图数量越多，低级错误出现的概率就越高。最典型的问题包括：某个格子被城墙和河流围死，导致出生点根本走不到王座；宝箱放在了不可达区域；敌人单位配置漏了坐标或职业字段。这些错误靠人眼一张张图去看，效率低且容易漏。

所以我在完成编辑器之后，紧接着写了一个批量校验脚本。它要做的事情本质上很简单：对每一张地图 JSON，按事先定义好的规则逐项检查，输出报告。

校验的维度包括：

• 地图尺寸是否合理。
• 是否存在王座（THRONE）。
• 玩家出生点到王座是否连通。
• 所有宝箱是否在可达区域内。
• 敌人单位是否包含必要的 x / y / class 字段。
• 事件是否包含必要的 type / x / y 字段。

文件路径：validate_maps.py

# -*- coding: utf-8 -*- """批量校验 maps 目录下所有地图 JSON，输出检查报告。""" import json import sys from collections import deque from pathlib import Path # 简化阻挡地形表：仅用于编辑器内的连通性校验，不等同于原版规则 BLOCKED_TERRAINS = {"WALL", "RIVER", "SEA", "MOUNTAIN", "CASTLE", "HOUSE", "GATE"} def load_map(path: Path) -> dict: with open(path, "r", encoding="utf-8") as f: return json.load(f) def build_tile_map(data: dict): return {(t["x"], t["y"]): t for t in data["tiles"]} def reachable_tiles(data: dict, start): """从起点出发，用 BFS 找出所有可达格子。""" width, height = data["width"], data["height"] tile_map = build_tile_map(data) queue = deque([(start[0], start[1])]) seen = {(start[0], start[1])} while queue: x, y = queue.popleft() for dx, dy in ((1, 0), (-1, 0), (0, 1), (0, -1)): nx, ny = x + dx, y + dy if not (0 <= nx < width and 0 <= ny < height): continue if (nx, ny) in seen: continue tile = tile_map.get((nx, ny)) if tile is None or tile["terrain"] in BLOCKED_TERRAINS: continue seen.add((nx, ny)) queue.append((nx, ny)) return seen def validate_one(path: Path) -> list: problems = [] data = load_map(path) cid = data.get("chapter_id", path.stem) width, height = data.get("width", 0), data.get("height", 0) if width < 10 or height < 8: problems.append(f"{cid}: 地图尺寸过小 {width}x{height}") thrones = [t for t in data["tiles"] if t["terrain"] == "THRONE"] if not thrones: problems.append(f"{cid}: 缺少王座 THRONE") return problems starts = data.get("player_start", []) if not starts: problems.append(f"{cid}: 缺少玩家出生点 player_start") return problems start = (starts[0]["x"], starts[0]["y"]) reachable = reachable_tiles(data, start) throne = (thrones[0]["x"], thrones[0]["y"]) if throne not in reachable: problems.append(f"{cid}: 出生点到王座不可达") for chest in [t for t in data["tiles"] if t["terrain"] == "CHEST"]: if (chest["x"], chest["y"]) not in reachable: problems.append(f"{cid}: 宝箱({chest['x']},{chest['y']})放在不可达区域") for idx, unit in enumerate(data.get("enemy_units", [])): if "x" not in unit or "y" not in unit or "class" not in unit: problems.append(f"{cid}: 敌人单位第{idx + 1}条缺少 x/y/class 字段") for event in data.get("events", []): if "type" not in event or "x" not in event or "y" not in event: problems.append(f"{cid}: 事件配置缺少 type/x/y 字段") return problems def main(): maps_dir = Path(sys.argv[1] if len(sys.argv) > 1 else "maps") if not maps_dir.exists(): print(f"目录不存在: {maps_dir}") return report = [] for path in sorted(maps_dir.glob("*.json")): problems = validate_one(path) if problems: report.extend(problems) else: print(f"[OK] {path.name}") if report: print("\n发现以下问题:") for line in report: print(" -", line) else: print("\n所有地图均通过校验。") if __name__ == "__main__": main()

运行方式：

python validate_maps.py maps

如果所有地图都通过，会输出[OK] chapter_xx.json；如果有问题，会在最后汇总成一份问题清单。这个脚本的成本很低，但价值很高。每次改完一批地图，跑一次脚本，5 分钟内就能知道是否引入了低级错误。

这里要特别说明：脚本里的BLOCKED_TERRAINS是简化处理。真实火纹的移动规则会区分职业、马匹、大门能否用钥匙开启等。开发完整游戏时，应该把移动消耗表做成可配置数据，校验逻辑读配置而不是读硬编码。

7. 复刻 25 张地图的实战工作流

有了编辑器和校验脚本之后，25 张地图的复刻工作就不再是“一张张凭感觉画”，而是一条有节奏的生产流水线。整个过程我大致分成三个阶段。

7.1 第一阶段：前 3 张地图，打磨工具

前 3 张地图是最慢的。不是因为它们难，而是这时候编辑器本身还在磨合。

你会不断调整数据结构：发现需要一个“门”地形，原来漏了；发现村庄需要记录事件 ID，原来events里没设置；发现单位坐标容易填错，需要在工具栏里加一个“单位标记”模式。这些需求在画前几张图时最容易暴露，改起来成本也最低。

在这个阶段，我的原则是：宁可放慢速度，也不绕过编辑器去手改 JSON。因为手改 JSON 解决一个问题，往往会在后面制造两个新问题。

7.2 第二阶段：中间 20 张地图，进入批量生产

工具稳定后，后面的地图生产速度会明显加快。每张地图的流程基本固定：

• 加载参考底图，半透明叠在网格上做几何对照；
• 先铺大块地形，比如整片平原、主要河流、山脉走向；
• 再补细节地形，比如村庄、森林、桥梁、城堡；
• 然后配置王座、玩家出生点、敌我双方单位；
• 最后添加事件点、宝箱、门等交互对象；
• 导出 JSON，跑一遍校验脚本，通过该张地图就算完成。

这个阶段最需要注意的是“地形一致性”。同一张地图里，山脉和河流要形成自然的视觉边界，不能出现“河流到一半消失，图片看起来断断续续”的情况；王座周围要留出符合关卡设定的守卫空间。

7.3 第三阶段：最后几张地图，处理特殊关卡

规模越大，越容易出现边缘情况。比如大型城堡关，地图尺寸比其他关更大；有传送门的地图，需要额外的events配置；整张图以室内为主的关卡，可能需要重新定义“墙壁”和“门”的视觉语言。

这些特殊地图不建议在最后一次性处理。更稳妥的做法是：每完成 5 张普通地图，就插入一张特殊地图，让工具和规则持续接受挑战。否则等到最后才发现数据结构不支持某类地图，返工成本会很高。

还要强调一点：如果你也是参考原版地图做复刻，注意素材边界。参考图应当只用于个人学习场景下的几何对照和地形辨认，不要把原版截图直接作为资源发布到正式项目里。个人练习可以用于位置对齐；如果要对外发布或商用，地图里的所有视觉素材都要替换成原创作品。

8. 常见问题与排查方法

9. 最佳实践与工程建议

这次项目做完，我最大的感受是：自研编辑器最重要的产物不是界面，而是数据结构与校验规则。下面这些实践建议是从这个项目里沉淀出来的，以后再做类似的地图工具，可以直接参考。

先定义数据结构，再写交互逻辑。很多编辑器项目失败，是因为一上来就写鼠标事件、绘图接口，数据结构却还停留在“像素数组”层面。战棋地图编辑器的地基是“格子 + 地形 + 单位 + 事件”，这个模型不稳，后面所有功能都会返工。

JSON 里加version字段。25 张地图做到后期，难免要调整字段格式。如果没有版本号，你根本不知道某张旧地图应该用哪套解析逻辑。我在to_dict()里保留了version: 1，以后升级数据格式，可以用脚本批量迁移，而不是人肉改 JSON。

校验脚本要从第一天就开始写。不要等 25 张地图全部画完再写校验，那时你面对的问题数量会非常恐怖。正确做法是：编辑器每新增一个功能，校验脚本就同步加一条对应规则。这样地图数据始终处于“可验证”状态。

渲染与数据解耦。所有绘制逻辑都从ChapterMap读取数据，而不是在画布上临时记录状态。鼠标事件只负责修改数据层，_redraw()只负责把数据画出来。这个分离让之后的撤销、重做、批量操作都变得简单。

调色板集中管理。地形颜色不要散落在各个绘制函数里，放在TerrainType.color属性里统一维护。换主题时只需要改一个地方，而且颜色变更不会影响数据结构。

地图文件逐张提交到版本管理。每完成一张地图，导出 JSON，提交一次 git。它不仅提供历史回溯，还能在批量校验失败时快速定位是哪张图、哪个版本被改坏了。

保留“加载参考图”这类功能，但严格控制素材边界。参考图层非常适合用来对齐原版地图的结构，但它只是编辑阶段的辅助工具。正式输出时，别让参考图混入真正的游戏资源。

如果可以，最后导出一张“预览大图”用于人工 review。编辑器可以做一个附加功能：把整张地图渲染成 PNG，按章节命名放到previews目录。这样你不用打开编辑器，翻文件夹就能快速浏览这 25 张地图的完成度和风格一致性。

这套自研编辑器真正让我满意的点，不是它有多炫，而是它在 25 张地图之后依然能用。到项目后期，我不需要再担心属性配错、坐标偏移、王座和出生点不连通。编辑器已经把那些容易出错的判断，提前拦在了数据提交之前。如果你也要做类似的地图复刻项目，先从数据结构下手，再写你自己的编辑器，这条路会顺畅很多。