1. 项目概述从寻路到智能移动的进化在虚幻引擎UE里做AI移动很多开发者可能还停留在“让AI从A点走到B点”的初级阶段。确实NavigationSystem导航系统最基础的功能就是寻路它帮你解决了“怎么走”的问题。但如果你做的项目里有超过一个的AI单位或者你的AI需要在复杂、动态的环境中移动比如一个熙熙攘攘的集市、一个战术小队执行任务或者是一群受惊的动物四散奔逃你就会发现单纯的寻路远远不够。它会带来AI互相卡位、穿模、移动僵硬得像排队买票一样不自然的问题。这就是我们今天要深入探讨的核心如何利用UE的NavigationSystem超越基础的寻路打造出真正“智能”的、能感知环境与同伴的AI移动行为。关键词是RVOReciprocal Velocity Obstacles相互速度障碍避让和人群管理Crowd Manager。这不仅仅是让AI不撞墙更是让它们能像真实生物一样在移动中做出合理的决策——礼让、绕行、跟随、分散。我接手过不少需要大量AI同屏的项目从RTS的单位控制到开放世界的NPC人流踩过的坑让我深刻意识到一套好的移动逻辑是游戏体验的“隐形守护者”它不显眼但一旦出问题玩家会立刻感到出戏。简单来说我们将要搭建的是一套分层级的智能移动方案底层是NavigationSystem提供的可靠寻路网格中层是RVO避让负责处理AI之间的瞬时碰撞避免让移动平滑自然上层是人群管理或自定义逻辑用于实现更高级的群体行为如分流、跟随、保持队形等。这个方案能显著提升你游戏中AI的“智商”和可信度无论是对于沉浸式叙事还是对于需要精确单位操控的游戏类型都至关重要。2. 导航系统的核心架构与设计思路在动手写代码或摆弄蓝图之前我们必须先理解UE NavigationSystem的骨架。它不是黑盒而是一套设计精巧的模块化系统理解其架构能让你在定制化时游刃有余。2.1 NavigationSystem 组件构成与数据流UE的导航系统主要由以下几部分构成它们协同工作完成了从请求到移动的完整链条NavMesh导航网格这是所有寻路的基础。它是一张覆盖在可行走区域上的多边形网格通常是三角形由NavMeshBoundsVolume生成。AI只能在NavMesh覆盖的区域内寻路。你需要理解的是NavMesh是静态或半静态的虽然可以通过NavModifierVolume动态影响其成本但它的生成和更新有一定开销。NavigationSystem系统的总调度中心。它是一个UWorldSubsystem负责管理NavMesh的查询、更新以及处理来自AAIController或CharacterMovementComponent的寻路请求。我们大部分的高阶操作如设置避让参数、管理人群都是通过它与UNavigationSystemV1或其派生类交互。AIController 与 PathFollowingComponentAAIController是AI的“大脑”它持有UPathFollowingComponent。当你调用MoveToLocation或MoveToActor时实际上是AIController通过PathFollowingComponent向NavigationSystem发起了一个寻路请求。PathFollowingComponent负责解读返回的路径FNavPathSharedPtr并转换为具体的移动指令发送给CharacterMovementComponent。CrowdManager人群管理器这是实现RVO避让和人群管理的核心模块。它不是默认开启的。当CrowdManager被创建并初始化后它会接管注册到它旗下的AI的移动。它基于每个AI的UCrowdFollowingComponent替代标准的UPathFollowingComponent来进行路径跟随和动态避障计算。数据流的简化视图是AIController请求移动 -NavigationSystem在NavMesh上计算路径 - 路径交给PathFollowingComponent或CrowdFollowingComponent - 组件根据路径和避障逻辑每帧计算期望速度 - 速度指令传递给CharacterMovementComponent执行。注意很多开发者遇到避让不生效的问题第一步就应该检查是否正确地启用了CrowdManager并将AI的PathFollowingComponent替换为了CrowdFollowingComponent。这两步缺一不可。2.2 为何选择 RVO 与 Crowd Manager你可能会问我自己用射线检测做简单的排斥力如AI之间太近就施加一个反向力不行吗对于几个AI或许可以。但对于成规模的群体这种简单方法会迅速陷入混乱AI可能陷入高频振荡你推我我推你或者产生不合理的“锁死”状态。RVO算法则优雅得多。RVO的核心思想是相互性和速度空间。每个AI不仅考虑自己的移动也预测周围其他AI的移动并在所有AI的“速度选择空间”中寻找一个能避免未来碰撞的最优解。这带来了几个天然优势无震荡算法本身倾向于寻找稳定解避免了简单的排斥力导致的来回抖动。自然流畅避让行为是提前规划和微调的看起来更像是生物的本能反应而非生硬的“急刹车”或“弹开”。性能可扩展虽然计算量比简单寻路大但UE的CrowdManager实现经过了优化通过空间划分如网格或四叉树来快速查找邻近AI能够支持相当数量数十到数百取决于参数和硬件的并发避让计算。而CrowdManager在RVO之上提供了更丰富的群体行为控制层例如分层避让你可以定义不同的“人群类型”Crowd Agent Type比如“平民”、“士兵”、“巨人”。可以设置巨人不避让平民但平民必须避让巨人模拟出权力或体型差异。路径偏移与优化人群中的AI可以共享部分路径计算或进行轻微的路径偏移以避免所有人严格走同一路径线。状态管理管理AI在人群中的状态正常、受阻、脱离等并提供相应的事件回调。因此对于需要高质量、大规模AI群体移动的场景集成RVO和CrowdManager是官方推荐且经过验证的高效方案。它节省了你重复造轮子的时间并提供了一个性能与效果俱佳的基础。3. RVO 避让的核心配置与实战细节理论说再多不如一行配置。让我们深入到项目设置和代码中看看如何激活并调优RVO避让。3.1 启用与基础配置首先我们需要在项目中启用并配置CrowdManager。项目设置打开Edit - Project Settings搜索“Navigation System”。启用 CrowdManager在导航系统设置中找到Crowd Manager Class。默认可能是空的。你需要将其设置为CrowdManager对应UCrowdManager类。这一步是告诉引擎使用人群管理模块。配置代理参数在Agents分类下你可以定义不同的Nav Agent属性如半径、高度、步高、最大坡度等。这些属性主要影响寻路。对于避让更关键的是在CrowdManager中配置的Crowd Agent Types但基础的Agent半径也会被用作碰撞体参考。更关键的配置在CrowdManager本身。通常我们通过一个数据资产Data Asset或直接在代码中初始化时进行配置。一个常见的做法是创建一个CrowdManager的子类BP_CrowdManager在其BeginPlay事件或初始化函数中通过SetCrowdSimulationParams来设置参数。核心参数包括AgentRadiusAI的碰撞半径。这是避让计算的基础。务必与AI角色胶囊体Capsule的半径协调。通常为了给避让留出缓冲空间AgentRadius会略大于或等于胶囊体半径。AgentHeightAI的高度影响一些立体空间的判断。MaxAcceleration/MaxSpeedAI的最大加速度和速度。这决定了AI改变移动状态的敏捷程度。加速度太低AI会显得“笨重”转弯和启动慢。NeighborDist寻找“邻居”需要进行避让计算的其他AI的最大距离。设置太大计算量增加设置太小可能导致AI在高速下反应不及而相撞。通常设置为AgentRadius的3-5倍是个不错的起点。TimeHorizon/TimeHorizonObst时间前瞻。算法会预测未来这么多秒内的位置来进行避让。对于移动的AITimeHorizon和静态障碍TimeHorizonObst可以设置不同的值。值越大避让行为越“保守”和提前值越小AI可能更“激进”在最后一刻才避让。通常设置在1.0到2.0之间。ObstacleAvoidanceType避障质量等级。这是一个枚举从Low到Good可能还有High。等级越高避让效果越平滑精确但CPU开销也越大。对于大量AI从Medium开始测试。// 示例在CrowdManager子类中初始化参数 void ABP_CrowdManager::BeginPlay() { Super::BeginPlay(); if (UCrowdManager* CrowdManager UCrowdManager::GetCurrent(this)) { FCrowdAvoidanceConfig AvoidanceConfig; AvoidanceConfig.VelocityBias 0.5f; AvoidanceConfig.AdaptiveDivisions 5; AvoidanceConfig.AdaptiveDepth 1; // ... 设置其他参数 CrowdManager-SetAvoidanceConfig(0, AvoidanceConfig); // 设置第0种避让配置 FCrowdAgentParams AgentParams; AgentParams.Radius 45.0f; AgentParams.Height 160.0f; AgentParams.MaxAcceleration 512.0f; AgentParams.MaxSpeed 300.0f; AgentParams.NeighborDist 150.0f; AgentParams.TimeHorizon 1.5f; AgentParams.TimeHorizonObst 1.5f; AgentParams.ObstacleAvoidanceType ECrowdAvoidanceQuality::Medium; // ... 设置其他代理参数 CrowdManager-SetAgentParams(0, AgentParams); // 设置第0种代理类型的参数 } }3.2 将AI移交给CrowdManager管理仅仅配置了Manager还不够你需要让每个AI个体“注册”到人群管理中。替换 FollowingComponent在你的AI角色或Controller的蓝图/代码中确保其使用的PathFollowingComponent是UCrowdFollowingComponent而不是默认的UPathFollowingComponent。你可以在AIController的子类构造函数中设置AYourAIController::AYourAIController(const FObjectInitializer ObjectInitializer) : Super(ObjectInitializer.SetDefaultSubobjectClassUCrowdFollowingComponent(TEXT(PathFollowingComponent))) { }设置移动请求标志当你调用移动函数如MoveToLocation时需要确保其参数启用了人群避让。在蓝图中Move To Location节点有一个Use Pathfinding的布尔值为True时如果存在CrowdManager且AI使用的是CrowdFollowingComponent就会自动尝试使用避让。在C中FAIMoveRequest会默认处理。完成这两步后你的AI在移动时其CrowdFollowingComponent就会与CrowdManager通信参与RVO避让计算。你可以立刻在场景中放置多个AI并让它们走向同一个点观察它们是否会自然地相互绕开而不是挤成一团。实操心得调试避让行为时强烈建议在游戏运行时使用控制台命令p.Nav.DebugCrowds 1。这会在屏幕上可视化显示每个AI的避让半径、速度矢量、邻居关系等是排查问题如参数是否生效、邻居检测距离是否合适的利器。用完后记得输入p.Nav.DebugCrowds 0关闭。4. 人群管理的高级策略与实战应用当基础的RVO避让工作后我们就可以利用CrowdManager提供的更高级功能来模拟更复杂的群体行为。4.1 分层避让与代理类型现实世界中不同实体间的避让规则是不同的。比如行人会主动避开车辆而车辆可能只对其他车辆进行精细避让。在UE中这通过定义不同的CrowdAgentType来实现。你可以在CrowdManager中定义多种代理类型如Type0: 平民 Type1: 士兵 Type2: 载具。每种类型都有自己的一套FCrowdAgentParams半径、速度等。最关键的是避让配置矩阵。CrowdManager内部维护一个避让配置索引的矩阵。对于任意两种代理类型A和B你可以指定它们之间使用哪种避让配置通过SetAvoidanceConfig设置的配置。你甚至可以设置为“不避让”。这允许你实现单向避让平民Type0必须全力避让载具Type2而载具只对其它载具进行标准避让对平民使用一个更宽松甚至忽略的配置。分组避让同一小队同类型的AI之间使用更紧密的避让参数而对其他小队的AI使用更宽松的参数模拟团队协作。设置通常通过CrowdManager的SetAvoidanceGroupMask和SetGroupsToAvoid等函数来完成但更直观的方式可能是直接通过你的BP_CrowdManager在初始化时根据代理类型索引来设置两两之间的避让关系。4.2 动态障碍物与导航修改器RVO主要处理AI之间的动态避让。但对于突然出现在路径上的动态障碍物比如玩家扔下的一个箱子、一扇突然关闭的门我们需要另一种机制。这就是NavModifierVolume和NavLinkProxy的用武之地。你可以将一个NavModifierVolume附加到动态障碍物上并设置其Area Class。例如设置为NavArea_Null这个区域就会从NavMesh上被“挖掉”AI在寻路时会主动绕过它。如果你希望AI可以以更高成本通过比如灌木丛可以设置一个自定义的NavArea并赋予较高的DefaultCost或较低的FixedAreaEnteringCost。对于像门这样需要特殊交互的障碍NavLinkProxy导航链接代理更合适。你可以设置一个双向的导航链接当门打开时链接启用AI可以穿过当门关闭时链接禁用AI会重新寻路。将动态障碍物与RVO结合就能应对绝大多数动态环境。CrowdManager的避障参数TimeHorizonObst会让AI提前对这类静态/动态障碍做出反应。4.3 实现群体行为分流、跟随与队形CrowdManager提供了基础但像“一群人分成两股通过一个瓶颈路口”、“AI跟随一个领队并保持大致队形”这类更上层的群体行为需要额外的逻辑层。这里分享两种实战思路1. 路径点与区域分流这不是CrowdManager的直接功能但可以通过导航系统配合实现。例如在一个十字路口你可以预先在两侧设置不同的NavMesh区域通过NavModifierVolume标记为不同的Area Class。为不同组的AI分配不同的移动策略组1的AI在寻路时偏好使用路口左侧的区域通过FAIMoveRequest的FilterClass设置包含该区域偏好的NavigationQueryFilter组2的AI则偏好右侧区域。这样在宏观上就实现了人群的分流。这需要你在关卡设计阶段就做好规划。2. 基于子群的跟随与队形对于小队跟随一个简单有效的方案是**“虚拟路径点”**。领队AILeader正常寻路移动。每个跟随者Follower并不直接寻路到最终目标而是动态地计算一个“偏移目标点”。这个点基于领队的位置、领队的面向方向以及一个预设的队形偏移量比如在领队左后方200单位。// 每帧或在领队移动后更新跟随者目标 FVector LeaderLocation LeaderActor-GetActorLocation(); FVector LeaderForward LeaderActor-GetActorForwardVector(); FVector LeaderRight LeaderActor-GetActorRightVector(); // 计算队形中的相对位置例如2号队员在左后方 FVector FormationOffset (-LeaderRight * 100.0f) (-LeaderForward * 200.0f); FVector FollowTargetWorld LeaderLocation FormationOffset; // 让跟随者的AIController移动到这个动态目标点 FollowerAIController-MoveToLocation(FollowTargetWorld);每个跟随者都独立地向自己的“虚拟路径点”移动同时它们之间以及它们与领队之间都通过底层的RVO进行自然的避让。这样既能保持大致的队形又不会出现AI完全重叠或死板排队的问题。当遇到障碍时RVO会让它们暂时分散绕过障碍后再逐渐回归队形行为非常自然。5. 性能优化与常见问题排查将数百个具有RVO避让的AI放入世界是对性能的严峻考验。以下是一些关键的优化方向和排查清单。5.1 性能调优要点控制同时活动的AI数量这是最有效的手段。使用NavigationInvokerComponent或自定义逻辑只让玩家周围一定范围内的AI进行高精度的避让和寻路更新。远处的AI可以切换到简化的移动模式如沿着固定路径移动或直接每几帧更新一次位置。调整避让更新频率不是每个AI都需要每帧进行昂贵的RVO计算。在CrowdManager的代理参数中虽然没有直接的“更新频率”参数但你可以通过自定义CrowdFollowingComponent在TickComponent中根据AI的重要性或距离决定是否调用父类更新。或者更粗暴一点将不重要的AI的ObstacleAvoidanceQuality设为Low。合理设置邻居搜索距离NeighborDist这是性能的关键参数之一。在满足游戏效果的前提下尽可能减小这个值。你可以根据AI的最大速度来动态调整高速移动的AI需要更大的前瞻距离。使用简化的碰撞表示确保用于RVO计算的AgentRadius没有不必要地设置过大。同时对于非常密集的人群可以考虑让一部分AI如背景人群使用更简单的、基于规则的移动而不参与全功能的RVO。NavMesh 优化复杂的NavMesh会降低寻路查询速度。使用NavMeshBoundsVolume精确框定需要导航的区域避免覆盖不可行走的区域。合理使用NavModifierVolume而不是用大量的小体积去雕刻复杂区域。5.2 常见问题与解决方案速查表问题现象可能原因排查步骤与解决方案AI完全不避让直接穿模或卡住。1. CrowdManager未启用或未正确初始化。2. AI未使用UCrowdFollowingComponent。3. AI的移动请求未使用路径寻找。1. 检查项目设置中Crowd Manager Class是否已设置。2. 在游戏运行时检查UCrowdManager::GetCurrent是否返回有效指针。3. 在AI Controller蓝图中检查PathFollowingComponent的类。4. 确保调用MoveTo时Use Pathfinding为True。避让行为僵硬AI频繁停顿或抖动。1.MaxAcceleration过低导致AI加速/减速太慢。2.TimeHorizon设置过小AI规划太短视。3.ObstacleAvoidanceQuality可能过低计算精度差。4. NavMesh网格过密或有瑕疵。1. 适当增加MaxAcceleration如从256增至512。2. 适当增加TimeHorizon如从1.0增至2.0。3. 尝试将避障质量提高到Medium或Good。4. 使用p.Nav.DebugCrowds 1观察速度矢量是否稳定。检查NavMesh是否有狭窄通道或孤岛。AI在拐角处或门口堆积。1.AgentRadius相对于通道宽度过大。2. 没有足够的“侧向通过”空间RVO解算失败。3. 动态障碍物如门的NavArea更新有延迟。1. 减小AgentRadius或加大关卡中的通道宽度。2. 尝试增加NeighborDist让AI更早发现拥堵。3. 对于门确保NavModifierVolume或NavLinkProxy的状态切换SetAreaClass/SetEnabled及时且网络同步如果是多人游戏。性能开销过大帧数下降明显。1. 同时进行RVO计算的AI数量过多。2.NeighborDist或ObstacleAvoidanceQuality设置过高。3. NavMesh过于复杂寻路查询耗时。1. 实现距离裁剪LOD减少远处AI的更新频率。2. 降低NeighborDist和ObstacleAvoidanceQuality。3. 简化NavMesh使用RecastNavMesh-Debug绘制查看网格密度合并不必要的多边形。特定AI类型之间避让不符合预期。代理类型之间的避让配置矩阵设置错误。检查CrowdManager中为不同代理类型SetAvoidanceConfig和SetAgentParams的代码逻辑。确保A避让B和B避让A的配置是你期望的。使用调试绘制观察不同颜色代表的代理类型。踩坑实录在一次项目中我们遇到了AI在狭窄楼梯上完全卡死的问题。p.Nav.DebugCrowds显示所有AI的速度矢量都几乎为零但它们明明有路径。最终发现原因是楼梯的NavMesh在自动生成时每个台阶边缘产生了一些微小的、不可行走的“裂缝”由于碰撞体精度问题。这些裂缝对于单个AI寻路没问题但当多个AI试图通过时RVO算法认为彼此完全堵死了所有可行的速度方向。解决方案不是调整RVO参数而是回头修复关卡碰撞体的连续性并手动使用NavModifierVolume确保楼梯斜坡的NavMesh是完整、平滑的。这个教训是很多高级移动问题根源可能在于基础的NavMesh质量。
1. 项目概述从寻路到智能移动的进化在虚幻引擎UE里做AI移动很多开发者可能还停留在“让AI从A点走到B点”的初级阶段。确实NavigationSystem导航系统最基础的功能就是寻路它帮你解决了“怎么走”的问题。但如果你做的项目里有超过一个的AI单位或者你的AI需要在复杂、动态的环境中移动比如一个熙熙攘攘的集市、一个战术小队执行任务或者是一群受惊的动物四散奔逃你就会发现单纯的寻路远远不够。它会带来AI互相卡位、穿模、移动僵硬得像排队买票一样不自然的问题。这就是我们今天要深入探讨的核心如何利用UE的NavigationSystem超越基础的寻路打造出真正“智能”的、能感知环境与同伴的AI移动行为。关键词是RVOReciprocal Velocity Obstacles相互速度障碍避让和人群管理Crowd Manager。这不仅仅是让AI不撞墙更是让它们能像真实生物一样在移动中做出合理的决策——礼让、绕行、跟随、分散。我接手过不少需要大量AI同屏的项目从RTS的单位控制到开放世界的NPC人流踩过的坑让我深刻意识到一套好的移动逻辑是游戏体验的“隐形守护者”它不显眼但一旦出问题玩家会立刻感到出戏。简单来说我们将要搭建的是一套分层级的智能移动方案底层是NavigationSystem提供的可靠寻路网格中层是RVO避让负责处理AI之间的瞬时碰撞避免让移动平滑自然上层是人群管理或自定义逻辑用于实现更高级的群体行为如分流、跟随、保持队形等。这个方案能显著提升你游戏中AI的“智商”和可信度无论是对于沉浸式叙事还是对于需要精确单位操控的游戏类型都至关重要。2. 导航系统的核心架构与设计思路在动手写代码或摆弄蓝图之前我们必须先理解UE NavigationSystem的骨架。它不是黑盒而是一套设计精巧的模块化系统理解其架构能让你在定制化时游刃有余。2.1 NavigationSystem 组件构成与数据流UE的导航系统主要由以下几部分构成它们协同工作完成了从请求到移动的完整链条NavMesh导航网格这是所有寻路的基础。它是一张覆盖在可行走区域上的多边形网格通常是三角形由NavMeshBoundsVolume生成。AI只能在NavMesh覆盖的区域内寻路。你需要理解的是NavMesh是静态或半静态的虽然可以通过NavModifierVolume动态影响其成本但它的生成和更新有一定开销。NavigationSystem系统的总调度中心。它是一个UWorldSubsystem负责管理NavMesh的查询、更新以及处理来自AAIController或CharacterMovementComponent的寻路请求。我们大部分的高阶操作如设置避让参数、管理人群都是通过它与UNavigationSystemV1或其派生类交互。AIController 与 PathFollowingComponentAAIController是AI的“大脑”它持有UPathFollowingComponent。当你调用MoveToLocation或MoveToActor时实际上是AIController通过PathFollowingComponent向NavigationSystem发起了一个寻路请求。PathFollowingComponent负责解读返回的路径FNavPathSharedPtr并转换为具体的移动指令发送给CharacterMovementComponent。CrowdManager人群管理器这是实现RVO避让和人群管理的核心模块。它不是默认开启的。当CrowdManager被创建并初始化后它会接管注册到它旗下的AI的移动。它基于每个AI的UCrowdFollowingComponent替代标准的UPathFollowingComponent来进行路径跟随和动态避障计算。数据流的简化视图是AIController请求移动 -NavigationSystem在NavMesh上计算路径 - 路径交给PathFollowingComponent或CrowdFollowingComponent - 组件根据路径和避障逻辑每帧计算期望速度 - 速度指令传递给CharacterMovementComponent执行。注意很多开发者遇到避让不生效的问题第一步就应该检查是否正确地启用了CrowdManager并将AI的PathFollowingComponent替换为了CrowdFollowingComponent。这两步缺一不可。2.2 为何选择 RVO 与 Crowd Manager你可能会问我自己用射线检测做简单的排斥力如AI之间太近就施加一个反向力不行吗对于几个AI或许可以。但对于成规模的群体这种简单方法会迅速陷入混乱AI可能陷入高频振荡你推我我推你或者产生不合理的“锁死”状态。RVO算法则优雅得多。RVO的核心思想是相互性和速度空间。每个AI不仅考虑自己的移动也预测周围其他AI的移动并在所有AI的“速度选择空间”中寻找一个能避免未来碰撞的最优解。这带来了几个天然优势无震荡算法本身倾向于寻找稳定解避免了简单的排斥力导致的来回抖动。自然流畅避让行为是提前规划和微调的看起来更像是生物的本能反应而非生硬的“急刹车”或“弹开”。性能可扩展虽然计算量比简单寻路大但UE的CrowdManager实现经过了优化通过空间划分如网格或四叉树来快速查找邻近AI能够支持相当数量数十到数百取决于参数和硬件的并发避让计算。而CrowdManager在RVO之上提供了更丰富的群体行为控制层例如分层避让你可以定义不同的“人群类型”Crowd Agent Type比如“平民”、“士兵”、“巨人”。可以设置巨人不避让平民但平民必须避让巨人模拟出权力或体型差异。路径偏移与优化人群中的AI可以共享部分路径计算或进行轻微的路径偏移以避免所有人严格走同一路径线。状态管理管理AI在人群中的状态正常、受阻、脱离等并提供相应的事件回调。因此对于需要高质量、大规模AI群体移动的场景集成RVO和CrowdManager是官方推荐且经过验证的高效方案。它节省了你重复造轮子的时间并提供了一个性能与效果俱佳的基础。3. RVO 避让的核心配置与实战细节理论说再多不如一行配置。让我们深入到项目设置和代码中看看如何激活并调优RVO避让。3.1 启用与基础配置首先我们需要在项目中启用并配置CrowdManager。项目设置打开Edit - Project Settings搜索“Navigation System”。启用 CrowdManager在导航系统设置中找到Crowd Manager Class。默认可能是空的。你需要将其设置为CrowdManager对应UCrowdManager类。这一步是告诉引擎使用人群管理模块。配置代理参数在Agents分类下你可以定义不同的Nav Agent属性如半径、高度、步高、最大坡度等。这些属性主要影响寻路。对于避让更关键的是在CrowdManager中配置的Crowd Agent Types但基础的Agent半径也会被用作碰撞体参考。更关键的配置在CrowdManager本身。通常我们通过一个数据资产Data Asset或直接在代码中初始化时进行配置。一个常见的做法是创建一个CrowdManager的子类BP_CrowdManager在其BeginPlay事件或初始化函数中通过SetCrowdSimulationParams来设置参数。核心参数包括AgentRadiusAI的碰撞半径。这是避让计算的基础。务必与AI角色胶囊体Capsule的半径协调。通常为了给避让留出缓冲空间AgentRadius会略大于或等于胶囊体半径。AgentHeightAI的高度影响一些立体空间的判断。MaxAcceleration/MaxSpeedAI的最大加速度和速度。这决定了AI改变移动状态的敏捷程度。加速度太低AI会显得“笨重”转弯和启动慢。NeighborDist寻找“邻居”需要进行避让计算的其他AI的最大距离。设置太大计算量增加设置太小可能导致AI在高速下反应不及而相撞。通常设置为AgentRadius的3-5倍是个不错的起点。TimeHorizon/TimeHorizonObst时间前瞻。算法会预测未来这么多秒内的位置来进行避让。对于移动的AITimeHorizon和静态障碍TimeHorizonObst可以设置不同的值。值越大避让行为越“保守”和提前值越小AI可能更“激进”在最后一刻才避让。通常设置在1.0到2.0之间。ObstacleAvoidanceType避障质量等级。这是一个枚举从Low到Good可能还有High。等级越高避让效果越平滑精确但CPU开销也越大。对于大量AI从Medium开始测试。// 示例在CrowdManager子类中初始化参数 void ABP_CrowdManager::BeginPlay() { Super::BeginPlay(); if (UCrowdManager* CrowdManager UCrowdManager::GetCurrent(this)) { FCrowdAvoidanceConfig AvoidanceConfig; AvoidanceConfig.VelocityBias 0.5f; AvoidanceConfig.AdaptiveDivisions 5; AvoidanceConfig.AdaptiveDepth 1; // ... 设置其他参数 CrowdManager-SetAvoidanceConfig(0, AvoidanceConfig); // 设置第0种避让配置 FCrowdAgentParams AgentParams; AgentParams.Radius 45.0f; AgentParams.Height 160.0f; AgentParams.MaxAcceleration 512.0f; AgentParams.MaxSpeed 300.0f; AgentParams.NeighborDist 150.0f; AgentParams.TimeHorizon 1.5f; AgentParams.TimeHorizonObst 1.5f; AgentParams.ObstacleAvoidanceType ECrowdAvoidanceQuality::Medium; // ... 设置其他代理参数 CrowdManager-SetAgentParams(0, AgentParams); // 设置第0种代理类型的参数 } }3.2 将AI移交给CrowdManager管理仅仅配置了Manager还不够你需要让每个AI个体“注册”到人群管理中。替换 FollowingComponent在你的AI角色或Controller的蓝图/代码中确保其使用的PathFollowingComponent是UCrowdFollowingComponent而不是默认的UPathFollowingComponent。你可以在AIController的子类构造函数中设置AYourAIController::AYourAIController(const FObjectInitializer ObjectInitializer) : Super(ObjectInitializer.SetDefaultSubobjectClassUCrowdFollowingComponent(TEXT(PathFollowingComponent))) { }设置移动请求标志当你调用移动函数如MoveToLocation时需要确保其参数启用了人群避让。在蓝图中Move To Location节点有一个Use Pathfinding的布尔值为True时如果存在CrowdManager且AI使用的是CrowdFollowingComponent就会自动尝试使用避让。在C中FAIMoveRequest会默认处理。完成这两步后你的AI在移动时其CrowdFollowingComponent就会与CrowdManager通信参与RVO避让计算。你可以立刻在场景中放置多个AI并让它们走向同一个点观察它们是否会自然地相互绕开而不是挤成一团。实操心得调试避让行为时强烈建议在游戏运行时使用控制台命令p.Nav.DebugCrowds 1。这会在屏幕上可视化显示每个AI的避让半径、速度矢量、邻居关系等是排查问题如参数是否生效、邻居检测距离是否合适的利器。用完后记得输入p.Nav.DebugCrowds 0关闭。4. 人群管理的高级策略与实战应用当基础的RVO避让工作后我们就可以利用CrowdManager提供的更高级功能来模拟更复杂的群体行为。4.1 分层避让与代理类型现实世界中不同实体间的避让规则是不同的。比如行人会主动避开车辆而车辆可能只对其他车辆进行精细避让。在UE中这通过定义不同的CrowdAgentType来实现。你可以在CrowdManager中定义多种代理类型如Type0: 平民 Type1: 士兵 Type2: 载具。每种类型都有自己的一套FCrowdAgentParams半径、速度等。最关键的是避让配置矩阵。CrowdManager内部维护一个避让配置索引的矩阵。对于任意两种代理类型A和B你可以指定它们之间使用哪种避让配置通过SetAvoidanceConfig设置的配置。你甚至可以设置为“不避让”。这允许你实现单向避让平民Type0必须全力避让载具Type2而载具只对其它载具进行标准避让对平民使用一个更宽松甚至忽略的配置。分组避让同一小队同类型的AI之间使用更紧密的避让参数而对其他小队的AI使用更宽松的参数模拟团队协作。设置通常通过CrowdManager的SetAvoidanceGroupMask和SetGroupsToAvoid等函数来完成但更直观的方式可能是直接通过你的BP_CrowdManager在初始化时根据代理类型索引来设置两两之间的避让关系。4.2 动态障碍物与导航修改器RVO主要处理AI之间的动态避让。但对于突然出现在路径上的动态障碍物比如玩家扔下的一个箱子、一扇突然关闭的门我们需要另一种机制。这就是NavModifierVolume和NavLinkProxy的用武之地。你可以将一个NavModifierVolume附加到动态障碍物上并设置其Area Class。例如设置为NavArea_Null这个区域就会从NavMesh上被“挖掉”AI在寻路时会主动绕过它。如果你希望AI可以以更高成本通过比如灌木丛可以设置一个自定义的NavArea并赋予较高的DefaultCost或较低的FixedAreaEnteringCost。对于像门这样需要特殊交互的障碍NavLinkProxy导航链接代理更合适。你可以设置一个双向的导航链接当门打开时链接启用AI可以穿过当门关闭时链接禁用AI会重新寻路。将动态障碍物与RVO结合就能应对绝大多数动态环境。CrowdManager的避障参数TimeHorizonObst会让AI提前对这类静态/动态障碍做出反应。4.3 实现群体行为分流、跟随与队形CrowdManager提供了基础但像“一群人分成两股通过一个瓶颈路口”、“AI跟随一个领队并保持大致队形”这类更上层的群体行为需要额外的逻辑层。这里分享两种实战思路1. 路径点与区域分流这不是CrowdManager的直接功能但可以通过导航系统配合实现。例如在一个十字路口你可以预先在两侧设置不同的NavMesh区域通过NavModifierVolume标记为不同的Area Class。为不同组的AI分配不同的移动策略组1的AI在寻路时偏好使用路口左侧的区域通过FAIMoveRequest的FilterClass设置包含该区域偏好的NavigationQueryFilter组2的AI则偏好右侧区域。这样在宏观上就实现了人群的分流。这需要你在关卡设计阶段就做好规划。2. 基于子群的跟随与队形对于小队跟随一个简单有效的方案是**“虚拟路径点”**。领队AILeader正常寻路移动。每个跟随者Follower并不直接寻路到最终目标而是动态地计算一个“偏移目标点”。这个点基于领队的位置、领队的面向方向以及一个预设的队形偏移量比如在领队左后方200单位。// 每帧或在领队移动后更新跟随者目标 FVector LeaderLocation LeaderActor-GetActorLocation(); FVector LeaderForward LeaderActor-GetActorForwardVector(); FVector LeaderRight LeaderActor-GetActorRightVector(); // 计算队形中的相对位置例如2号队员在左后方 FVector FormationOffset (-LeaderRight * 100.0f) (-LeaderForward * 200.0f); FVector FollowTargetWorld LeaderLocation FormationOffset; // 让跟随者的AIController移动到这个动态目标点 FollowerAIController-MoveToLocation(FollowTargetWorld);每个跟随者都独立地向自己的“虚拟路径点”移动同时它们之间以及它们与领队之间都通过底层的RVO进行自然的避让。这样既能保持大致的队形又不会出现AI完全重叠或死板排队的问题。当遇到障碍时RVO会让它们暂时分散绕过障碍后再逐渐回归队形行为非常自然。5. 性能优化与常见问题排查将数百个具有RVO避让的AI放入世界是对性能的严峻考验。以下是一些关键的优化方向和排查清单。5.1 性能调优要点控制同时活动的AI数量这是最有效的手段。使用NavigationInvokerComponent或自定义逻辑只让玩家周围一定范围内的AI进行高精度的避让和寻路更新。远处的AI可以切换到简化的移动模式如沿着固定路径移动或直接每几帧更新一次位置。调整避让更新频率不是每个AI都需要每帧进行昂贵的RVO计算。在CrowdManager的代理参数中虽然没有直接的“更新频率”参数但你可以通过自定义CrowdFollowingComponent在TickComponent中根据AI的重要性或距离决定是否调用父类更新。或者更粗暴一点将不重要的AI的ObstacleAvoidanceQuality设为Low。合理设置邻居搜索距离NeighborDist这是性能的关键参数之一。在满足游戏效果的前提下尽可能减小这个值。你可以根据AI的最大速度来动态调整高速移动的AI需要更大的前瞻距离。使用简化的碰撞表示确保用于RVO计算的AgentRadius没有不必要地设置过大。同时对于非常密集的人群可以考虑让一部分AI如背景人群使用更简单的、基于规则的移动而不参与全功能的RVO。NavMesh 优化复杂的NavMesh会降低寻路查询速度。使用NavMeshBoundsVolume精确框定需要导航的区域避免覆盖不可行走的区域。合理使用NavModifierVolume而不是用大量的小体积去雕刻复杂区域。5.2 常见问题与解决方案速查表问题现象可能原因排查步骤与解决方案AI完全不避让直接穿模或卡住。1. CrowdManager未启用或未正确初始化。2. AI未使用UCrowdFollowingComponent。3. AI的移动请求未使用路径寻找。1. 检查项目设置中Crowd Manager Class是否已设置。2. 在游戏运行时检查UCrowdManager::GetCurrent是否返回有效指针。3. 在AI Controller蓝图中检查PathFollowingComponent的类。4. 确保调用MoveTo时Use Pathfinding为True。避让行为僵硬AI频繁停顿或抖动。1.MaxAcceleration过低导致AI加速/减速太慢。2.TimeHorizon设置过小AI规划太短视。3.ObstacleAvoidanceQuality可能过低计算精度差。4. NavMesh网格过密或有瑕疵。1. 适当增加MaxAcceleration如从256增至512。2. 适当增加TimeHorizon如从1.0增至2.0。3. 尝试将避障质量提高到Medium或Good。4. 使用p.Nav.DebugCrowds 1观察速度矢量是否稳定。检查NavMesh是否有狭窄通道或孤岛。AI在拐角处或门口堆积。1.AgentRadius相对于通道宽度过大。2. 没有足够的“侧向通过”空间RVO解算失败。3. 动态障碍物如门的NavArea更新有延迟。1. 减小AgentRadius或加大关卡中的通道宽度。2. 尝试增加NeighborDist让AI更早发现拥堵。3. 对于门确保NavModifierVolume或NavLinkProxy的状态切换SetAreaClass/SetEnabled及时且网络同步如果是多人游戏。性能开销过大帧数下降明显。1. 同时进行RVO计算的AI数量过多。2.NeighborDist或ObstacleAvoidanceQuality设置过高。3. NavMesh过于复杂寻路查询耗时。1. 实现距离裁剪LOD减少远处AI的更新频率。2. 降低NeighborDist和ObstacleAvoidanceQuality。3. 简化NavMesh使用RecastNavMesh-Debug绘制查看网格密度合并不必要的多边形。特定AI类型之间避让不符合预期。代理类型之间的避让配置矩阵设置错误。检查CrowdManager中为不同代理类型SetAvoidanceConfig和SetAgentParams的代码逻辑。确保A避让B和B避让A的配置是你期望的。使用调试绘制观察不同颜色代表的代理类型。踩坑实录在一次项目中我们遇到了AI在狭窄楼梯上完全卡死的问题。p.Nav.DebugCrowds显示所有AI的速度矢量都几乎为零但它们明明有路径。最终发现原因是楼梯的NavMesh在自动生成时每个台阶边缘产生了一些微小的、不可行走的“裂缝”由于碰撞体精度问题。这些裂缝对于单个AI寻路没问题但当多个AI试图通过时RVO算法认为彼此完全堵死了所有可行的速度方向。解决方案不是调整RVO参数而是回头修复关卡碰撞体的连续性并手动使用NavModifierVolume确保楼梯斜坡的NavMesh是完整、平滑的。这个教训是很多高级移动问题根源可能在于基础的NavMesh质量。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
