1. 项目拆解这不是复刻游戏是在做一套RPG基础设施如果你是一个从 Flash 时代走过来的老玩家对《仙剑奇侠传》的感情大概率是从 踩地雷遇敌-排排站砍怪-看剧情演出 这一整套循环里长出来的。这个项目标题里最有意思的词不是仙剑而是从零重写和可视化编辑器这两件事的组合。它把目标拆成了两层第一层是让游戏能跑、能通关第二层是让游戏里的所有内容——地图、对话、战斗、物品——都能通过编辑器配置出来不需要改代码。换句话说这是一个典型的运行时Runtime 编辑器Editor双端架构。游戏本体是运行时负责读取资源、播放剧情、结算战斗编辑器是开发工具负责生成这些资源。两者共用一套数据结构只是消费角度不同。这个思路和现在游戏工业化里的数据驱动开发是同一条路子只不过你用 TypeScript 在浏览器里把它从零实现了一遍。1.1 为什么选 TypeScript而不是 JavaScript 或 Rust 编译到 wasmTypeScript 这个选择几乎没什么悬念。原因有三首先是生态兼容性浏览器本身就是 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: Recordstring, 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。最后这个项目的成就感不在于做到了能通关而在于我终于可以用一个可视化的工具把一类游戏的内容生产流程完整地串了起来。大家要是自己动手试试有坑随时可以来交流。
