Previous article: Open-World Player Vehicle Driving P10: Driving, Aiming, and In-Vehicle Combat — How One Vehicle Handles Motion and Interaction
P10 examined how driving, aiming, and in-vehicle weapon interaction can coexist on one continuously running vehicle. P11 addresses the next layer: when a task asks the vehicle to approach, intercept, maintain distance from, or escape a target, how can routes, driving policy, and control sources change without rebuilding the vehicle?
Introduction: A Chase Does Not Replace the Vehicle Runtime
Consider a vehicle cruising through a city. It already has a route, a driving task, speed state, seat relationships, vehicle capabilities, and traffic constraints. A mission event then appears: a target vehicle must be intercepted, the player must escape pursuit, or an occupant requires the driver to maintain a certain distance for an interaction.
From the player’s perspective, only one thing seems to happen: the vehicle starts chasing or escaping. The runtime handles several changes in parallel. The target moves continuously, the previous route may become invalid, the desired distance must be reevaluated, the driving policy may become more aggressive, in-vehicle combat may continue, and the mission script may request interception, slowing, departure, or waiting.
If these changes are compressed into a single chase switch, continuity is quickly lost. The previous route may be cleared, the driving task may be destroyed, the weapon system may lose its execution entry, and the original driving state may have no recovery path. The opposite mistake is to let the chase task write throttle, steering, and braking directly. That crosses the command contract of P3, the driving policy boundary of P6, and the physical execution boundary of P8.
P11 therefore focuses less on making a vehicle catch a target and more on this question:
How can a chase task change route, distance, and behavior constraints while preserving the vehicle’s identity, execution stack, and recoverability?
Chase is a high-level runtime mode. It can reinterpret the target, route, and policy, while the existing vehicle runtime continues to provide routes, local targets, execution, and physics feedback. Escape follows the same organization principle, but changes the objective from reducing distance to increasing separation, reaching safety, or maintaining a disengagement condition.
This article focuses on task-side chase, escape, and dynamic control. P10 covers in-vehicle aiming and weapon interaction; P12 will cover network, replay, LOD, and world continuity after the player leaves. Chase is not a physics controller, and a mission script is not the final driving command.
1. A Chase Changes Runtime Constraints, Not Vehicle Identity
A Vehicle Already Has State Before It Enters a Chase
Before the vehicle begins a chase, it already has an entity identity, seat relationships, a current command source, a route or local target, speed and direction, damage and physics feedback, and constraints from the surrounding traffic world.
The chase task should attach a target relationship and new constraints to this runtime. It should not create a second vehicle, reset the seat graph, or replace the physical state merely because the mission phase has changed.
One Chase Lifecycle Can Contain Several Active Poses
Source reading shows that a chase cannot be reduced to “move toward the target.” It may switch among several operational poses:
- Approach: the distance is too large, so the system reduces the gap;
- Follow: the vehicle is within a useful range and maintains a relative position;
- Intercept: the system predicts the target route and seeks a reachable position ahead;
- Parallel approach: the vehicle keeps a lateral relationship for observation or in-vehicle interaction;
- Ramming: when mission and policy constraints allow it, vehicle contact is used to change the target state;
- Escape: the target relationship becomes a threat to disengage from, and the vehicle seeks distance or a safe condition.
Departure is a transition result after the active pose ends. It may lead to reattachment, search, waiting, recovery, or exit. These poses do not require independent low-level driving systems. A high-level chase task can select the pose while lower-level vehicle tasks execute approach, following, or local motion.
Chase Entry and Exit Need Independent Conditions
Chase cannot be represented by one Boolean flag. Entry may require a valid target, a task that still permits pursuit, a valid control source, sufficient vehicle capability, and a usable spatial relationship. Exit needs separate checks for target invalidation, mission completion, severe loss of control, inaccessibility, timeout, driver departure, and task replacement.
The lifecycle therefore needs to retain its source, target and target version, current pose, distance and relative speed, command source, permitted aggressive actions, exit reason, and recoverable previous state. Ending a chase requires the runtime to decide whether the previous route returns, whether the task is rewritten, whether policy parameters roll back, whether in-vehicle interaction continues, and whether the vehicle enters waiting or safe state.
Two axes should be maintained independently:
- Task lifecycle: enter → analyze → active → wait, search, or recover → active again → exit;
- Current chase pose: approach, follow, intercept, parallel approach, ramming, or escape;
- Interruption conditions: target loss, unavailable route, local inaccessibility, vehicle stuck, insufficient capability, control-source change, or task cancellation.
Target loss and a stuck vehicle are interruption conditions, not chase poses. They may pause, downgrade, or reselect the current pose without necessarily ending the chase lifecycle.
2. Chase Task Ownership and State Machine
The terms “chase parent task,” “vehicle chase wrapper,” “target coordination layer,” and “analysis phase” are responsibility aliases derived from source structure, creation relationships, call paths, and cleanup paths. They do not imply a unique public class name or a fixed implementation hierarchy.
The Chase Policy Layer Supervises and Selects
The chase layer observes the target and vehicle, calculates relative distance, direction, and speed, checks whether the current pose remains valid, selects a new target point or distance constraint, handles blocked and stuck conditions, and exchanges state with in-vehicle interaction and vehicle capability systems. It does not directly write throttle, steering, or braking.
Chase Tasks and Vehicle Tasks Have Different Responsibilities
A chase parent task may select different branches according to vehicle type, target state, and geometry. Cars, boats, aircraft, helicopters, and other vehicles can share target semantics while using different execution wrappers. The chase layer defines the relationship and constraint; the vehicle task turns that constraint into a route request, local target, or low-level task combination.
Multiple Chasers Cannot Select Positions Independently
Several vehicles approaching one target cannot all choose the nearest point. They would converge on the same space, block one another, and potentially block the target. A coordination layer therefore assigns roles such as primary approach, side position, rear position, and replacement position. Its output remains a relative position, target offset, or chase pose, not throttle, steering, or braking.
The Analysis Phase Is the Strategy Center
The analysis phase reevaluates four groups of state: target relation, road and space, vehicle capability, and task constraints. Together they determine an explainable chase pose. The phase does not directly generate throttle, steering, or braking.
Approach Distance Is Not a Fixed Number
The useful distance changes with target speed, road curvature, vehicle type, policy, and current state. A fixed distance works only for simple following. In open-world traffic it either produces no pressure or creates repeated collisions and loss of control. The policy can combine a base distance, a speed compensation, a braking-safety margin, road and lane geometry, space needed for in-vehicle combat, and mission-specific constraints. The result passed to the vehicle task is an expected offset or local target, not a physics position.
Normal Pursuit and Aggressive Actions Need Separation
Approach and following can remain active while the task evaluates whether interception or ramming is permitted. Aggressive actions need additional conditions: target relation, vehicle capability, mission permission, cooldown, collision risk, and a valid recovery path. A task that cannot distinguish these layers will oscillate between normal following and forceful contact.
Interception Is Not Placing a Target Point at the Target’s Current Position
An intercept position must account for target velocity, heading, road topology, reachable lanes, braking distance, and the chaser’s own capability. The target’s current position is a fact; the ideal interception position is a strategy output. Mixing the two makes the vehicle chase a point that is already obsolete.
Ramming Is a Constrained Vehicle Interaction
Ramming consumes a specific interaction permission and should be subject to capability, cooldown, collision safety, mission phase, and target state. The chase task requests a constrained relation; the executor and physics layers decide whether the vehicle can realize it. Contact facts, damage, and loss of control return as runtime feedback.
Parallel Approach Serves Several Interaction Goals
Lateral approach may support observation, dialogue, boarding, passenger interaction, weapon use, or a scripted handoff. It should therefore be expressed as a relative position and orientation constraint. The vehicle still needs a valid route and local execution path.
A Chase Can Start from More Than One Event
The entry may come from a mission event, a response system, a target relationship, a player action, a script phase, or a vehicle-side condition. The source affects priority and recovery, but it should converge on the same explicit target, permission, pose, and lifecycle state.
Police Response and Vehicle Chase Are Not the Same Layer
A response system can decide that a target should be pursued and can assign vehicles. The vehicle chase task then maintains the target relationship, chooses a pose, requests route changes, and receives execution feedback. Separating response from pursuit prevents dispatch policy from becoming a low-level driving controller.
Driver and Occupant Chase Responsibilities Can Diverge
The driver maintains vehicle movement and consumes route and local-target constraints. Occupants can observe, aim, fire, or execute mission actions under their own seat and weapon permissions. The chase task coordinates their shared target relationship without merging their command channels.
3. Escape: An Independent Target Relationship and Exit Condition
Escape Is Not the Negative of Chase
Escape does not merely negate an approach vector. It changes the objective: increase separation, break visibility, reach a safe region, maintain a time threshold, or end a threat relationship. The route, local target, and policy must be regenerated around that objective.
Escape Conditions Must Be Observable and Recoverable
The system should record why escape is active, which target relationship it is escaping from, what condition counts as disengagement, and what happens if the vehicle cannot reach safety. A temporary loss of visibility may start a search or concealment phase; it should not automatically destroy the task.
Escape Routes May Preserve Deliberate Uncertainty
A safe route is not always the shortest route. It may avoid predictable roads, preserve multiple exits, reduce exposure, or delay a final commitment until the target relationship changes. The route system provides candidates; the escape policy chooses which constraints matter.
4. Dynamic Control and In-Vehicle Interaction Handoff
A Chase Task Does Not Always Receive the Highest Permission
Control is decided by current task rules, seat relations, player input, script constraints, network authority, and vehicle capability. A chase task may provide a target and policy constraint while another source remains responsible for the final command. It should not silently overwrite a valid player or mission control window.
Player Control During a Chase Needs Local Space
When a player takes control during a chase, the target relationship may remain active while the player controls immediate movement. The task can continue to provide destination, threat, or distance information without directly submitting steering. If the player leaves, the system must decide whether the chase resumes, waits, or exits.
Dynamic Control Must Handle Late Requests
Route searches, target queries, and task transitions can complete out of order. Every request needs source identity, target version, sequence, and validity checks. A late result may be rejected without becoming a new command. This is part of the lifecycle model rather than a networking exception.
In-Vehicle Combat Continues to Consume Its Own State
Weapon mode, aim target, seat permission, cooldown, ammunition, and interaction results remain owned by the interaction system. The chase task can change relative position and vehicle movement, but it does not become the weapon task. A failed shot does not necessarily end a chase; an invalid seat or weapon state does not necessarily stop the vehicle.
Damage Can Change the Chase Pose
Damage and capability feedback may remove the ability to turn, accelerate, ram, or maintain a preferred position. The chase policy should select a less demanding pose, maintain distance, request recovery, or exit. It should not continue submitting an action the vehicle can no longer execute.
Script Tasks Provide Event and Phase Constraints
Scripts may request a chase, define a target, prohibit ramming, require a pause, or declare completion. They should not need to own every route and movement detail. The task hierarchy interprets script constraints and lets route, policy, executor, and physics systems preserve their own responsibilities.
5. Source-Reading Conclusion: Chase Is a Supervisory Layer, Not a Low-Level Driver
Observe Responsibilities through State and Creation Relationships
The most reliable evidence comes from who creates a task, who writes its target and parameters, who consumes the result, and who clears it. Names alone are not enough. A source-like name may describe a wrapper, a shared contract, or a temporary role rather than a permanent subsystem.
Cars, Boats, and Aircraft Do Not Share One Control Law
They can share target facts, chase poses, relative offsets, and lifecycle semantics. Their route interpretation and execution remain vehicle-specific. P11 stops at that boundary and leaves steering, propulsion, attitude, buoyancy, and flight-control laws to P8.
Target Offset, Ideal Distance, and Reachable Position
These are different values. Target offset is a relation, ideal distance is a policy preference, and reachable position is a geometry- and capability-constrained result. Conflating them causes the chase task to assume that a desired point is automatically executable.
Prediction Cannot Replace Target Facts
Prediction can estimate where a target may be. It cannot replace target identity, validity, version, or current state. When the target changes direction, the prediction must be invalidated or recomputed without allowing stale estimates to overwrite current facts.
Multi-Chaser Coordination Assigns Roles, Not Control Values
Coordination decides which vehicle approaches, blocks, follows, or replaces another vehicle. Each vehicle still consumes its own local target and policy through its own executor. This preserves a clear ownership boundary.
Chase Results Must Return as Facts
The chase layer should distinguish several result facts:
- Chase pose submitted: the high-level task has requested approach, follow, intercept, or ramming;
- Lower-level task accepted: the route or vehicle task confirms that the request is executable;
- Vehicle execution started: the executor has consumed the local target or control constraint;
- Geometric relation satisfied: distance, heading, or relative position has reached the phase condition;
- Physical contact occurred: physics has confirmed a collision, ram, or other contact fact;
- Target state changed: the target’s speed, position, capability, or task state has changed observably;
- Task condition satisfied: the chase phase has a result that permits progression, transition, or completion.
These facts are separated because they occur at different times. A chase task may advance its internal phase when execution starts, but it should not advance on the basis of target, physics, or mission completion until the corresponding system has confirmed the result.
6. Environment Seams, Failure, and Diagnostics
Chase Vehicles Remain Part of the Shared Road World
Chase does not suspend traffic, road availability, lane relations, or spatial queries. The vehicle may receive a more urgent objective, but it still depends on the same world services and must react to unloaded roads, blocked intersections, and unavailable local space.
Target Relations and Road Relations Must Remain Separate
The target relation answers who or what is being pursued. The road relation answers where the vehicle can move. A target may be valid while no current road route is available; a road route may exist while the target relation has expired.
Intersections and Traffic Density Change the Chase Pose
The same target distance can imply different actions on an open road, at a signalized intersection, or in dense traffic. The policy interprets the environment and selects a pose; the traffic and route layers provide the constraints.
Forced Waiting Creates Pressure Without Being a Failure
A chase vehicle may wait because of a red light, a blocked lane, a missing route segment, or a temporary lack of safe space. Waiting is a state with a reason and a recovery condition. Treating every pause as failure creates oscillation and unnecessary task replacement.
Chase Failure Must Be Explainable
The runtime should distinguish target loss, geometric inaccessibility, capability loss, timeout, control-source change, task cancellation, and world-data unavailability. Each cause may lead to a different exit or recovery path.
Logs Should Not Record Only the Final State
Useful diagnostics include request sequence, target version, selected pose, rejected result, capability snapshot, route state, control source, and exit reason. A final “chase ended” message cannot explain which relation failed first.
Observability Also Protects the Source-Reading Boundary
When a responsibility is inferred from creation, write, consume, and cleanup paths, the diagnostic model should preserve that distinction. It should be possible to tell a directly observed state transition from an architectural interpretation.
What the Chase Layer Must Be Able to Answer
At any update, the system should be able to answer: which target is active, which version is valid, which pose is selected, who may submit movement, which route or local target is current, what capability limits apply, which request is pending, and what recovery path will be used if the next action fails.
Target Loss, Inaccessibility, and Chase Failure
Temporary Target Loss Is Not Automatically Task Failure
The target may be hidden, occluded, or temporarily unavailable to the query service. The chase can enter search, maintain a last-known relation, or wait under a timeout. Only the task rules decide whether that becomes a failure.
Inaccessibility Needs Geometric and Task-Level Distinctions
A route can fail because data is not loaded, the target is in an invalid region, the chaser is blocked, or the vehicle lacks the required capability. These causes should not collapse into one generic “no path” result.
Stuck Detection Is More Than Low Speed
Low speed may be intentional waiting. A stuck decision needs time, displacement, expected motion, road context, control input, collision state, and the current pose. Recovery can then choose a local adjustment, a new route, a pose downgrade, or task exit.
Dynamic Parameters and Driving Personality
The chase task can modify risk weights, desired distance, and permitted aggression. It should not rebuild the driver’s entire personality model. Policy inputs are temporary constraints layered onto a stable strategy contract.
Chase Can Change Risk Weights Without Rebuilding Personality
This separation lets the same vehicle respond to a mission phase while preserving driver-specific tendencies. It also makes recovery explicit: when the chase ends, temporary weights can be removed without replacing the driver object.
Aggressive Driving Requires Capability Gates
Ramming, high-speed interception, and narrow side approaches require available steering, braking, traction, collision tolerance, and mission permission. Capability gates prevent policy from requesting an action the executor cannot safely realize.
Chase Rhythm Comes from State Duration
Approach, follow, search, and intercept should not change every frame merely because a measurement crosses a threshold. Hysteresis, minimum durations, and explicit transition conditions stabilize the runtime and make the resulting behavior explainable.
7. Task Completion and Control Recovery
The Reason for Chase Completion Must Be Preserved
Completion, target loss, escape success, timeout, damage, player takeover, and cancellation have different recovery implications. The reason is part of the task result, not an incidental log string.
Whatever Chase Temporarily Overrides Must Be Restored
If chase paused a route, changed a target constraint, added a policy override, or reserved a coordination role, the end path must release or restore that relationship. Cleanup is the inverse of installation and must be explicit.
Player Takeover Does Not Automatically Remove the Target
Player control can replace the current movement command source while the mission target and chase relationship remain valid. Whether the task continues, pauses, or exits is a separate decision.
Chase Cleanup Has an Order
A safe closeout can record the result, invalidate pending requests, release coordination roles, restore or replace the route, remove temporary policy constraints, close the chase relation, and return the vehicle to the next valid control source. The exact order depends on ownership, but no temporary relationship should remain ownerless.
8. Cross-Vehicle Abstraction, Validation, and Migration Boundary
Class Names Alone Cannot Establish the Chase Layer
The architecture should be inferred from state ownership, task creation, parameter writes, result consumption, and cleanup. A class name can be a wrapper, a shared base, a vehicle-specific branch, or a temporary adapter.
Combining a Car Chase Parent Task with Child Tasks
The parent task maintains the target relationship and chase phase. Child tasks consume route, local-target, and vehicle-specific constraints. This keeps high-level decisions separate from motion execution and gives the parent a place to handle recovery.
Vehicle-Specific Chase Wrappers
Different vehicle families can share the chase lifecycle while exposing different route and capability contracts. The wrapper translates approach, intercept, follow, or escape into the form that the relevant executor understands.
What to Preserve when Migrating to a Target Engine
Preserve phase timing, target and request versions, pose transitions, capability checks, result facts, and cleanup ownership. Do not copy source class names mechanically or allow a single controller to absorb target relations, route ownership, policy, execution, and physics.
Validation Scenarios for P11
The following scenarios test ownership, failure explanations, and recovery paths rather than only whether the vehicle eventually reaches the target.
Single-Vehicle Chase
Verify that ordinary navigation can enter chase, establish the target relation, change route and local target, and restore the previous source according to the exit reason.
Multi-Vehicle Chase
Verify that several vehicles form distinct relative positions and that a blocked or removed vehicle releases its role for reassignment.
Brief Target Loss
Verify that occlusion or temporary query failure enters search or hold rather than ending the task immediately, and that timeout follows the task rule.
Target Inaccessibility
Test unloaded roads, invalid target regions, blocked vehicles, and insufficient vehicle capability separately. Each should produce an identifiable recovery result.
Parallel In-Vehicle Combat
Verify that occupants can aim or fire while the vehicle continues pursuit, and that weapon failure affects the interaction branch without automatically stopping the vehicle.
Vehicle Damage
Verify that reduced steering, speed, or weapon capability changes the chase pose or enters recovery instead of continuing to submit an impossible action.
Player Takeover and Exit
Verify target preservation, AI command release, player command arbitration, and the post-exit decision among AI recovery, mission continuation, waiting, or safe state.
Late Requests
Introduce delays between route search, target queries, and chase transitions. Confirm that stale targets, routes, and control-source results cannot overwrite the current state.
AI-Assisted Review
AI is useful here for organizing cross-file relationships among chase tasks, vehicle wrappers, route requests, and in-vehicle interaction. It can expose state dimensions that are easily conflated: pose, lifecycle, failure reason, and command-submission eligibility.
Human review must still return to creation, write, consume, and cleanup paths: who creates a child task, who changes target offsets, who validates a result, who cancels a late request, and who removes temporary relations at completion. Cross-file coordination and response-chain responsibilities remain hypotheses until the call paths and state fields support them.
Case One: A Chase Event During Ordinary Navigation
A vehicle is following a route to a fixed destination. An event establishes a target relation and asks the route layer for a target-oriented interpretation. The original navigation task does not necessarily disappear; it may be paused, saved as a recovery candidate, or stripped of only its active target constraint.
Three relationships change at once: the target source becomes an entity relation, the route request source changes from navigation to chase, and the policy changes from ordinary cruising to pursuit risk. Vehicle identity, seat relationships, damage, and the physical executor remain intact. If the target becomes invalid, the runtime can restore navigation, enter search, or end the event according to the result.
Case Two: The Target Turns Suddenly
When the target turns at an intersection, the predicted position and local target can become invalid. The chase layer updates the target fact first, then checks whether the current pose remains valid. If an interception point is unreachable, the request is cancelled and follow or approach is selected. A new route result can update the route slot before the local-follow layer produces another target.
The vehicle may continue in the old direction briefly while the previous command remains valid. It is consuming a still-valid command until the new target is accepted. Smoothing can avoid an abrupt visual reversal, but it must not prolong an invalid target relation.
Case Three: The Chaser Loses Steering after a Ram
Physics produces the collision fact, and the damage layer converts it into a steering-capability limitation. The chase task cannot continue treating ramming as a valid pose. It may maintain distance, follow the road, wait for recovery, or return the result to the response layer.
In-vehicle weapons may be affected independently. A vehicle that can still move may not be able to fire, while a temporarily unavailable weapon does not necessarily end the chase. The chase exits only when movement capability, target relation, or task phase can no longer continue.
These cases show that a chase is not a discrete conversion from an ordinary vehicle into a special vehicle. It is a sequence of relationship changes across multiple update phases. Every change needs a source, validity period, consumer, and recovery exit.
P11 and Its Neighboring Articles
P10 covers parallel consumption by driving and in-vehicle combat. P11 adds task-level target changes and chase poses without reimplementing weapon lifecycles. P12 will cover world continuity across network authority, replay, LOD, and player departure.
P6 supplies driving-policy parameters, P7 handles short-range spatial conflicts, P8 turns acceptable commands into motion, and P9 produces damage and capability limits. P11 organizes those results into a chase task without duplicating their implementation.
Conclusion: Chase Changes Constraints, Not Vehicle Identity
A chase or escape task does not need to rebuild a vehicle. It establishes a target relationship, selects a pose, requests route and local-target changes, applies temporary policy constraints, consumes capability and physics feedback, and preserves an explicit recovery path. The vehicle remains the same runtime entity before, during, and after the event.
The useful abstraction is therefore not “chase mode,” but a supervised control relationship with a lifecycle. It can enter, analyze, approach, follow, intercept, wait, search, escape, recover, and exit while keeping route ownership, execution, physical feedback, and interaction responsibilities distinct.
That is why a pursuit system can remain compatible with player control, in-vehicle combat, multiple vehicle families, and the wider open world: it changes the constraints under which the vehicle operates, rather than replacing the vehicle itself.