Dynamic City | Vehicle Driving Runtime (Part 1): Persistent Driving Intelligence, Seat Relationships, and Driving Authority

This is one of the practical installments in the “How to Build an Open-World Game” series, following the two-part character article *Rebuilding a City Packed with People in UE5*. That article examined the runtime organization of a large population—world ownership, phase scheduling, population, and the perception pipeline. This article turns to the other half deliberately left open: the vehicle runtime for cars controlled by drivers. The material comes from long-term source-level reverse engineering of the engine and client code of a mature commercial open-world game—roughly 700+ source-level notes. Class names, function names, and phase boundaries were checked against the source and anonymized for publication.

The vehicle topic is split into two layers: Part 1 covers scheduling and decision-making, ending when a driving intent is produced—ownership of driving intelligence, authority over seat relationships, arbitration among command sources, driving authorization, and behavior-level LOD. Part 2 covers behavior, presentation, and physics—the execution of that intent: converting a target into control values, the enter/exit-vehicle action chain, low-cost dummy-vehicle motion, and the connection from intent to real physics.

As in the character article, the UE5 discussion here is not a paper exercise. The VirtualWorld / VW prototype is being built as a runtime in which the world owns entities and advances them by phase; it does not hand the vehicle relationship layer to an off-the-shelf batch-processing framework. Vehicle code is one of the prototype’s most developed areas: seat relationships, command arbitration, driving-authority consistency, behavior-level LOD, and control validation have real implementations covered by a substantial automated-test suite. At the time of writing, the runtime plugin contains 769 automated tests—about 70,000 lines of test code—including 173 tests whose names contain “Seat”, 74 containing “Reservation”, and 32 containing “DriverCommand”. The test count is not a direct measure of system complexity; it indicates the portion of the state space that has been modeled explicitly and kept under continuous verification. The implementation sections therefore distinguish code that already exists from skeletons and planned work.

Each subsystem follows the same three-part line: first, how the original system is organized at source level; then why the semantics require an explicit relationship boundary and which engine facilities remain reusable; finally, how the prototype implements or plans the mechanism. Completed work, structural skeletons, and known gaps remain separate.

Boundary note: the vehicle runtime’s organization and ownership boundaries are covered in depth here. The internal algorithms of the concrete driving executors—vehicle-specific cruise, pursuit, avoidance geometry, pathfinding internals, and junction decisions—are not covered to the same depth. The execution-side design appears in Part 2; algorithmic blind spots are labeled as such wherever they occur.

UE5 implementation details belong to the later landing articles. This proposal article focuses on design and migration decisions: why the original system is organized this way, what should be built, what can be reused, and where the responsibility seams lie. The corresponding landing article will cover the actual UE5 runtime, code walk-throughs, engine-subsystem integration, and verification results.

---

Introduction: Ownership of the Driver–Vehicle Runtime Relationship

The character article opened by asking who decides which entities are created and removed in a frame. This article starts with an equally plain but harder question:

A car driven by an NPC: does its driving AI belong to the vehicle or to the driver?

This is not a wording dispute. It is a primary constraint of the vehicle runtime. If ownership is assigned incorrectly, the rest of the structure inherits the error:

• If driving AI belongs to the driver ped, what happens when the driver exits? The vehicle’s driving loop follows the driver’s task tree; when the driver changes tasks, the vehicle loses control. In a networked session, the driver may even exist on another machine, leaving vehicle control without a clear owner.
• If driving AI belongs to the vehicle, why does a newly generated empty vehicle already have a driving intelligence waiting for work? When the driver changes, how does the new driver take over the same driving state rather than rebuilding it from zero?

There is a second chain of questions:

• Hundreds of vehicles may be active at once. The steering command for each vehicle can have several sources—player input, AI driving, or a forced script command. Which source is accepted for this frame?
• An NPC may decide to use a seat well before the final seat relationship is established. How is duplicate occupation prevented, and how is a state such as “the seat says someone is present, but nobody actually is” repaired? If the target seat is already occupied, who selects an alternative or terminates the attempt? Which side is authoritative when the records disagree?
• A vehicle three hundred meters away does not need full physics and full driving AI. Who decides that it should move to a lower-cost LOD?

The article follows these questions through one central principle, already introduced in the character articles and made explicit here: the runtime must not confuse a state’s owner with an observer of that state. The vehicle owns the persistent driving loop; the ped submits a driving intent. Seat relationships have an explicit authority; the ped-side record is a non-authoritative snapshot. Driving commands have explicit arbitration and ownership, and every authorization is recorded for later reconciliation. Responsibility is ownership. That is the basis for keeping a large vehicle population independent.

The short answer comes first: the driving AI belongs to the vehicle; the ped submits intent. The rest of the article shows how that decision becomes a runtime structure. Most chapters are not arrows on a design diagram; their prototype counterparts can be checked function by function and verified by hundreds of tests.

The route is straightforward: establish persistent driving AI first; then examine the ped–vehicle boundary through seat relationships and reservations, followed by network cloning and migration; then make driving-authority consistency explicit; then consolidate those states into a single-vehicle traffic-readiness gate; then cover the decision side of behavior-level LOD; and finally summarize the migration choices.

Scope boundary: this article ends when a driving intent has been produced—who may drive, how relationships are established, and when the vehicle changes LOD. The other half—turning intent into execution through the driving stack, enter/exit actions, dummy-vehicle kinematic preview, and the physical integration seam—belongs to Part 2. How many vehicles cooperate as traffic—road networks, junctions, signals, and dispatch—belongs to the traffic articles.

One number captures the structure of this article: the seat-management, relationship, reconciliation, repair, authorization, command-acceptance, ownership-consistency, reservation, intent-bridge, and intent-parser families together return more than one hundred enumerated states. None of these paths answers “valid or invalid” with a bare Boolean. This is not decorative complexity; it makes large-scale vehicle failures diagnosable and gives every rejection a verifiable reason.

The ownership boundary can be fixed in one diagram: who proposes intent, who arbitrates, who owns relationship state, and who stores only a non-authoritative snapshot. The six chapters below expand different relationships and lifecycles from that diagram.

The prototype’s implementation depth is deliberately uneven. Seat relationships and driving-authority consistency have substantial real code; the control loop, readiness gate, and LOD state have observable skeletons whose behavior is still being filled; network cloning and migration have deep original-system evidence but almost no prototype implementation. The article labels these states separately instead of presenting a planned migration path as completed work.

---

I. Persistent Driving AI: Vehicle-Owned Control Loop and Ped-Submitted Intent

Question for this chapter: who owns a vehicle’s driving intelligence, and why is vehicle ownership rather than driver ownership the prerequisite for scale and networking?

① How the Original System Is Organized

The source presents this structure: the vehicle runtime holds a persistent driving-intelligence object (here called VehicleIntelligence). It is created when the vehicle is initialized, attached to the vehicle, and given a default task—“no driver.” A newly created vehicle with no occupants therefore already has a driving-intelligence object waiting in a defined state: no driver, do not move. This describes the observable source organization, not the only possible implementation of a vehicle system.

This object is not a helper created for one pursuit. It is a long-lived owner with the same lifecycle as the vehicle. The factory specializes it by vehicle family: one implementation for ordinary ground vehicles and boats, another for helicopters, and another for aircraft.

The decisive evidence is the driving-update path: the vehicle’s ProcessIntelligence() calls Process() on the intelligence object owned by that vehicle. The driver ped does not own the complete driving-update loop. The relationship is:

• the vehicle owns the persistent driving-intelligence object;
• that object owns the vehicle-side task manager and update phases;
• the ped’s task submits a driving task to that owner.

The driving intelligence is more than the current driving task. It is a persistent vehicle-side AI state and service center that owns the vehicle task manager, nearby ped/vehicle/object scans, distributed updates for steering, braking, lane changes, avoidance, following, junction behavior, and siren reactions, passenger-response event groups, road-node caches, junction and signal state, stuck detection, and the dummy/super-dummy conversion policy after task processing. Its Process() is a multi-phase pipeline: reset frame flags → update water, siren, and threat-vehicle state → process boat avoidance → process network clones early → pre-update by vehicle type → scan nearby entities → process events → process the vehicle task manager → perform task post-processing.

What does the ped side own? It exposes a bridge (here called the ControlVehicle bridge) between the ped runtime and the vehicle runtime. Its state machine performs four stable operations: ensure that the ped is in the target vehicle, add the vehicle to the road system, install an in-vehicle subtask on the ped, and copy a driving task into the vehicle intelligence’s task tree. When entering a driving state, it updates both sides: the ped receives its subtask and the vehicle intelligence receives the driving task.

The separation is therefore explicit: the ped-side wrapper task handles occupant/driver orchestration and decides which driving task to submit; the vehicle-side intelligence owns the persistent runtime, task manager, scans, events, road caches, and the factory that translates generic task identifiers into concrete driving tasks; the concrete cruise, goto, pursuit, and police-driving algorithms belong to lower driving executors.

One further point matters: network cloning is a first-class path, not a later wrapper. Driving intelligence distinguishes local vehicles from network clones. For a clone, ordinary local control is skipped in favor of nearby-entity scans, road and junction refresh, and AI-task data read from the network object. The ped-side bridge is also part of network takeover: it can rehydrate driving tasks as control moves between clone and local state. Network awareness is built into the vehicle-side owner rather than bolted on outside it.

Meaning of this chapter: giving the vehicle—not the driver—the persistent driving loop is a counterintuitive but decisive ownership choice. It gives empty vehicles a defined waiting intelligence, lets a driver change without reconstructing vehicle state, and gives network control a clear owner. The ped submits intent; the vehicle executes the task. Every later chapter—seats, driving authority, and LOD—depends on this split.

② Relationship Model and Batch-Processing Boundary

“The vehicle owns a persistent object with a task manager and many services” is fundamentally different from a representation optimized only for homogeneous batch processing.

Mass is well suited to data-oriented, batch-friendly entity representation. Vehicle driving intelligence, however, is a long-lived object with internal state and subordinate services: a push/pop task tree, road caches, junction state, stuck-detection history, and separate local-versus-clone branches. These are properties of an identified object with a lifecycle and internal state machine; they cannot be replaced directly by independently processed homogeneous data.

The deeper issue is ownership: the ped submits a task, the vehicle owns it, the task is copied into the vehicle task tree, and a clone must rehydrate it from network state. This is an object relationship graph, not merely a table of values. A data-oriented implementation would need explicit fragments, lookup structures, and an external relationship layer; the responsibility boundary would still have to exist.

In short: driving intelligence is a stateful, identified, network-aware long-lived owner. A distant decorative traffic field with no individual driving intelligence may justify a different representation. A vehicle with a driver, takeover, and network identity must retain this object boundary.

③ Prototype Implementation and Plan

This ownership split already exists as real prototype code. FVWVehicle owns its vehicle-side control loop separately from the ped side:

• The vehicle exposes DoProcessControl(Context) and ProcessIntelligence(Context) as observable boundaries. The call chain mirrors the original organization: ProcessControl records the control count and time slice → calls DoProcessControl → the latter records its own count → runs UpdateKinematicPreview first, then ProcessIntelligence. Preview advancement and intelligence processing therefore belong to the control phase, with a fixed order and one call per control update. FVWVehicleState records the control count, previous control time slice, previous delta, and related counters (ControlProcessCount / DoProcessControlCount / IntelligenceProcessCount / LastControlTimeSlice …) so the timing can be verified.
• The physics phase also records a branch: ProcessPhysics increments PhysicsProcessCount, then records whether the base physics step was skipped or executed in SkippedPhysicsCount and DomainPhysicsStepCount. Whether physics actually ran in a frame is measured by branch counters rather than inferred.
• Driving commands and their sources are first-class state: FVWVehicleControlCommand (throttle, brake, steering, handbrake, and reverse intent) plus EVWVehicleCommandSourceType { Player, AI, Script, Fallback }. The vehicle executes the currently authorized command; it does not need to know which source produced it.
• Ped-side intent uses the task slot and the enter/exit steps from the character article (TaskEnterStep / TaskExitStep). A task slot becomes a vehicle-intent state and is then resolved against a seat. The intent is not a one-shot call but a lifecycle-bearing state object (FVWPedVehicleIntentState: intent type, target vehicle, target seat, request serial, and Requested → Completed / Rejected state machine). The ped proposes; the resolver consumes the proposal at the appropriate time and writes the result back.

The task-slot-to-intent phase is itself an explicit bridge: FVWPedVehicleTaskIntentBridge::RequestVehicleIntentFromTask. Its header comment fixes the boundary: “Explicit semantic bridge only. It does not execute tasks, call the seat resolver, or mutate task lifecycle.” It translates a request from a task tree into an intent and passes five gates: a task must exist (MissingTask), its lifecycle must allow the operation (DisallowedTaskLifecycle), the task type must be present, the target vehicle handle must be valid, and the intent type must be legal. Only then does the state become Requested. The result carries the complete source provenance—task tree, priority, type, owner, lifecycle state, script-task flag, script command, and phase—together with the new intent serial.

The complete path is therefore: task slot → intent bridge (translation only, five gates) → Requested intent → seat resolver (consume, reject, or fallback) → terminal intent state (Completed / Rejected) → reverse lifecycle bridge back to task completion or interruption. Each segment has one responsibility, and each rejection has a name.

Honest boundary: the prototype has established an observable vehicle control/intelligence boundary, command sources, and LOD observation. The concrete vehicle-side services—nearby scans, road caches, junction state, stuck detection, and the driving-task factory—are not implemented. ProcessIntelligence currently records the intelligence count, delta, time slice, and update count. The intelligence is presently a precisely observable shell. Its call timing and frequency are testable; the behavior that will eventually fill the shell is not implemented. The ownership skeleton is real, while the behavior inside the loop remains planned. The network-clone branch is subject to the same boundary.

---

II. Seat Relationships and Reservations: Authority over Seat State

Question for this chapter: an NPC may decide to use a seat long before the final relationship is established. How is duplicate occupation prevented? Which side is authoritative? How is a state such as “the seat says someone is present, but the occupant record says otherwise” repaired?

The original enter/exit flow is a multi-step action chain—approach the door, open it, enter, place the ped, and close the door. Every step can fail and must support rollback. The action chain itself belongs to the execution side of Part 2. This chapter covers the foundation below it: the seat relationship, who creates and removes it, and which side is authoritative when records diverge.

① How the Original System Is Organized

The original system exposes two clear seat operations: add a ped to a seat and remove a ped from a seat. They are the authoritative operations for establishing and clearing the relationship; every leaf in the enter/exit chain ultimately reaches these operations.

One important separation is between entering a seat—the action sequence—and placing the ped in the seat—the final relationship handoff. They are separate leaf tasks: one performs the action, the other establishes the relationship. The source notes do not state the original motivation directly. A reasonable interpretation is that animation progress and relationship establishment have different lifecycles: an animation can be interrupted or replayed, while a relationship must be created at one explicit atomic point. The source-level fact remains narrower and stronger: relationship mutation is implemented as a separate handoff leaf, not as a side effect of the animation leaf.

Meaning of this chapter: a seat is not a Boolean “occupied / empty” value. It is a relationship with an authority, an intermediate state, and reconciliation. Establishment and removal have unique write paths; action and relationship are separate; failure must roll back. The prototype expresses this as three layers: intent resolution (rejectable, with fallback), authoritative operations (gated, atomic, rollback-capable), and consistency (bidirectional reconciliation and directed repair).

② Relationship Model and Batch-Processing Boundary

The difficult part is modifying a relationship between two entities, the ped and the vehicle:

• Changing the ped–vehicle relationship must update both sides atomically and roll back on failure. A data-oriented entity representation therefore needs an explicit transaction boundary and rollback mechanism for this cross-entity operation.
• Seat consistency is a cross-entity invariant: the seat’s occupant and the ped’s vehicle/seat record must refer to each other. It cannot be assumed that a batch-processing framework will maintain this invariant automatically.

Consider two NPCs approaching the same driver seat. A marks the seat as occupied, but before A’s own occupancy record is written, scheduling allows B to inspect the seat. Without one authority and an atomic operation, the system can reach a three-way disagreement: the seat says A, A does not acknowledge the vehicle, and B believes the seat is free. The original design and the prototype prevent this with one authoritative seat operation and rollback on every failed step. A failed occupation immediately releases the seat instead of leaving a partial relationship.

③ Prototype Implementation and Plan

This layer has substantial real code. FVWVehicleSeatManager owns the authoritative operations corresponding to AddPedInSeat, RemovePedFromSeat, and MovePedToSeat. AddPedInSeat is an ordered gate chain:

1. Invalid ped handle → InvalidPedHandle.
2. Invalid vehicle handle → InvalidVehicleHandle.
3. Invalid seat index → InvalidSeatIndex.
4. The ped already occupies another vehicle → PedAlreadyInVehicle.
5. The target seat is occupied → SeatOccupied.
6. Only after these checks does the vehicle seat receive the ped.
7. The ped-side occupancy snapshot is then written. If this step fails, the newly assigned seat is cleared and PedOccupancyMismatch is returned.

Step 7 is the essential property: the operation is not “write and hope”; it is write, verify, and roll back. The implementation calls ClearSeatOccupant when the ped-side write fails, and it also clears a stale reservation held by that ped. The result is one of eleven precise EVWVehiclePedSeatRelationshipStatus values—three success states (AddedPedInSeat, RemovedPedFromSeat, MovedPedToSeat) and specific failure states—not an opaque Boolean.

The result object is itself an audit record. FVWVehiclePedSeatRelationshipResult carries previous and new ped-occupancy serials, the previous seat occupant, the previous driving-command owner and ownership serial, and mutation flags (bMutatedVehicleSeat, bMutatedPedOccupancy, bClearedDriverControlCommand). The caller receives not merely success or failure, but a record of what the world looked like before and after the operation and which state domains changed.

Every low-level seat mutation also checks driving authority. ConfigureSeats, AssignSeatOccupant, and ClearSeatOccupant preserve the previous command ownership, rebuild a consistency snapshot after the change, and clear a stale driver-owned command when the seat mutation invalidates it. A driver change or seat clear invalidates the associated driving command at the seat layer; it is not dependent on an upper layer remembering to clean it later.

Removal and seat changes use the same gate shape. RemovePedFromSeat checks the ped occupancy, vehicle, seat, and occupant identity before clearing the seat, ped occupancy, and attached reservation. MovePedToSeat permits idempotent re-entry to the same seat, rejects another occupant, and clears a stale reservation on the old seat after a successful move. Establishment, removal, and movement are all validation → atomic mutation → associated cleanup.

The manager also detects duplicate occupancy with CountDuplicateOccupantSeats and records ClearedDuplicateCount. Idempotent assignment is not reported as a mutation when the occupant and driver-seat flag already match. This makes “did the state really change?” a testable fact.

The authority boundary is explicit in the state comments. FVWPedVehicleOccupancyState is a ped-local, non-authoritative snapshot only; it does not prove that the vehicle is live or that the vehicle seat still matches. Vehicle-local queries only validate stored handles; they do not prove that the ped remains live in FVWWorldRuntime. Each layer is responsible for the state it owns. Cross-layer truth comes from reconciliation.

The reconciliation path is a nine-state gate in BuildPedSeatRelationshipSnapshot: invalid ped handle, invalid vehicle handle, invalid seat index, no ped occupancy, vehicle mismatch, seat mismatch, empty seat, another occupant, and finally Consistent. It is bidirectional: the first half checks the ped’s claim against the vehicle, and the second half checks the vehicle’s record against the ped. The snapshot also exposes individual facts such as bSeatOccupantMatchesPed, bPedOccupancyMatchesVehicle, and bPedMarksDriver.

RepairPedSeatRelationship is a directed, explicitly authorized two-channel repair: ClearStalePedOccupancy clears an obsolete ped-side record, while ClearStaleVehicleSeatOccupant clears the vehicle-side record. The repair layer does not guess whether the vehicle or ped should be trusted; the caller selects the direction. A successful ped-side repair also invokes RepairDriverCommandOwnership, because clearing the ped occupancy may invalidate the associated driving authority. Every repair records BeforeSnapshot and AfterSnapshot. The snapshot is non-authoritative, the vehicle seat is authoritative, reconciliation is bidirectional, and repair is directed and observable.

The prototype adds an online-ready mechanism that is only lightly expanded in the original notes: seat reservation. ReserveTaskSeat → ConfirmTaskSeatReservation → ReleaseTaskSeatReservation is a three-step protocol, with replacement of stale reservations from the same source. A reservation exists because the interval between “this NPC intends to use the seat” and “the NPC is actually seated” is real. The seat must be protected during that interval without becoming permanently occupied.

The three operations share one reservation-flow entry point and carry a reservation serial and requester handle:

• Reserve: mark the seat as reserved by a particular ped and request serial; the seat is not occupied yet, but other NPCs will not select it.
• Confirm: accept the occupation only when the same serial still matches. A replaced or expired reservation is rejected.
• Release: clear the reservation after occupation or abandonment. A stale reservation may be replaced only by a request from the same source.

This is a versioned, expiring reservation protocol. It models an asynchronous intent that temporarily owns a resource and can be recognized as obsolete. The seat therefore has three meaningful states—empty, reserved, and occupied—rather than a single occupied flag.

The reservation policy has two additional boundaries. First, it rejects calls that would require entity lifecycle changes, world scans, physical movement, task lifecycle changes, or resolver calls (WouldRequireEntityLifecycle, WouldRequireWorldScan, WouldRequirePhysicalMovement, WouldRequireTaskLifecycle, WouldRequireResolver). The policy only evaluates reservation state; callers handle cross-system work outside it. Second, reservation and confirmation perform a dual-side consistency precheck and return directional failures such as StalePedSidePair and StaleVehicleSidePair. A reservation is never placed on an already inconsistent relationship. Read-only checks (CheckReservationReadiness and CheckReservationConflict) remain separate from mutation.

At implementation level, reservation state lives on FVWVehicleSeatState, not on the ped. FVWVehicleSeatReservationFlowPolicy::EvaluateAndApply calculates the accepted next state; the manager is the only component that writes it. ReplaceStaleSameSourceTaskSeatReservation allows replacement only when the ped, vehicle, seat, and requester form the same source identity. A different source cannot use replacement as an occupation back door. The reservation manager exposes ten precise states, and 74 automated tests contain “Reservation” in their names.

Finally, the seat-intent resolver translates a ped’s enter/exit intent into the authoritative operations. FVWVehicleSeatIntentResolver::Resolve distinguishes “no intent” and “intent not requested” from a real operation failure: the first two are reported without consuming the intent, while invalid or occupied seats reject it. Passenger fallback is explicit and reservation-aware: it prefers the ped’s current seat in the same vehicle, otherwise selects the first available non-driver seat that is neither occupied nor reserved. Fallback always clears bDriverSeatIntent; a passenger is never silently routed into the driver seat.

The resolver also repairs stale records encountered during normal processing. An enter request can restore a missing ped-side occupancy after confirming the vehicle-side seat; an exit request can clear a stale ped record after confirming the seat’s occupant. Entering another seat in the same vehicle is recognized as MovePedToSeat, and a successful resolver writes the chosen seat back into the intent state when the caller did not specify one.

The complete second chapter is therefore: intent layer (rejectable, with fallback) → authoritative operation layer (gates, atomicity, rollback) → consistency layer (reconciliation and directed repair). The relationship state is observable at every layer.

Honest boundary: seat relationships, reservations, intent resolution, and consistency repair are real, testable state and operations. The execution chain beneath them—door opening, entry animation, placing the ped, and closing the door—remains deferred in the Layer5 material and belongs to Part 2. The relationship protocol is implemented; the action and physical presentation chain is not.

---

III. Network Cloning and Migration: Cross-Machine Vehicle-State Consistency

Question for this chapter: in a networked session, the same vehicle may be authoritative on one machine and a clone on another. When the player crosses an ownership boundary, control must migrate. How do the driving task, seat relationship, and driving authority remain continuous, non-conflicting, and singular rather than producing a second vehicle?

The first two chapters dealt with ownership inside one machine. This chapter adds the network dimension. It is not a synchronization wrapper placed around a single-player system; it is part of the vehicle runtime’s ownership model from the beginning. That is why it deserves a separate chapter: if network awareness is added only afterward, it cannot be repaired cleanly everywhere.

① How the Original System Is Organized

The original structure can be summarized in one sentence: network cloning is a first-class vehicle-runtime path, not a second architecture.

The vehicle-side intelligence distinguishes local vehicles from network clones from the start. A clone’s Process() skips ordinary local-control work and relies more heavily on nearby-entity scans, route and junction refresh, and AI-task data read from the network object. A clone is therefore not simply a local vehicle with a few steps removed; it follows a different update path, with driving intent synchronized from the network object rather than computed locally. Helpers that read active-task information, node lists, following routes, and route-search assistance branch explicitly between local task-tree state and clone state stored in the network object. Network awareness is built into the vehicle-side owner, not wrapped around it later.

The ped-side bridge is also a network-takeover layer. Its clone-related work creates and reads queryable state, creates tasks for clone and local peds, and advances the clone state machine. It serializes the target vehicle, driving-task type, and serialized task payload; during clone/local migration, the vehicle intelligence rehydrates the task through its network-driving-task factory.

This is why the unified command payload introduced in the next chapter matters. A driving intent is expressed as a standard package—target, position, driving flags, cruise speed, and related parameters—so it can be serialized, migrated between clone and local state, and rehydrated during network takeover. If every driving task used an unrelated data shape, migration would have no stable representation to carry.

The enter/exit chain follows the same rule. Network and clone logic changes authority, state serialization, seat/component reservation checks, and how the same state machine is restored or replayed on a clone. The outer FSM and narrow task leaves remain the same. Multiplayer is a cross-cutting overlay on the same task family, not a second generic vehicle-access stack.

Meaning of this chapter: networking is not synchronization added around single-player logic. Authority, serialization, and migration reconstruction must be part of the ownership model. A serializable driving payload and clone branches embedded in the vehicle owner and ped bridge are what make network awareness coherent rather than a collection of patches.

② Relationship Model and Batch-Processing Boundary

This is the previous relationship boundary extended across machines. The core of network cloning and migration is authority: where the vehicle’s authoritative instance exists, which ped owns the driving task, and how state moves from one machine to another and is rebuilt. This requires explicit identity, relationship, and version mechanisms; a batch-oriented entity representation cannot supply them by itself.

The original system embeds network awareness in the task FSM and vehicle owner: clones have a clone update path, and migration rehydrates tasks. “This entity has a clone on another machine, authority lives there, and state must be reconciled across both sides” remains a cross-machine ownership relation that must be modeled explicitly outside the raw entity representation. The point here is not to repeat a framework comparison, but to show how identity, authority, and version become part of the vehicle runtime.

③ Prototype Implementation and Plan

Network cloning and migration are not implemented in the prototype. The ownership model has, however, established two important foundations.

The first is handles and serials. The prototype references entities through stable FVWEntityHandle values rather than raw pointers. Seat relationships, occupancy, and driving-authority ownership carry serials (OccupancySerial / ReservationSerial / OwnershipSerial). A handle provides a uniform validity check; a serial answers whether this is still the operation that produced the referenced state. Serial monotonicity is strict: a real ownership change increments the serial, an idempotent assignment does not, and clearing ownership is itself a change. Serials never wrap during the entity lifetime, so a post-migration reconciliation cannot mistake a reused serial for a current one.

The second is an explicit distinction between authoritative and non-authoritative state. The previous chapter established that ped-side occupancy is a non-authoritative snapshot and the vehicle seat is authoritative. The driving-authority chapter makes reconciliation between ownership and actual occupancy explicit. Migration is fundamentally the same operation at a larger scope: authority moves from one machine to another, and the non-authoritative side reconciles again. The tolerant repair paths from the previous chapter—trusting the vehicle side and repairing a damaged ped-side record—are also useful after migration, where one side may simply be older than the other.

Together these foundations define the prototype’s network-preparation strategy. No network code was written before there was a validated state model. Instead, every state that may eventually be synchronized is shaped as a handle reference plus a version serial, an explicit authority, and a reconciliable repair path. Network readiness is not a module; it is a state-modeling discipline. That is why this chapter remains useful even though the actual network layer is absent.

Honest boundary: the handle, serial, and authority foundations are real code. The clone update path, driving-task serialization, migration-time rehydration, and cross-machine authority transfer have not been implemented and remain explicit plan items. The ownership model is network-friendly; networking itself is not implemented. This third section is a migration map, not a claim that the road has been built.

IV. Driving Authority Consistency: Authorization and Actual Driver Occupancy

The previous chapter establishes where a driving command may come from. This chapter addresses the stricter question: does the command still belong to the entity that is authorized to issue it? In an open-world runtime, a valid command is not enough. Its source, owner, task, and current driver must still agree.

① Original-System Mechanism: command arbitration and ownership

The original vehicle runtime presents driving as a multi-source arbitration problem rather than a single input stream. MissionParams can provide a command candidate, while player control, AI tasks, scripts, and other vehicle-side sources may provide competing candidates. FVWVehicle::EvaluateCommandCandidateArbitration evaluates those candidates by priority and readiness, then selects the highest-priority ready candidate. If no candidate is ready, the result is NoReadyCandidates rather than an implicit zero command.

The distinction matters. A command with no motion input is still a valid command; it may intentionally maintain braking, steering constraints, or a stop state. No motion input is not the same as no command. The arbitration result therefore carries both the selected source and the selected command state. AcceptDriverCommandCandidate records the accepted source as the current owner instead of treating the command as an anonymous value.

The runtime then separates three questions that are often collapsed into one:

• Is there a command candidate?
• Is the candidate ready to be accepted?
• Which source owns the accepted command?

This separation makes replacement explicit. A newly accepted source may replace an earlier owner, but the replacement must be visible to the task and authority layers. The vehicle does not merely overwrite a steering value; it updates a relationship between the vehicle, the command, and the source that is allowed to explain that command.

② Relationship Model and Batch-Processing Boundary

The command itself is a small data object. The relationship between the command, its source, its task, and the driver seat is not. That relationship includes lifecycle, replacement, authority, and repair rules. It therefore belongs to the vehicle-side owner and its relationship services rather than to a flat command buffer.

The prototype keeps this boundary explicit through FVWVehicleControlCommandOwnershipState. A command snapshot is built by BuildDriverCommandCandidateSnapshot, and the command state records whether the source is ready, whether it has motion input, and whether the vehicle has accepted it. The ownership state is then inspected separately from the command payload.

The design also narrows the write surface. SetControlCommandOwner is private and exposed only to the seat manager through a designated friend relationship. SetControlCommand and ClearControlCommand remain separate from ClearControlCommandOwner, because changing the command value and changing the command’s owner are different mutations. This distinction prevents a direct command write from silently implying a valid authority transfer.

③ Prototype Implementation: exact consistency states and repair

The prototype expresses the consistency check through BuildDriverCommandOwnershipConsistencySnapshot. It does not return a single Boolean. EVWVehicleDriverCommandOwnershipConsistencyStatus distinguishes ten precise states, including MissingDriverSeat, DriverSeatEmpty, PedNotDriverSeatOccupant, PedSeatRelationshipMismatch, PedOccupancyNotDriver, Ready, and stale-owner conditions.

This turns “ghost driving” into an inspectable state rather than a visual symptom. A vehicle may still contain a non-empty command while the former driver has left, the seat relationship has changed, or the command owner no longer matches the current task source. The snapshot records the mismatch and the repair path can then make an explicit decision.

RepairDriverCommandOwnership repairs the state through explicit authorization and before/after snapshots. The repair may clear an expired command owner, clear a command for a specific task source through ClearDriverCommandForTaskSource, or abort the replaced owner through AbortReplacedOwner. Source-targeted cleanup requires five matching conditions rather than a broad “clear whatever looks old” rule. bAllowCleanup, bDetectedStaleDriverControlCommand, and the mutation flags make the decision auditable.

The same principle applies to seat changes. When Assign, Clear, or ConfigureSeats changes the driver-seat relationship, the vehicle-side code performs the corresponding stale-command check as part of the operation’s completion path. A seat change is therefore not complete until related driving authority has been reconciled.

The test suite gives this boundary a concrete footprint: 32 DriverCommand tests and four DriverAuthority tests cover arbitration, replacement, stale ownership, and targeted cleanup. These counts are not a direct measure of system complexity; they show which state transitions have been made explicit enough to verify.

Meaning of this chapter: driving authority is not a scalar field attached to a vehicle. It is a consistency relation between a command, its source, the driver seat, and the current task. A runtime that can detect and repair stale ownership is more reliable than one that merely produces plausible movement.

V. Traffic Readiness Gate: Single-Vehicle Participation Eligibility

The preceding chapters establish the vehicle’s internal relations. Traffic does not need every internal detail; it needs a reliable answer to a narrower question: is this vehicle currently qualified to participate? That answer should be derived from one inspection boundary rather than reconstructed independently by every traffic system.

Traffic participation is a gated decision. A vehicle may exist, have a route, and contain a command, yet still be unready because traffic is disabled, the vehicle handle is invalid, a dummy LOD blocks participation, the driver is missing, the command source is missing, or the lane or route is unavailable.

The prototype gathers these conditions in BuildTrafficReadinessSnapshot. Its gate states include TrafficDisabled, InvalidVehicleHandle, DummyLodBlocked, MissingDriver, MissingCommandSource, MissingLane, and MissingRoute. The point is not to make every traffic caller understand every vehicle subsystem. The point is to expose a stable readiness result with a reason that can be inspected, logged, and tested.

The readiness gate is a relationship boundary between the vehicle runtime and the traffic runtime. It does not own the vehicle’s seats, command, route, or LOD state. It observes their relevant snapshots and decides whether the vehicle may cross into traffic processing.

This is another case where a batch-friendly entity representation is useful for broad iteration but insufficient for the complete decision. Traffic needs a composed answer: the vehicle must be valid, the driver relationship must be acceptable, the command source must be present, and the route-side prerequisites must be available. The gate is therefore a facade over several authoritative owners, not a second owner of their state.

The prototype uses BuildInspectionFacadeSnapshot to assemble 17 sub-snapshots, then formats them through BuildInspectionDiagnosticLine. BuildTrafficParticipantDescriptorSnapshot provides the traffic-facing descriptor and its key. This keeps diagnostic output tied to the same state model used by the readiness decision.

The main readiness-gate discussion belongs in the traffic article. In this vehicle article, the important conclusion is narrower: traffic must consume a vehicle-side readiness contract, not infer readiness by reaching into unrelated state containers. The current prototype has 117 traffic-related tests, which exercise the gate and its failure reasons. The actual multi-vehicle coordination, lane scheduling, and traffic-scale policy remain topics for the traffic series.

VI. Behavior LOD: Ownership of Vehicle Behavior-Demotion Decisions

LOD is often described as a rendering concern. For vehicles in an open-world runtime, it is also a behavior decision: which parts of the vehicle’s identity and control loop remain active, which are reduced, and which are represented only as a lightweight state.

This chapter covers only vehicle-side behavior LOD. It does not repeat the behavior-level LOD discussion from the character article, and it does not claim to implement a global manager that decides which vehicle should move between levels.

① How the Original System Is Organized

The original vehicle runtime exposes three AI/physics LOD levels: real, with full physics, full AI, and a complete driving loop; dummy, with simplified movement along the road network; and superdummy, with that simplified movement compressed further. A global vehicle LOD manager rearranges vehicles by effective distance, batches the work, and uses hysteresis and an N-LOD budget to choose the target level. This scheduling semantic belongs to the same family as the behavior-level LOD discussed in the character article.

Vehicle-side intelligence then applies the dummy/superdummy transition strategy after task processing. Stepping down does not pause the vehicle; it changes the lower-cost representation through which the vehicle continues to move. The concrete kinematic movement belongs to Part 2.

Meaning of this chapter: the decision side of LOD is a global scheduling problem. It continuously decides which level each vehicle should use, while the execution side determines how that vehicle continues to move at lower cost.

② Vehicle LOD Decision Boundary

This is the vehicle version of the character article’s “agent switching versus batch LOD” distinction. Batch LOD determines how often work runs; vehicle dummy behavior determines what the vehicle is computed as—a different kinematic approximation with a seamless transition between levels. The full argument belongs to the character article, and the kinematic seam belongs to Part 2.

The prototype defines EVWVehicleAILod with three states: Normal, Dummy, and SuperDummy. SetAILod, GetAILod, and IsDummyAILod provide the vehicle-side state boundary; IsDummyAILod returns true for both Dummy and SuperDummy.

The distinction is deliberately small. The vehicle can expose its current behavior representation to traffic and inspection systems without pretending that the global policy has already been implemented. A three-state enum is a state contract, not a completed LOD scheduler.

The LOD state belongs to the vehicle runtime because it affects whether command processing, driver relationships, route participation, and traffic readiness may continue. The decision of which vehicle should be downgraded belongs to a higher-level manager. Keeping those responsibilities separate prevents a local vehicle object from becoming an implicit global scheduler.

③ Prototype Implementation and Plan

The current prototype has not implemented the global LOD manager. It can represent and inspect the vehicle-side state, but it does not yet calculate a city-wide ranking or perform automatic promotion and demotion. Kinematic preview also belongs to the execution and physical-integration topics of Part 2 rather than this article.

Meaning of this chapter: LOD is a contract between cost management and entity identity. The vehicle needs a precise state boundary; the world needs a separate policy owner to decide when that boundary changes.

VII. Migration Trade-offs: Vehicle Part 1 Implementation Checklist

The table below brings the chapters together. The criteria follow the series convention: ① implemented (function body and tests), ② skeleton established (types and state exist, behavior is empty), ③ not started (roadmap item, original-system deep research, or prototype work not yet written), and reuse (use the engine subsystem).

Layer	Key mechanism	Prototype state	Landing point
Driving ownership	Vehicle owns the control/intelligence boundary	① Implemented	FVWVehicle::DoProcessControl / ProcessIntelligence
Driving ownership	Driving command and source type	① Implemented	FVWVehicleControlCommand + EVWVehicleCommandSourceType
Driving ownership	Ped issues intent during enter/exit steps	② Skeleton	Layer 4 TaskEnterStep / TaskExitStep
Driving ownership	Concrete vehicle intelligence services	③ Not started	ProcessIntelligence currently records observations only
Seat relationships	Establish, clear, and move seat relationships	① Implemented	AddPedInSeat / RemovePedFromSeat / MovePedToSeat
Seat relationships	Atomic rollback on failure	① Implemented	Step 7 rollback in AddPedInSeat
Seat relationships	Vehicle-side authority, ped-side non-authoritative snapshot	① Implemented	FVWPedVehicleOccupancyState comments + consistency repair
Seat relationships	Seat reservation: reserve → confirm → release	① Implemented	ReserveTaskSeat family
Seat relationships	Same-source replacement without stealing another reservation	① Implemented	ReplaceStaleSameSourceTaskSeatReservation
Seat relationships	Clear stale driving commands after seat changes	① Implemented	Completion checks in Assign/Clear/ConfigureSeats
Seat relationships	Bidirectional reconciliation snapshot and repair	① Implemented	BuildPedSeatRelationshipSnapshot + bridge
Network cloning	Handle and serial as synchronization prerequisites	① Implemented	FVWEntityHandle + *Serial
Network cloning	Authority/non-authority distinction	① Implemented	Seat and driving-authority boundaries
Network cloning	Clone update, task serialization, migration rehydration	③ Not started	Original-system deep research; prototype not written
Driving authority	Multi-source command arbitration	① Implemented	EvaluateCommandCandidateArbitration
Driving authority	Accept command and record authorized source	① Implemented	AcceptDriverCommandCandidate + ownership state
Driving authority	Ownership consistency and ghost-driving detection	① Implemented	BuildDriverCommandOwnershipConsistencySnapshot
Driving authority	Repair stale driving authority	① Implemented	RepairDriverCommandOwnership
Driving authority	Closed ownership write surface	① Implemented	Private SetControlCommandOwner; seat-manager access only
Driving authority	Source-targeted cleanup with five-way matching	① Implemented	ClearDriverCommandForTaskSource
Test coverage	Automated tests across the plugin	① Implemented	769 total: Seat 173 / Reservation 74 / DriverCommand 32 / Traffic 117
Driving authority	Real command producers: player, AI, and script	③ Not started	Controller binding, AI output, and script import not connected
Behavior LOD	Three-state vehicle LOD	① Implemented	EVWVehicleAILod
Behavior LOD	Global LOD manager	③ Not started	Three states are currently observed only
Traffic readiness	Layered readiness gate	① Implemented	BuildTrafficReadinessSnapshot

One-sentence reading of the table: the ownership, seat-relationship, driving-authority, and LOD-state skeletons are real, testable code; concrete vehicle intelligence, real command producers, global LOD scheduling, and network migration are mostly not implemented. The execution stack, enter/exit behavior, kinematic preview, and physical seam belong to Part 2. Multi-vehicle coordination belongs to the traffic article. The network-cloning chapter is deliberately a migration map rather than a claim that the road has already been built.

Build order, and why relationship boundaries come first

The build order is the same as in the character article: establish ownership and consistency first (the vehicle owns its loop, seat relationships have an authority, and driving ownership can be checked); then establish cost and seams (LOD state and readiness gates); only then fill in concrete behavior (real driving executors, traffic AI, and physics integration in Part 2 and the traffic series). Starting with visible driving behavior before ownership is stable would make every lower-level correction expensive.

The test distribution makes this emphasis visible: 173 tests contain Seat, 117 contain Traffic, 74 contain Reservation, and 32 contain DriverCommand, while only five contain Kinematic and 13 contain PhysicalIntegration. The distribution records the current engineering center of gravity: the prototype is buying “ownership does not silently become wrong,” not yet “the vehicle can already drive.”

Three implementation lessons

First, a result object is an audit record. State-changing operations return more than success or failure: they record the before state, after state, changed surfaces, and side effects—serial changes, previous occupants, previous owners, and mutation flags. Those additional fields reduce the need to reconstruct an incident by replaying the entire scene. In a system with hundreds of interdependent entities, that is a qualitative reduction in diagnosis cost.

Second, write entrances should be few and language-enforced. Ownership writes are sealed behind a private method and designated friendship; reservation writes return through one manager while strategy code calculates but does not mutate; a public direct-command setter can explicitly abandon ownership semantics. The question “who may change this state?” should not rely on convention or review alone. When the language can express the ownership boundary, the compiler should enforce it.

Third, design for late operations as the normal case. Serials increase monotonically across clears, cleanup requires five-way source matching, reservation confirmation checks the serial, and intent consumption requires the state to be Requested. Every write path assumes that its caller may hold stale information and provides a precise, harmless outcome for that case. In asynchronous systems—and eventually in networked systems—temporal misalignment is normal. Establishing stale-state detection in the single-threaded prototype is the most practical preparation this code can make for online migration.

The recurring subject is not a framework label but relationships and invariants: vehicle-to-intelligence ownership, ped-to-seat relationships, and the consistency between driving-command ownership and driver-seat occupancy. These are relations that must be conserved between entities, maintained by explicit write authorities, versioned state, and validation protocols. Physics belongs to the engine seam and will be addressed in Part 2.

AI Collaboration Review

This article combines two evidence lines: reverse-engineering notes on a mature open-world vehicle runtime and a UE5 prototype whose vehicle-side foundation is already substantial.

What AI contributed. On the reverse-engineering side, AI extracted and aligned the ownership chain in which the vehicle owns persistent intelligence, the ped side bridges tasks, and network cloning is treated as a first-class path. On the prototype side, AI read the actual function bodies in VWVehicle.cpp (1,922 lines), VWVehicleSeatManager.cpp (1,226 lines), and two headers, then mapped the state enums in the headers back to implemented behavior. This confirmed that AddPedInSeat performs the step-seven rollback when ped occupancy fails, BuildDriverCommandOwnershipConsistencySnapshot captures stale ownership precisely, and EvaluateCommandCandidateArbitration performs multi-source priority arbitration. The test files—about 70,000 lines and 769 automated tests—were also classified so that “covered by tests” became a citable measurement rather than a slogan.

The close reading exposed details that would be easy to miss from summaries alone: seat changes automatically trigger stale-command cleanup; a zero-input command is not the same as no command; and C++ friendship closes the ownership write surface inside the seat manager. These details are included because they are visible in implementation and tests, not because they make a convenient narrative.

Where the analysis nearly went wrong. During series planning, AI once judged that the prototype vehicle side covered only a small part of LOD and nearly postponed vehicles as an “original system thick, prototype thin” topic. Reading the real vehicle implementation overturned that judgment: seat relationships, driving-authority consistency, and command arbitration are already implemented. This is why the vehicle theme can support two parts and why most third sections can compare against real code rather than a paper plan. The lesson is simple: read the implementation before making claims about prototype maturity.

The same lesson applies to numbers. An early draft reused the character article’s figure of 31 automated tests for the foundation layer. That figure was correct at an earlier milestone, but the current plugin contains 769 tests. Measurements become stale as quickly as conclusions. The current workflow reruns a repeatable test-name classification command before writing; numbers become measurements rather than memory.

Test names are specification fragments. The test suite is named by behavioral assertion, so the list itself functions as a specification document: IntentDoesNotAutoScanTasks, IntentLifecycleIndependence, EnterRepairsStalePedOccupancy, and AbortReplacedOwner each state a design promise before the implementation is opened. Reading the test names first and then the corresponding implementation is more efficient than reading the entire source linearly. It also confirms the series principle: tiered states, precise enums, and mutation traces naturally produce testable designs.

Graded honesty is the article’s structural boundary. Some chapters have substantial prototype code—seat relationships and driving-authority consistency. Some have the strongest original-system evidence but almost no prototype code—network cloning and migration. Some remain blind spots, including the internals of driving algorithms and pathfinding. The article does not disguise one status as another. A skeleton or seam is not described as a working vehicle, and an original-system mechanism is not presented as a prototype implementation. This graded honesty is the credibility boundary for a reverse-engineering article written alongside an unfinished prototype.

*This is a practical article in the “How to Make an Open-World Game” series. The vehicle topic is split into two parts: Part 1 covers scheduling and decision-making—who owns driving intelligence, who owns seat relationships, how driving authority is arbitrated and reconciled, and who decides when the vehicle steps down; Part 2 covers behavior, presentation, and physics—the driving execution stack, enter/exit execution, kinematic preview, and the physical seam. The prototype currently has real code for vehicle ownership, seat relationships, driving-authority consistency, and LOD state; network-clone migration is supported by strong original-system evidence but has not been implemented. Class names and source paths in the article are based on long-term reverse-engineering and verification against the in-progress project; publication follows the series convention of anonymizing project-specific identifiers.*