1. 项目概述当Laya游戏需要“聪明”的NPC在LayaAir引擎开发2D或3D游戏时尤其是RPG、SLG、塔防这类需要角色自主移动的游戏一个绕不开的核心需求就是如何让游戏里的NPC、怪物或者单位能够智能地找到从A点到B点的路径并且能优雅地绕开障碍物这就是我们常说的“寻路”Pathfinding。你可能尝试过用简单的直线移动但一堵墙、一棵树就能让角色卡住显得非常“傻”。你也可能手动预设好固定路线但一旦场景动态变化比如玩家建造了一堵墙预设路线就失效了。这时一个可靠、高效的AI寻路系统就成了项目从“玩具Demo”迈向“可玩产品”的关键一步。LayaAir本身是一个优秀的渲染与框架引擎但在复杂的AI寻路领域它并没有内置一个开箱即用的、功能完善的解决方案。官方提供的laya.ai包中的寻路模块相对基础面对复杂地形、动态障碍、多单位寻路等实际开发中的高频需求往往需要开发者投入大量精力进行二次开发和优化。因此寻找并集成一套成熟的第三方寻路方案或者基于成熟算法自建一套几乎是中大型Laya游戏的必经之路。这个“Laya游戏开发中AI寻路解决方案”要解决的就是在Laya生态下如何为游戏角色赋予“认路”的智慧。它不仅仅是调用一个findPath()函数更涉及到网格划分、算法选型、性能优化、动态障碍处理、与Laya渲染循环的整合、不同游戏类型如2D俯视角、3D第三人称的适配等一系列环环相扣的问题。接下来我将结合多年项目实战经验为你拆解构建这套方案的核心思路、技术细节与避坑指南。2. 寻路方案核心选型网格、算法与数据结构在动手写代码之前选对底层方案决定了后续开发的效率和最终效果的上限。寻路方案的核心三要素是世界表示法用什么描述可行走区域、寻路算法用什么计算路径、数据结构如何高效存储和查询。2.1 世界表示法网格Grid vs 导航网格NavMesh vs 点阵Waypoint对于Laya游戏尤其是2D游戏或俯视角3D游戏网格Grid是最常见、最易上手的选择。它将游戏世界划分为均匀的二维方格在3D中可能是体素每个格子标记为“可行走”或“不可行走”。其优势在于实现简单、概念直观、动态更新障碍物非常方便只需修改格子状态。Laya官方laya.ai.PathFinder默认就支持网格寻路。缺点是路径不够平滑锯齿状且内存占用与网格分辨率成正比大世界高精度网格开销大。导航网格NavMesh在3D游戏中更为强大。它用一系列凸多边形来覆盖所有可行走区域角色可以在多边形内部任意点自由移动路径天生平滑且更符合真实地形。Unity的NavMesh系统就是典型代表。在Laya中实现完整的NavMesh需要较复杂的几何计算和第三方库支持如recast-detour的JavaScript端口复杂度高但效果最好适合复杂的3D场景。点阵Waypoint则是在场景中手动或自动放置一系列路径点角色只能在点与点之间移动。它非常轻量适合固定路线明显的游戏如赛车、平台跳跃但灵活度最低无法处理动态障碍。实操心得对于大多数Laya项目尤其是刚接触寻路的团队从基于网格的A*算法开始是最稳妥的。它足够解决80%的问题社区资源丰富调试可视化也容易。我们可以先用较粗的网格保证性能后期再考虑结合导航网格或分层寻路HPA*进行优化。2.2 寻路算法为什么A*是绝对主力谈到网格寻路就离不开A*A-Star算法。它之所以是业界标准是因为它在“盲目”的Dijkstra算法和“激进”的贪心最佳优先搜索Greedy Best-First-Search之间取得了完美平衡。简单来说A*为每个待评估的网格节点计算一个代价函数F G H。G值从起点移动到当前节点的实际代价。H值启发式估计从当前节点到终点的预估代价常用曼哈顿距离适用于4方向移动或欧几里得距离适用于8方向或任意方向。F值总预估代价。算法总是优先探索F值最小的节点从而高效地找到最短路径。// 一个非常简化的A*节点类结构示意 class AStarNode { constructor(x, y) { this.x x; // 网格X坐标 this.y y; // 网格Y坐标 this.g 0; // 起点到本节点的实际代价 this.h 0; // 本节点到终点的预估代价 this.f 0; // g h this.parent null; // 父节点用于回溯路径 this.walkable true; // 是否可行走 } }相较于广度优先搜索BFSA通过启发函数H大幅减少了需要搜索的节点数量速度更快。相较于深度优先搜索DFSA能保证找到最优解如果启发函数H是可采纳的即从不高估实际代价。注意事项启发函数H的选择直接影响效率和路径“自然度”。在允许斜向移动的8方向网格中使用对角线距离Chebyshev距离或Octile距离会比简单的欧几里得距离更准确计算也更快。同时确保H永远不大于实际剩余代价否则A*可能找不到最优解。2.3 数据结构优化开放列表OpenList的性能关键A*算法需要频繁地从“开放列表”待考察节点集合中取出F值最小的节点。如果使用普通的数组每次查找都需要遍历性能是O(n)在大型网格上将是灾难。因此优先队列Priority Queue特别是二叉堆Binary Heap是实现开放列表的标准数据结构。插入和删除最小元素的操作复杂度为O(log n)能极大提升A*的性能。在JavaScript中我们可以自己实现一个最小堆或者利用一些库。// 基于数组的二叉堆最小堆简化实现用于开放列表 class MinHeap { constructor() { this.heap []; } // 插入节点并上浮调整 push(node) { this.heap.push(node); this._siftUp(this.heap.length - 1); } // 弹出堆顶F值最小的节点 pop() { if (this.heap.length 0) return null; const top this.heap[0]; const bottom this.heap.pop(); if (this.heap.length 0) { this.heap[0] bottom; this._siftDown(0); } return top; } // 上浮和下沉调整方法省略... }此外还需要一个快速查找节点状态的数据结构通常用一个二维数组或字典来映射网格坐标到节点对象用于判断节点是否在开放或关闭列表中这就是“关闭列表”的实质它避免了昂贵的数组查找。3. 在Laya中实现网格A*寻路从理论到代码理解了核心原理我们开始在Laya项目中落地。我们将构建一个比官方更灵活、功能更完善的网格A*寻路模块。3.1 构建寻路网格与地图数据首先我们需要将游戏世界转换为网格。这通常需要一个“地图数据”它可能来自TileMap的碰撞层、或者由美术在编辑器中绘制、或者通过代码动态生成。// Laya中一个简单的网格寻路管理器 class GridPathfinding { private _grid: number[][]; // 二维数组0可走1不可走障碍 private _gridWidth: number; private _gridHeight: number; private _cellSize: number; // 每个网格单元的世界坐标大小 /** * 初始化网格 * param width 网格列数 * param height 网格行数 * param cellSize 单元格大小像素或世界单位 * param obstacleData 初始障碍数据可后续动态更新 */ constructor(width: number, height: number, cellSize: number, obstacleData?: number[][]) { this._gridWidth width; this._gridHeight height; this._cellSize cellSize; this._grid []; // 初始化所有格子为可行走 for (let i 0; i height; i) { this._grid[i] []; for (let j 0; j width; j) { this._grid[i][j] 0; // 0表示可行走 } } // 如果有初始障碍数据则设置 if (obstacleData) { this.setObstacles(obstacleData); } } // 世界坐标转换为网格坐标 worldToGrid(wx: number, wy: number): {x: number, y: number} { return { x: Math.floor(wx / this._cellSize), y: Math.floor(wy / this._cellSize) }; } // 网格坐标转换为世界坐标通常返回格子中心点 gridToWorld(gx: number, gy: number): {x: number, y: number} { return { x: gx * this._cellSize this._cellSize * 0.5, y: gy * this._cellSize this._cellSize * 0.5 }; } // 动态设置或清除障碍 setObstacle(gridX: number, gridY: number, isObstacle: boolean): void { if (this.isInsideGrid(gridX, gridY)) { this._grid[gridY][gridX] isObstacle ? 1 : 0; } } // ... 其他工具方法 }3.2 实现A*寻路核心算法接下来我们实现A*算法的核心。这里我们实现一个支持8方向移动允许斜走的版本并考虑斜走代价略高符合真实移动。class AStarFinder { private _grid: number[][]; private _heuristic: (dx: number, dy: number) number; // 启发函数 private _diagonalCost: number Math.SQRT2; // 斜向移动代价约1.414 constructor(grid: number[][]) { this._grid grid; // 默认使用欧几里得距离作为启发函数对于8方向使用对角线距离(octile)更优 this._heuristic function(dx, dy) { // Octile distance: D * (dx dy) (D2 - 2*D) * min(dx, dy) // 假设直线代价D1对角线代价D2√2 const D 1; const D2 this._diagonalCost; dx Math.abs(dx); dy Math.abs(dy); return D * (dx dy) (D2 - 2 * D) * Math.min(dx, dy); }.bind(this); } findPath(startGrid: {x: number, y: number}, endGrid: {x: number, y: number}): {x: number, y: number}[] { // 0. 边界检查起点终点是否合法、是否相同、是否不可行走 if (!this._isWalkable(startGrid.x, startGrid.y) || !this._isWalkable(endGrid.x, endGrid.y)) { return []; } if (startGrid.x endGrid.x startGrid.y endGrid.y) { return [startGrid]; } // 1. 初始化开放列表二叉堆和关闭集合 const openList new MinHeap(); const closedSet new Set(); // 使用字符串键 x,y 来快速查找 const nodeGrid: AStarNode[][] []; // 存储所有节点信息 // 初始化节点网格 for (let y 0; y this._grid.length; y) { nodeGrid[y] []; for (let x 0; x this._grid[0].length; x) { nodeGrid[y][x] new AStarNode(x, y, this._grid[y][x] 0); } } const startNode nodeGrid[startGrid.y][startGrid.x]; const endNode nodeGrid[endGrid.y][endGrid.x]; startNode.g 0; startNode.h this._heuristic(Math.abs(startNode.x - endNode.x), Math.abs(startNode.y - endNode.y)); startNode.f startNode.g startNode.h; openList.push(startNode); // 8个方向的向量上、下、左、右、左上、右上、左下、右下 const directions [ {x: 0, y: -1}, {x: 0, y: 1}, {x: -1, y: 0}, {x: 1, y: 0}, {x: -1, y: -1}, {x: 1, y: -1}, {x: -1, y: 1}, {x: 1, y: 1} ]; // 2. 主循环 while (!openList.isEmpty()) { const currentNode openList.pop(); // 取出F值最小的节点 const nodeKey ${currentNode.x},${currentNode.y}; closedSet.add(nodeKey); // 找到终点了 if (currentNode endNode) { return this._retracePath(startNode, endNode); } // 3. 遍历邻居节点 for (const dir of directions) { const neighborX currentNode.x dir.x; const neighborY currentNode.y dir.y; // 检查邻居是否有效且可行走 if (!this._isInsideGrid(neighborX, neighborY) || !this._isWalkable(neighborX, neighborY)) { continue; } const neighborNode nodeGrid[neighborY][neighborX]; const neighborKey ${neighborX},${neighborY}; if (closedSet.has(neighborKey)) { continue; // 已在关闭列表中跳过 } // 计算从当前节点移动到邻居节点的代价 // 如果是斜向移动检查对角线是否被阻挡防止“切墙角” const isDiagonal dir.x ! 0 dir.y ! 0; let moveCost isDiagonal ? this._diagonalCost : 1; if (isDiagonal) { // 如果斜角方向的两个相邻格子至少有一个是障碍则不允许斜向移动 const c1Walkable this._isWalkable(currentNode.x dir.x, currentNode.y); const c2Walkable this._isWalkable(currentNode.x, currentNode.y dir.y); if (!c1Walkable || !c2Walkable) { continue; } } const newG currentNode.g moveCost; // 如果邻居不在开放列表或者找到更优路径 if (!neighborNode.isInOpenList || newG neighborNode.g) { neighborNode.g newG; neighborNode.h this._heuristic(Math.abs(neighborX - endNode.x), Math.abs(neighborY - endNode.y)); neighborNode.f neighborNode.g neighborNode.h; neighborNode.parent currentNode; if (!neighborNode.isInOpenList) { neighborNode.isInOpenList true; openList.push(neighborNode); } else { // 如果节点已在堆中且G值更新需要调整堆的位置这里简化处理实际需要decreaseKey操作 // 一个简单但低效的方法是重新插入因为JavaScript堆实现通常不提供decreaseKey。 // 更好的做法是记录节点在堆中的索引并实现上浮。 openList.updateItem(neighborNode); // 假设我们的堆支持更新 } } } } // 开放列表为空未找到路径 return []; } private _retracePath(startNode: AStarNode, endNode: AStarNode): {x: number, y: number}[] { const path: {x: number, y: number}[] []; let currentNode: AStarNode | null endNode; while (currentNode ! null currentNode ! startNode) { path.unshift({x: currentNode.x, y: currentNode.y}); // 从终点向前插入 currentNode currentNode.parent; } path.unshift({x: startNode.x, y: startNode.y}); // 加入起点 return path; } private _isInsideGrid(x: number, y: number): boolean { return x 0 x this._grid[0].length y 0 y this._grid.length; } private _isWalkable(x: number, y: number): boolean { return this._isInsideGrid(x, y) this._grid[y][x] 0; } }3.3 路径平滑与角色移动A*找到的路径是基于网格中心的折线直接让角色按这个路径移动会产生生硬的“格子步”感。我们需要进行路径平滑。最简单的平滑方法是拐点筛选从起点开始检查当前点到后续某个点之间是否有直接视线无碰撞如果没有障碍就跳过中间点。这可以消除路径中的冗余拐点。// 简单的视线检测平滑 function smoothPath(originalPath: {x: number, y: number}[], grid: GridPathfinding): {x: number, y: number}[] { if (originalPath.length 2) return originalPath; const smoothed: {x: number, y: number}[] []; let currentIndex 0; smoothed.push(originalPath[currentIndex]); while (currentIndex originalPath.length - 1) { let furthestVisible currentIndex 1; // 从当前点向后找看最远能无碰撞连接到哪个点 for (let i currentIndex 2; i originalPath.length; i) { if (this._hasLineOfSight(originalPath[currentIndex], originalPath[i], grid)) { furthestVisible i; } else { break; // 一旦遇到障碍停止 } } smoothed.push(originalPath[furthestVisible]); currentIndex furthestVisible; } return smoothed; } // Bresenham算法检查两点间网格是否全部可通行 private _hasLineOfSight(start: {x: number, y: number}, end: {x: number, y: number}, grid: GridPathfinding): boolean { let x0 start.x, y0 start.y; let x1 end.x, y1 end.y; const dx Math.abs(x1 - x0); const dy Math.abs(y1 - y0); const sx x0 x1 ? 1 : -1; const sy y0 y1 ? 1 : -1; let err dx - dy; while (true) { // 检查当前网格点是否可行走 if (!grid.isWalkable(x0, y0)) { return false; } if (x0 x1 y0 y1) break; const e2 2 * err; if (e2 -dy) { err - dy; x0 sx; } if (e2 dx) { err dx; y0 sy; } } return true; }得到平滑后的世界坐标路径点后就可以使用Laya的Tween或自己写移动逻辑让角色逐点移动了。记得要处理到达每个路点的小范围容差以及移动中的旋转朝向LookAt问题。4. 性能优化与高级特性实战当游戏中有大量单位同时寻路时基础的A*可能成为性能瓶颈。以下是一些关键的优化策略和高级功能实现思路。4.1 性能优化四板斧空间换时间路径缓存与共享。对于静态场景中频繁请求的相同起点终点比如所有小怪出生点走向玩家可以缓存计算结果。对于多个单位走向同一目标如RTS中所有士兵攻击一个建筑可以使用流场寻路Flow Field或Dijkstra算法一次性计算整个网格到目标点的代价然后每个单位根据本地代价梯度移动即可这比每个单位单独跑A*高效得多。降低搜索规模使用更粗的导航网格Hierarchical Pathfinding。先在一个粗糙的低分辨率网格上进行高层寻路找到大致区域再在目标区域的高精度网格上进行精细寻路。这能极大减少搜索节点数。算法优化使用更高效的A*变种。Jump Point Search (JPS)算法在均匀网格上可以跳过大量对称路径特别适合无障碍或障碍稀疏的网格能提升一个数量级的性能。但在障碍密集的动态环境中优势不明显。限制与异步避免卡顿。为单次A*搜索设置最大迭代次数或时间预算超时则返回当前最优路径或失败。将耗时的寻路计算放入Web Worker中异步执行避免阻塞主线程导致游戏卡顿。这是提升游戏流畅度的关键。// 伪代码在Laya中使用Web Worker进行异步寻路 class AsyncPathFinder { private _worker: Worker; constructor() { // 假设寻路Worker代码在pathfinder.worker.js中 this._worker new Worker(pathfinder.worker.js); this._worker.onmessage (e) { const { taskId, path } e.data; // 根据taskId找到对应的回调函数并处理路径 this._handlePathResult(taskId, path); }; } requestPathAsync(start, end, callback): number { const taskId this._generateTaskId(); this._worker.postMessage({ type: findPath, taskId: taskId, start: start, end: end, gridData: this._grid.getData() // 传递网格数据 }); // 存储callback等待worker返回结果后调用 this._pendingTasks[taskId] callback; return taskId; } }4.2 处理动态障碍物游戏中的障碍物常常是动态的如可破坏的墙、玩家建造的建筑。我们的寻路系统必须能快速响应。实时更新网格当动态障碍物出现或消失时立即调用GridPathfinding.setObstacle()更新对应网格状态。局部重规划对于正在移动中的单位如果前方路径上突然出现新障碍不需要从头开始寻路。可以从当前位置开始执行一次目标不变的A*搜索。因为大部分旧路径可能仍然有效局部重规划比全局重规划快得多。避障与碰撞寻路解决的是宏观路径微观上的单位间避免碰撞还需要局部避障Local Avoidance算法如RVOReciprocal Velocity Obstacles或其简化版。这通常与寻路系统配合使用寻路给出大方向局部避障处理瞬间的拥挤和穿插。4.3 不同游戏类型的适配要点2D俯视角/等距视角这是网格A*最自然的应用场景。注意网格坐标与等距世界坐标的转换。移动时角色的速度、动画需要与网格移动同步。3D场景如果地面不平坦简单的2D网格可能不够。需要考虑高度图Heightmap或真正的3D导航网格。移动时角色的Y坐标需要根据路径点所在位置的地形高度进行插值避免“穿地”或“漂浮”。RTS即时战略游戏海量单位是最大挑战。必须采用流场寻路Flow Field或分层寻路HPA*。同时要处理单位编队移动、保持阵型等高级AI行为。RPG/ARPG游戏NPC的寻路可能还需要结合行为树Behavior Tree或状态机根据不同的AI状态巡逻、追击、逃跑选择不同的寻路目标或参数。5. 常见问题、调试技巧与避坑指南在实际开发中你会遇到各种各样奇怪的问题。这里记录一些典型的“坑”和解决方法。5.1 寻路问题排查清单问题现象可能原因排查与解决思路角色卡住不动不寻路1. 起点或终点被标记为障碍。2. 起点终点相同。3. 寻路算法返回空数组。4. 移动逻辑未正确触发或路径点列表为空。1. 打印起点终点的网格坐标和 walkable 状态。2. 检查寻路函数返回值确保是有效路径。3. 在场景中可视化网格和障碍物确认数据正确。角色移动路径很“蠢”绕远路或贴墙走1. 启发函数 H 值权重不合适或计算有误。2. 移动代价G值设置不合理如斜向移动代价过高。3. 路径平滑算法未启用或失效。4. 网格精度太低无法描述狭窄通道。1. 检查 H 值计算函数确保其可采纳不高估。2. 调整斜向移动代价通常设为 sqrt(2) ≈ 1.414。3. 启用并调试路径平滑函数检查视线检测是否因障碍物判断太严格而失败。4. 适当提高网格分辨率或对关键区域使用更高精度的网格。大量单位同时寻路时游戏严重卡顿1. 主线程同步进行复杂A*计算。2. 未对相同寻路请求进行缓存。3. 网格过大算法搜索节点过多。1.必须将寻路放入 Web Worker。2. 实现路径缓存机制对于静态场景的相同请求直接返回缓存结果。3. 考虑使用更粗的导航网格进行分层寻路或改用流场寻路处理群体移动。动态障碍物更新后单位仍走被堵住的旧路1. 单位持有的路径是旧的未因障碍物更新而重新规划。2. 局部重规划逻辑未触发或失败。1. 为每个移动单位增加“路径有效性检查”定期或当靠近旧路径下一点时检测前方是否畅通不通则触发重寻路。2. 实现一个全局或局部的“导航网格更新事件”系统通知受影响单位重新规划。单位移动时“抖动”或频繁轻微调整方向1. 到达路径点的判断容差太小。2. 每帧移动速度不一致帧率影响。3. 局部避障与全局路径的指令冲突。1. 增大“到达”容差例如距离目标点小于0.1个单位即视为到达。2. 使用基于时间的移动velocity * deltaTime而非每帧固定距离。3. 确保局部避障的力度适中不要过度偏离全局路径或者让局部避障只处理非常近的威胁。5.2 调试与可视化技巧“看不见”的寻路逻辑是调试的难点。必须让它们可视化。绘制调试网格在Laya的渲染后阶段Laya.stage.on监听Event.RENDER后使用Graphics绘制网格线、用不同颜色填充可行走/不可行走格子、高亮显示当前寻路搜索过的节点开放列表和关闭列表以及最终计算出的路径。这是最直接的调试手段。关键数据打印在寻路开始时打印起点、终点坐标和状态寻路结束后打印路径长度、搜索节点数、耗时。这有助于性能分析和逻辑验证。录制与回放对于偶发的寻路异常可以记录下发生问题前后几帧的游戏状态单位位置、障碍物状态、寻路请求参数便于离线复盘。5.3 我踩过的几个“坑”“切墙角”问题早期实现8方向A*时没有检查斜向移动时相邻格子的阻挡情况导致单位可以紧贴着障碍物的对角线“挤”过去看起来像是穿过了墙角。解决方法就是在斜向移动前判断(xdx, y)和(x, ydy)两个格子是否都可通行。Web Worker数据传递开销第一次使用Web Worker时每帧都把巨大的网格二维数组通过postMessage传递造成了巨大的序列化/反序列化开销。后来改为只在初始化时传递一次网格数据后续只传递变化的部分delta或者使用Transferable Objects如ArrayBuffer来传递数据性能提升显著。移动与动画不同步寻路系统给出的路径点世界坐标直接用来驱动角色的x, y属性。但角色的移动动画播放速度是固定的导致角色可能“滑步”。解决办法是根据角色移动速度计算每帧应播放的动画帧或者使用动画状态机根据实际速度混合不同的移动动画走、跑、慢走。构建一个健壮的Laya AI寻路解决方案是一个从基础算法到工程优化再到与具体游戏逻辑深度融合的过程。它没有唯一的“标准答案”但遵循“网格/A*打底、异步计算保流畅、动态更新要及时、高级需求再升级”这条路径能让你在大多数项目中稳步推进。最终一个优秀的寻路系统会让游戏世界的居民真正“活”起来而这正是沉浸感的重要来源之一。
