用Canvas 2D重写回合制游戏战斗系统：架构设计与移动端优化实战

先交代一个背景：半年前我在地铁上打开一款老牌开源回合制策略游戏的安卓版，结果菜单加载就花了十几秒，进入战斗后单位一多直接卡成幻灯片，手机发热得像暖手宝。这款游戏本身不算重量级，地图是 2D 格子，单位是简单帧动画，理论上手机完全带得动。问题出在它的引擎链路上——原生代码、老旧的渲染流程、对触摸屏几乎没有优化。我当时就在想：既然客户端跑不动，不如把战斗系统在浏览器里重建一份，至少我手机上肯定有个浏览器。

于是就有了这个项目：某开源奇幻回合制策略游戏（下文简称W 游戏）的浏览器版战斗系统。不移植完整战役，不做网络对战，只做战斗核心——从玩家选择单位、规划移动路线、执行攻击，到敌方 AI 走子、伤害结算、回合推进。几个月做下来，踩坑无数，也把很多"原版是这么写，我偏要那样写"的思路理清了。这篇文章就把整个过程、选型理由和实际经验写出来，给想做同类"浏览器重构"的朋友做个参考。

1. 为什么原生客户端跑不动：先搞清楚问题在哪

动手之前，我没有直接跳到"那就写个网页游戏吧"，而是先花了半天时间搞清楚手机版到底为什么卡。原因找不准，搬到浏览器依然会重蹈覆辙。

1.1 运算量真的不大，瓶颈在渲染和输入链路

W 游戏的单局战斗通常有几十个单位，每个单位每回合有移动、攻击、反击三次动作。按传统回合制策略的算法体量，这计算量放到今天的手机上连热身都算不上。真正的瓶颈有三个：

• 原生 UI 与游戏循环耦合过深：菜单、对话框、战斗动画全在一个线程里排队，触摸事件处理也有额外的等待。
• 渲染管线对 GPU 不友好：大量绘制指令不批量提交，单位一多就掉帧。
• 数据加载方式落后：地图、单位配置、文本翻译全部散落在若干配置文件中，启动时要解析大量重复内容，IO 路径长。

这些不是手机硬件的问题，是软件架构的问题。明白了这一点，我确定浏览器方案可行，因为浏览器本身有成熟的 Canvas 2D、合成器、事件调度，某些层面反而比原版那条老链路更干净。

1.2 为什么不尝试给原版修 bug，而是另起炉灶

有人可能会问：你干嘛不去给原版提交补丁，或者换个平台重新编译？说实话我一开始也这么想，但深入了解后发现，改原版的成本可能比重写还高。

原版代码库有几十万行 C++，经历过多代重构，很多模块互相依赖。修复触摸支持、重做渲染队列，涉及的是引擎底层，不是改几个文件就能完事。而且我没有把握在短时间内把整个构建链跑通。相比之下，浏览器作为目标平台有天然优势：我只需要定义一份清晰的"战斗协议"，把单位的回合制行为核心抽出来，用 JavaScript 重写一遍，UI 和渲染都用 Web 标准能力。这样我能控制每一行代码，也能随时在手机上调试。

这里我认为有个特别重要的判断标准：如果目标是修复原版，那就去修；如果目标是让一个核心玩法在特定环境里可用，重写往往更划算。我的目标明显是后者。

2. 重建范围划定：从"整个游戏"缩小到"一场战斗"

真正开始写代码前，我先做了一件事：把任务范围从"做一个网页版 W 游戏"压缩成"做一个能跑通完整单局战斗的 Web 应用"。这一步直接决定了项目能在一个合理时间内落地。

2.1 最小可玩闭环：只需要六个阶段

围绕"单位在地图上移动、交战、结算回合"这个核心，我把单局战斗抽象成一条线性流程：

1. 玩家先手单位选择
2. 计算可移动范围与可攻击目标
3. 玩家移动单位
4. 玩家发动攻击或待机
5. 结算伤害、反击、经验与状态效果
6. 敌方 AI 行动并结束回合

这个闭环就是我的 MVP。战役地图、招募单位、升级成长、天气系统、多人对战全部砍掉。没有这些，项目才能在两周内出现第一个可玩的版本，而不是永远停在"搭建框架"阶段。

2.2 逻辑与表现彻底分离：战斗内核不碰 DOM

浏览器开发最常见的一个坑，就是顺手把游戏状态写在 DOM 或者 Canvas 绘制代码里。我特意把战斗内核写成一个纯 TypeScript 模块，不依赖任何 UI 框架，也不直接操作 Canvas。

内核负责维护所有状态：战场网格、单位位置、生命值、武器参数、回合阶段。表现层只负责两件事：读内核状态、把状态画出来。玩家点击某个格子后，事件层把坐标换算成网格坐标，传给内核，内核返回新的状态，表现层重绘。

这样做的最大好处是可测试。我在 Node 环境里直接跑内核的单元测试，模拟一场完整的 10 回合战斗，不需要浏览器。很多逻辑 bug 都在这一步被拦住了，比在页面上肉眼查错快得多。

3. 技术选型与核心实现：Canvas 2D + 自研回合状态机

技术选型是这种项目里最有争议的部分。我最终的选择可能让一些习惯用现成游戏引擎的人皱眉：没用 Phaser、没用 PixiJS，也没引 React 做 UI，而是用原生 Canvas 2D + 自写状态机。

3.1 为什么没上现成引擎

当时我认真对比过两条路线。表格列一下：

我的结论是：这个项目的复杂度还没到需要用引擎的程度。回合制策略游戏的画面变化频率低，不像动作游戏需要 60 帧物理和粒子系统。Canvas 2D 的 API 处理几百个单位、每周 30 次重绘，性能绰绰有余。真正需要用心的，是回合流程和数据组织。

3.2 回合状态机：把"战斗"拆成五个阶段

最早实现时，我图省事，直接用一堆 if-else 判断当前状态。结果第三天就发现逻辑开始失控：单位移动中能不能被选中？攻击动画期间玩家能不能点地图？敌方 AI 行动时 UI 要不要锁死？

后来我老老实实做了一个状态机 + 状态栈。核心定义大致是这样：

type TurnPhase = | 'PLAYER_SELECT' | 'REACH_CALC' | 'UNIT_MOVE' | 'UNIT_ATTACK' | 'ENEMY_PHASE' | 'ROUND_END'; interface BattleState { phase: TurnPhase; grid: Map<string, UnitState>; selectedUnitId: string | null; reachableCells: CellCoord[]; movableTarget: CellCoord | null; }

状态机的作用不是炫技，而是把我前面提到的"玩家手一快就出 bug"的场景全部规范化：

• PLAYER_SELECT阶段只接受单位点击，不接受移动指令
• UNIT_MOVE阶段只接受可达格点击，点击地图空白就取消
• ENEMY_PHASE阶段锁死所有玩家输入

每个阶段的允许操作就是一个白名单。非法操作要么忽略，要么触发阶段专属的取消逻辑。写完这套之后，我在手机上狂点乱戳，bug 数量肉眼可见地下降。

3.3 寻路与攻击范围：BFS 的工程化实现

回合制策略里的寻路看起来简单，但细节很多。W 游戏的地图有六边形网格，不是常见的方形网格。六边形寻路比方形多一个维度：相邻格子有 6 个方向，坐标转换容易写错。

我采用了经典的六边形立方体坐标方案。每个格子用(q, r, s)表示，满足q + r + s = 0。这样相邻判断和距离计算都非常简洁。寻路算法用 BFS（广度优先搜索），因为每单位每回合的移动点数有限（通常 3 到 7 格），BFS 的实际开销很小，完全不需要引入 A*。

伪代码逻辑如下：

def compute_reachable(start, movement_points, terrain_costs): queue = deque([(start, 0)]) visited = {start: None} while queue: cell, cost = queue.popleft() for neighbor in hex_neighbors(cell): new_cost = cost + terrain_costs[neighbor] if new_cost <= movement_points: if neighbor not in visited or visited[neighbor].cost > new_cost: visited[neighbor] = (cell, new_cost) queue.append((neighbor, new_cost)) return visited

BFS 出来的visited集合就是可移动范围。再把每个可移动格周围的敌人格子纳入攻击范围，就能画出玩家看到的绿色/红色高亮。

这里有一个我踩过的坑：最初的实现把"移动后攻击"和"先攻击后移动"一起处理，导致高亮范围多算了很多格子。后来我查了原版规则，确认 W 游戏里单位移动后可以攻击，但攻击后不能再移动，所以我把流程严格限制为：先算可达格，再在可达格基础上扩展一层的攻击格。这样展示给玩家的信息才和规则一致。

3.4 敌人 AI：先威胁估值，再走子

AI 部分我做了一个不算复杂的估值决策循环。它的核心逻辑是：每个敌人单位评估自己周围所有可移动格，选一个能最大化"生存收益 + 攻击收益 + 地形收益"的位置走子。

具体估值项有三类：

• 攻击收益：移动到某格后，能攻击到多少个玩家单位；如果攻击能击杀目标，额外加权
• 生存收益：该格周围敌人数量越少越好，地形防御加成越高越好
• 阵型收益：尽量不脱离队友的互相支援范围

AI 不需要多聪明，够用就行。实际上 W 游戏原版的 AI 也不复杂，多数时候是以稳妥和抱团为主。我实现的这套已经能对新手玩家造成压力，配合随机扰动还能避免每次走法都一样。

4. 素材与数据：把游戏资源喂给浏览器

代码逻辑搞定只算完成了一半，另一半是数据。W 游戏有大量单位、地形、武器配置和美术素材，不可能全部手动处理成 JavaScript 对象。

4.1 开源素材的许可边界，动手前一定要查清楚

W 游戏本身是开源项目，素材和配置沿用了自由许可，这给我复用在浏览器里提供了合法性基础。但这里必须提醒一句：开源不等于可以随便用，尤其要注意素材的署名条款和修改声明。我专门去项目文档里确认了单位立绘、地形贴图、音效的使用条件，最后在项目里附上了完整的素材来源列表。

如果你要复刻的是商业游戏或者素材版权不明的项目，别冒这个险。宁可自己画占位图、找公开许可素材库，也不要拿来源不清的图片上线。

4.2 配置数据 JSON 化：单位、地形、武器

原版用的是类似 INI 的文本配置，每个单位属性写在多层段落里。我写了一个一次性转换脚本，把这些配置解析成 JSON：

{ "unitId": "orc_grunt", "name": "兽人步兵", "hp": 32, "movePoints": 5, "weapons": [ { "name": "长剑", "damage": 8, "strikes": 3, "range": 1 } ], "resistances": { "blade": 20, "impact": 0, "fire": -10 } }

地形数据也被转成一个二维数组，每个元素包含移动消耗、防御加成和贴图编号。单位动画则麻烦一些，原版是逐帧 PNG 序列，我做了两种处理：保留关键姿势的静态帧做站立图，移动动画直接用 Canvas 的插值位移模拟，战斗动画先用简单的刀光色块代替。

数据转换的坑主要出现在编码上。原版文本是 UTF-8，但某些旧配置里混入了特殊空格和换行符，解析出来角色名末尾带奇怪字符。我后来在脚本里加了字符清洗，把常见不可见字符统一过滤，否则单位名在 Canvas 上画出来对不齐。

5. 移动端浏览器的三个真实深坑

项目进入真机测试后，各种"桌面浏览器好好的，手机一到就翻车"的问题如约而至。这里记三个印象最深的坑，每一个都花了我不少时间排查。

5.1 Canvas 画布缩放后的坐标漂移

我最初把 Canvas 画布设成固定尺寸，发现手机屏幕上地图特别小。后来加了 CSS 缩放，让画布撑满屏幕宽度。结果点击地图时，单位选中位置全部偏了。

根因是逻辑坐标和设备 CSS 坐标不一致。Canvas 的width/height属性是绘图缓冲区尺寸，而 CSS 的尺寸是页面显示尺寸。当两者不同时，点击事件返回的offsetX/offsetY是 CSS 像素，必须换算成 Canvas 内部像素才能命中正确的格子。

修正方式是在事件处理里做一次换算：

function toCanvasCoord(e) { const rect = canvas.getBoundingClientRect(); return { x: (e.clientX - rect.left) * (canvas.width / rect.width), y: (e.clientY - rect.top) * (canvas.height / rect.height) }; }

这个公式很简单，但如果你一开始没意识到 Canvas 内部坐标和显示坐标是两套系统，排查起来会非常绕。

5.2 长按唤出系统菜单：触摸交互的默认行为

回合制策略游戏里，玩家经常需要"长按一个格子查看信息"，或者在一个单位上按住不放思考下一步。但在移动端浏览器里，长按会触发系统级的选择菜单（复制、搜索、分享等），直接打断操作。

解决方案有两层。第一层是阻止默认事件：

canvas.addEventListener('contextmenu', (e) => e.preventDefault()); canvas.addEventListener('touchstart', (e) => e.preventDefault(), { passive: false });

第二层是在游戏内部实现自己的"长按计时器"：记录touchstart时间，如果 500ms 内没有touchmove超过阈值，就触发长按逻辑；一旦手指移动超过 10px，则转为拖动或取消。

这里特别要注意passive: false。浏览器默认把 touch 事件当作 passive（不阻止默认行为）以提高滚动性能，如果你要调用preventDefault，必须显式声明非 passive，否则控制台会报警告且拦截无效。

5.3 重绘风暴与内存抖动

最初版本每帧都会清空整个 Canvas 并重绘所有单位、地形和 UI 元素。在 PC 上没感觉，但手机上掉帧明显，而且内存曲线呈锯齿状飙升。

优化分三步走：

1. 静态地形缓存：地图格子在一场战斗内基本不变，我先把完整地形绘制到一张离屏 Canvas 上，每次重绘时先绘制这张缓存图，再叠加单位和高亮。
2. 脏矩形重绘：只有发生变化的位置才重绘。移动单位时，只清除该单位原来和现在所在格子的区域，重画这两个格子。
3. 控制重绘频率：战斗动画使用requestAnimationFrame驱动，但逻辑计算和 UI 刷新不每帧都做，只在状态变化后触发重绘。

这三步做完，手机上的帧率从 20 帧左右稳定到 60 帧，内存也不再疯涨。说真的，对于这种低频操作的回合制游戏，"一变化就重绘"比"固定 60 帧死循环"要合适得多，既省电又流畅。

6. 工程复盘与个人体会

项目能跑起来是一回事，能不能稳定复现 bug、方便后续扩展又是另一回事。最后的阶段我做了一些工程化收尾，这里也整理几条值得参考的经验。

6.1 用"战斗录像"代替肉眼调试

回合制游戏的 bug 经常藏在一连串操作之后：某个单位在特定地形被打残、撤退到某格、下一回合敌人在另一侧发起攻击……没有记录的话，你很难说清楚"刚才发生了什么"。

我给内核加了一个极简的事件日志系统：每次操作（移动、攻击、待机、结束回合）都会生成一条带时间戳的 JSON 记录，战斗结束后可以导出。出现 bug 时，把日志丢回一个"回放模式"，内核会逐条重放所有事件，复现每一步的状态变化。这比用户口述"我点了好多下就这样了"要高效得多。

实现回放的原理并不复杂：内核在收到事件时只改变状态，不关心事件从哪来。同一组事件输入，永远得到同一组状态输出。这也是前面"逻辑与表现分离"带来的巨大红利——没有这一层，回放功能根本没法做。

6.2 如果重新开始，我会在项目初期就做三件事

复盘整体进展，我觉得有几个决策如果早点定下来，能省不少时间。

• 先定数据格式，再写界面逻辑。我一开始先啃寻路算法，结果地图数据格式后来为了适配 JSON 转换又改了两轮，连带网格坐标系统也跟着调。
• 尽早把状态机完整落地。前三天用 if-else 走的弯路，如果第一周就写状态机，至少省两天。
• 真机调试从第一天开始，而不是等"电脑上完美了再上手机"。移动端浏览器的事件模型和桌面差异很大，越晚接入，返工越多。

6.3 这个项目给我留下的几个可复用资产

虽然这次只做了一个战斗系统，但里面的很多模块是通用的，后续做其他项目可以拿来即用：

• 六边形网格坐标库：基于立方体坐标，支持 BFS、范围计算、距离计算，约 200 行代码，不依赖任何库。
• 回合状态机模式：不只适合游戏，任何"用户分步操作 + 子步骤间有条件限制"的流程都可以用这个模式建模。
• Canvas 脏矩形渲染思路：静态场景离屏缓存 + 动态对象局部重绘，比无脑全量 clear 实用得多。

我现在的计划是基于这套内核继续扩展：先把完整的战役地图和单位招募接进来，再做本地存档，最后研究一下 WebRTC 联机对战的可行性。当然这些都是后话。

最后分享一个做这个项目体会最深的一点：把一个老旧但优秀的游戏内核搬到新平台，最难的往往不是代码，而是"克制"。克制住"把整个游戏都做出来"的冲动，克制住"上一个重型框架"的惯性，克制住"每帧都重绘"的直觉。想清楚最小范围、核心状态和输入边界，这个类别的移植项目其实可以做得很顺。如果你也有一个想搬到浏览器里的老游戏，别犹豫，拿我的路子做参考，动手试起来就对了。