企业官网建设流程全解析

1. 项目拆解：这不是"复刻游戏"，是在做一套RPG基础设施

如果你是一个从 Flash 时代走过来的老玩家，对《仙剑奇侠传》的感情大概率是从 "踩地雷遇敌-排排站砍怪-看剧情演出" 这一整套循环里长出来的。这个项目标题里最有意思的词不是"仙剑"，而是"从零重写"和"可视化编辑器"这两件事的组合。它把目标拆成了两层：第一层是让游戏能跑、能通关，第二层是让游戏里的所有内容——地图、对话、战斗、物品——都能通过编辑器配置出来，不需要改代码。

换句话说，这是一个典型的"运行时（Runtime）+ 编辑器（Editor）"双端架构。游戏本体是运行时，负责读取资源、播放剧情、结算战斗；编辑器是开发工具，负责生成这些资源。两者共用一套数据结构，只是消费角度不同。这个思路和现在游戏工业化里的"数据驱动开发"是同一条路子，只不过你用 TypeScript 在浏览器里把它从零实现了一遍。

1.1 为什么选 TypeScript，而不是 JavaScript 或 Rust 编译到 wasm

TypeScript 这个选择几乎没什么悬念。原因有三：首先是生态兼容性，浏览器本身就是 JavaScript 的运行环境，TypeScript 编译后可以直接跑，省掉一层跨语言适配。其次是类型安全，RPG 游戏里面最怕的不是怪物的数值设计不合理，而是改了一个字段之后，所有引用它的地方静默崩掉——类型系统能帮你把这个崩溃提前到编译期。第三是开发效率，编辑器本身是个前端应用，游戏本体又是另一个前端应用，两者用同一门语言维护，可以在共享包（Shared Package）里导出共用的类型定义。

有个很容易被忽略的点：编辑器里拖拽配置生成的对象，最终要被游戏运行时读取。如果编辑器那边用 JavaScript 写，游戏用 TypeScript 写，两边对接时没有编译期校验，一旦编辑器保存的数据结构少了一个字段，游戏读取时要么 undefined 报错，要么渲染异常。而 TypeScript 可以在共享类型上同时约束两边，算是用最小的成本换最稳的对接。

1.2 核心难点不在"重现仙剑"，在于"如何让编辑器生成的数据被游戏无缝消费"

这个项目真正难的不是把某个迷宫画出来，也不是把某段对白复刻出来，而是设计一套"编辑时数据 == 运行时数据"的协议。编辑器画一张地图的时候，画布上放的是"图块ID+坐标"，游戏读取的时候同样拿"图块ID+坐标"来做碰撞检测和地图拼接。两边不能有格式转换，否则就会出现"编辑器里看着正常，游戏跑起来错位"的经典问题。

所以整个项目成败的关键，其实在于数据建模够不够干净。用一句话概括我的设计思路：先定义游戏世界的"最小原子"，再用组合的方式搭建复杂玩法。这就像乐高，先有标准砖块，才能拼出城堡。

2. 核心系统架构：渲染、状态机、数据驱动三驾马车

2.1 渲染层：Canvas 2D + 分层绘制，不引入重量级游戏引擎

项目选择用原生 Canvas 2D 而不是 PixiJS 或 Phaser，主要是因为两个原因：一是 2D 像素风 RPG 的渲染需求并不复杂，主要就是"贴图块 + 精灵动画 + 文本绘制"，这些 Canvas 2D 的 API 已经覆盖了九成；二是从零重写意味着对每一帧渲染什么都有绝对掌控力，这在调试编辑器数据时特别重要——你能清晰地知道地图上一个块为什么画在那里。

实现上我把渲染分成四层：

• 地面层（Ground Layer）：绘制地图图块、地表装饰，如草地、道路、水面
• 物体层（Object Layer）：绘制不可移动的物件，如房子、树木、石碑
• 角色层（Character Layer）：绘制玩家和 NPX，包含行走动画、战斗出场
• 特效层（Effect Layer）：绘制光影、粒子、对话高亮框

每层是一个独立的离屏 Canvas，帧更新时按层叠加合成。这样做的好处是：角色站在房子后面时，只需要把角色层的坐标插到物体层和装饰层之间，不用重绘整张地图。这个"排序分组"的思路，来自传统 2D 游戏里的 Y-Sorting，只是在这里用分层替代了逐像素排序，性能更好，逻辑也更清晰。

注意，如果你照抄这个方案，请务必处理 Retina 屏的 DPR 缩放。Canvas 的默认坐标是 CSS 像素，但屏幕物理像素可能是它的 2 倍或 3 倍，不缩放画出来会糊。

2.2 状态机驱动：游戏不是"循环"，是一系列可暂停、可回退的状态集合

RPG 看上去像一个线性流程：走路 -> 遇敌 -> 战斗 -> 回主城 -> 继续走。但真正实现的时候，如果直接用流程逻辑硬编码，会有两个毛病：一是状态之间的切换散落在各个函数里，没法整体管理；二是存档读档时不知道当前处于哪个状态，状态值不好序列化。

我用一个中央状态机（GameStateMachine）来管理所有全局状态：Idle 地图行走、Dialog 对话播放、Battle 战斗结算、Inventory 打开背包、Cutscene 剧情演出。底层是一个可嵌套的栈式状态管理器（StateStack），每次 push 一个状态，顶层的状态拥有控制权，pop 之后自动回到上一层。这样"打开背包 -> 使用物品 -> 回到地图"就只是三次栈操作，非常干净。

状态机的核心价值在于：后续如果要在浏览器存档系统里做"中断恢复"，只需要把当前栈里的每个状态的前缀数据序列化下来，加载时按顺序重建栈即可。这个机制加上 TypeScript 的判别联合类型（Discriminated Union），能实现"编译器帮你验证状态对象结构是否正确"的效果。

2.3 数据驱动：地图、对话、战斗脚本统一走 JSON + Schema 校验

游戏里的地图怎么编排？对话怎么分支？战斗里敌人放什么技能？如果这些写在 TypeScript 代码里，每次调数值都要重新编译。我把它们全部抽到统一的 JSON 数据文件里，同时用 TypeScript 的编译期类型和 JSON Schema 双重校验。

数据结构大概是这个风格：

interface MapData { id: string; name: string; width: number; height: number; tilesets: TileSetRef[]; // 引用的图块集 layers: LayerData[]; // 地面层、物体层、碰撞层等 encounters: EncounterRule[]; // 踩地雷遇敌规则 triggers: ScriptTrigger[]; // 事件触发器 } interface ScriptTrigger { id: string; position: { x: number; y: number }; eventType: "dialog" | "battle" | "transfer" | "flag-set"; payload: Record<string, unknown>; // 具体由编辑器填入 }

游戏运行时只认这个结构，编辑器也只生成这个结构。这样达成的效果是：在编辑器里拖一块石头放到地图上，保存后游戏运行时自动就能在那个坐标渲染出石头并参与碰撞检测。没有中间翻译层，就没有"同步延迟"和"两边不一致"的隐患。

实操心得：JSON Schema 建议用它的"additionalProperties: false"选项，可以禁止掉所有未定义的字段。因为编辑器多写一个拼错的字段时，游戏运行时会忽略它，但编辑器显示可能正常，排查起来极难。

3. 浏览器版游戏实现：那些绕不开的战斗、移动和存档机制

3.1 地图加载与瓦片拼接

地图文件不直接保存大量图块数据，而是保存"图块索引 + tileset 图片路径"。运行时先用图片加载器拉取 tileset，然后按索引把每一块裁剪下来贴到 Canvas 对应位置。经典 32x32 像素的老式 RPG 地图，一屏大约需要 640 个瓦片绘制调用，直接用 drawImage 性能完全没问题。

关键细节是一个"只绘制可视区"的优化：不要循环整张地图的所有瓦片，而是根据相机位置先计算出可视区域的行列范围，再只绘制范围内的瓦片。比如 100x100 的地图，总瓦片数 10000 个，可视区可能只有 20x12 个瓦片，直接循环全图会白白浪费 98% 的绘制调用。这个优化在脚本语言里一视同仁，千万别省。

3.2 移动与碰撞：先判断能否走，再移动，而不是移动后回溯

角色移动的逻辑如果写成"先移动再检测碰撞，碰了就退回原位"，会出现一个经典问题：角色在两个碰撞块之间来回抖动。正确做法是"先预测，再提交"——按下方向键之后，计算出下一帧的位置，先用碰撞层检测这个位置是否可行，可行才更新坐标。

碰撞检测的具体实现可以基于网格数据，也可以基于 AABB 包围盒。对于像素风 RPG，网格检测更合适：地图上每个坐标点对应一个格子，格子的类型要么是"可行走"，要么是"不可行走"。角色移动时，把目标位置的格子类型取出来判断即可，效率高且逻辑简单。

这套方案的边界问题也要注意：角色不能"卡进"障碍物一半的位置。所以角色的大小和格子的尺寸最好保持倍数关系，比如格子是 32x32，角色宽度也是 32，这样任何时刻角色都对齐到天然坐标，碰撞判断永远直接有效。

3.3 遇敌机制：踩地雷的随机概率与平滑过渡

经典仙侠 RPG 用的是明雷和暗雷混合的方式。这里的暗雷逻辑是：地图上每个可行走区域都有自己的"遇敌概率表"。角色每走一步，生成一个 0~1000 的随机数，如果落在某个区间内，就切换到战斗状态。

工程实现上要注意"概率不要硬编码"：每个地图的 encounter 数组里包含了敌人组、概率、触发条件（第几章剧情推进后该区域不再遇低级敌人）。例如：

{ "enemies": ["骷髅兵", "毒蛇"], "chance": 12, "minLevel": 3, "maxLevel": 5 }

游戏运行时把概率表按地图加载进来，在每次行走后用权重随机取出一个敌人组。这个数据结构看着简单，但其实是"游戏平衡"最核心的调节旋钮——改 JSON，不用改代码，就能调整刷怪难度。

遇敌后界面切换有个过渡动画，我用的方案是"淡入到战斗背景，再淡出"。这个过渡不该打断状态机，应该注册成一个独立的 Cutscene 状态，结束后自动 push Battle 状态，整体流程非常顺滑。

3.4 回合制战斗系统：指令队列与 AI 决策

战斗部分我把它做成了一个独立子系统，不依赖地图模块。战斗场景初始化时会从敌人组数据中创建敌人实体的列表，玩家队伍则从当前队伍配置中读取。

核心数据结构：

interface BattleEntity { id: string; name: string; stats: { hp: number; maxHp: number; attack: number; defense: number; speed: number; }; skills: Skill[]; }

回合流程是"双方行动排序 -> 我方指令选择 -> 双方按序执行 -> 结算音效特效 -> 判断胜负"。行动排序用速度值来确定先后手，速度相同则随机。玩家每个角色可以选攻击、技能、防御、使用物品四类指令，这些指令收集完成后统一进队列执行。

AI 部分我给怪物设计了一个简单的"决策函数"：血量低于 30% 时优先使用回复技能，攻击目标默认选血量最低的玩家，偶尔会释放全体攻击技能。不必写复杂的行为树，RPG 战斗里一个包含两三个条件的规则函数已经足够出效果。

这里踩过一个坑：指令队列在多个回合中累积，必须在每回合结算后清空上一轮的指令，否则会出现"上回合选的攻击在这一回合重复执行"的 bug。清理代码放在回合切换的事件里，做一个数组重置即可。

3.5 存档：本地多槽位存储与恢复

浏览器端做存档，第一反应是 localStorage，但它有大小限制（通常 5MB），且只能存字符串。考虑到游戏数据是结构化 JSON，我直接用 localStorage 做了"槽位 + 存档时间"的方案。存档内容除了玩家状态（血量、等级、经验、位置），还包括当前地图 ID、已触发的剧情标记位、以及队伍成员状态。

存档时机有两个：一个是在每个固定存档点触发，另一个是战斗胜利后自动存"进度快照"（不覆盖手动存档，而是单独存一个 auto 槽）。这样用户出现"手动存档后卡死"的情况时，还能从自动存档回退。

从存档恢复时的要点是：不能只恢复数值，必须同步恢复全局状态机的栈。比如当前角色正在对话中存档，恢复时要把 Dialog 状态、对话索引、当前面的选项记录全部还原，否则恢复后 UI 会出现"话说到一半没有后续选项"的诡异状态。所以存档内容里必须包含一个"当前状态快照"的字段，在 load 时重建状态栈。

3.6 角色动画与站立帧

角色行走动画本质上是一组连续的 sprite 帧。为了表现得自然，我把每个方向的行走拆成两帧（左脚、右脚），加上一个站立帧。行走时切换帧，停止时回到站立帧。切换频率由移动速度决定，每走完一格切换一次即可，比时间驱动更符合"步进式"移动节奏。

要注意的是，很多复刻版把"行走动画在移动开始前播放"做成了"移动完成后播放"，看起来角色会先滑行再抬脚，非常僵硬。正确做法是：移动状态刚开始时立刻切到"左脚帧"，移动结束后切回站立帧，这样能避免"迈步"和"位移"错位的观感。这个小细节在复刻像素风时特别提分。

4. 可视化编辑器：用"组件化表单 + 画布操作"武装内容生产

4.1 编辑器整体布局：地图画布 + 图块面板 + 属性面板

编辑器是一个独立的前端应用，和游戏项目位于同一仓库的另一个包。核心布局三块：

• 左侧：图块面板，展示本地 tileset 里所有可用的图块截图，点击选取
• 中间：地图画布，支持鼠标绘制、橡皮擦、矩形填充、碰撞层开关
• 右侧：属性面板，展示当前选中图块、对象、区域的相关配置项

这种布局几乎是所有地图编辑器的标准范式，好处是学习成本低，用过的地图编辑器（比如 Tiled）的用户上手极快。我一开始尝试过把属性面板并在地图画布右侧浮动，后来发现屏幕宽度不够，必须独立成区域，这个调整很值得。

画布的基础操作，我的实现方式是：用 canvas 监听 mousedown、mousemove、mouseup，在绘制模式下按下时,把鼠标坐标映射成"图块行列"，再调底层数据模型加一块图块并重绘。橡皮擦就是把该位置的图块索引置为 null。这个交互看起来简单，但在鼠标快速拖动时要避免对每个像素都触发保存，否则性能直接爆炸。

建议加一个"保存频率限流"：每 300ms 自动保存一次，鼠标拖拽过程中不保存，松手时才同步。我在实际开发中就是因为每次绘制都调保存接口，导致画布卡顿明显，后来改成"只在离开画布和主动点保存时写入"，体感立刻流畅了。

4.2 对话树编辑器：可视化配置分支选项

RPG 里最繁琐的是对话系统。如果直接在 JSON 里写对话树，每写一条分支都要手动对着花括号数层级，三天就能劝退。我做了个独立的对话树编辑器：

左边是节点列表，每个节点代表一句 NPC 发言或玩家选项；右边是当前节点的详细配置（发言人、文本内容、跳转目标节点、条件标记位）。

数据结构是带条件的树状结构：

interface DialogNode { id: string; speaker: string; text: string; options?: { label: string; condition?: string; // 如 "已获得令牌" nextNodeId: string; }[]; nextNodeId?: string; }

编辑器里往节点面板拖一根线到另一个节点，就把两个节点的跳转关系保存了下来。对话运行时会把这个结构递归读取，逐句显示并等待玩家选择。这套逻辑搞定之后，剧情的复刻效率大大提升——可以把游戏里的每个对话都通过文字配置出来。

这里有一个实操细节：对话文本里的"变量"（比如主角的名字）不能写死。我用了一套"模板插值"方案：文本里写 {playerName}，运行时从上下文变量表里读取替换。编辑器端保存的还是模板原文，这样同一个对话树可以在不同角色甚至不同周目的存档下，显示出不同主角名。

4.3 战斗编辑器：数值配置与技能模板

战斗编辑器的目标是：不写代码，就能创建一种新怪物、一个新技能、甚至一个新物品。

怪物编辑器是"表单 + 预览"模式。表单里填怪物的名字、立绘图片、初始血量、攻击力、防御力、速度和技能列表；预览区能实时算出该怪物在 1 级玩家面前大概的出手顺序和伤害范围。这个"预估"功能特别好用，随时调数值，不用等到进游戏实测。

技能编辑器稍微复杂：每种技能有一个类别（单体物理、全体法术、治疗等），还有若干参数（伤害系数、附加状态、动画特效）。我用一个统一的公式来计算伤害：

function calculateDamage(attacker: BattleEntity, skill: Skill, target: BattleEntity) { const base = attacker.stats.attack * skill.damageMultiplier - target.stats.defense * 0.5; const variance = Math.floor(base * (0.9 + Math.random() * 0.2)); return Math.max(variance, 1); }

编辑器里的预览也是调用同一个公式函数，所以编辑器中看到的伤害范围和游戏完全一致。这个"同一个公式函数，两端共用"的设计，是编辑器开发里最省心的一环，不必担心"编辑时和运行时数值不一致"的错位。

4.4 数据导出管道：从编辑器数据到游戏资源的完整流程

编辑器里所有配置好的地图、对话、怪物、物品，最后都通过一个"导出"按钮打包成一个大的 game-data.json 文件，压缩后约几百 KB。游戏启动时直接拉取这个 JSON，按模块加载。

导出之前编辑器会自动跑一轮"数据校验"：检查地图里每个"传送点"的 Target 地图 ID 是否存在、对话树里是否有悬空节点、怪物引用的技能 ID 是否存在于技能表等。这些校验在编辑阶段就能卡住大部分运行时异常，比游戏运行时无限封装 try-catch 靠谱得多。

我在导出的 JSON 前面还会附带一个版本号字段。游戏运行时对比本地版本号和服务器版本号，如果不一致就提示"内容更新，请重新加载"。这个机制帮我解决了"编辑器里改完内容，但浏览器游戏还在用旧缓存数据"的经典问题。

5. 内容管线与工程化组织：怎么让多个人顺畅地给游戏做内容

5.1 共享类型包：一处定义，两端自动同步

整个项目结构上分成三个包：

• packages/engine：游戏运行时核心逻辑
• packages/editor：可视化编辑器
• packages/types：两端共用的数据结构类型

所有地图、对话、战斗的数据结构，都定义在 packages/types 里。编辑器导入这些类型来生成表单表单校验，引擎导入这些类型来做运行时解析。这样不管是编辑器加字段还是引擎加字段，编译期就能发现两边没有同步的接口。

这个结构在多人协作时尤其重要。假设 A 同事负责编辑器新增一种"宝箱"物件类型，他只需在 types 里加一个 ChestData 的定义，然后在编辑器里画配置表单，在引擎里加渲染和交互逻辑。其他依赖地图数据的人都不用改，字段就能自然流转。

5.2 资产目录约定：图片、音频、数据文件各归其位

资产目录我沿用了一个非常简单的约定：

assets/ images/ # 精灵图、立绘、图块集 audio/ # BGM、战斗音效、UI 音效 data/ # 地图、对话、怪物、物品等 json

编辑器上传图片时，会按照"资源类型 + 资源名"自动生成路径，并把相对路径写进 JSON 数据。游戏运行时按相对路径拼接 URL 去加载，不会出现绝对路径导致的环境迁移问题。这个约定不复杂，但能省掉大量"图片显示不出来"的排查时间。

5.3 热更新调试：编辑器保存后游戏自动刷新数据

实际开发中我加了"开发模式热更新"。编辑器端每次保存内容，默认往 localStorage 写一份"devData"，游戏在开发模式下优先读取这份数据，而不是打包好的 game-data.json。改完地图立即切换浏览器窗口就能看到新地图，不用重新构建。

等到正式发布时，再通过打包工具把编辑器导出的 JSON 合并进生产环境。这个"开发环境直接读编辑器数据"的思路，让"改内容 - 看效果"的迭代循环从几分钟压缩到了几秒，效率提升很明显。

注意，生产环境千万别启用这个热更新开关，否则用户一打开就读取他自己浏览器里的 localStorage 数据。我加了一个构建环境变量来控制这个开关，生产构建默认关掉。

6. 通关测试与找 Bug：质量不是靠看，是靠跑完整链路

6.1 从"能启动"到"能通关"：用自动化冒烟测试验证全流程

这个项目最特殊的一点是"通关"本身是一个验收指标。不能只做到"启动不崩"，要保证从第一张地图走到最终 Boss 战击败，全程无 bug。

我做了一个自动化冒烟测试脚本：在 Playwright 里驱动浏览器游戏，模拟玩家输入方向键走过前几章的关键路径，触发每个剧情点，随机进入两场战斗，攻击到胜利。脚本里加了"每步截图"的机制，跑完一套后，我可以通过截图快速发现渲染异常的位置。这套冒烟测试虽然不能替代人工玩游戏，但能用来拦截"地图传送错误""对话卡死""战斗不掉血"这类基础级 bug。

6.2 数据校验器：防止编辑器生成"坏数据"流入游戏

编辑器导出数据时，除了内部校验外，还有一个针对运行时的一组"静默修复"逻辑。比如对话树里如果有节点指向了不存在的节点 ID，游戏运行时会自动跳过并打印一条警告，而不是直接死循环或白屏。这种"宽容式容错"在生产环境很有必要：与其让一个配置小错误让玩家卡死，不如降级处理并记录日志。

通用做法是：导出的 JSON 附带一个 schemaMeta 字段，校验器根据这个字段决定是否严格校验。开发模式实时校验，生产模式只做基础类型检查。这个分层策略让开发时的错误暴露得足够早，又不影响生产环境的稳定性。

6.3 编辑器里记录到的"调参体验"

编辑器对数值的"即时反馈"到底有没有用，我举个实际的例子。某只 Boss 的初始血量我设成了 2300，攻击力 150。在战斗编辑器里用等级 10 的玩家队伍去模拟一场对战，发现伤害输出打完所有技能也只能砍到 Boss 的 40% 血。于是我直接改 Boss 血量到 1800，攻击调整到 120，重新模拟后胜率回到了合理区间。整个过程用了不到 10 分钟，如果在游戏里跑，光是触发战斗、打完、退出重进就够喝一壶了。

这就是为什么我相信编辑器让"做内容"的效率提升不是多了一点点，而是整个工作流被重塑了。做游戏内容的门槛被拉低，意味着更多的创意可以被快速试错。

7. 常见问题与隐藏彩蛋：给踩坑人的一份速查清单

7.1 为什么地图保存后游戏里位置偏移了

最典型的问题就是图块坐标原点不一致。编辑器里鼠标点击返回的坐标可能是像素值，地图数据里保存的是行列号，中间少了一步换算。检查方式：在编辑器里点击某个格子，看控制台输出的行列号是否与预期一致。如果行列号正确而游戏里偏移，那要考虑是不是游戏运行时在放大 Canvas 时忘了乘 DPR。

7.2 对话后角色动不了，但 UI 还在显示

基本可以确信是状态机没有正确 pop 掉 Dialog 状态。请在对话结束事件里手动打印当前状态栈的深度，看看是不是叠了两层。这个 bug 通常在"对话中被打断、切换到另一段对话"的场景中最容易出现。

7.3 怪物死亡后战斗画面不结束

原因往往是敌方实体还在战斗列表中。初始化战斗时，敌方列表是引用还是拷贝，会影响删除是否生效。推荐在战斗开始时做一次深拷贝，或者用一个存活的实体 ID 列表来驱动渲染，而不是直接删原对象。

7.4 编辑器上传图片后已经生成路径，但游戏加载失败

多半是图片资源路径在 JSON 里存的是绝对路径，而生产环境部署在子目录下。我的方案是：JSON 里只存相对路径，运行时用 globalThis.location.origin 拼出完整 URL。这个 bug 排查了足足半天，绝对值得写在避坑清单里。

7.5 存档后重新加载只能恢复数值，画面卡在地图加载中

这是状态栈没有保存完整导致的。恢复流程只恢复玩家坐标，但没有恢复"当前地图的加载状态"。解决方法：存档前把地图模块的解析状态（地形数据、NPC 标记、模块已加载标志）一并序列化保存，恢复时直接重建模块。

8. 经验收尾：这套组合拳还能带到哪些项目里

做完这个项目后，我的一个明显体会是：框架设计本身的价值，比"复刻某个游戏内容"的价值要持久得多。游戏部分后续更新容易，但编辑器那套"数据驱动 + 类型安全 + 双端同步"的思路，可以完全平移到很多应用场景里。

比如做营销活动落地页时，可以用"可视化配置"的方式把页面的模块、文案、图片交给运营去改，不用每次让前端重新发版；比如做教务管理系统里的考试题库，可以用"结构化编辑器 + 运行时校验"的组合，让老师用自己的语言录入选择题和答案解析。这些本质上都是"生产工具（编辑器）+ 消费工具（运行时）"的配套模式。

如果你也想做类似的尝试，我的三点建议是：先把数据协议定义到你能接受的最细粒度，再写引擎避免边写边改协议；编辑器永远先做"手动录入+保存导出"的极简版，再去扩展拖拽画布；任何时刻都不要忽略类型系统的力量，它能让你在编译期拦住整个团队一半的隐性 bug。

最后，这个项目的成就感不在于做到了"能通关"，而在于我终于可以用一个可视化的工具把一类游戏的内容生产流程完整地串了起来。大家要是自己动手试试，有坑随时可以来交流。