This is the lower half of the vehicle topic in the “How to Build an Open-World Game” series. The previous article covered scheduling and decisions: the vehicle owns the persistent driving loop, the ped submits intent, seat relationships have an authority owner, driving authority supports arbitration and consistency checks, and LOD has explicit tiers. This article follows the next stage: converting intent into execution controls—throttle, brake, and steering. Which runtime layers produce those controls after a vehicle receives a junction target? How is a vehicle-entry chain organized so that failure can roll back? How does a distant dummy-tier vehicle preserve motion without full simulation? How does driving intent enter the physics system?
The material comes from source-level reverse engineering of a mature commercial open-world engine and client codebase, cross-checked against the same UE5 prototype project, VirtualWorld / VW. Each subsystem follows the same structure: original mechanism → batch-processing boundary → prototype implementation and plan.
Prototype status is stated in each section. Relationship-level vehicle entry orchestration, kinematic preview, and the physics seam have code and tests. The driving execution stack, together with the animation and physical action leaves for vehicle entry, remains an original-system study and migration plan. The third subsection of each chapter states the implementation status explicitly.
The internal geometry of several driving algorithms remains outside the available evidence: avoidance steering scores, pursuit-drift detection, speed-shaping formulas, the pathfinding core, and navigation-mesh construction. Those areas are marked as blind spots.
UE5 implementation details belong to the later landing articles. This solution article focuses on design and migration decisions: the original mechanism, the reuse boundary, and the location of each seam. The corresponding landing article will cover UE5 code, engine-subsystem integration, diagnosis, and verification.
Introduction: From Driving Intent to Execution Controls
The previous article ended with consistency checks for driving-authority ownership. This article continues with command production and execution. How the AI driving task computes the current-frame control values was one of the items marked “not yet connected” in the previous article. On the original side, the path is a four-layer execution stack with three supporting families. On the prototype side, relationship orchestration, kinematic preview, and the physics seam are implemented, while behavior-level interfaces remain planned.
The article addresses four questions in order. Chapter 1 explains how path selection, local approach, and control generation are separated into four layers shared by cruising, pursuit, and police containment. Chapter 2 explains the vehicle-entry runtime chain and its rollback paths. Chapter 3 explains how a dummy-tier vehicle replaces full physics with low-cost kinematic advancement. Chapter 4 defines the adapter boundary between driving intent and Chaos physics. Chapter 5 consolidates the migration decisions.
The central principle is separation of strategy and execution. Upper layers reshape targets; lower layers generate controls. Relationship state belongs to its authority owner; actions belong to the execution chain. Intent belongs to the runtime; rigid-body simulation belongs to the engine.
The implemented portion has a measurable size: vehicle entry, exit, and seat-move orchestration occupy roughly 343, 226, and 737 lines, supported by a 212-line driver and a 1,450-line slot executor. Together they account for roughly three thousand lines and 198 automated tests. Kinematic preview and the physics seam add several hundred lines and 18 tests. The execution-side boundary and orchestration are established; the concrete behavior implementation is not.
1. Driving Execution Stack: Four Responsibilities from Route Planning to Control Generation
Question for this chapter: after a vehicle receives a driving intent for a junction, which runtime layers produce steering and longitudinal controls? Why can cruising, pursuit, and police containment expose different behaviors while sharing one lower execution stack?
The previous article established the ownership entry point: the vehicle owns the driving loop and the ped submits intent. This chapter fills in the behavior executed inside that loop—the vehicle moving through the road network. The original evidence is strongest here. The structure is a four-layer stack, with a single responsibility at each layer: upper layers reshape targets, lower layers generate controls.
1.1 Original mechanism
Automatic vehicle driving is not one large function. It is a four-layer execution stack. Each layer owns one responsibility, and an upper layer continuously submits a local target point plus a speed limit to the layer below.
Layer 1: route owner. The task usually described as cruising is more than open-ended movement. It owns the route runtime for the vehicle: path-helper lifetime, road-node lists, follow-route construction, replanning, lane-change requests, lane reservations, signal and junction policy, speed-zone policy, and the choice between road-network, straight-line, and navigation-mesh execution. Its state machine makes these macro states explicit: FindRoute → Cruise → StopForJunction → WaitBeforeMovingAgain → GoToStraightLine → GoToNavmesh → GetToRoadUsingNavmesh → Burnout → RevEngine → PauseForUnloadedNodes → Stop. Streaming road nodes are therefore a driving-task state, not an opaque blocking wait.
The key bridge in this layer finds a target point and applies a speed cap. It reduces complete route, lane, and junction context to one immediate target and one bounded cruise speed. Inputs include road-node metadata, speed-zone multipliers, look-ahead distance derived from current and desired speed, junction and vehicle-shape adjustments, and an already-selected stop state. The lower task does not select the road-network target; the route owner repeatedly submits a recomputed local target. This is the binding mechanism of the stack.
Route lifetime is divided among three owners: generation belongs to the route owner, interpolation belongs to the route follower, and consumption belongs to the action leaf. Replanning is triggered by target movement or route exhaustion. The previous lane choice becomes input to the next search, preserving lane context instead of restarting from zero. The specialized route branch also handles streaming nodes and prevents a selected route from requiring an immediate U-turn to connect.
A point-directed task is a specialization of the same route/search/state machinery. It changes open-ended cruising into target-directed travel, exits when the target is invalid, and chooses between straight-line recovery and arrival based on distance. The traffic articles use this branch for police pursuit.
Layer 2: local executor with avoidance. This is the short-range driving leaf. It owns local steering, obstacle scans, speed limits around traffic, pedestrians, doors, and objects, three-point-turn escalation, short waits, braking, and evasive steering. Its states include GoToPoint → ThreePointTurn → WaitForTraffic → WaitForPed → TemporarilyBrake → Swerve.
The layer delays avoidance work, then evaluates route caches, current travel direction, target orientation, traffic, pedestrians, objects, curbs, and local occlusion. It selects steering direction, computes a safe speed, and updates the inner task. It also contains junction yielding, exceptional handling for stationary vehicles, players, and police vehicles, close-follow policy, pedestrian escalation, warning and evasive branches, siren-driven ambient response, and overtaking requests submitted by the upper layer. It does not own complete route search or long-range destination choice. Those remain with the route owner.
Layer 3: final control writer. This layer does not understand traffic or route topology. It converts one target point plus one desired speed into raw controls: steering angle, throttle, brake, and handbrake. It computes desired heading, maps desired speed against current forward speed, reduces throttle for slope, traction loss, and slip, optionally uses handbrake in aggressive turns, applies driver-style smoothing, and writes the resulting values to the vehicle. The important boundary is that the upper layers do not directly write the steering input.
The stack can therefore be audited as: route owner selects the destination → avoidance leaf computes the local approach → point task generates control values.
The navigation-mesh branch is a fallback under the same ownership model. If the road network is unsuitable or unreachable, it searches a navigation mesh, builds a follow route, and still uses the same avoidance and point-driving leaves. The three navigation modes are road route, straight-line fallback, and navigation-mesh or off-road recovery. The same composition appears in the door-approach task from the previous article, only at a smaller spatial scale.
Supporting maneuver tasks demonstrate the compositional capacity of the stack. Three-point turning is the only local recovery leaf that bypasses the indirect target-point path and writes controls directly. It alternates forward and reverse phases, evaluates timeout and displacement, gradually relaxes constraints after repeated failure, and returns control to the upper layer once orientation is restored. The direct-write exception is narrow, temporary, and recoverable.
The reusable stop leaf maintains a stopped state and records why the vehicle is stopped. Pull-over is a four-state sequence: find a suitable route segment, approach the curb point, decelerate, and stop. Parking is a ten-state corrective procedure with a stop leaf between phases. Approach tasks redirect a dispatch target to the nearest reachable road position when the nominal target is off-road or inside a building.
Temporary action leaves form a second direct-control exception. They carry an end timestamp, normally do not replicate over the network, and prevent the vehicle from entering the deepest proxy tier while the action is active. Each leaf writes a short corrective control policy and exits at its deadline. Their scope is deliberately narrow: short, time-bounded, corrective actions.
The fourth layer is the tactical wrapper. Police behavior, pursuit, and parallel driving continuously reshape targets while delegating movement to the first three layers. Police behavior selects a subtask—cruise, ram, follow, or contain—according to target validity, wanted level, vehicle type, special handling, and siren policy. Pursuit rewrites the point-directed target from pursuit geometry. Parallel driving computes an offset target and continuously updates the point task. Even a highly customized behavior such as police containment decomposes into a selector, several narrow leaves, and the shared point-driving base.
Meaning of this chapter: the vehicle execution path consists of route ownership, local avoidance, control generation, and tactical wrapping, with navigation fallback and supporting maneuver families alongside it. The four layers answer four different questions: where to go, how to approach, how to control, and why the current driving policy applies. Cruise, pursuit, containment, parallel driving, pull-over, parking, and passenger drop-off can reuse the same execution stack because their differences are expressed in target reshaping and sequencing.
1.2 Relationship model and batch-processing boundary
This stack is an object-oriented, stateful task tree with nested state machines. It is not naturally a batch-processing data shape. The route owner has roughly ten states and the avoidance leaf has six; upper tasks hold lower tasks and continuously update their targets. That parent-child lifetime and push/pop behavior does not map directly to a flat Fragment/Processor scan. The execution stack therefore belongs to a purpose-built object runtime.
There is one qualification: distant decorative traffic is different. Vehicles without tactical behavior, pursuit, or recovery can follow the road network at a fixed rate and use a batch path. The Mass boundary is therefore an LOD decision: nearby vehicles with full driving behavior use the object runtime; distant decorative traffic may use a batch representation.
1.3 Prototype implementation and plan
The four-layer driving execution stack itself is not implemented in the prototype. The prototype has the vehicle-owned driving-loop boundary and the kinematic preview described in Chapter 3. Route search, avoidance leaves, control generation, navigation fallback, and tactical wrappers remain migration items.
The planned insertion points are nevertheless explicit. The existing vehicle-control command is the output boundary for the control writer. Avoidance leaves will depend on spatial queries. The route owner will depend on road-network data from the traffic articles. Tactical wrappers can follow the same intent-bridge pattern used by vehicle-entry orchestration. Temporary actions must also reserve an LOD tier while active.
The build order is therefore: establish the control output contract, add avoidance leaves, add the route owner, then add tactical wrappers. Each step attaches to a testable seam rather than introducing an unbounded subsystem.
2. Vehicle Entry Relationship Orchestration: A Reversible Runtime Chain
This chapter is not primarily about animation. It is about the relationship protocol behind animation: intent, reservation, seat occupancy, task slots, and terminal-state write-back. Opening a door, entering a seat, and closing a door remain later presentation-layer work.
The previous article established the foundation: seat relationships have one authoritative operation, failure must roll back atomically, and the ped-side view is non-authoritative. This chapter examines how the multi-step chain is organized in the original system and which part is worth migrating.
2.1 Original mechanism
The outer state machine owns policy; narrow leaves own execution. Entry, exit, and seat movement share the same family of terminal states and relationship transitions. The outer layer selects the door and operation. The leaf resolves the local action. A failed leaf reports a named failure and returns through the appropriate rollback path.
The entry chain can be described as: select a vehicle and seat, create an intent, pass the intent bridge, reserve the seat, resolve the approach mode, execute the action, commit the authoritative relationship, and write the terminal state back to the task slot. Reservation is not a seat convenience; it models a future relationship before the physical presentation has completed.
The active-script driver selects an open vehicle command when no vehicle intent exists, continues an intent that is still executing, and handles a terminal intent by either chaining to the next task owned by the same source or performing terminal cleanup. Event-owned task slots and script-command slots do not cross authority boundaries. Slot-to-intent matching is field-level: task tree, priority, type, owner, script identity, command, phase, session tag, and target vehicle must all agree.
Exit and seat movement are symmetric members of the same family. Exit does not reserve a seat and does not perform passenger-seat rollback. Seat movement releases the old seat, reserves the new one, updates driver-seat state, and updates the ownership of driving commands. MovedSeat and AlreadyInSeat are distinct successful terminal states, so an idempotent re-entry is not misreported as a movement.
2.2 Relationship model and batch-processing boundary
Vehicle entry is a multi-step state machine in which every step may fail, retry, or roll back. The outer FSM must know the current phase and its recovery target; each leaf must expose success and failure exits. This is per-object, priority-aware logic with interruption and retry. It is a stateful task tree, not a stateless batch row.
The important migration boundary is between relationship state and presentation. Relationship state is fact; animation is replaceable presentation. The prototype can already perform the vehicle-occupancy state transition and keep the relationship records consistent. It does not yet replace that direct transition with approach movement, door animation, seating, and door closing.
2.3 Prototype implementation and plan
The relationship-level orchestration is implemented and tested. The intent bridge, reservation gates, seat resolution, lifecycle write-back, script command protocol, active driver, and task-slot executor are present. The action leaves for approach, door, seating, attachment, and presentation effects remain deferred.
The migration plan is to connect each action leaf to the existing success, rejection, cancellation, and rollback enumerations. The orchestration layer should not need to change when a direct occupancy transition is replaced by a real sequence of movement and animation.
3. Kinematic Preview: Low-Cost Motion after Behavior Downgrade
Question for this chapter: how can a vehicle several hundred meters away preserve road-following motion without full physics and full driving AI?
3.1 Original mechanism
Vehicle LOD is not merely an update-frequency switch. A dummy tier changes the representation of both decision cost and movement cost. The dummy vehicle follows the same route data but advances along it with a low-cost kinematic model instead of running complete tires, suspension, collision, and rigid-body simulation.
3.2 Relationship model and batch-processing boundary
The preview is a deterministic semantic model. Given control values, handling data, current speed, and a time step, it computes acceleration, speed, forward distance, direction, and steering angle. It does not mutate the transform and it does not run physics. Preview answers where the vehicle should be in semantic motion terms; Physics later resolves the rigid body and collision state.
The real and dummy tiers must migrate atomically. A real-tier vehicle carries full driving decisions, a real driver, and Chaos physics. A dummy-tier vehicle uses simplified driving semantics, a proxy driver, and kinematic preview. The system must not expose a mixed state such as a proxy driver with full physics or a full driver with downgraded motion. The preview speed also supplies the initial condition when returning to the real tier, preventing a velocity jump.
3.3 Prototype implementation and plan
The prototype contains the deterministic preview state and formula. It clamps throttle, brake, and steering to legal ranges, validates handling data, computes net acceleration, updates speed, applies handbrake behavior, and advances forward distance. It exposes update time and update count, and the physical request requires at least one preview update.
The preview has behavior tests for throttle, brake, neutral input, and the explicit guarantee that it does not run physics. Handling data has separate valid, incomplete, and invalid states. The global LOD manager is not implemented, and the preview does not yet drive transform mutation or rendering interpolation. The semantic preview exists; the decision to downgrade a vehicle and the presentation of the result remain planned.
4. Physical Integration Seam: Reuse Chaos and Isolate Physics
The original vehicle system contains its own scheduling and approximation semantics, but UE5 already provides a vehicle rigid-body and collision implementation through Chaos Vehicles. The migration decision is therefore to carry over the scheduling semantics—tiers, hysteresis, budgets, and dummy motion—while reusing the engine physics implementation.
4.1 Original mechanism
The physical seam separates the production of driving intent from the application of physical motion. The upper layer packages a request containing vehicle identity, command source, handling readiness, preview readiness, speed, distance, steering angle, and mass. The lower adapter returns an integration result and diagnostic reason.
The request is ready only when four conditions hold: the source vehicle handle is valid, the command source is non-empty, handling data is ready, and the preview has updated at least once. Legal handling data and configured handling data are separate checks. A zeroed structure may be within range while still being incomplete.
The null adapter is intentional. It lets upper-layer development, tests, and diagnostics proceed without a physics implementation. A ready request produces an unavailable result because the adapter does not execute; an incomplete request produces a skipped result because the input is not ready. These outcomes point to different causes and remain distinct.
Between the two sides is a pending-intent buffer with a monotonically increasing revision. Production and consumption do not have to run at the same rate: physics may be throttled, may execute several substeps per frame, or may run on another thread. The consumer uses the revision to distinguish a new intent from an already-consumed one. Clearing the intent also increments the revision. Disappearance is a state change.
The seam has complete diagnostics: request boundary failures, integration summary, pending intent, and pre-render state. Preview speed, distance, and steering angle are recorded in three places so that a mismatch identifies the handoff that failed. A pending intent whose request is no longer ready is represented as its own diagnostic state.
4.2 Engine reuse boundary
Rigid-body physics, tires, suspension, drivetrain, and collision do not own population relationships, seat ownership, or driving authority. They are homogeneous calculations from inputs to physical results, so they should be reused from Chaos rather than rebuilt. The custom runtime belongs around scheduling, ownership, consistency, and LOD semantics—not inside the rigid-body solver.
4.3 Prototype implementation and plan
The adapter interface, request packaging, null adapter, revisioned buffer, and integration diagnostics are implemented. The real Chaos adapter is not connected. The future adapter will consume the newest pending intent, apply revision checks, translate the request into Chaos vehicle inputs, and return a physical result. The upper preview, request, buffer, and diagnostic layers should remain unchanged.
5. Migration Decisions: Vehicle Part 2 Implementation Matrix
The four chapters can be reduced to the following matrix. The status vocabulary is consistent with the series: implemented means function bodies and tests exist; skeleton means types and state exist but behavior is empty; not started means a roadmap or reverse-engineering target; reuse means the engine should provide the implementation.
| Layer | Mechanism | Prototype status | Migration target |
|---|---|---|---|
| Driving execution | Route owner | Not started | Purpose-built vehicle task tree |
| Driving execution | Local avoidance leaves | Not started | Custom orchestration with reused spatial queries |
| Driving execution | Control output boundary | Implemented | Vehicle control command seam |
| Driving execution | Navigation-mesh fallback | Not started | UE navigation system; construction remains a blind spot |
| Driving execution | Tactical wrappers | Not started | Original behavior study and custom wrappers |
| Vehicle entry | Relationship orchestration | Implemented | Intent bridge, reservation, resolution, lifecycle write-back |
| Vehicle entry | Script command protocol | Implemented | Request / cancel / complete / reject contract |
| Vehicle entry | Animation and action leaves | Not started | Reuse engine animation; add runtime leaves |
| Vehicle LOD | Kinematic preview | Implemented | Deterministic dummy-tier semantic motion |
| Vehicle LOD | Handling validation | Implemented | Separate valid, incomplete, and invalid states |
| Physics | Intent-to-physics seam | Implemented | Adapter interface and revisioned handoff |
| Physics | Real Chaos adapter | Not started | Translate intent into Chaos vehicle inputs |
| Rigid body | Tires, suspension, drivetrain, collision | Reuse | Use Chaos Vehicles; do not rebuild |
The result complements the previous article. The seam, approximation, and relationship orchestration are implemented boundaries. The four-layer driving behavior, action leaves, tactical wrappers, and real Chaos adapter are migration work. The table is an evidence-based measurement, not a promise about unimplemented behavior.
Three transferable seam principles
1. A no-op still needs semantic states. A null adapter distinguishes “the request is valid but this adapter does not execute” from “the request itself is incomplete.” A reservation diagnostic distinguishes a rejected precondition, a mismatch, and a boundary failure. Placeholder code is useful when it preserves the meaning of each result.
2. Disappearance is also a change. Clearing an intent increments its revision; clearing ownership increments its sequence. A state with consumers must make its disappearance observable just as it makes its appearance observable.
3. Record the same value at each handoff. Preview state, integration request, and pending intent should agree. Recording all three makes a lost handoff diagnosable without reproducing the issue. Redundancy used for consistency checks is inexpensive monitoring.
Together with the previous article’s principles—results are auditable, write entrances are closed, and late operations are normal—these form the recurring implementation discipline of the series.
AI Collaboration Review
The material follows the same two-source method as the previous article: reverse-engineering notes plus prototype code. The proportions are reversed. The driving execution stack has the strongest original evidence but is not implemented in the prototype; vehicle-entry orchestration is implemented more deeply than the initial draft suggested.
AI’s role was to align the four-layer execution stack, verify the state lists, compare route ownership, inspect the deterministic preview formula, check the null-adapter and revision-buffer protocol, and read the complete vehicle-entry execution path. Its main value was not generating new mechanisms; it was reconciling multiple sources into one consistent specification and separating implemented code from migration planning.
The main writing risk is presenting a detailed original mechanism as if it were already implemented. The article therefore states the prototype boundary at the beginning of every implementation subsection. The same distinction applies to kinematic preview: its state and deterministic formula exist, but transform mutation, LOD selection, and the real Chaos adapter do not.
*This is a practical article in the “How to Build an Open-World Game” series. The vehicle topic is split into two parts: the previous article covered ownership, seats, driving authority, and LOD decisions; this article covers driving behavior, vehicle-entry orchestration, kinematic preview, and the physics seam. The prototype currently implements relationship-level vehicle orchestration, kinematic preview, and the physics seam. The four-layer driving stack and real Chaos adapter remain migration work. Road networks, junctions, signals, and dispatch are covered in the two traffic articles. Class names and source paths are anonymized for publication.*