单个 NPC 能从城外走进城内不代表十个 NPC 也能稳定通过同一座城门。常见情况是一个角色测试完全正常人数增加后却排成长队、互相推挤甚至在路径查询显示成功时仍然停在桥头或门口。先给结论“能算出路径”和“多人能稳定通行”是两项不同的验收。前者主要检查 NavMesh 是否连续、起点和目标是否可达后者还要检查 Agent 尺寸、局部避障、动态障碍、入口吞吐量和排队规则。本文固定一条测试路线城外道路 → 桥面 → 城门 → 城内广场排查前先固定 NPC 数量、出生点、目标点、城门宽度、移动速度和相机路线。只有测试条件一致修改前后的结果才有可比性。道路、桥梁和城墙可以帮助我们理解路线层级但不能证明导航已经连通。图注大尺度道路网络可以建立 NPC 路线设想导航网格、Agent 尺寸、动态避障与城门吞吐量仍需运行测试。这张素材不能证明画面存在真实关卡、城门可进入、道路具有碰撞、NavMesh 已生成或 NPC 能够寻路。画面中的“Complete Game Environment”也不是运行证据。本文只借它说明路线层级不把概念图当成可验收场景。一、显示可行走区域先找断缝和窄口常见现象NPC 在城外道路上移动正常到桥头、坡道、台阶、门槛或城门边缘时突然停下。路径可能直接失败也可能绕向一条并不存在的远路。为什么会这样NavMesh导航网格是引擎根据碰撞几何、坡度、台阶高度和 Agent 配置生成的可行走区域。视觉上连在一起的道路不一定在导航层面连续。例如桥面与两端地面之间存在很小的高度差门槛高于代理允许跨越的高度坡面超过最大可行走坡度城门两侧碰撞体挤占了通道两块导航区域看似接触实际没有建立连接。怎么检查打开 NavMesh 可视化沿固定路线逐段检查城外道路、桥头、桥面、坡道、门槛和城内广场。不要只看绿色覆盖面积要记录第一次中断的位置以及中断前后所属的导航区域。还可以做一次路径查询对照城外道路到桥头桥头到城门内侧城门内侧到广场城外道路直接到广场。前三段都成功、第四段失败说明问题可能出在区域连接或查询配置某一短段已经失败则优先修复对应位置。Epic 官方的基本寻路文档说明了 NavMesh 如何根据场景碰撞生成可行走空间。该资料用于解释机制不代表本文案例已经在 Unreal Engine 中运行。二、用不同 Agent 尺寸复核城门净宽常见现象小体型 NPC 可以通过中大型 NPC 到门口就停角色的视觉模型看起来能挤过去导航却判定无路。为什么会这样门洞的视觉净宽不等于导航系统认可的可用宽度。NavMesh 生成时会结合 Agent 半径、碰撞边界和安全间距收缩可行走区域。角色胶囊更宽门洞两侧的导航边界也会更靠近中间。因此只把可见门框拉宽不一定能解决问题。真正影响通行的可能是隐藏碰撞盒、导航生成参数或者角色使用了错误的 Agent 配置。怎么检查准备小、中、大三组 Agent 配置分别生成或查询同一座城门记录项小型 Agent中型 Agent大型 Agent角色胶囊半径角色胶囊高度导航 Agent 半径城门碰撞净宽路径查询结果实际通行结果如果某一档 Agent 的 NavMesh 在城门处直接消失重点检查尺寸和碰撞如果路径存在但角色仍被挡住则继续检查角色胶囊、门扇碰撞和局部避障。三、区分改变导航的动态障碍和临时占位物常见现象城门打开时能够通行门扇、车辆或箱子出现后路线突然被切断关闭动态导航影响后NPC 又会直接撞向障碍。为什么会这样动态物体可能有两种不同职责改变导航区域例如关闭的城门确实让该通道不可用需要更新或切割 NavMesh只参与局部避障例如短暂停靠的推车代理可以减速、绕行或等待不一定要重新生成整片导航。如果把临时物体都设为导航切割障碍场景会频繁重建如果所有动态物体都不影响导航路径系统又会继续把 NPC 引向被占用的空间。怎么检查对门扇、车辆和箱子分别做三组测试不影响导航只保留碰撞参与局部避障修改或切割 NavMesh。记录路径变化、导航重建时间、角色实际位置和是否发生穿透。关门、开门、移除障碍都要单独测试不能只验证场景加载后的初始状态。四、检查局部避障与代理占位常见现象每个 NPC 单独都能到达城内广场十个 NPC 同时进入城门时却开始互相推挤、原地振荡或者两组人迎面相遇后完全堵死。为什么会这样全局路径主要回答“从起点到终点有没有路线”局部避障要在运行中处理邻居、速度和短距离碰撞预测。下面这些参数不匹配都可能让路径正确但移动失败期望速度过高邻居检测半径过小或过大停止距离与角色胶囊不一致多个代理使用相同优先级转向加速度不足无法及时调整双向人流同时抢占同一窄口。怎么检查固定城门宽度分别用 1、5、10 个 NPC 测试。每轮只改一个参数记录最大同时通过人数第一个 NPC 通过时间最后一个 NPC 通过时间最大等待时间是否发生振荡、反复回头或相互穿透。不要用“提高移动速度”掩盖拥堵。速度越高代理越难在狭窄区域及时调整推挤和振荡反而可能更明显。五、给城门增加等候点、通行槽位和超时改道常见现象城门本身可以通行但所有 NPC 都在入口前争抢同一个位置。后方人群越积越多最终把桥头和城外主路一起堵住。为什么会这样NavMesh 和局部避障不会自动替项目设计完整的入口调度。城门、闸机、窄桥和单人楼梯都存在吞吐量上限需要额外的排队规则。怎么处理可以为城门增加三层控制等候点放在不会阻塞主路的位置引导未取得通行资格的 NPC 排队通行槽位例如一次只允许两名 NPC 进入门洞超时改道超过等待阈值后查询备用城门或重新分配目标。建议为每个代理输出agent_id | path_status | gate_id | slot | wait_time | reroute_reason有了这些字段才能区分四种状态没有路径、有路径但没有槽位、被动态障碍阻塞、达到超时阈值后主动改道。排队系统也不能只在 UI 上显示号码。取得槽位、进入门洞、离开门洞和释放槽位应当对应明确事件否则一个异常退出的 NPC 可能永久占用通道。六、测试动态重建并在目标设备上复测常见现象编辑器里偶尔能够通过打包后或人数增加后却出现长时间等待、路径失效和明显掉帧。门已经打开NPC 仍沿用关闭时的旧路线。为什么会这样动态导航重建、批量路径查询和局部避障都需要 CPU 时间。只在编辑器里测试一个 NPC无法反映多人并发也无法验证关门、开门和移除障碍后的更新时延。大场景如果采用分区加载或只在代理附近生成导航还会出现新的边界问题当前区域有路下一块导航尚未准备好NPC 到区域边缘后就停止。怎么检查至少建立以下测试矩阵NPC 数量城门打开城门关闭移除障碍11030每格记录路径查询耗时、CPU 帧时间、导航更新完成时间、最大等待、通过人数和失败数。开发机通过后还要在最低目标设备上沿相同路线复测。如果项目只生成局部导航还要记录导航区块加载时间、代理跨区时的等待策略以及新区块加载失败后的回退方式。七、六项验收卡先判断“没路”还是“通不过”1. 导航连续城外道路、桥面、城门和城内广场是否由连续 NavMesh 连接第一次断点位于哪里2. 尺寸匹配小、中、大 Agent 是否分别通过角色胶囊、导航 Agent 和门洞碰撞是否使用一致的尺度基准3. 障碍分类门扇、车辆和箱子中哪些需要改变 NavMesh哪些只参与局部避障状态变化后多久生效4. 避障稳定多人进入门洞时速度、邻居半径、停止距离和优先级能否保持稳定间距5. 入口调度是否设置等候点、通行槽位、最大等待时间和备用路线日志能否解释每个 NPC 为什么等待6. 动态重建与性能在不同人数、城门状态和目标设备上导航能否及时更新CPU 帧时间和最大等待是否在项目预算内如果需要整理大场景中的道路、桥梁、城门和区域关系可以使用世界模型作为空间构思入口。但场景生成不能替代 NavMesh、Agent 避障、动态重建和目标设备性能测试。八、路径成功不等于入口吞吐合格NPC 堵在城门口时不要先把移动速度调快。更可靠的排查顺序是显示 NavMesh检查道路、桥面和城门是否连续用不同 Agent 尺寸复核实际净宽区分导航切割障碍和临时占位物检查局部避障与代理占位为狭窄入口增加排队、槽位和超时改道在不同人数、障碍状态和目标设备上复测动态重建与性能。完成这六步后才能判断问题究竟是“根本没有路径”还是“路径存在但入口吞吐量不足”。你的 NPC 更常卡在城门、桥头还是动态障碍出现后突然找不到路