This is the first solution-focused article in the open-world player vehicle driving series. The prologue established that the player does not take over a newly spawned static prop, but enters a vehicle that already has identity, seat relationships, tasks, and runtime state. This article focuses only on how the player enters that runtime and how driving control moves from an existing source to the player. Detailed execution interfaces and prototype implementation are left to later articles.
Previous article: Open-World Player Vehicle Driving Series: The Player Takes Over a Car That Was Already Running on Its Own
Introduction: The Player Sees Boarding; the Runtime Processes a Relationship Transfer
From the player’s perspective, the sequence is simple: approach the vehicle, press the enter key, open the door, sit down, switch the camera, and begin driving. For an open-world vehicle runtime, however, boarding is not equivalent to possessing driving control.
The vehicle may already have an AI driver and an active route. The driver seat may already be reserved by another request. A mission may currently forbid takeover. The local network role may also be unable to submit authoritative vehicle state. Even after the entry animation finishes, the vehicle may not yet accept player commands.
The relevant question is not “which function plays the entry animation?” It is:
At what point does the player become the vehicle’s currently valid driver?
That is a relationship and permission transfer, not a single input-mapping event.
The Vehicle Already Has Relationships Before the Player Enters
An open-world vehicle is not an isolated moving object. Before the player arrives, it may already have an identity, a current driver or driverless state, seat occupants, a route, a task phase, damage state, and relationships with traffic or mission systems.
The player does not initialize these states and then write “player driving” over them. The player requests a control entry into an existing runtime. Whether that entry is accepted depends on the vehicle, the target seat, the current task, and the rules governing command submission.
This is why “the player owns the vehicle” is an unsafe shortcut. Driver identity, command submission authority, entity ownership, and mission ownership are different concepts. A player can become the current driver without becoming responsible for every aspect of the vehicle’s lifecycle.
The player receives the current driving command submission right; the player does not automatically receive every runtime responsibility of the vehicle.
The Vehicle Looks Like One Object, but the Runtime Is a Set of Relationships
The visible vehicle contains at least four independent relationship groups:
- the character-to-seat relationship;
- the vehicle-to-command-source relationship;
- the vehicle-to-task relationship;
- the vehicle-to-final-state relationship.
The first confirms whether a character may occupy a seat. The second identifies who may submit the current driving command. The third preserves mission or route context. The fourth confirms the final position, velocity, damage, and collision result. These groups must coordinate during takeover, but they should not be collapsed into one field.
A Seat Is Not a Position; It Is a Relationship
A seat has a spatial transform, but the transform is not the seat relationship. A usable seat must also represent reservation, occupancy, validity, permission, and release behavior.
Error 1: A Seat Is Only a Socket
A socket can answer where a character should move. It cannot answer who may use the position when two characters request it simultaneously.
Error 2: A Seat Is Only an Occupant Pointer
Seat.Driver = Player can describe a completed result, but not the asynchronous entry process. It cannot explain reservation, interruption, timeout, or rollback.
Error 3: The Seat Belongs Only to the Character
If only the character stores “I am driving this vehicle,” the vehicle cannot independently validate the relationship after the character is destroyed, the task is canceled, or the state is reconstructed.
The seat relationship therefore needs confirmation on both sides. The character side maintains the entry and occupant relationship; the vehicle side maintains the seat resource and its validity.
Entry Is Not One Action; It Has Four Runtime Phases
The entry process can be understood as four logical phases: request, reservation, entry action, and confirmation. They do not have to be exposed as four public fields, but they must exist as distinct states in the logic.
Request: The Player Expresses Intent
The request identifies the target vehicle, target seat, requester, and current context. It expresses intent; it does not prove that the relationship exists.
Reservation: Protecting an Asynchronous Process
Entry animation, door movement, alignment, and pose adjustment can span multiple updates. Reservation prevents another request from taking the same seat during that interval. Reservation is not occupancy: it is a temporary commitment with explicit invalidation conditions.
Entry Action: The Relationship Is Still Being Built
While the character performs the entry action, the vehicle can move, collide, or become invalid. Animation progress alone cannot confirm the relationship.
Confirmation: Occupancy Becomes Formal
Only after the entry action and vehicle-side checks succeed can occupancy be confirmed. For the driver seat, driver identity and command submission must then be settled separately. Being seated does not automatically mean that driving control has been accepted.
The relationship sequence is shown in the “Entry State Transition” diagram above.
Every stage can fail, cancel, or roll back. That is what allows the runtime to represent “the character entered, but takeover was not established.”
Driver Identity Is Not the Same as Command Submission
Who occupies the driver seat and who can influence vehicle motion are closely related, but they are not identical.
Who Occupies the Driver Seat
This is the driver-identity question. It depends on seat occupancy, character validity, and entry confirmation.
Who May Submit the Current Driving Command
This is the command-source question. The player may have entered the vehicle while the current state still rejects player commands, or while a mission retains a restriction.
Why Should the Vehicle Move in a Particular Direction?
This is the constraint question. The goal may come from a mission, route, traffic rule, or another world relationship. Entering the vehicle does not erase those constraints.
Which State Version Is Authoritative?
This is the state-authority question. The vehicle runtime confirms the final result rather than accepting a character-side declaration as the final state. Network and replay modes may change submission and confirmation rules; those belong to later articles.
The “Driving Authority Model” diagram above shows this separation: driver identity, command source, goal source, and final state authority must remain distinct.
A system that stores only one Driver field answers only the first question. It cannot express the command source, constraints, or final authority.
Character Tasks and Vehicle Tasks Need Different Responsibilities
The source structure and responsibility distribution indicate that the character side and vehicle side do not share one identical task tree. The character side handles entering, maintaining the occupant relationship, and leaving. The vehicle side maintains the vehicle’s persistent runtime, task context, and current command source.
This is not duplicate work. The two sides have different lifetimes. A character can be interrupted or leave while the vehicle continues. Conversely, the vehicle can change its task while the character remains seated.
The character side primarily maintains the character–vehicle relationship; the vehicle side primarily maintains vehicle operation. A bridge synchronizes the two during entry, takeover, and exit.
Player Takeover of AI: A Control-Window Transfer
Player takeover should preserve the AI runtime context. The AI may hold a route, mission phase, target, recovery context, or current vehicle state. The correct transition is closer to:
The transition is shown in the “Player Takeover Does Not Destroy AI” diagram above.
AI releases the current control window; it does not necessarily destroy the vehicle intelligence. Route and task context may remain available for recovery after the player exits.
Takeover Failure Is a Partial Relationship Change
Failure paths test the model more thoroughly than the successful path.
| Phase | Failure | Required recovery |
|---|---|---|
| Target selection | Vehicle invalid or out of range | Cancel request |
| Reservation | Seat occupied or reserved | Release reservation |
| Entry action | Vehicle moved or animation interrupted | Restore the previous relationship |
| Occupancy confirmation | Task or vehicle state rejects entry | Do not confirm occupancy |
| Command transfer | Old source has not released | Refuse or defer takeover |
| Exit recovery | No valid next source | Preserve vehicle state and wait |
Rollback does not rewind world time. It removes the relationship changes that were not completed: temporary reservations, provisional permissions, and unconfirmed command sources.
A Broken Entry Example
Suppose the player requests the driver seat of a vehicle currently controlled by AI. The request is accepted and the character begins the entry action. While the animation is running, the vehicle receives a traffic update and moves forward.
The animation cannot be allowed to decide success by itself. The runtime must recheck that the target is still the same vehicle, that the reservation is still valid, and that the old command source can be released. If those conditions fail, the entry is canceled and the reservation is cleared. The vehicle keeps its previous legal state.
Another case occurs when the character has finished entering, but the AI source has not yet released its command relationship. Occupancy may be confirmed while takeover remains pending. The system must not overwrite the old relationship with a new Driver pointer and hope that another system repairs the inconsistency.
After the Player Leaves, the Vehicle Still Needs a Next Control Entry
Clearing Driver = null only says who is no longer in the driver seat. It does not say what the vehicle does next. The vehicle may resume AI, wait, remain mission-controlled, enter a lower-cost world state, or become temporarily invalid.
Leaving therefore needs to close the player command relationship, finish the seat release, and select a valid next control entry. The vehicle identity, task context, damage state, and other required state do not disappear merely because the player left.
Exiting player control does not mean exiting the world.
Two Relationship Diagrams
Entry State Transition
The “Entry State Transition” diagram above shows this state chain.
Character-Side and Vehicle-Side Responsibilities
The “Character and Vehicle Responsibility Boundary” diagram above shows this division.
This is a responsibility diagram, not a frame-by-frame call chain. The bridge allows both sides to agree on the same relationship.
How to Keep Source Evidence Separate from Architectural Abstraction
The value of source reading is not only locating a class that looks like a driving task. The stronger questions are: where is the state created, who processes it, and when does it cross into the next responsibility.
If vehicle initialization and processing have an entry independent of a player character, the evidence supports an independent vehicle-side runtime. If character-side entry and driving tasks cross into vehicle-side tasks through bridge logic, the evidence supports a split between relationship maintenance and vehicle operation.
These observations justify the abstractions used in this article, but they do not prove that every project must use the same class hierarchy. The article therefore uses “the source structure indicates” and “the call relationships suggest” rather than presenting the abstraction as the only possible implementation.
What This Article Does Not Expand
P1 establishes the relationship entry points. It does not expand input sampling and cameras, Driver Command fields, AI driving algorithms, GPS and route generation, local avoidance, physics execution, combat, pursuit, networking, replay, or multi-vehicle control laws. Those topics depend on the relationship established here and belong to later articles.
What an Entry Request Must Observe, Not Merely Check
An entry request must observe target stability, seat stability, character validity, and control stability across its lifetime. A vehicle may move, a seat may be reserved by another request, the character may be interrupted, or the old command source may remain active. A one-time distance check cannot explain these transitions.
The request therefore needs explicit invalidation conditions. “The seat is empty” is not the same as “this request may occupy the seat,” and “the animation is still playing” is not the same as “the relationship remains valid.”
Three Forms of Control Handoff
There are at least three useful handoff patterns:
- Player takes over AI. The old source releases its current command relationship while the vehicle context remains.
- Player releases the vehicle. The player command relationship closes and the vehicle selects a continuation source.
- A mission temporarily constrains the player. The player may remain the driver while the mission constrains the valid goal or control state.
These patterns show that driver identity, command source, and goal constraints must remain separate.
State Owners in a Relationship Transfer
The important question is not only where a value is stored, but which runtime owns its interpretation, updates, and recovery.
| State | Primary owner | Entry-time confirmation |
|---|---|---|
| Target identity | Vehicle runtime | The target remains the same entity |
| Seat availability | Vehicle-side relationship | No conflicting reservation or occupant |
| Entry progress | Character-side entry flow | The action was not canceled |
| Driver identity | Character–vehicle bridge | Occupancy is confirmed |
| Command source | Control relationship | Old source released, new source accepted |
| Vehicle context | Vehicle-side runtime | Task context was not cleared accidentally |
Why Writing the Result First Causes Drift
Writing Driver = Player before the entry relationship is confirmed exposes an unconfirmed result to every other system. Input may begin too early, the old source may still submit commands, and the task may believe that the previous driver has already left. A safer order is to establish temporary relationships, confirm formal occupancy, and only then open the command window.
What Source Entrances Can Prove
Source reading should follow three layers: creation, processing, and bridging. Independent vehicle initialization supports the existence of a vehicle-side runtime. An independent vehicle processing entry supports a vehicle lifecycle that does not depend on the player character. A character-to-vehicle bridge supports the separation between relationship maintenance and vehicle operation.
These observations justify an architectural abstraction, but they do not prove that every project must use the same class hierarchy or naming scheme.
Continuity as Seen Through Player Experience
The player does not see internal fields, but can still detect broken continuity. Control that activates before entry feels premature. A vehicle that forgets its task after takeover feels like a different entity. A vehicle that disappears or loses context after exit breaks world continuity.
Identity continuity, seat continuity, command continuity, and vehicle-state continuity are therefore external tests of the relationship model.
What a Mature Takeover System Must Ultimately Solve
- When does the player actually become the driver?
- Why must reservation and occupancy be separate?
- Why is a
Driverfield insufficient? - Why can AI not be directly removed?
- How does takeover failure recover?
- How does the vehicle continue after the player leaves?
These six questions define the scope of P1. Later articles can explain how input becomes a command, how a task creates a goal, and how an executor produces motion, but each of those systems depends on a stable character–seat–vehicle relationship.
Source Supplement: Why the Vehicle Continues Before and After Player Entry
The following is an architectural abstraction based on source structure, call relationships, and responsibility distribution. It is not the only possible public implementation.
The initialization and processing entry points indicate an independent vehicle-side runtime owner. The vehicle establishes its intelligence and baseline task state before a player enters, and its processing path continues to maintain tasks and state changes independently of the driver.
This means that player entry changes the seat relationship and current command source; it does not create vehicle intelligence from nothing. When the player leaves, the character-side task may exit while the vehicle still has a valid continuation entry.
Three source-reading conclusions are enough for P1:
- The vehicle has an independent continuation entry. Characters may enter and leave while the vehicle remains a runtime entity.
- The character side maintains the relationship; the vehicle side maintains operation. A bridge synchronizes the two instead of making one task own everything.
- Takeover changes the current command source. It does not automatically delete route, mission, identity, or recovery context.
From an Implementation Perspective, What Must a Seat Relationship Answer?
- Who confirms the target vehicle when the player presses enter?
- Are reservation and formal occupancy separate states?
- Who clears a reservation when entry is interrupted?
- When does the vehicle confirm the seat relationship?
- Are driver identity and the player command window settled separately?
- What happens to the previous AI task?
- Can the character remain a passenger if player control is rejected?
- Who maintains route, task, and damage state after exit?
- How does a vehicle failure reach the relationship state?
- After a failed entry, are the previous driver, route, and task still legal?
If all ten questions are answered by one global Boolean, control transfer has probably not been modeled. If each has an owner, submitter, and recovery entry, the later articles have a stable foundation.
Closing
P1 is not about playing an enter animation. It is about how a vehicle that already exists recalculates relationships, permissions, and command sources when a player enters it.
Reservation protects the asynchronous entry process. Occupancy confirms the character relationship. Driver identity records who occupies the driver seat. Command submission identifies who may affect driving execution. When the player exits, the vehicle identity and required context remain, and the next control source takes over through an explicit recovery entry.
The player does not receive a new vehicle. The player receives a control window into a vehicle that was already running.
The next article examines that control window itself: how player input is sampled, filtered, and accepted, why the camera expresses control state, and why pressing a direction key still does not guarantee that the vehicle has accepted the command.
*This article presents a public abstraction of the original mechanism and its evidence boundary. It does not claim that the architectural abstraction is the only implementation proven by the source.*