This article is the lower half of the traffic-runtime topic in the “How to Build an Open-World Game” series. It follows the upper half, which covers scheduling and decision-making: road networks, junction right of way, signal phases, dispatch orchestration, and traffic readiness. This article covers route execution, continuous replanning, driving policy, dispatch-task realization, and dedicated executors for helicopters, aircraft, and boats. The material comes from long-term source-level reverse reading of a mature commercial open-world engine and client codebase, based on approximately 700+ mechanism notes; names and identifiers are anonymized for publication.
The four-layer vehicle execution stack—route ownership → local avoidance → control write → tactical wrapper—is covered in detail in the lower vehicle article. This article uses the stack from a traffic-scale perspective. The execution layer described here has not been implemented in the prototype; the article therefore separates original mechanisms, UE5 migration decisions, and prototype status throughout.
UE5 implementation details belong to the later landing article. This proposal article records mechanism boundaries, ownership, migration choices, and acceptance criteria. Search internals, avoidance geometry, aircraft executor internals, and downstream police-task interpretation remain explicitly marked as blind spots.
Introduction: From Traffic Decisions to Route Execution
The upper article ends with two states that have been decided but not executed: the readiness gate has admitted a vehicle, and dispatch orchestration has assigned a group of police vehicles. Scheduling can be recalculated; execution must continue through time, space, and failure states. This article describes the mechanisms that keep that execution consistent.
An admitted vehicle requires a valid route and continuous replanning. Driving policy then turns external parameters into signal response, following distance, lane-change behavior, and braking decisions. A dispatched police vehicle may create a roadblock assembly and later return its members to ordinary traffic. Helicopters, aircraft, and boats require specialized executors because their kinematic assumptions differ from ground vehicles.
All of these layers share one output contract: FVWVehicleControlCommand. Throttle, brake, steering, and handbrake commands are the common landing point for execution logic; policy functions modulate inputs, and vehicle-specific executors extend the payload where necessary.
The article uses a three-part structure: original mechanism → UE5 migration choice → prototype status and plan. The prototype currently contains the shared command output and several prerequisite foundations, but not the execution systems described in the following chapters.
I. Driving Execution Stack: Traffic-Scale View
The vehicle article owns the detailed state machines and responsibility list for the four-layer stack. At traffic scale, three relationships matter.
1. The execution stack consumes traffic decisions
The route owner consumes the road-network queries, speed limits, junction stop decisions, and asynchronous search results described across the two traffic articles. Driving policy supplies speed limits and behavior parameters. Dispatch supplies tactical wrappers such as pursuit or roadblock duty. Traffic decisions become motion by continuously supplying a local target point and a capped speed to the execution stack.
2. Shared execution controls multi-vehicle cost
Hundreds of cars can share the route, avoidance, and control-write core. Only vehicles requiring tactical behavior add an additional wrapper. Adding a taxi, truck, or patrol-car type therefore primarily adds a parameter set and a lightweight wrapper, rather than an independent AI implementation.
Distant vehicles without tactical behavior may use a batch-oriented path. The vehicle article’s dummy kinematic preview and dummy passengers form an intermediate state between a decorative traffic representation and a fully simulated vehicle. The promotion path remains explicit: batch representation → dummy preview → real execution stack.
3. Reuse is constrained by kinematics
Cars use the ground execution stack. Helicopters and aircraft use dedicated control laws. Boats reuse selected deep ground leaves and add water-specific adaptation. “Shared execution stack” therefore describes a cost optimization for the majority ground population; it does not require every vehicle type to use the same control law.
The complete execution stack is not implemented in the prototype. The currently implemented foundation is the lowest-level FVWVehicleControlCommand output interface.
II. Pathfinding, GPS Routes, and Replanning: Route Calculation and Continuous Repair
A route system does not merely find a route; it maintains a usable route while the world continues to change.
Scope. This chapter covers route selection, route calculation, replanning triggers, and the relationship between the player GPS route and AI vehicle routes. The search capability can be shared, but it is exposed through different upper-level wrappers; the GPS wrapper is itself a stateful subsystem with multiple fields and modes.
The vehicle article covers execution after a route exists. This chapter covers route creation and maintenance. AI routes and player GPS routes share the lower search capability but not the route lifecycle. AI routes serve the execution stack and require nodes and lane details; GPS routes serve presentation and require polylines, colors, visibility policy, and progress information. AI routes follow task lifetime, while GPS slots follow markers or script lifetime.
1. Original mechanism
The system separates lower-level pathfinding—owned by the road-network database—from upper-level route wrappers, one of which is GPS. GPS registers initialization and shutdown but does not join the simulation skeleton’s per-frame registration. Its runtime updates are driven by front-end/HUD path handling and minimap rendering.
The lower search layer handles nearest-node queries, asynchronous path jobs, streamed path nodes, road flags, lane offsets, right-lane adjustment, and distance-to-target output. Search runs as an asynchronous job so that a long-distance query does not block the main frame. The lifecycle is request → background search → result consumption on later frames.
Waiting relationships are explicit. The GPS side owns slot-level asynchronous state and frame guards; the search side owns slot-assigned jobs and frame-end reclamation. Both sides must close the lifecycle of one search. A forgotten slot is a resource leak, which is why unused asynchronous slots are reclaimed as part of the GPS maintenance pass.
Each GPS slot owns its route coordinates, node addresses, distance data, destination or target reference, color, flags, visibility range, route state, timers, partial-destination state, and invalidation state. A normal route first passes admission checks, captures its destination, resets timers, and optionally clears stale nodes. Specialized race, multi-point, and custom routes reuse the slot pool while applying different priority and generation rules.
Routes require continuous maintenance. Each slot performs route shift after vehicle progress, removes consumed nodes, and raises an invalidation flag when the rendered route changes. Target movement, long-distance searches, vehicle deviation, entering or leaving a vehicle, and periodic validation can all trigger replanning. A partial-destination route can provide direction information before a long search completes. Arrival handling is local to the slot: it closes the active path point and clears the minimap route when the route reaches its terminal condition.
The rendering handoff belongs to the rendering thread. A centralized visibility predicate evaluates settings, portals, flashing state, custom maps, script-forced display, pause maps, and other presentation conditions. The state side submits route data and invalidation; the presentation side owns update and rendering.
Chapter significance: pathfinding, route-slot ownership, replanning, invalidation, and rendering handoff are separate responsibilities. GPS and AI routes share search capability, not lifecycle. Partial destinations represent a responsiveness policy: provide a usable direction first, then refine it as asynchronous work completes.
2. UE5 migration choice
- Road-network search: build an asynchronous search over the custom road graph. UE Navigation System can provide scheduling patterns, but navmesh output is not a lane-level traffic route.
- Asynchronous accounting: preserve explicit request state, frame guards, slot-assigned jobs, and frame-end reclamation. TaskGraph decides where work runs; it does not own business-level waiting, timeout, or cleanup.
- Route slots and replanning: build as a strategy layer above the road graph. Keep AI routes and GPS routes separate at the lifecycle level even when their lower search is shared.
- GPS-to-minimap handoff: reuse the UI and rendering stack. Route data, colors, invalidation, and explicit clearing remain the interface from runtime state to presentation.
3. Prototype status and plan
Pathfinding and GPS routes are not implemented in the prototype. The current placeholder is an expected-route label; the search, route slots, and replanning logic do not yet exist. The migration map is nevertheless concrete: implement the road-graph search first, then route slots and replanning, followed by GPS and minimap presentation. Search internals and cost calculation remain blind spots.
III. Driving Personality: Compressing Behavioral Variation into Stateless Policy Functions
Scope. This chapter covers how risk parameters produce differentiated signal response, following distance, braking, lane-change, and horn behavior.
The personality layer exposes static functions only. It owns no member fields, manager singleton, or update loop. Persistent inputs come from ped intelligence, ped-model personality data, and vehicle-side dummy-passenger fields. The calculator produces normalized policy outputs from those sources and owns no runtime state.
1. Original mechanism
The input chain is explicit. Driving ability and aggression are selected from dummy-passenger values, ped overrides, or model defaults. Derived functions produce maximum accelerator input, maximum cruise speed, post-signal delay, post-obstruction delay, amber-light and stop-sign behavior, lane-change policy, stopping distance, following distance, pedestrian clearance, turn-signal use, motorcycle lane movement, and horn timing.
These are policy answers, not persisted behavior states. A high-aggression input can yield an earlier start, shorter following distance, and more permissive signal response; a low-aggression input can yield the opposite. Both vehicles use the same execution stack and stop-decision chain. Only the policy inputs differ.
The calculator supports hierarchical overrides: model defaults, temporary ped-intelligence overrides, and dummy-passenger approximations for distant vehicles without a real driver. A pursuit scenario can set a temporary high-aggression override and later clear it, returning the driver to the model default. The same policy functions remain in use throughout.
Because derived outputs are deterministic, a network peer only needs the source inputs; it does not need to synchronize every derived policy result. This is the practical value of a stateless policy layer.
Chapter significance: driving personality is a pure policy calculator, not a traffic manager, component, or persistent behavior owner. Separating external state from policy evaluation makes the layer reusable, testable, and independent from route and junction implementation.
2. UE5 migration choice
- Build the calculator as stateless functions or a policy class with no runtime ownership.
- Store ability and aggression in data assets or tables. Preserve the source-priority chain: intelligence override → dummy-passenger approximation → model default.
- Store tunable offsets in configuration. Keep derived functions shaped as base value × personality coefficient + tunable offset where the source behavior supports that mapping.
- Expose policy outputs through the shared vehicle command path. Do not make the calculator own route, seat, task, or vehicle lifetime.
3. Prototype status and plan
The driving-personality layer is not implemented, but it is independent from the road graph and junction runtime. It can be implemented and unit-tested first once the source input schema is available. Its inputs, override order, and derived-output responsibilities are specified; the prototype has not yet committed the implementation.
IV. Dispatch Execution and Roadblocks: From Assignment to World Assembly
Scope. This chapter covers how a “set up a roadblock” assignment becomes a runtime assembly of police cars, peds, and blocking props, and how that assembly returns to ordinary traffic after the task ends.
1. Original mechanism
A roadblock is not an incident or an assignment. It is a generated world assembly with a group of vehicles, peds, props, a location, a target ped, a minimum lifetime, and a disperse/despawn policy. Vehicle barricades and spike strips are variants resolved through generated props rather than separate systems.
Creation requires several conditions: the target is wanted, the target is driving, a suitable road node exists ahead of the target’s travel direction, and the vehicle, ped, and prop models are streamed. If a condition fails, the system does not create a partial roadblock. After creation, the assembly re-enters the ordinary assignment pipeline; the special path is limited to creation, not to the rest of the task lifecycle.
The roadblock needs its own lifecycle because incident lifetime follows demand, task lifetime follows an executor, while the roadblock follows the physical existence of a group of world entities. Its update loop tracks time and target range, triggers automatic disperse, unregisters members that have left the assembly, and keeps unoccupied blocking vehicles visible to traffic semantics. Despawn is constrained by minimum lifetime, target distance, and screen visibility.
Two exit paths exist. Disperse restores the assembly to the environment: vehicles receive dummy passengers, persistent ownership is released, and population ownership is restored. Despawn deletes the assembly and releases its objects. Disperse is preferred because special entities can return to ordinary traffic instead of disappearing from the world.
In networked execution, roadblocks do not participate in manager-level resource reservation, but each object creation still checks the network registration limit. This is an intentional tradeoff for a low-frequency, short-lived, local assembly.
The dispatch record is the seam between multi-vehicle coordination and single-vehicle execution. Police assignments transition through states such as dispatch travel, vehicle search, foot search, combat, and roadblock duty. A responder can serve only one incident at a time; conflicts require explicit arbitration rather than last-writer-wins replacement. How downstream police tasks interpret assignments into pursuit, arrest, or search motion remains a blind spot.
Chapter significance: a dispatch execution endpoint is a world assembly with its own owner, update loop, and exit paths. The preferred exit is restoration to ordinary traffic. This pattern also applies to checkpoints, escort formations, and accident scenes.
2. UE5 migration choice
- Build the roadblock as a composite world entity with member handles, formation-level policy, and a lifecycle state machine.
- Reuse the vehicle dummy-passenger path and population-return ownership contract for disperse.
- Query the road graph for a node ahead of the target’s velocity vector. Use streamed asset readiness as an admission condition.
- Let the dispatch record drive downstream task transitions. Keep conflict resolution explicit and preserve one-responder/one-incident ownership.
3. Prototype status and plan
Dispatch execution is not implemented. The required migration dependencies—dummy passengers and population-return ownership—are defined in earlier articles but remain planning items. Roadblock generation, independent update, disperse, and downstream police-task interpretation remain part of the migration map.
V. Multi-Vehicle Executors: Kinematic Differences Across Helicopters, Aircraft, and Boats
Scope. This chapter defines the reuse boundary between cars, boats, helicopters, aircraft, and motorcycles, and explains how kinematics determine executor responsibilities.
| Vehicle | Route | Control | Reuse |
|---|---|---|---|
| Car | Road network | Ground vehicle execution stack | Base |
| Boat | Water route | Ground deep leaves plus water adapter | Medium |
| Helicopter | 3D target | PID and three-axis control | Low |
| Aircraft | Fixed-wing path / takeoff | Dedicated fixed-wing control law | Lowest |
1. Original mechanism
The vehicle-side driving intelligence is specialized by vehicle type. Cars operate on a two-dimensional road graph and require lanes, junctions, and avoidance. Helicopters operate in three-dimensional space and use a direct control core with PID groups, three-axis projection, terrain-safe target height, asynchronous world avoidance, and low-LOD time-sliced steering. Ordinary “go to” behavior also contains hover-hold semantics; hover, escort, attack, and landing are wrappers above the control core.
Aircraft use dedicated control channels for yaw, pitch, roll, throttle, speed-brake, steering angle, and virtual speed. Their modes include precise vertical positioning, fixed-heading positioning, and conventional fixed-wing control with turn-radius geometry, terrain avoidance, and altitude slope control. Landing is an independent task layered over the aircraft core.
Boats build their own water-route search, segment following, turning, pause, stop, and shore-approach policies, but reuse selected ground avoidance, navigation, and parking leaves for control writing. A boat-specific avoidance helper injects water-speed and heading corrections into those leaves.
All vehicle tasks still share a task contract and command payload: target entity, target position, arrival distance, driving flags, cruise speed, and maximum cruise speed. The shared base owns serialization, migration, target resolution, arrival-distance normalization, speed rules, and output clamping. It owns administrative compatibility, not vehicle-specific control knowledge.
The result is a shared contract, a shared command payload, shared cross-vehicle policy, and specialized executors above them. Tactical wrappers can remain cross-vehicle because they select modes and reshape targets; the concrete executor still owns control writing.
2. UE5 migration choice
- Build a shared contract and command payload around
FVWVehicleControlCommand. Keep serialization, migration, target resolution, and output clamping in the shared layer. - Build vehicle-specific executors separately. Implement boats before aircraft because boats can reuse ground leaves with an adapter; helicopters and aircraft require new control laws.
- Reuse the engine’s rigid-body and water-physics solutions. Introduce one intent-to-physics adapter per vehicle class.
- Preserve source control structure, not source PID parameters. Re-tune gains against the UE5 physics model.
3. Prototype status and plan
Vehicle-specific executors are not implemented, including the car execution stack. The shared command output exists as a ground-vehicle foundation and can later be extended with three-dimensional intent such as climb and hover. The internal algorithms for helicopter hover, aircraft landing alignment, and boat avoidance geometry remain blind spots.
VI. Presentation Is Not Execution: Passing State to Light and Sound
This chapter defines the interface between runtime state and visual/audio presentation. It does not transfer ownership of route, policy, or control to the presentation layer.
Vehicle lights, brake lights, turn signals, distant traffic rendering, engine audio, horns, and sirens belong to the engine presentation stack. Runtime state submits route coordinates, colors, invalidation, brake intent, steering intent, and horn/siren state. Presentation components consume those values, update materials, lights, and audio, and own their render or audio scheduling.
The GPS-to-minimap handoff is the same pattern: the state side submits data and invalidation; the presentation side owns update and rendering. Visibility policy remains centralized in one predicate rather than distributed across vehicle and UI code.
The presentation fields must be designed early even when the presentation implementation comes later. Brake, steering, horn, and signal intent belong in the command and policy contracts; material, light, and audio components consume them without becoming owners of traffic state.
VII. Migration Decisions: Traffic Part 2 Checklist
| Layer | Original mechanism | Prototype status | UE5 migration landing |
|---|---|---|---|
| Execution stack | Route owner, avoidance, control write, tactical wrapper | Not started | Shared vehicle command and staged executors |
| Route / GPS | Slots, async jobs, route shift, invalidation, replanning | Not started | Road-graph search plus route-slot subsystem |
| Driving personality | Stateless policy calculator | Not started | Data-driven policy functions |
| Dispatch execution | Roadblock assembly, assignment handoff | Not started | Composite world entity and lifecycle owner |
| Vehicle executors | Ground, water, helicopter, aircraft variants | Not started | Shared contract plus kinematic adapters |
| Presentation | State-to-light/audio handoff | Not started | Engine presentation components |
The execution layer remains a migration map. The shared command output is implemented; the remaining rows are specifications and planned packages, not completed runtime features.
Reading Both Traffic Articles: Four Invariants
- Separate static data from active state. Road databases, route templates, and personality data are static inputs; active slots, junction instances, and policy evaluation are runtime state.
- Facades consume; sources own. Signals consume junction phases, GPS consumes search jobs, and stop decisions consume personality outputs. A facade must not take ownership of another subsystem’s input.
- A readiness gate is an ordered contract. Shell readiness, metadata readiness, and local readiness must be evaluated in order.
- Derived state should remain derived. If a value can be recomputed from synchronized inputs, it should not become another replicated state owner.
These invariants apply beyond traffic. They can be reused for scenario points, closed areas, and NPC decision weights.
Reconstructing One Police Dispatch
A wanted-state transition creates an incident. The incident queries a response table, the dispatch service selects responders, the assignment record binds each responder, and the roadblock assembly creates vehicles, peds, and props. The roadblock then updates its own lifetime, while each police task interprets its assignment and enters the vehicle tactical wrapper. When the target is no longer valid, the assembly disperses and its members return to population and traffic ownership.
This sequence describes the original ownership chain and migration interfaces. It does not claim that the complete chain runs in the current prototype.
Three Execution-Layer Principles
First, responsiveness precedes completeness. Partial routes, asynchronous streaming, and disperse-before-delete provide usable intermediate states. Each intermediate state must have an explicit upgrade path.
Second, lower-level reuse produces the largest gain. Search is shared by AI and GPS, deep ground leaves are shared by cars and boats, and the personality calculator is shared across vehicle types. Upper wrappers remain independent so that reuse does not become lifecycle coupling.
Third, specialized paths need a specialized entry and an ordinary exit. Roadblocks use a dedicated creation path but return to ordinary assignment and population pipelines after creation. Specialized routes may own their setup while reusing existing slots and presentation paths.
AI Collaboration Review
This article contains detailed original-mechanism material while the prototype execution layer remains unimplemented. The analysis therefore records functions, states, fields, ownership, and migration gaps explicitly rather than presenting planned behavior as completed code.
The main consolidation results are the separation of shared search capability from route lifecycle, the separation of shared task contracts from vehicle-specific control laws, and the identification of roadblocks as world assemblies rather than tasks or incidents. The personality layer is a stateless policy calculator, not a traffic manager.
AI is not used here to fill unimplemented systems. Its role is to compress uncertain systems into testable interfaces. The acceptance outputs are the road-query surface, GPS slot responsibilities, policy-function set, roadblock admission and update contract, vehicle reuse matrix, and state-to-presentation seam.
*This is the traffic-runtime lower article in the “How to Build an Open-World Game” series. The upper article covers scheduling and decisions; this article covers route execution, driving policy, dispatch execution, vehicle-specific executors, and presentation boundaries. The original-mechanism sections are based on function-level reverse-reading notes. Prototype status is reported explicitly: the execution systems remain unimplemented, while the shared command output and prerequisite foundations are available. All names and paths are anonymized for publication.*