本文属于「如何制作一款开放世界游戏」系列的交通运行时下篇,承接上篇的调度与决策层。上篇讨论路网、路口通行权、信号相位、派遣编排与交通就绪门;本篇讨论路线执行、持续重规划、驾驶策略、派遣任务落地以及直升机、飞机和船的专用执行器。材料来自对成熟商业开放世界引擎与客户端代码的长期源码级逆向阅读(约 700+ 篇源码级笔记),发布时按惯例做匿名化处理。
本文有两个边界。其一:单车执行的四层驾驶执行栈(路线所有者→局部避让→控制写入→战术包装)主讲于车辆篇下篇;本篇第一章仅从车流视角说明这套执行栈如何消费路网与路线数据,以及共用执行栈对交通运行成本的影响。其二:本篇执行层的原型实现尚未开始,相关内容均属于就绪门之后的原版机制分析与 UE5 迁移地图;每章③将区分已具备的输出接口与后续规划。
全文沿用三段结构:原版机制 → UE5 迁移取舍 → 原型状态与规划。寻路搜索算法内核、避让几何、各车型执行器内部(直升机悬停/飞机降落/船舶避让)以及下游警察任务如何将指派转换为机动,均明确标注为「盲区」。
UE5 实现实操安排在后续落地篇:本篇及本系列其他方案篇聚焦设计与迁移决策,包括原版机制的设计原因、自建与复用范围以及系统接缝。对应的落地篇将讨论 UE5 工程实现、引擎子系统接入、工程问题与验证结果。
引言:从交通决策到路线执行
上篇结束于两个“已决定、待执行”的状态:交通就绪门已经放行具备参与资格的车辆,派遣编排已经为警车建立任务指派。调度决策可以重新计算,执行过程则必须持续面对时间、空间与失败状态。本篇关注原版如何在这些约束下维持执行一致性。
执行层首先需要为车辆异步计算一条有效路线(第二章),并在世界状态变化时持续重规划;随后由驾驶策略调制信号响应、跟车距离等行为参数(第三章)。派遣警车还需要将任务指派转换为路障这一运行时世界装配体,并在任务结束后回收其特殊状态(第四章)。对于直升机、飞机和船,则需要依据不同运动学约束提供专用执行器(第五章)。
这些执行层共享同一个输出接口:FVWVehicleControlCommand。车辆篇定义的油门、刹车、转向与手刹命令是各类执行逻辑的共同落点;执行栈写入控制量,驾驶策略调制参数,多车型执行器扩展命令载荷。车辆侧输出契约已经建立,本篇讨论其上层执行结构。
材料口径先交代:本篇①段对照的母库笔记有六篇是函数级的——GPS 路线运行时、驾驶个性、派遣与路障编排,以及直升机/飞机/船三个飞行与航行执行核——加上车辆篇已引的执行栈与支援族笔记。原版执行层的证据密度不低于前置交通决策层,原型侧则仍处于规划阶段。六篇笔记均以职责边界更正收尾(个性不是管理器、船不是第四套栈、包装不写控制);因此本篇①段按接口级需求说明书组织,分别记录各层的状态归属、暴露接口与明确缺口,算法内部继续标注盲区。
读完六章,应能明确:导航路线从目标输入到小地图表现经过哪些模块;同型车辆为何在相同信号条件下产生不同响应;路障从派遣指令生成到特殊状态回收的完整生命周期;以及直升机、飞机、船与汽车在执行器职责上的共享部分与差异边界。
一、驾驶执行栈:车流视角
单车四层驾驶执行栈——路线所有者 → 局部避让 → 控制写入 → 战术包装——主讲于车辆篇下篇。本章不重复其状态机与职责清单,只从车流视角说明三点。
① 执行栈是交通层的消费者
第一,执行栈是交通层的消费者。 路线所有者消费上篇的路网查询、限速区、路口判停与本篇的异步寻路;驾驶策略提供速度上限与行为参数;派遣链通过追击或路障包装改变局部目标。交通层最终通过“局部目标点 + 封顶速度”持续向执行栈提供输入,由执行栈转化为车辆运动。
第二,多车辆通过共享执行栈控制成本。 数百辆汽车共享路线、避让与控制写入核心,少数战术车辆增加包装层。新增车型主要增加参数集合与轻量包装,而不是独立 AI。远景无战术车辆则可以降级为批处理路径;车辆篇的 dummy 运动学预览 + 假乘客提供了从批处理车流到完整执行栈的中间状态。
② 多车辆共享执行栈
第三,共享范围受运动学约束限制。 汽车采用地面执行栈,直升机与飞机采用独立控制律,船舶复用部分地面深层叶子并增加水面适配。因此“共享执行栈”准确指向多数汽车的成本优化,而不是要求所有载具采用同一控制律。
③ 远景车辆与车型分档
原型状态:执行栈整体③未开始,目前仅有最底层输出接口 FVWVehicleControlCommand 已落地。
二、寻路、GPS 路线与重规划:路线计算与持续修正
路线系统解决的不是“找到一条路”,而是在世界持续变化时保持一条可用的路。
研究范围:路线所有者的路径选择、路线计算与重规划触发条件,以及玩家 GPS 导航线与 AI 车辆路线的底层寻路关系。底层寻路能力可以共享,上层由两种不同封装承载;GPS 封装本身就是包含多个字段与状态的完整子系统。
车辆篇下篇讨论路线生成后的执行,本章补充路线生成与维护机制。AI 车辆路线与玩家 GPS 导航线共享寻路能力,但不共享路线生命周期:AI 路线面向执行栈,需要节点与车道细节,由路线跟随辅助模块插值且不负责渲染;GPS 路线面向界面表现,需要坐标折线、颜色、显隐策略与进度提示。AI 路线随任务生命周期变化,GPS 路线槽则随标记或脚本生命周期变化;AI 重规划由驾驶状态触发,GPS 还需要处理玩家偏离导航线的输入。
① 原版机制
系统分为两层:底层寻路(归上篇第一章的路网数据库 PathFind / ThePaths)与上层路线封装(GPS 是其中一种封装)。该分层也体现在注册方式上:GPS 门面在游戏核心中仅注册初始化与关闭,不加入模拟骨架的逐帧更新;运行时更新由前端/HUD 路径和渲染线程的小地图更新驱动。GPS 属于界面侧,不拥有模拟状态。
底层寻路承担最近节点查找、异步路径搜索、路径节点流式请求、道路标志解析、车道偏移与右车道调整,并输出到目标的距离。路径搜索以异步作业执行,避免跨城搜索阻塞主帧;其生命周期为“请求→后台搜索→后续帧读取结果”。等待关系必须显式记录:GPS 侧维护槽级异步状态位与帧守卫,寻路侧维护按槽分配的搜索作业并在帧末回收,两侧共同闭合一次搜索的生命周期。
上层的 GPS 路线(玩家小地图导航)是一个很好的封装样本,它有一套清晰的所有权:
- GPS 门面拥有固定数量的「路线槽」(slot)数组、每槽的节点缓冲大小、自定义/竞速/多点路线的共享缓冲、异步搜索的帧守卫、GPS 闪烁与音频开关状态、以及跨「更新线程」和「渲染线程」双缓冲的玩家坐标(渲染线程读坐标画导航线时,更新线程可能正在写——双缓冲把这对读写解开)。
- 每个路线槽是一条具体路线的 owner:它拥有自己的路线坐标数组、路径节点地址、到目标的距离数组、目的地或目标实体引用、路线颜色、标识、脚本旗标、就近显示距离、路线状态机、计时门、部分目的地状态、路线推移进度、指令与距离状态、以及渲染失效位。「一条路线」在这套设计里是一个十几个字段的完整生命体,不是一串坐标——正因为槽里状态齐全,重规划、进度提示、按需显隐这些行为才都能槽内自理,不需要一个外部管理器替每条路线记账。
一条普通 GPS 路线的生命是这样的:Start() 先做一次准入(普通路线不许覆盖正在工作的竞速/多点/自定义路线——特化路线优先级更高)、捕获目的地或目标实体、重置计时、可选清掉过期的缓存节点,进入「计算路线中」状态;Update() 里,计算中的路线先请求一块 X/Y 区域的节点流式加载,等节点加载好、且这一帧允许搜索了,再调底层的「为 GPS 生成路线点(异步)」。GPS 拥有槽级的异步闸门(一面「本帧此槽禁搜」的旗),底层 PathFind 拥有真正的搜索作业——所有权切得很干净。闸门的存在还暗含一条节流约定:多个槽同帧都想搜时,由门面统一排布「这帧谁能搜」——寻路预算的分配权在消费端的门面,不在供给端,供给端只管把接到的作业算完;预算和产能分开管,任何一侧的调整都不惊动另一侧。门面层每帧的家务也值得列一遍:快照双缓冲的玩家坐标、复位各槽的异步搜索守卫、为每个 GPS 槽复位路网的活跃区域请求、更新所有槽、帧末清掉没用完的寻路侧异步 GPS 搜索槽——「每帧把借来的资源还干净」是门面对底层的礼貌,异步资源不跨帧悬挂。
路线需要持续维护,因此存在重规划。每个槽在车辆推进后执行 route shift,移除已消费节点;路线改变时设置失效位,通知渲染线程重新提交折线;目标实体移动、长距离搜索、车辆偏离、进出车与周期核验均可触发重算。长距离搜索可以先生成部分目的地路线,先提供方向信息;周期核验则通过异步作业检查附近路径节点,捕捉道路封闭或桥梁变化。到达检查由槽本地执行,负责关闭路径点并清除小地图路线。维护触发源与对应修正方式需要逐项建模,不能由单一定时器统一刷新。
GPS 还有几种特化路线,复用同一批槽但状态不同:竞速路线(收集作者标注的点、按路线边界请求节点、走专门的竞速路线生成入口——检查点导航要「按赛道走」而不是「按最短路走」,所以连生成入口都是另一个)、多点路线(多个点,缓存每个点的节点地址、拼接多段寻路腿,用一个专门的「腿进度」字段逐腿跟踪、消费完就剪掉该点——「送三个乘客」这类多目的地玩法的导航形态)、自定义路线(设计师/录制的折线,把点拷贝进槽缓冲直接显示,不做任何寻路搜索——「按我画的走」是显示需求,不是导航需求)。自定义路线还有两条只进不出的导入通道:从「路径点录制」和「辅助移动路线」两个数据商店导入折线——商店保留数据所有权,GPS 只借显示,又一处「数据归数据主,消费归消费者」。这说明「路线槽」是一个足够通用的容器,能装从「实时寻路」到「预定折线」的各种路线;而「哪些槽能被哪类路线占用」的仲裁(普通让特化)在入口处一次说清。
最后,GPS 到小地图的渲染交接在渲染线程做——它检查「GPS 该不该可见」(这个策略函数把十余条规则收拢在一处:禁用偏好、传送门可用性、GPS 闪烁、自定义地图、脚本强制显示、暂停地图/高尔夫地图/室内、飞机与水面与两栖浸水时的抑制、步行时只放行自定义路线、渲染线程容量、目标太近隐藏),然后把路线坐标、颜色、偏移、裁剪一并提交给小地图的导航线渲染入口;清除也走显式路径(清除旗+清导航线调用)。GPS 只供给路线状态和导航线提交,小地图的更新/渲染归小地图自己——而小地图反过来是 GPS 的调用方:标记路线开关时替玩家开合 GPS 槽、标记变色时给活跃路线重上色、路径点移除时清槽,卫星导航 UI 要显示的「找到路了吗/下一条指令/剩余距离」也从槽里查。两个系统互为消费者,但每一份状态只有一个主人——「双向依赖」不可怕,可怕的是「双向拥有」:小地图永远不改路线数据、GPS 永远不画像素,依赖的两个方向各走各的只读接口,循环引用就不会升级为循环所有权。脚本这一侧同样有完整的控制面(在实体上设路径点、闪烁、多点/自定义/竞速路线的建/加/渲/清、从录制导入),而脚本退出时的收尾归脚本处理器——把该脚本开的竞速路线、GPS 旗标、多点/自定义槽统一清掉,脚本忘了清理也不残留资源。这是「谁开的门谁关」在系统层的强制版:资源和它的申请方绑定登记,申请方生命周期结束时由框架统一回收——不指望每个脚本作者都记得清理,而是让「忘了清理」在结构上不可能泄漏。任何暴露给内容脚本的运行时资源(路线、覆盖值、事件),都值得配这么一个「随脚本死亡的回收器」。顺带一条考古发现:GPS 语音播报的代码整支被编译开关彻底禁用——「废弃通道以编译期禁用的形式留在原地」也是大型工程的真实面貌之一。
本章的意义:路线由异步搜索生成,并通过路线槽持续执行重规划。底层寻路与 GPS、竞速、多点、自定义等上层封装分离;route shift、部分目的地、偏离重算与周期核验均属于路线维护职责。AI 路线与 GPS 路线共享底层寻路,但不共享生命周期。部分目的地允许系统先提供可用的方向信息,再在后续搜索完成后补齐路线,以降低异步等待对界面的影响。
② UE5 迁移取舍
- 异步寻路作业——UE 的 Navigation System 支持异步路径查询,可复用其调度方式。但它计算的是 navmesh 路径,不是车道级道路路线;底层仍需在道路图上自建异步搜索或提供自定义查询。迁移时保留原版的异步账目结构:请求方持有状态位与帧守卫,供给方维护按槽作业,帧末统一回收。TaskGraph 只负责计算调度,作业等待、超时与回收仍属于业务层职责。
- 路线槽 + 状态机 + 重规划——纯业务逻辑,自建。route shift、部分目的地、偏离重算、周期核验这些都是策略;槽的字段清单(上文那十几项)可以直接当结构体设计的底稿。
- GPS 到小地图渲染——UI 层,复用 UMG/小地图方案,GPS 只供路线数据;「集中式可见性策略函数 + 渲染失效位 + 显式清除」三件套照搬。
一句话:异步调度可借引擎,车道级路线的搜索和维护自建。
③ 原型状态与规划
寻路与 GPS 路线在原型里未实现——它们在就绪门后面。原型目前只有「期望路线」这个占位标签(车辆篇讲过),背后的搜索、路线槽、重规划都没写。
规划方向清楚:底层异步寻路建在自建的道路图上(异步调度可参考 UE Navigation System),路线槽 + 重规划作为策略层自建,GPS/小地图渲染复用 UI 方案。落地顺序上,AI 路线先于玩家 GPS:两者共享底层,但 AI 路线是就绪门「缺期望路线」那道门的供给方、是执行栈能跑的前提,而 GPS 是纯玩家便利——先把底层寻路和「路线喂给执行栈」的通路打通,GPS 门面作为第二个消费者接入时,顺便就验证了「底层被两个上层共享」的架构是否真的成立。第二个消费者是对「共享设计」成本最低的检验。
诚实边界:这一章③是迁移地图。异步路径搜索的算法内核(在道路图上怎么搜、cost 怎么算)是盲区。
三、驾驶个性:把行为差异压缩成无状态策略函数
研究范围:风险参数如何产生差异化驾驶策略,以及信号响应、跟车距离与停车行为等输出的来源和计算方式。
本章机制范围有限,但它是交通行为差异化的重要基础。其设计重点在于职责收敛:该模块不是交通管理器,也不维护车辆运行时状态。原版笔记专门记录了这一职责边界,以下将通过具体机制说明这一点。
① 原版机制
原版的驾驶个性(下称 DriverPersonality)有一个反直觉、但极其干净的设计:它没有任何自己的持久状态——它是一个纯粹的、无状态的策略计算器。
它只暴露静态方法,不拥有成员字段、管理器单例或更新循环。该模块是策略函数库,提供驾驶能力、激进程度、巡航速度、信号延迟、变道时机、停车距离、鸣笛行为、车道摆动与转向灯使用等策略输出。
其输入全部来自外部状态源:
- 「找驾驶能力」从三个来源取:车没真司机时用假乘客的能力值、ped 有覆盖值时用覆盖值、否则用 ped 模型的个性设置。
- 「找激进程度」同理:假乘客的激进值 / ped 的覆盖值 / ped 模型个性设置。
因此,持久状态归属于 ped 智能、ped 模型个性数据与车辆侧假乘客字段;驾驶个性模块只从这些来源计算归一化输出,不持有运行时状态。
然后它从“勇敢度/激进度”两个输入派生一组策略输出,并可叠加可调参数。函数命名本身构成行为清单:FindMaxAcceleratorInput(最大油门输入)、FindMaxCruiseSpeed(最大巡航速度)、FindDelayBeforeAcceleratingAfterLightsGoneGreen(绿灯后的起步延迟)、FindDelayBeforeAcceleratingAfterObstructionGone(障碍消失后的起步延迟)、AccelerateSpeedToCatchGreenLight(加速通过绿灯)、RunsAmberLights / RunsStopSigns / RollsThroughStopSigns(黄灯、停车标志与滚行通过策略),以及变道意愿与时机、额外停车距离、跟车行为、行人避让距离、转向灯使用、摩托车道摆动和鸣笛响应间隔等。函数命名集中体现策略求值,而非运行时状态维护。
这些都是由驾驶策略参数计算得到的输出,而不是持久化的运行时状态。 模块回答的是“当前输入下应采用何种驾驶策略”,而不是维护驾驶者的持久状态。
该设计将驾驶差异实现为可对任意输入即时求值的纯函数。函数不持有状态,避免策略缓存与实际状态分离,并可由本地车辆、网络克隆车辆和假乘客统一调用。由于输出由能力、激进度和可调参数确定性推导,联机侧只需同步这些输入状态,无需同步派生策略结果。
在同一个黄灯路口,高激进度驾驶者可能得到“允许通过黄灯、短起步延迟、较近跟车距离”等输出;低激进度驾驶者则可能得到相反参数。两者使用同一套执行栈与判停链,差异仅来自策略计算器的输入参数,但会形成不同的信号响应与跟车行为。叠加鸣笛响应、变道意愿和停车标志处理等参数后,同一套行为逻辑可以产生多种驾驶风格。驾驶个性不是为每辆车编写独立行为,而是为共享行为逻辑提供不同参数。
该策略支持分级覆盖:默认值来自 ped 模型个性设置,ped 智能可提供临时覆盖值,假乘客使用车辆侧保存的近似值。追逐场景可以将逃犯驾驶者的激进度覆盖为高值,继续复用环境车辆的同一组策略函数;场景结束后清除覆盖,恢复模型默认值。特殊驾驶行为由输入覆盖实现,不需要新增独立 AI。
这个计算器的消费面比「汽车抢黄灯」宽得多,两条跨章证据:上篇红绿灯的判停链问它「要不要抢黄灯」;本篇第五章会看到,连巡航的船都拿它的最大巡航速度做钳制——「个性」是全载具通用的行为调制层,不是汽车专属。反过来的负向结论也要钉死(母库笔记专门做了这个澄清):它不是全局交通服务、不是路口控制器、不是车辆更新循环、也不是存在每辆车上的行为组件——后续任何设计讨论把「活的世界编排」归到这个文件头上,都是归因错误。它只是一个被所有真正的运行时 owner 调用的策略函数库。 为什么这个澄清重要到值得专门一节?因为「个性」这个词天然容易引起误解——直觉上它该是「每辆车身上的一个组件」,而错误的直觉会长出错误的架构(每车挂个性组件 → 组件要同步 → 组件要和实际行为对账 → 一致性问题凭空多一层)。命名会引导架构,负向结论是给命名消毒。
本章的意义:信号响应、跟车距离与鸣笛响应等驾驶差异,由无状态策略计算器即时求值,而不是由每辆车维护独立行为状态。驾驶个性数据与计算逻辑分离,可被不同车辆统一复用,也便于表驱动测试与参数调校。该模块不依赖尚未实现的交通执行系统,适合在交通运行时其他部分之前独立实现。
② UE5 迁移取舍
驾驶个性这层几乎是纯策略数学,没有 UE 现成对应(它业务属性太强),但它恰恰是最容易、也最该原样搬的一层:
- 个性计算器自建为一组无状态函数/一个策略计算类——照搬原版「无状态、从外部输入即时求值」的设计,连「问句式命名」都建议保留(函数名即行为文档)。
- 个性数据(能力、激进度)用数据表/数据资产承载,让策划配「这类司机多激进」;三级来源的优先级链(智能覆盖 > 假乘客近似 > 模型默认)做成一个单独的「取值函数」,所有派生函数只从它拿输入——来源优先级只写一遍。
- 可调项(tunable)用配置承载,方便运营期调参;每个派生函数「基础值 × 个性系数 + 可调偏移」的形状统一,调参工具可以按函数批量生成滑杆。
该层不涉及实体关系或批处理组织,仅负责“输入→策略输出”。由于无状态且依赖少,可以独立于路网与路口实现并进行单元测试。
③ 原型状态与规划
驾驶个性层在原型里未实现,但规划边界明确:该层无状态、依赖能力与激进度输入,可独立于路网与路口优先实现并进行单元测试。
它的输出口也已经有着落——车辆篇讲的 FVWVehicleControlCommand(油门/刹车/转向)就是它「最大油门/巡航速度」这类输出的落点,EVWVehicleCommandSourceType::AI 就是它作为 AI 驾驶来源的身份。而且它的测试形态在这套代码库里最为简洁:纯函数意味着测试就是「表驱动断言」——一张(勇敢度, 激进度, 可调项)→ 期望输出的表,几十行断言覆盖全部派生函数;等执行栈落地时,个性早已是被测透的现成组件。在依赖链的最末端先造好一个零依赖的组件,是「等待上游」期间性价比最高的动作。
诚实边界:本章③属于迁移地图,原型尚未实现。个性策略的输入与派生关系已明确,算法内部没有额外盲区。
四、派遣执行与路障:从指派到世界装配体
研究范围:派遣编排如何将“设置路障”的指派转换为由警车、警察与阻挡物组成的运行时实体集合,以及任务结束后如何回收这些特殊实体并恢复常规交通状态。路障是本篇唯一需要批量生成实体集合的场景,其生命周期体现特殊生成路径与常规世界状态之间的一致性要求。
① 原版机制
派遣链的执行端,最有代表性的就是路障层(roadblock)。路障结构上和普通警车复用/生成不同——它既不是事件也不是指派,而是一个生成出来的世界装配体:拥有一小组车、一小组 ped、一小组物件、路障位置、目标 ped、最小存活时间、驱散/despawn 策略。具体变体有两种:车辆拒马和钉刺带——变体由这次生成用的物件模型解析出来,不是两套独立系统。它由「路障派遣服务」生成——四个前提缺一不可:目标是通缉 ped、目标在车里且通常在开(对步行目标设路障没有意义)、生成辅助器在目标行进方向前方找到了合适的路网节点(路障要设在「他将要经过的路」上,这是一次小型的路径预判)、车/人/物三类模型集都已流式就绪。四个前提各防一种穿帮:没通缉不设卡(世界不无端敌对)、不在驾不设卡(卡了也没意义)、不在前方不设卡(设在身后毫无意义)、模型没到不设卡(宁可这次不设,也不让半套资产的残缺路障出现在玩家面前)——「条件不齐就干脆不做」比「勉强做一半」更能保住世界的可信度。然后从选中的路网节点构建一份「创建输入」、生成路障、标记「目标不再通缉就自动驱散」、给生成的车打上「派遣所生」标记、把新生成的路障 ped 推进服务资源列表——之后正常的指派流程给这些 ped 发「通缉·在路障等待」的专用指派枚举。特殊生成路径只特殊在「怎么出生」,出生之后立刻回流进普通的指派/任务管线——不会因为是路障就多一套平行的执行体系。
先把「路障为什么不能是任务或事件」说透:事件的生命跟着「需求」走(通缉没了事件就该结束),任务的生命跟着「执行者」走(警察死了任务就中止),而路障的生命跟着「一组世界实体的物理存在」走——警察全灭了拒马还堵在路上、通缉结束了车还要开走。三种生命周期没有一种能覆盖另一种,所以路障必须是第三种对象。这也是判断「要不要引入新对象类型」的通用测试:找不到一个现有 owner 的生命周期能完整承载它,才有理由新建一类。
路障生成后独立更新自己:计时、对目标的超距跟踪、自动驱散(联机下目标死亡或持续超距也触发)、周期清理走散实体(路障的车被撞离就从装配体里注销)、逼空的路障车让其他交通停下(没有司机的拒马车也要参与交通语义——别的 AI 车得把它当成「停着的障碍」绕行或排队,而不是无视)、按最小存活时间/目标距离/是否在屏幕上决定 despawn(在屏幕上时不删——玩家眼前的物体不能凭空消失,和角色篇人口剔除的「视锥规则」同源)。它有两个不同的结束态:驱散(把路障实体放回环境所有——车装上假乘客开走、实体撤销「持久拥有」保护、人口类型与归属恢复给人口控制)和 despawn(硬删除,释放后销毁)。路障不是「不需要了就消失」,而是先尝试变回普通世界实体。
联机侧路障派遣不参与管理器级资源预留,但每个实体创建点仍检查网络对象注册上限。路障属于低频、短命、局部装配体,因此采用“无预留、守硬上限”的工程折衷;该不一致需要明确记录。
路障生命周期集中演示四条不变式:生成经过准入校验,运行期间由唯一 owner 更新,结束时优先驱散回流,成员回归后重新进入个性与预览等推导层。路障因此成为执行层的代表性样本。
“驱散优先于删除”的设计具有连续性价值:通缉状态解除后,玩家再次经过原路障区域时,看到的不是路障实体直接消失,而是警车恢复为普通交通状态并离开现场——特殊场景实体在任务结束后回归环境,是世界状态连续性的来源。 这一过程依赖前文建立的假乘客与人口控制归属机制。
把路障和角色篇的场景点并排看,还能看出「内容进入世界的两条对偶通道」:场景点是数据先于实体——点烘焙在世界里,人口系统按点生成 NPC 并装上行为;路障是事件先于实体——派遣按运行时事件凭空装配一组实体再回流秩序。前者供给「常态的活」(街角总有人抽烟),后者供给「事件的活」(通缉才有路障)。两条通道的终点相同:实体要么被打断回日常(场景 NPC 被吓跑),要么被驱散回环境(路障车开走)——「从哪来」各有各的门,「回哪去」共用一个归宿:人口系统的常规秩序。
被绑定指派的单个警车或警察实体由下游任务读取指派字段,并在“前往派遣点、车内搜索、步行搜索、战斗、路障值守”等状态之间切换,最终进入车辆篇下篇讨论的战术包装层(警察行为选择器→追击/封堵→执行栈)。多车辆协调与单车机动之间的交接点是可变的指派记录。 指派首次绑定到 ped 时才写入时间戳,重试不重复计时;联机状态还需要处理响应者已有其他事件指派的冲突。同一响应者在同一时刻只能服务一个事件,资源争夺必须经过显式冲突处理,不能由后到指派覆盖既有状态。下游任务如何将指派解释为追捕、逮捕或搜索机动,仍属于本系列未深挖的盲区。
本章的意义:派遣执行端不是简单生成车辆,而是一个具有生命周期、独立更新与多种结束路径的世界装配体。“驱散回环境”优先于硬删除,使特殊场景实体在任务结束后恢复为普通交通。凡是“一组实体整体生成、整体退出并共享编队级策略”的场景,例如检查站、车队护送与事故现场,均可采用类似的复合对象;成员实体继续由各自系统维护,装配体只拥有编队级生命周期与策略。
② UE5 迁移取舍
- 路障作为复合生成体——自建;它的「驱散 vs despawn」正好复用车辆篇的「假乘客」和角色篇的「实体放回人口控制」机制。装配体范式本身值得抽象成一个可复用的基类形态:成员句柄列表 + 编队级策略 + 生灭状态机——检查站、车队、事故现场共用。落进原型的形状也现成:装配体就是一个持有成员句柄的世界实体(角色篇的句柄纪律保证成员死了能被识别),它的独立更新挂控制相位,成员通过既有的人口/座位/驾驶权协议操作——不需要为「编队」发明任何新的底层能力,只需要一个新的编队级 owner。
- 生成前提(目标前方路网节点、流式好的模型集)——依赖上篇的路网数据和引擎的流式设施;「在目标行进方向前方找节点」这一步,将来是路线层的一个查询(给定实体速度向量,取前方 N 米最近节点),接口今天就能定。
- 指派→任务的状态交接——自建(指派记录在上篇已讲,执行侧读它切状态);「位置需要更新」旗的消费端,对应原型任务槽已有的「按帧读状态、变了才重定向」模式。
③ 原型状态与规划
派遣执行在原型里未实现。 但「驱散回环境」路径依赖的两块基础已有着落:假乘客(车辆篇讲过其预算模型,规划项)和实体放回人口控制(角色篇讲过人口所有权契约,规划项)——这两块落地后,路障的驱散路径将来接得上。
诚实边界:路障生成、独立更新、驱散策略,原型都没写,是迁移地图。下游警察任务把指派解释成机动的内部,盲区。
五、多车型执行器:直升机、飞机与船的运动学差异
研究范围:汽车之外的直升机、飞机、船与摩托车对汽车执行器的复用边界,以及运动学差异对执行器职责拆分的影响。
本章补充车辆篇下篇的四层汽车执行栈。其他载具类型依据运动学约束采用不同执行器,但仍共享任务契约、命令载荷与跨载具策略。三个执行核均已完成函数级阅读,因此原版机制部分将具体说明各核写入的控制通道、内部模式划分及其与地面执行栈的复用关系。
| 载具 | 路线来源 | 控制执行 | 复用程度 |
|---|---|---|---|
| 汽车 | 道路网络 | 地面车辆执行栈 | 基础 |
| 船舶 | 水面路线 | 复用地面深层叶子并增加水面适配 | 中等 |
| 直升机 | 三维目标与飞行路径 | 专用 PID 与三轴控制律 | 较低 |
| 飞机 | 固定翼路径与起降状态 | 专用固定翼控制律 | 最低 |
① 原版机制
车辆篇上篇已经说明,车辆侧的持久驾驶智能由工厂按车型特化:普通地面车/船、直升机和飞机分别采用不同执行器。原因在于各类载具的运动学约束不同:
- 汽车沿二维路网走,要处理车道、junction、避让——就是车辆篇下篇那套四层栈。
- 直升机在三维空间飞。它的「去点飞行执行核心」是一个真正的直写控制器:每帧配置直升机的 PID 控制器组,把「期望速度减当前速度」的差投影到机体前/右/上三轴,换算成俯仰/横滚/油门修正并钳制后直接写入(偏航单独走一条:有显式朝向要求就朝它,否则朝水平速度方向,否则保持现向,差值过偏航 PID)——四个写入通道还能被旗标各自独立压制。它自己拥有地形安全的目标高度规划(前向探测预估地面高度)、异步世界避障加飞行器互避、以及一条专用的低 LOD 时间片转向路径(远处的直升机降频后仍由这条路径保持航向——且只有「无父任务」的顶层 goto 才启用时间片,被包装持有的不启用)。这条时间片路径值得和车辆篇的运动学预览对照:汽车的「远处便宜近似」是一套独立的预览状态,直升机的则是执行核自带的降频模式——用上次的转向目标、一面「全量更新之间还要不要转向」的缓存旗、一段「最近躲过障碍」的记忆支撑起低频飞行;近似的形态不同,但「降档 = 换开销更低的推进方式」的原则一致。语义上还有一个反直觉点:直升机的普通「去某点」任务默认到点不结束——它同时是「把直升机保持在这个任务点」的悬停核。降落、悬停、逃逸、护航、盘旋、攻击、跟随录制路线这些看起来五花八门的直升机行为,全部是它上面的包装,没有一个自己写控制。
- 飞机的「去点飞行执行核心」同样是直写控制器(偏航/俯仰/横滚/油门/减速板/转向角/虚拟速度七个通道),内部是一个三态模式开关:精确垂直起降模式(位置保持/进近,直接控制而非委托悬停任务——「精确模式」也在自己的控制律里,不外包)、带固定朝向的精确模式(侧向误差走横滚 PID、前向距离走俯仰,边保持朝向边平移——「保持机头朝向同时横着挪」这种电影镜头式的飞行方式,是一条独立的控制路径)、以及常规固定翼模式(转弯半径几何+地形回避+高度斜率控制;高度控制同时拥有目标坡度和地形回避,XY 转向按「空中滚转转弯 / 地面偏航加轮子」干净分成两支)。悬停/垂直逃逸/降落/攻击/追逐这些包装都坐在这个核之上;降落(对齐跑道、下降、减速、着陆)是坐在这个核上的独立任务——起降的复杂度配得上单独成篇的状态机。
- 三个核在栈里的深度也不一样,先给一个定位:直升机与飞机的核=「路线所有者+控制写入者」合并为一层(空中没有共享叶子可分层,两层职责收进一个类);船的核=纯「路线所有者」(控制写入完全下放)。「一套执行器」在空中是一个类,在水面是半个类——层数由可复用的下层决定,不是由载具的地位决定。
- 船是三种非汽车里最「复用」的一支:船的「去点」任务拥有水面路线搜索、分段跟随、直线/导航网格/三点掉头/暂停/停船的模式切换和靠岸策略,但它不是最深的控制写入者——真正的运动执行委托给汽车家族的避让叶子、导航网格叶子和停车叶子,船特有的避岸速度/朝向修正通过一个「船只避让助手」挂进那些深叶子里生效。上面两层包装更薄:巡航船是「环境点选器」(两个状态的壳:挑一个游荡点、可选按人口数据定巡航速度、再用驾驶个性的最大巡航速度钳制一道——个性这条线连船都管;下层任务受阻或路线将尽就提前换点,游荡目标移远了把新位置推给现有 goto 而不是重建任务;设参时还特意保留上一个游荡目标不被通用重置覆盖掉——包装层自己那点状态,守得同样仔细)、逃逸船是「反向目标包装」。
但共享契约仍在:所有这些载具任务都继承同一个「载具任务基类」,用同一个共享的驾驶命令载荷(目标实体、目标位置、到达距离、驾驶标志、巡航速度、最大巡航速度)。基类还实现一批跨载具复用的策略:从实体或显式位置解析目标坐标、判目标是否移动、归一化到达距离和巡航速度规则、暴露「是否遵守红绿灯」这类驾驶标志策略、拟人化并钳制转向/油门/刹车、为网络同步序列化任务状态、迁移后重建路线。注意这份共性清单的性质:它们全是「任务作为网络与调度公民」的义务(可序列化、可迁移、目标可解析、输出被钳制),而不是任何具体的驾驶知识——基类抽走的是行政共性,不是驾驶共性,这正是它能横跨天上水里的原因;哪怕以后加潜艇、加摩托艇,这份行政义务照样适用。
所以结构是:一个共享的载具任务契约 + 共享的命令载荷 + 共享的跨载具策略,之上是各载具类型自己的具体执行器。 战术包装层(追击、并排、警察行为)则跨载具复用——警察行为文件里同时有汽车、直升机、船的分支,因为「选择跑哪个战术子任务」的逻辑是通用的,只是委托给的具体执行器不同。空中侧也各有一层自己的包装生态:警用直升机有独立的行为选择器(选巡逻/追击/支援哪种模式)和保护/护航包装(围绕保护目标维持位置),飞机有追逐包装(为空中追逐几何持续重写 goto)——名字不同,形状和地面的警察行为/追击/并排完全同构:选择器选模式、包装重塑目标、执行核写控制,这个三段式跨介质成立。
三个执行核还共享一条和地面栈相同的元规律:包装永远比核薄。直升机的护航/盘旋/攻击、飞机的追逐/降落、船的巡航/逃逸,每一个都只有两三个状态、一两样自有状态(游荡点、追逐几何、护航偏移),厚度全部沉在各自的执行核里。「上薄下厚」是健康执行栈的体检指标——反过来「上厚下薄」(包装里堆满控制细节)意味着抽象层选错了位置。
综合三种车型,执行器可以分为两类。空中载具采用独立控制律:没有可复用的地面路网与避让叶子,因此直升机和飞机分别实现 PID 组、三轴投影或转弯半径等控制机制。船舶则采用部分复用方案:路线与模式管理自建,控制写入复用汽车家族的深层叶子,并通过避让辅助模块注入水面差异。新增载具是否需要独立执行器,取决于其运动学假设能否复用:若与地面驾驶同样具备二维推进、前向运动和制动能力,可采用复用加适配;若存在三维运动、升力或悬停等差异,则需要新的控制律。
本章的意义:驾驶执行器不是单一实现,而是建立在共享任务契约、共享命令载荷与共享跨载具策略之上的类型化执行器。汽车遵循二维道路网络,直升机遵循三维飞行控制,飞机处理起降与固定翼运动,船舶遵循水面路线;各类载具在任务表示与序列化方面保持共性,在控制律与运动学执行方面进行特化。复用判据最终落在运动学假设是否兼容。
② UE5 迁移取舍
- 共享契约 + 命令载荷 + 跨载具策略——自建为一个基类/接口,正好对应车辆篇讲的
FVWVehicleControlCommand(可扩展成含三维意图)。基类只装「行政共性」(序列化、迁移、目标解析、输出钳制),不装任何驾驶知识——这条边界从原版原样搬。 - 各载具具体执行器——各自自建,按两档判据排期:船先(路线层 + 避让插件,复用地面栈),飞行器后(各一套控制律)。直升机/飞机的控制核抄结构不抄参数:三轴投影、通道独立压制、地形安全高度这些结构照搬,PID 增益针对 Chaos 的飞行体重调;「普通去点默认悬停保持」这条语义也值得一并继承——它省掉了一个独立的悬停任务。
- 物理——各载具的刚体物理(车/直升机/飞机/船)复用引擎的对应方案,不自建(和车辆篇「物理接缝」一章一个道理);每种载具接物理时,沿用车辆篇那道「意图-适配器」接缝,一种载具一个适配器实现。
③ 原型状态与规划
各车型执行器在原型里未实现——连汽车的执行栈都还没写,其它载具类型更靠后。但共享契约的输出口已经有雏形:车辆篇的 FVWVehicleControlCommand 就是「共享命令载荷」的地面车版本,将来扩成含三维意图(爬升/悬停)就能覆盖直升机/飞机。而「两档复用」的判据直接翻译成原型的建造顺序:船先于飞行器——船只要地面执行栈落地就能以「路线层+避让插件」的成本接入;直升机/飞机各需要一套新控制律(以及 UE 侧对应的飞行物理),是独立的、可以无限期后置的工作包。UE 复用面也照判据分:船的水面物理看 Chaos 的浮力设施,飞行器的控制律不建议照抄原版 PID 参数(那是调给另一套物理引擎的),抄结构、重调参。
诚实边界:各载具执行器的算法内部(直升机的悬停控制、飞机的降落对齐、船的水面避让几何)是盲区。这一章诚实地是「原版设计 + 迁移方向」,原型无对应代码。
六、表现不是执行:状态如何交给灯光与声音
本章用于界定交通状态与视觉、音频表现之间的接口,不展开表现系统内部实现。
车流的视觉表现(车灯、刹车灯、转向灯的亮灭,远景车流的渲染)和听觉表现(引擎声随速度、鸣笛、警笛的空间化),在本系列的口径里全部归复用引擎:灯光走材质/光照(上篇红绿灯章的「表现归表现」同理),音频走引擎音频系统的空间化与参数驱动。自建的只有一件事:行为层要把「表现需要的状态」暴露成可查询的数据——车此刻在刹车吗(刹车灯)、转向意图是什么(转向灯)、鸣笛决策(个性章的输出之一)——这些状态在驾驶指令和个性输出里本来就有,表现层只是消费者。「表现层只管表现,状态归拥有它的系统」——上篇红绿灯章立的这条纪律,对车本身同样适用。
本篇第二章的 GPS→小地图交接,顺带给「行为层和表现层怎么正确交接」提供了一个可照抄的范本:状态侧只提交数据(路线坐标、颜色、失效位),表现侧拥有自己的更新与渲染,可见性策略集中在一个函数里、清除走显式路径、跨线程用双缓冲——将来车灯/音频接表现层,按这五条办即可。上篇红绿灯的「灯泡=骨骼+损坏位」补充了视觉侧的另一半范本;两者合起来,车流表现层的设计输入其实已经齐了,缺的只是排期。
顺带把本章和 UE 的对应物逐项点名:车灯亮灭对应材质参数/灯光组件的开关,由车辆 Actor 的表现组件消费行为状态;引擎音效对应 MetaSounds/音频组件的参数驱动(转速、速度作输入);警笛空间化走引擎音频的衰减与遮挡。没有一样需要自研——这正是把它压成「备注」而非「章」的原因。
最后一个次序提醒:表现层虽然排最后,「行为层暴露表现所需状态」这半件事却要提前做——刹车、转向意图、鸣笛这些字段,在设计驾驶指令和个性输出的那一刻就该带上(原型的 FVWVehicleControlCommand 已经带了刹车与转向),否则等表现层开工时再回头改行为层的结构,就是一次跨层返工。表现可以晚接,表现的数据口不能晚留。
原型状态:③ 未开始(表现层排在所有行为层之后);无盲区(纯复用)。
七、迁移取舍:交通篇(下)的落地清单
判据沿用系列口径:① 已落地 / ② 已立骨架(输出口就绪)/ ③ 未开始 / 复用 / 盲区。
| 层 | 关键机制 | 原型状态 | 落点 |
|---|---|---|---|
| 驾驶执行栈 | 四层栈(主讲在车辆篇下篇) | ③ 未开始 | 输出口 FVWVehicleControlCommand 已落地 |
| 寻路/路线 | 异步路径搜索(请求→后台→取结果) | ③ 未开始 | 原版 deep;异步调度可参考 UE Nav |
| 寻路/路线 | 路线槽 + 状态机 + 重规划(shift/部分目的地/偏离/周期核验) | ③ 未开始 | 原版 deep;纯策略自建 |
| 寻路/路线 | 特化路线(竞速/多点/自定义 + 导入通道) | ③ 未开始 | 原版 deep;槽容器通用化 |
| 寻路/路线 | GPS→小地图渲染(双缓冲/失效位/集中可见性策略) | 复用 | UMG / 小地图;GPS 只供路线数据 |
| 驾驶个性 | 无状态策略计算器(问句式函数库) | ③ 未开始(最易搬) | 原版 deep;输出口 = 驾驶指令结构 |
| 驾驶个性 | 三级来源(模型默认/智能覆盖/假乘客近似) | ③ 未开始 | 原版 deep;数据表 + 配置承载 |
| 派遣执行 | 路障装配体(拒马/钉刺带两变体) | ③ 未开始 | 原版 deep;「编队级复合对象」范式 |
| 派遣执行 | 生成四前提(通缉/在驾/前方节点/模型流式) | ③ 未开始 | 原版 deep;生成即预判路径 |
| 派遣执行 | 驱散回环境(优先于硬删) | ③ 未开始 | 依赖假乘客 + 人口控制(已有基础) |
| 派遣执行 | 指派→警察任务的机动解释 | 盲区 | 下游执行层,未深挖 |
| 各车型 | 共享契约 + 命令载荷 + 跨载具策略 | ② 输出口有雏形 | FVWVehicleControlCommand(可扩三维意图) |
| 各车型 | 直升机直写控制核(PID 三轴 + 低 LOD 时间片) | ③ 未开始 | 原版 deep;控制律抄结构不抄参数 |
| 各车型 | 飞机直写控制核(三态模式开关 + 起降任务) | ③ 未开始 | 原版 deep;同上 |
| 各车型 | 船(路线层自建 + 复用地面深叶子 + 避岸插件) | ③ 未开始 | 原版 deep;排在飞行器之前 |
| 表现层 | 车灯/引擎声/鸣笛表现 | 复用 | UE 材质光照 + 音频;状态由行为层暴露 |
本篇没有一项执行层机制达到“① 已落地”;执行层整体仍处于规划阶段。已具备的基础包括 FVWVehicleControlCommand 输出接口、假乘客与人口控制的迁移落点,以及可独立实现的驾驶个性计算器。原版函数级阅读将执行层拆分为可单独验收的条目,并为每一项提供迁移判据。结合上篇,建造优先级为:就绪门 → 驾驶个性 → 路网与执行栈 → 路口与红绿灯 → 派遣执行与多车型执行器;越接近单车运动的层越早实现,越依赖多实体协同的层越后实现。
这个优先级还能换一个角度验证——按「消费者数量」排:个性被一切载具消费(最通用,先做);路网被执行栈/路口/红绿灯/人口/GPS 五方消费(次之);路口相位只被红绿灯和执行栈消费;派遣只被警用行为消费;单车型执行核只被自己的包装消费(最专用,最后)。被消费得越广的层,越早落地收益越大——它每提前一天,下游所有依赖方的开发就解锁一天。两种排法(依赖方向、消费广度)给出同一个顺序,这个顺序就比较可信了。
而交通主题两篇合起来,再次印证系列心法:纯数据/查询层复用引擎(navmesh、异步调度、灯光、音频、流式、小地图),带业务语义的关系与策略自建(道路图、执行栈、重规划、路口仲裁、判停、个性数学、派遣编排与路障)。分得清这条界,交通系统才不会变成一个既想套用引擎、又处处对抗引擎的折中产物。
本篇还给心法追加了执行侧特有的一条:「无状态的尽量无状态,有状态的必须有主人。」 个性是纯函数(零同步、零一致性负担)、判停是纯咨询、可见性策略是纯谓词;而路线槽、路障装配体、指派记录这些不得不有状态的东西,每一个都有唯一的 owner 和明确的生命周期。执行层的复杂度守恒——把能压掉的状态全部压成函数,剩下的状态才支撑得起足够的纪律。
两篇合读:交通的四条不变式
出勤叙事之前,先把交通主题上下两篇反复出现的结构规律收成四条「不变式」——它们在路网、路口、灯、GPS、派遣、车型六个题材里各自独立出现,却是同一批形状:
- 数据与活跃分离:路网数据库(静)对路口注册表(动)、路口模板(静)对路口实例(动)、个性数据表(静)对个性求值(动)——每个题材都把「作者写死的」和「运行时跳动的」分成两个 owner。
- 门面消费、源头拥有:红绿灯消费路口相位、GPS 消费寻路作业、判停消费个性答案——门面负责「合成一个可用的决定」,从不夺走任何一项输入的所有权。
- 准入与回流:就绪门、事件可行性门管进;路障驱散、脚本退出清理、异步槽帧末回收管出——进来的要够资格,出去的要干净,系统内部才能只处理干净的中间态。
- 确定性推导不同步:红绿灯的共享时钟、个性的纯函数——凡能从共享输入推导的,绝不作为状态同步。
后续评审交通子系统时,可按四项检查:静态数据与运行时状态是否分离;门面是否越权;生命周期入口与出口是否均有 owner;可推导结果是否被错误建模为需要同步的状态。这些检查同样适用于场景点、封闭区和 NPC 决策权重等系统,是开放世界运行时的通用不变式。
把两篇拼回一辆警车的一次出勤
交通主题上下两篇讲了十几个 owner,收尾前用一次完整出勤把它们串回一条线(每个环节都指回它的主讲章节):玩家通缉升到三星——通缉系统的状态变化流进通缉事件,事件查响应表把三星翻译成「再要两辆警车一个路障」(上篇第四章);派遣服务先清点存量(那辆已经在追的警车保留),差额从空闲资源里补、补不齐就按前提生成,路障派遣在目标前方的路网节点上生成一组拒马和警员(本篇第四章);新警车被绑上指派,巡逻任务读指派切进「去派遣点」状态(上篇第四章),它的警察行为选择器选中追击,追击包装不断把目标位置写进去某点任务(车辆篇下篇);去某点任务向路网数据库发异步搜索、等节点流式、拿到路线交给跟随路线助手插值(上篇第一章、本篇第二章);路上每个活跃路口都先把它登记进管辖、按相位放行,红绿灯问过驾驶个性——这位司机激进度高,黄灯照冲(上篇第二、三章,本篇第三章);而这一切开始之前,这辆警车先通过了就绪门的七道检查(上篇第五章)。玩家最终甩掉通缉——事件需求归零,服务撤指派,路障驱散:警员上车、拒马车装上假乘客汇入车流,一切变回普通交通(本篇第四章)。没有任何一个「总导演」写过这段剧本——十几个各管一段的 owner,把它演了出来。 需要重申:这段叙事描述的是原版机制的协同;在原型里,这条链上今天真实存在的只有就绪门和它两侧的所有权状态。把这条链当成原型的验收愿景读,正合适——每落地一层,叙事里就有一句话从「原版如此」变成「我们也如此」。
执行层的三条通用经验
与前两篇的「实现经验/接缝经验」对仗,本篇从原版执行层沉淀三条:
其一,响应性优先于完整性。 部分目的地路线、驱散优先于删除以及节点流式加载等待均应建模为显式状态,而非阻塞执行。异步系统可以先提供可用近似,但必须保留明确的升级路径。
其二,共享的东西越底层,收益越大。 底层异步寻路被 AI 和 GPS 共享、地面深叶子被汽车和船共享、个性计算器被一切载具共享——而上层封装(GPS 槽、船路线层、战术包装)各自独立。把共享做在稳定的底层、把差异留在多变的上层,复用才不会变成耦合。
其三,特殊路径应当入口特化、出口回流。 路障生成使用专门入口,生成后仍回到普通指派管线;特化路线拥有独立建立入口,但复用既有路线槽与渲染路径。避免为特殊场景增加长期平行的运行时路径,以控制状态空间。
AI 协作复盘
本篇属于交通主题的执行侧,原版机制材料完整,原型实现尚未开始。原版侧覆盖寻路/GPS、驾驶个性、路障与多车型执行器,原型侧目前仅有共同输出接口及相关基础。由于缺少原型代码交叉验证,①段的判断均需落实到函数、状态与字段层级,并在③段明确迁移边界。
AI 辅助结果。 本轮工作主要完成跨笔记的职责归并与边界核对:AI 车辆与玩家 GPS 共享底层异步搜索,但使用不同上层封装;巡航、追击与警察围堵共享执行栈,差异位于战术包装层。函数级笔记进一步确认了几项负向结论:船舶不是独立的第四套地面执行栈,直升机普通去点任务包含悬停保持语义,路障不参与预留预算但受注册上限约束,GPS 语音通道属于编译期禁用的遗留路径。驾驶个性模块不持有持久状态,也不承担交通管理职责。
边界控制。 与上篇相同,本篇没有任何章节能够对照原型真实代码,全文属于“原版设计 + 迁移地图”。因此每章③均明确标注“未实现”,唯一已落地的相关接口是 FVWVehicleControlCommand;文章不会将迁移规划描述为原型现状。
盲区处理。 寻路算法内核、避让几何、直升机与飞机 PID 调参值、船舶避岸修正几何以及警察任务的机动解释均标注为盲区。当前可确认的是控制核的输入输出结构(期望速度到三轴的投影、四个写入通道与旗标压制);PID 增益等参数需要结合 UE5 物理重新调校。驾驶策略是本篇唯一可完整还原的部分,其核心是从两个标量派生策略输出。
规格化验收方式。 本篇六章中有五章原型尚未实现,因此①段的产出被整理为可验收接口清单:路网查询面、GPS 门面的逐帧职责、个性计算器的函数集合、路障的生成前提与更新职责、以及多车型的复用判据。后续原型落地时,这些清单可直接转换为任务拆解与测试命名。未实现章节的产出是规格,而不是代码。
AI 在这里的价值不是补齐未实现系统,而是把未知系统压缩成可验收接口。
综合叙事的边界。 “出勤叙事”容易让读者误认为整条链已在原型中运行,因此相关段落为每个环节标注对应章节,并明确说明其描述对象是原版机制的协同关系。三车型章节中的直写控制器描述同样以③段标明原型尚未实现。综合叙事用于呈现结构,分级状态标注用于保持事实边界,两者必须同时保留。
*这是「如何制作一款开放世界游戏」系列实战篇。交通主题按层切成上下两篇:上篇讲调度与决策(路网、路口、红绿灯、派遣编排、就绪门),本篇(下)讲执行(寻路与重规划、驾驶个性、派遣执行与路障、各车型执行器、表现定调)。本篇①段对照六篇函数级逆向笔记,把每一层收束成可验收的接口清单;原型侧如实呈现:执行层全部未实现,已落地的是执行逻辑共同的输出口与若干基础,「未实现」章节的产出是规格而非代码。文中所有类名与源码路径均为长期逆向阅读与在建工程的实地核对结果,发布时按惯例做匿名化处理。*