尧图网页设计 
在 UE5 中训练追逐角色从 Schola 环境到 ONNX 推理本文介绍在 Unreal Engine 5.7 中让角色学习追逐移动目标。追击者由 PPO 策略控制逃跑者暂时由规则控制。本文不讲 PPO 的完整数学推导主要记录 UE 环境怎么接训练、踩过哪些工程问题以及怎样判断导出的模型在游戏里执行了正确的动作。代码已有障碍探测和Jump Action接口通过简单追逐再逐步学会城市绕障和跳跃。v0 · 球体追逐原型v1 · 平面角色追逐v2 · 障碍与复杂布景v3 · 跳跃维度与多人追捕1. 先把游戏任务变成训练接口强化学习需要一个可以反复运行的环境。每一步至少要回答四个问题角色看到了什么、能做什么、这一步得了多少奖励、回合是否结束。在项目中UE 负责角色运动、碰撞和这些环境逻辑AMD Schola 把数据传到 Python 侧Stable-Baselines3 用 PPO 更新策略。UE重置回合 → 收集观测 → 执行动作 → 计算奖励和结束条件 ↕ Schola / gRPC SB3 PPO 训练 ↓ checkpoint → ONNX ↓ UE NNE 游戏内推理主要代码分工如下类职责APursuitCharEnv重置位置、执行环境步、计算奖励、判断抓捕和超时APursuitCharAgent定义 Schola 观测/动作空间并将动作交给角色UPursuitTargetSensor收集目标方向、距离、速度和障碍探测UPursuitJumpActuator将跳跃意图转换为有条件的角色跳跃训练和推理必须遵守同一份接口契约观测的维度与顺序、动作的维度与顺序、动作最终作用到角色的方式都不能只在演示端“做得差不多”。2. 15 维观测是怎样组成的策略每一步收到 15 个数维度内容0–1角色局部坐标系中的目标方向2归一化后的目标距离3–4自身速度、目标速度5–9五个方向的障碍距离10–14对应方向的障碍净空目标方向先从世界坐标转换到追击者的局部坐标系。这样“目标在我左前方”才是相对稳定的输入不会因为整个关卡换了朝向就改变含义。障碍探测使用球体扫掠距离告诉策略前面多远有物体净空尝试提供物体高度信息。具体实现这里碰到过一个很实际的数据结构问题Schola Agent 返回的顶层观测是以组件名为键的FDictPointTargetSensor内部才是FBoxPoint。如果诊断代码直接把顶层观测当成FBoxPoint转换会失败障碍统计可能错误地显示“所有探头都畅通”。后来环境统一从字典中取传感器数据再解析数组。监控代码读取错了比没有监控更危险——它会给出一个看似明确的假结论。另外输入里有障碍信息不等于模型已经学会使用它。现有正式成绩来自无内部障碍关卡不能拿这些成绩证明绕障能力。3. 动作必须经过角色运动系统动作共有 3 维前进、横向移动和跳跃意图。前两维交给角色移动执行器最终走CharacterMovementComponent跳跃意图还要经过启用状态、阈值、着地和冷却判断才会触发LaunchCharacter。角色实现 / 跳跃执行器没有用SetActorLocation直接把角色推向目标。那样很容易做出“追上了”的画面却绕过了加速、摩擦、碰撞与落地状态用它训练再换回普通角色运动策略面对的就不是同一个系统。这也引出了早期最难定位的问题策略按环境步发送一次移动输入角色运动组件却按引擎帧处理加速和地面摩擦。实际地面速度曾远低于设置的最大速度。看训练结果像“策略不会追”追到执行器才发现角色根本没按预期跑起来。因此在调 PPO 之前应先用规则控制器做环境验收记录输入、地面速度、距离变化和抓捕是否在物理上可达。跳跃维度目前保留在动作空间中但课程关卡可以关闭跳跃执行。这样不同阶段仍使用相同的动作形状。4. 奖励不能只看总分追逐的主要反馈之一是距离变化项目使用相邻两步的距离差distance_reward scale × (previous_distance - current_distance)角色接近目标时为正远离时为负如果先接近又退回原处这部分回报会抵消。抓捕另有一次性奖励超时有惩罚近距离和碰撞也有各自的项。奖励实现距离差可以减少往返“刷距离”的空间但并不保证整个奖励设计没有漏洞。比如逐步发放的近距离奖励需要检查角色是否会停在目标附近而不完成抓捕。看 TensorBoard 的奖励曲线还不够必须同时核对抓捕率、超时、实际距离以及角色轨迹。5. 课程关卡与训练前后对比我没有直接从复杂城市地图开始。目标移动、建筑碰撞、绕行和跳跃同时出现时一旦失败很难判断是环境不可解、传感器没读到墙、角色运动异常还是策略本身没学会。项目先用较简单的关卡提高目标速度静止目标 → Moving025目标速度比 0.25→ Moving050目标速度比 0.50同一关卡上先评估上一阶段模型再评估在该关卡续训后的模型关卡续训前抓捕续训后抓捕Moving02555/100100/100Moving05084/10098/100每组评估运行 101 回合排除第一个预热回合正式统计 100 回合。这里的“续训前”不是随机初始化Moving025 使用静止目标阶段的权重Moving050 使用 Moving025 阶段的权重。各次评估也没有采用配对的同一批出生点因此表格是特定设置下的表现对照不是逐出生点的严格配对试验。Moving050 训练并未单调变好。多个续训分支差异明显98/100 是筛选后再进行正式评估的模型不能据此推断“再跑更多步一定会更好”。汇总 CSV、400 条正式回合记录和统计口径与模型溯源都放在仓库中。抓捕数统计 100 个正式回合部分 UE 行为均值只有 99 条完整日志两者没有混用。6. ONNX 能加载不代表动作相同训练后的 checkpoint 需要导出成 UE 可执行的 ONNX。但导出成功只是文件层面的结果输出节点名、动作排列或额外的激活函数有一点不一致游戏里运行的就可能不是评估过的策略。因此项目对选定模型做了动作对拍取 400 条真实观测分别运行 SB3 确定性预测和 ONNX逐维比较动作。记录到的最大绝对误差为1.192e-7。对拍记录只适用于这份模型重新导出其他权重时仍要重新验证。UE 推理时读取 ONNX 文件将数据初始化为UNNEModelData再交给追击者运行。角色仍走训练时的传感器与动作执行器而不是另写一套只用于录像的移动逻辑。7. 项目价值把“能跑”变成“能解释”对我来说这个项目的价值不在于单次抓捕率而在于把游戏 AI 的训练与验证接成一条可以检查的工程链路。第一UE 角色使用真实的移动、碰撞和动画表现。模型不是只在抽象坐标系里追一个点训练接口与最终游戏内推理共用角色运动路径。第二课程关卡把问题拆小了。策略失败时可以先检查基础追逐是否可解再检查目标速度或障碍而不是在城市里反复长训后仍不知道失败原因。第三结果保留了模型身份、关卡和评估口径。成功分支和退化分支都能解释ONNX 也经过动作对拍。这比只展示一段“追上了”的录像更能说明训练结果来自哪里、适用于什么条件。这套流程有复用价值但还不是“输入地图和规则自动生成模型”的通用平台。换任务时仍要重新设计或验证观测、动作、奖励、可达性与评估协议。8. 后续目标提高工具复用性把关卡配置、训练启动、checkpoint 身份、评估协议和结果图生成进一步参数化。目标是减少新任务的重复接线工作而不是预设任意地图都能自动训练成功。PursuitAI 已打通 UE 角色追逐的训练、评估和 ONNX 推理并在两个无内部障碍的移动目标关卡中观察到续训后的抓捕率提升并且进行绕障、跳跃和城市训练后续可以继续加入技能系统或其他系统也可以在目前基础上精进训练使模型更加通用。项目地址github.com/zhangxuhan/PursuitAI。 在 UE5 中训练追逐角色：从 Schola 环境到 ONNX 推理
在 UE5 中训练追逐角色从 Schola 环境到 ONNX 推理本文介绍在 Unreal Engine 5.7 中让角色学习追逐移动目标。追击者由 PPO 策略控制逃跑者暂时由规则控制。本文不讲 PPO 的完整数学推导主要记录 UE 环境怎么接训练、踩过哪些工程问题以及怎样判断导出的模型在游戏里执行了正确的动作。代码已有障碍探测和Jump Action接口通过简单追逐再逐步学会城市绕障和跳跃。v0 · 球体追逐原型v1 · 平面角色追逐v2 · 障碍与复杂布景v3 · 跳跃维度与多人追捕1. 先把游戏任务变成训练接口强化学习需要一个可以反复运行的环境。每一步至少要回答四个问题角色看到了什么、能做什么、这一步得了多少奖励、回合是否结束。在项目中UE 负责角色运动、碰撞和这些环境逻辑AMD Schola 把数据传到 Python 侧Stable-Baselines3 用 PPO 更新策略。UE重置回合 → 收集观测 → 执行动作 → 计算奖励和结束条件 ↕ Schola / gRPC SB3 PPO 训练 ↓ checkpoint → ONNX ↓ UE NNE 游戏内推理主要代码分工如下类职责APursuitCharEnv重置位置、执行环境步、计算奖励、判断抓捕和超时APursuitCharAgent定义 Schola 观测/动作空间并将动作交给角色UPursuitTargetSensor收集目标方向、距离、速度和障碍探测UPursuitJumpActuator将跳跃意图转换为有条件的角色跳跃训练和推理必须遵守同一份接口契约观测的维度与顺序、动作的维度与顺序、动作最终作用到角色的方式都不能只在演示端“做得差不多”。2. 15 维观测是怎样组成的策略每一步收到 15 个数维度内容0–1角色局部坐标系中的目标方向2归一化后的目标距离3–4自身速度、目标速度5–9五个方向的障碍距离10–14对应方向的障碍净空目标方向先从世界坐标转换到追击者的局部坐标系。这样“目标在我左前方”才是相对稳定的输入不会因为整个关卡换了朝向就改变含义。障碍探测使用球体扫掠距离告诉策略前面多远有物体净空尝试提供物体高度信息。具体实现这里碰到过一个很实际的数据结构问题Schola Agent 返回的顶层观测是以组件名为键的FDictPointTargetSensor内部才是FBoxPoint。如果诊断代码直接把顶层观测当成FBoxPoint转换会失败障碍统计可能错误地显示“所有探头都畅通”。后来环境统一从字典中取传感器数据再解析数组。监控代码读取错了比没有监控更危险——它会给出一个看似明确的假结论。另外输入里有障碍信息不等于模型已经学会使用它。现有正式成绩来自无内部障碍关卡不能拿这些成绩证明绕障能力。3. 动作必须经过角色运动系统动作共有 3 维前进、横向移动和跳跃意图。前两维交给角色移动执行器最终走CharacterMovementComponent跳跃意图还要经过启用状态、阈值、着地和冷却判断才会触发LaunchCharacter。角色实现 / 跳跃执行器没有用SetActorLocation直接把角色推向目标。那样很容易做出“追上了”的画面却绕过了加速、摩擦、碰撞与落地状态用它训练再换回普通角色运动策略面对的就不是同一个系统。这也引出了早期最难定位的问题策略按环境步发送一次移动输入角色运动组件却按引擎帧处理加速和地面摩擦。实际地面速度曾远低于设置的最大速度。看训练结果像“策略不会追”追到执行器才发现角色根本没按预期跑起来。因此在调 PPO 之前应先用规则控制器做环境验收记录输入、地面速度、距离变化和抓捕是否在物理上可达。跳跃维度目前保留在动作空间中但课程关卡可以关闭跳跃执行。这样不同阶段仍使用相同的动作形状。4. 奖励不能只看总分追逐的主要反馈之一是距离变化项目使用相邻两步的距离差distance_reward scale × (previous_distance - current_distance)角色接近目标时为正远离时为负如果先接近又退回原处这部分回报会抵消。抓捕另有一次性奖励超时有惩罚近距离和碰撞也有各自的项。奖励实现距离差可以减少往返“刷距离”的空间但并不保证整个奖励设计没有漏洞。比如逐步发放的近距离奖励需要检查角色是否会停在目标附近而不完成抓捕。看 TensorBoard 的奖励曲线还不够必须同时核对抓捕率、超时、实际距离以及角色轨迹。5. 课程关卡与训练前后对比我没有直接从复杂城市地图开始。目标移动、建筑碰撞、绕行和跳跃同时出现时一旦失败很难判断是环境不可解、传感器没读到墙、角色运动异常还是策略本身没学会。项目先用较简单的关卡提高目标速度静止目标 → Moving025目标速度比 0.25→ Moving050目标速度比 0.50同一关卡上先评估上一阶段模型再评估在该关卡续训后的模型关卡续训前抓捕续训后抓捕Moving02555/100100/100Moving05084/10098/100每组评估运行 101 回合排除第一个预热回合正式统计 100 回合。这里的“续训前”不是随机初始化Moving025 使用静止目标阶段的权重Moving050 使用 Moving025 阶段的权重。各次评估也没有采用配对的同一批出生点因此表格是特定设置下的表现对照不是逐出生点的严格配对试验。Moving050 训练并未单调变好。多个续训分支差异明显98/100 是筛选后再进行正式评估的模型不能据此推断“再跑更多步一定会更好”。汇总 CSV、400 条正式回合记录和统计口径与模型溯源都放在仓库中。抓捕数统计 100 个正式回合部分 UE 行为均值只有 99 条完整日志两者没有混用。6. ONNX 能加载不代表动作相同训练后的 checkpoint 需要导出成 UE 可执行的 ONNX。但导出成功只是文件层面的结果输出节点名、动作排列或额外的激活函数有一点不一致游戏里运行的就可能不是评估过的策略。因此项目对选定模型做了动作对拍取 400 条真实观测分别运行 SB3 确定性预测和 ONNX逐维比较动作。记录到的最大绝对误差为1.192e-7。对拍记录只适用于这份模型重新导出其他权重时仍要重新验证。UE 推理时读取 ONNX 文件将数据初始化为UNNEModelData再交给追击者运行。角色仍走训练时的传感器与动作执行器而不是另写一套只用于录像的移动逻辑。7. 项目价值把“能跑”变成“能解释”对我来说这个项目的价值不在于单次抓捕率而在于把游戏 AI 的训练与验证接成一条可以检查的工程链路。第一UE 角色使用真实的移动、碰撞和动画表现。模型不是只在抽象坐标系里追一个点训练接口与最终游戏内推理共用角色运动路径。第二课程关卡把问题拆小了。策略失败时可以先检查基础追逐是否可解再检查目标速度或障碍而不是在城市里反复长训后仍不知道失败原因。第三结果保留了模型身份、关卡和评估口径。成功分支和退化分支都能解释ONNX 也经过动作对拍。这比只展示一段“追上了”的录像更能说明训练结果来自哪里、适用于什么条件。这套流程有复用价值但还不是“输入地图和规则自动生成模型”的通用平台。换任务时仍要重新设计或验证观测、动作、奖励、可达性与评估协议。8. 后续目标提高工具复用性把关卡配置、训练启动、checkpoint 身份、评估协议和结果图生成进一步参数化。目标是减少新任务的重复接线工作而不是预设任意地图都能自动训练成功。PursuitAI 已打通 UE 角色追逐的训练、评估和 ONNX 推理并在两个无内部障碍的移动目标关卡中观察到续训后的抓捕率提升并且进行绕障、跳跃和城市训练后续可以继续加入技能系统或其他系统也可以在目前基础上精进训练使模型更加通用。项目地址github.com/zhangxuhan/PursuitAI。