1. 项目概述与核心价值

如果你正在用 Cocos Creator 3.8.0 搭配 Tiledmap 1.4.x 做游戏，尤其是 RPG、SLG 或者带点策略元素的类型，那么“AI寻路”这个功能大概率是你绕不开的坎。寻路做得好，角色移动行云流水，玩家体验丝滑顺畅；做得不好，角色就会卡墙角、走锯齿、原地鬼畜，直接劝退玩家。我之前写过一篇关于寻路系统搭建的“六合一”长文，讲了不少基础实现和A*算法原理。但文章发出去后，后台和社群里问得最多的，不是“怎么实现”，而是“为什么我的角色移动起来一顿一顿的？”、“参数怎么调才能让移动更自然？”。

这恰恰是寻路系统从“能用”到“好用”的关键一跃。实现一个基础的A*寻路脚本可能只需要几百行代码，但要让角色在各种复杂地图里移动得既聪明又流畅，背后是一整套参数调优的学问。这些参数就像汽车的悬挂和转向系统，调校好了，过弯平稳；调校不好，颠簸不断。网上能找到的教程，大多止步于算法实现，很少有一份能直接“抄作业”的参数对照表，告诉你每个参数动了会有什么效果，在什么场景下该用什么值。

所以，这篇“续前文”的文章，就是来解决这个痛点的。它是一份基于 Cocos Creator 3.8.0 和 Tiledmap 1.4.x 的AI寻路参数优化对照表。我不会再重复讲A*算法怎么写，而是假设你已经有了一个能跑起来的寻路系统，然后我们聚焦于那些控制寻路行为“手感”和“观感”的核心参数。我会把这些参数分成几大类，每一类都配上详细的说明、推荐值范围、调整后的效果对比，以及最重要的——调整背后的逻辑和适用场景。无论你是独立开发者还是团队里的TA（技术美术），这份对照表都能帮你快速定位问题，系统性地优化移动流畅度，让你的游戏角色真正“活”起来。

2. 寻路系统参数体系全解析

在开始调参之前，我们必须先建立一个清晰的认知：寻路系统的“流畅度”是一个综合结果，它由多个环节共同决定。我们可以把这些参数划分为三个层次：路径计算层、路径平滑与后处理层、移动执行层。每一层都有其独立的核心参数，它们环环相扣，共同决定了最终角色移动的“手感”。

2.1 路径计算层：寻路算法的“大脑”

这一层负责从起点到终点找出一条理论上可行的最短路径。核心是A*算法及其变种，参数主要影响计算的速度和路径的“基础形状”。

1. 移动代价（Cost）参数这是A*算法的核心。在网格（Grid）寻路中，每个格子都有一个移动代价G值。通常，平地代价为1，障碍物代价为无穷大（或一个极大值）。但为了更精细的控制，我们可以引入多种代价。

• 基础移动代价：默认是1。提高这个值（比如设为10），会让算法更“吝啬”步数，但计算量可能微增。一般保持1即可。
• 地形代价系数：这是优化的关键。例如，沼泽地格子代价设为3，道路格子代价设为0.8。在Tiledmap中，我们可以通过图块的自定义属性（如terrainCost）来标记，然后在A*的getCost函数中读取。调整这些系数，能引导AI优先走“好路”。

  注意：代价差异不宜过大。如果平地是1，沼泽是100，算法可能会为了绕开一点点沼泽而走出非常奇怪的远路。建议将不同地形的代价控制在1-5倍以内，以达到引导而非强迫的效果。

• 启发函数权重（Heuristic Weight）：A算法的F = G + H中的H（启发值）通常使用曼哈顿距离或欧几里得距离。有时我们会给H乘以一个权重W（如F = G + W * H）。W > 1时，算法会更倾向于快速向目标靠近（贪心），计算更快，但可能找到的不是最优路径；W = 1是标准A；W < 1时，会搜索更全面，路径更优，但速度慢。在游戏寻路中，为了性能，W常设为1.2到1.5，在保证路径“足够好”的前提下大幅提升搜索速度。

2. 寻路网格精度这由你的Tiledmap地图格子大小决定。例如，你的地图块（Tile）是32x32像素。

• 直接使用Tile网格：每个32x32的格子作为一个寻路节点。优点是简单，计算快。缺点是移动路径会呈现明显的“锯齿状”，角色永远在格子中心点之间跳转，非常不自然。
• 子网格划分（Sub-gridding）：将每个Tile再细分为更小的网格（如4x4，即每个节点8x8像素）。这能极大提升路径的精细度，使路径更贴近障碍物边缘，移动更平滑。但代价是节点数呈平方增长，寻路计算量剧增。对于中小型地图或静态障碍，这是一个非常有效的平滑化手段。
• 导航网格（NavMesh）：这是更高级的方案，将可行走区域划分为凸多边形。它能生成非常平滑自然的路径，且计算效率高。Cocos Creator社区有相关插件（如搜索内容中提到的gen_navmesh），可以将Tiledmap障碍物转换为NavMesh。这是追求高质量寻路的推荐方向，但其参数调优（如多边形最大顶点数、合并距离等）是另一个专业话题。

对照表：路径计算层核心参数

2.2 路径平滑与后处理层：优化“原始路径”

A*算法给出的原始路径往往是一串网格中心点的连线，直接用于移动会非常生硬。这一层负责对原始路径进行加工。

1. 路径点简化（Path Simplification）核心算法是漏斗算法（Funnel Algorithm）或视线检测（Raycasting）。目的是删除路径中不必要的中间点。

• 关键参数：拐角阈值（Corner Threshold）。当连续三个点形成的夹角大于某个阈值（如170度）时，认为中间点是冗余的，可以删除。这个阈值越小，简化越激进，路径点越少，移动越“直”，但可能在某些复杂角落丢失细节；阈值越大，保留的路径点越多，移动更精确但可能更迂回。
• 实操技巧：在移动层执行前，先对A*输出的路径数组做一次遍历简化。代码逻辑大致是：从起点开始，尝试用射线检测是否能“看到”后面的某个点而不碰撞障碍物，如果能，就跳过中间的所有点。

2. 路径平滑（Path Smoothing）在简化之后，路径点之间的连接仍然是直线。我们可以通过插值让路径变得圆滑。

• 贝塞尔曲线/样条平滑：这需要较多的计算，在动态环境中不常用。更游戏化的做法是让移动控制器来处理，即下一层的内容。
• 简单的拐角圆滑：在拐角处，不直接走到拐点，而是在距离拐点一定距离时就开始向新方向偏转。这可以通过在移动层加入“转向预览”来实现。

对照表：路径平滑层核心参数

2.3 移动执行层：控制“每一步”的体验

这是最终将路径转化为屏幕运动的一层，也是玩家直接感知“流畅度”的关键。

1. 移动速度与插值

• 恒定速度 vs 变速移动：直接给角色一个速度向量velocity是最简单的。但更自然的是加入加速度和减速度。靠近路径点或终点时减速，起步时加速，能让移动更有质感。
• 插值（Lerp）与平滑：使用Vec3.lerp或tween进行位置插值是常见的做法。这里的关键参数是插值系数（alpha）或平滑时间（smoothTime）。
  • 固定插值系数：如position = Vec3.lerp(position, targetPos, 0.1)。系数越大，跟进目标越快，但可能产生抖动；系数越小，移动越平滑但有延迟感。一个常见错误是每帧直接赋值position = targetPos，这会导致移动跳帧，极其不流畅。
  • 平滑阻尼（SmoothDamp）：类似Unity的Mathf.SmoothDamp，可以自己实现或使用Tween系统。它需要smoothTime（达到目标的大致时间）和maxSpeed参数。smoothTime是核心，通常设置在0.1s到0.3s之间，角色移动会带有轻微的“惯性”感，非常自然。

2. 朝向与旋转控制角色移动时，脸要朝着移动方向。这里也有大学问。

• 立即转向：node.angle = targetAngle。简单粗暴，效果很假。
• 插值转向：使用angle = cc.misc.lerp(angle, targetAngle, rotateSpeed * dt)。rotateSpeed（角速度）是关键。太快像抽搐，太慢像在滑行。通常，角速度应使得角色能在0.2-0.5秒内完成180度转向。
• 前瞻性转向（Look-ahead）：不要让角色只盯着下一个路径点转向。可以让他看向前方第2个或第3个路径点，这样在拐弯前就会提前开始转向，移动轨迹更圆滑。这是一个提升流畅度的高级技巧。

3. 动态避障与路径重算当角色移动过程中，预设路径上突然出现动态障碍（其他NPC、玩家），怎么办？

• 局部避障（Local Avoidance）：例如RVO（Reciprocal Velocity Obstacles）算法，但实现复杂。一个简化的游戏方案是：当检测到前方有动态障碍时，施加一个轻微的侧向力（Seek Force），让角色稍微绕行。这需要设置一个检测半径和避障力强度。
• 路径重算阈值：不要每帧都重算路径！代价太大。可以设置一个重算距离阈值。当角色偏离当前路径超过这个阈值（比如2个格子），或者每过一定时间（比如1秒），才触发一次完整的A*重算。

对照表：移动执行层核心参数

3. 实战调优：从“卡顿”到“丝滑”的排查流程

有了上面的参数对照表，我们就可以像老中医一样，针对不同的“症状”开“药方”了。以下是一个典型的调优流程：

症状1：角色移动“一蹦一蹦”，路径锯齿严重。

• 诊断：这是最经典的问题，根源在路径计算层的网格精度不足和移动执行层的插值不当。
• 排查与解决：
  1. 检查寻路网格：你的寻路节点是否就是Tiledmap的格子？如果是，尝试启用子网格划分。将每个32x32的Tile划分为4个16x16的小格子，重新生成寻路数据。你会发现路径立刻变得细腻很多。
  2. 检查移动插值：角色是否每帧直接position = nextPathPoint？如果是，改为使用平滑阻尼（SmoothDamp）。在Cocos Creator中，你可以用tween或自己实现一个：currentPos = lerp(currentPos, targetPos, smoothFactor)，其中smoothFactor是一个基于帧时间的较小值（如6 * dt）。
  3. 开启路径可视化：在调试模式下，将计算出的路径点用Graphics组件画出来。如果路径点本身就连成一条生硬的折线，那问题在1；如果路径点平滑但角色移动跳跃，那问题在2。

症状2：角色在拐弯处“打滑”或“急转”，显得不自然。

• 诊断：移动执行层的旋转控制不佳。
• 排查与解决：
  1. 调整角速度：降低旋转角速度。如果角色是720度/秒，尝试降到540或360。观察拐弯是否更柔和。
  2. 引入“转向前瞻”：这是质变的一步。修改你的移动逻辑，计算朝向时，不要只看下一个路径点path[i]，而是看path[i+lookAhead]（lookAhead设为2）。你会发现角色在接近拐点时就开始缓缓转向，走出一个圆润的弧线。
  3. 结合平滑阻尼：对旋转角度也使用平滑阻尼，而不是直接赋值。currentAngle = lerpAngle(currentAngle, targetAngle, rotateSmoothFactor)。

症状3：寻路过程卡顿，尤其是目标点远或单位多时。

• 诊断：路径计算层的性能瓶颈。
• 排查与解决：
  1. 增大启发函数权重(W)：将A*的H权重从1.0提高到1.2或1.3。这会显著减少搜索的节点数量，用轻微的非最优路径换取巨大的性能提升。对于游戏体验，玩家几乎感知不到这点路径长度的差异。
  2. 优化路径重算频率：检查是否在频繁重算路径。为每个移动单位增加一个“路径重算冷却计时器”，确保至少间隔0.5-1秒才重算一次。同时，使用距离阈值，只有偏离当前路径超过2个格子才触发重算。
  3. 考虑层级寻路（Hierarchical Pathfinding）：对于超大地图，这是终极方案。先在地图粗粒度网格（比如128x128一个大区）上寻路，找到大区路径，再在每个大区内进行精细寻路。这能极大降低搜索空间。

症状4：角色会“穿模”薄墙或卡在奇怪角落。

• 诊断：路径计算层的碰撞检测精度与移动执行层的碰撞体同步问题。
• 排查与解决：
  1. 检查寻路网格的碰撞数据：确保你的障碍物地图（从Tiledmap生成）准确地反映了视觉上的障碍。有时图块的碰撞框可能需要手动微调。在Tiledmap编辑器中，仔细检查障碍物图层的碰撞形状。
  2. 确保移动与物理同步：如果你使用了Cocos的物理引擎（如Builtin或Box2D），寻路移动和物理体的位置必须同步更新。最好以物理引擎的位置为权威，每帧根据物理体的位置来修正渲染节点的位置，而不是反过来。
  3. 增加路径简化中的安全边际：在进行视线检测简化路径时，检测的射线半径应略大于角色的碰撞半径（例如1.2倍），确保简化后的路径不会让角色太贴近障碍物。

4. 高级技巧与性能优化实录

当你调通了基础参数，移动已经比较流畅后，下面这些技巧可以让你的寻路系统更上一层楼。

4.1 利用Tiledmap自定义属性进行智能寻路Tiledmap的强大之处在于可以为每个图块（Tile）或每个图层（Layer）设置自定义属性。我们可以充分利用这一点。

• 为地形设置寻路代价：在Tiledmap中，为“草地”、“道路”、“沼泽”等地形图块设置一个moveCost属性（如1， 0.8， 3）。在Cocos Creator中加载地图时，读取这些属性并构建一个“代价网格”。A*算法在计算G值时，使用这个代价网格而非固定值1。这样AI就会自动偏好走道路，避开沼泽。
• 标记特殊区域：设置isWater（不可行走）、isSlow（减速区域）、isHidden（隐身区域）等属性。在寻路逻辑中，isWater的格子代价设为无穷大；当角色进入isSlow区域时，动态降低其移动速度；进入isHidden区域则触发隐身特效。这极大地增强了游戏玩法和策略深度。

4.2 多单位协同与队形移动当需要控制多个单位一起移动时（如RTS中的编队），直接让每个单位独立寻路会导致它们挤成一团。

• 主单位寻路，从单位偏移：只为主单位（或编队中心）计算一条路径。其他从单位的目标位置，是主单位路径点上对应的一个偏移位置（比如保持一个菱形或方形队形）。这样整个编队会沿着主路径整齐移动。
• 避免单位间碰撞：为每个移动单位添加一个简单的“分离力”。计算它与其他附近单位的向量，如果距离太近，就施加一个轻微的排斥力。这个力与寻路的“朝向力”合成，作为最终的速度方向。这能有效避免单位堆叠。

4.3 性能监控与动态降级在低端设备上，复杂的寻路可能成为性能杀手。我们需要有降级方案。

• 监控寻路耗时：在每次A*寻路开始和结束时记录时间。如果平均耗时超过一帧时间（比如16ms）的某个比例（如50%），就要警惕。
• 动态调整参数：当检测到性能压力大时，可以动态调整一些参数来降低计算量：
  • 降低寻路频率：将路径重算的最小间隔从0.5秒增加到1秒或2秒。
  • 降低寻路精度：从子网格切换回原始Tile网格进行寻路。
  • 减少同时寻路的单位数：对于屏幕外或非关键的单位，使用更简单的移动逻辑（如直接朝目标直线移动，遇到障碍再触发寻路）。

4.4 与动画系统的深度融合流畅的移动离不开动画的配合。不要让移动和动画各干各的。

• 速度驱动动画：角色的移动动画（走、跑、 idle）应由实际的速度大小来驱动和混合，而不是由输入按键。计算角色每帧的位移向量长度作为速度，用这个速度值去控制动画状态机的参数，实现从走到跑的平滑过渡。
• 转向驱动动画：对于需要转身动画的角色（如3D模型），使用旋转角速度来触发转身动画。当角速度超过一个阈值时，播放转身动画，同时用动画根运动（Root Motion）来部分控制位移，会使转向看起来非常自然。

调优是一个持续的过程，没有一劳永逸的“银弹”参数。最好的方法是建立你的参数配置表，为不同类型的角色（主角、小兵、Boss）预设不同的参数模板，并在实际游戏场景中反复测试、对比、微调。记住，最终的标准是玩家的主观感受——移动是否舒服、自然、符合预期。这份对照表为你提供了调整的杠杆和方向，但最终那个“手感”的甜点，需要你用玩家的眼睛和手去发现。