Open world player vehicle driving P5: How player goals become navigation – GPS, route life cycle and dynamic re-planning

P1 discusses how players obtain the driving control window through seating relationships; P2 discusses how input enters the vehicle; P3 discusses how multiple inputs, mission goals and constraints form consumable driving commands; P4 discusses how different control sources complete release, takeover and recovery. This article continues to ask: after the player specifies a destination, how does the vehicle turn this goal into a route that can be continuously executed?

Previous chapter: Open world player vehicle driving P4: How AI releases and retakes control of the vehicle

Introduction: The destination is not the route

When a player selects a location on the map or drives along a road toward a mission objective, the interface typically displays only a line, a marker, and an expected direction. The player’s understanding is also straightforward: I’ve told the vehicle where to go, all that’s left is to follow the route.

But for open world vehicle operation, the destination is not the same as the route. The destination is just a goal constraint; the route also needs to answer:

Which section of road, which lane or which type of drivable area the current entity is located;
Whether the target is still valid and whether the target entity has moved;
Whether the road network has been loaded and whether route query can be started;
Whether the current route has been generated or is still in the asynchronous search stage;
How to assign vehicle tasks to nodes, intersections, speed zones and lane selection on the route;
Whether the old route is still available after a blockage, collision, deviation or traffic change on the current road;
Whether the system needs to rebuild the entire route when the player just changes direction input.

Therefore, the core judgment of this article is:

The route system does more than search for a reachable path. It maintains a route that remains usable as the world changes.

This is also the difference between player navigation and racing game navigation. A racing game can treat a route as a static sequence on a track; a route in an open world must be continuous with entity identities, traffic states, mission phases, road loading, and local execution.

1. What the player sees is the GPS, and what the vehicle receives when running is the target constraint.

1.1 Map markers are only target expressions

When the player clicks on a location on the map, the input system does not directly create a control task for a vehicle. It first produces a target expression:

world location;
target entity;
target area;
Task association;
Whether re-planning is allowed;
Whether it is allowed to continue along the current road;
Whether you need to reach a facing direction or a roadside location.

This information may come from different portals. Navigation points can be generated by player map operations, or by the mission system, scripts, pursuit targets, escort objects, or recorded routes. The entrance is different, and the life cycle of the target is also different.

Fixed map points remain in effect for a long time; target entities may move, disappear, or change ownership. Mission objectives may be replaced before reaching them. The recording route may loop or end after reaching the end point. Therefore, “navigation point” should not be designed as a variable with only coordinates.

A more accurate abstraction is:

The target is a set of constraints consumed by the vehicle runtime, and coordinates are just one of the fields.

1.2 The target layer and route layer must be separated

The destination layer answers “where to go”; the route layer answers “which drivable connections will lead to getting there”. The frequency of changes between the two is different:

The target may change when switching tasks;
Routes may change due to entity movement, road closures or route exhaustion;
Local targets may change every control cycle;
Vehicle control commands are continuously updated within a shorter execution cycle.

If the destination is written directly to the vehicle controller, the system will compress the four different life cycles into one state. The result is usually: as soon as the player turns, the mission route is reconstructed; the vehicle encounters an obstacle and the original mission goal is lost; the target entity moves, and the actuator still travels along the old coordinates.

Open world route links need to separate these layers:

Goal constraints generate route requests, route requests generate route status, route status generates local targets, and the local targets then enter the vehicle execution layer.

2. Global road data: Who owns route search?

2.1 The road network is independent of individual vehicle tasks

It can be observed from reading the source code that the road path data is held by a global road query layer. It maintains road nodes, connection relationships, drivable attributes and stream-loaded route data on the map, and provides external route search entrances.

This article calls this layer the “global road query layer”. It is not the responsibility of a particular vehicle, nor is it part of the GPS interface. The vehicle task simply submits a query to it and consumes the results.

This distinction is important:

The global road query layer has road map and search capabilities;
The route task has the life cycle of the current route of a certain vehicle;
Route following assistance has progress and sampling on the generated route;
Local actuators have steering, braking and speed writes for the current target point.

If the road query object is copied to each vehicle, not only will the data be stored repeatedly as the number of vehicles grows, but the ownership of the road data and route instances will also be confused. The road map should be a shared query resource, and the route should be the runtime state on the entity side.

2.2 Streaming road data enables route query to have preconditions

An open world road map is not a static array loaded into memory all at once. Route nodes, intersection data, route regions, and related metadata may be streamed in by region. Therefore, route requests need to distinguish at least several states:

The request has not yet been submitted;
The area required for query is not loaded;
The query has been submitted, waiting for results;
The query is completed but the result is empty;
The query is completed and candidate routes are generated;
Routes installed to vehicle tasks;
Route failed during execution.

This is why the vehicle task cannot assume that the route already exists in the same frame it receives the destination. The task can first save the target and request status and enter the search phase after the road data is available.

2.3 Path areas, speed areas and intersections belong to different levels

Road nodes, route areas, intersection instances and road speed overrides do not form a single manager:

The road query layer provides global road node and path query;
Maintain nearby active intersections and their vehicle members when the intersection is running;
The path area provides static areas or area mapping;
Road speed zones provide runtime speed coverage;
The vehicle task is responsible for converting these results into the current route and local targets.

Therefore, vehicle navigation cannot just save an “array of nodes”. The same route may have different execution constraints at different intersections, speed zones and road conditions. Route data provides geometric connections, and intersection and speed strategies provide on-the-fly interpretation.

3. Route request: from target to asynchronous search

3.1 Route request requires your own identity

A route request needs to have at least:

source of request;
Target description;
Starting entity or starting position;
target version;
Request serial number;
Generation cycle;
Search mode;
allowed route types;
Whether it is allowed to continue on the old route;
Whether to allow waiting when the result is empty.

The request sequence number identifies and rejects late results. The vehicle may have changed its destination while waiting for the search, so an old query cannot overwrite the current route when it returns.

This type of problem is very common in asynchronous systems:

The player selects target A;
The system submits route request A;
The player selects target B again;
The system submits route request B;
B returns and installs first;
A delayed return.

Without a request sequence number or target version, late results from A could overwrite B. What appears to be a sudden U-turn is actually the old route crossing the current state boundary.

3.2 The route slot is not the route itself

When running a route, you usually need to distinguish between “route slot” and “route data”:

The route slot saves the current request, current status and result ownership;
Route data saves node, connection, lane or sampling information;
Route following assistance saves current progress;
Vehicle missions save the relationship between goals and routes.

The value of route slots is that asynchronous queries have a stable receiving position. When the request is not completed, the vehicle can still use the old route; after the request is completed, the system verifies the requested version before deciding to install, delay the installation, or reject it.

Therefore, route substitution should not be reduced to:


Route = NewRoute;

The process closer to actual runtime is:

Asynchronous route request and version verification

The code in this article is only used to express state relationships and does not correspond to original class names or unique interfaces in public implementations.

3.3 Search parameters themselves are also strategies

Different navigation requests cannot just change the end point. They may also change:

Whether to give priority to road access in the current driving direction;
Whether U-turn is allowed;
Whether access to non-arterial roads is allowed;
Whether to allow the use of navigation mesh instead of road paths;
Whether lane keeping is required;
Whether it is necessary to wait for the streaming node;
Whether route extension is allowed;
Whether for chasing, cruising, following or recording playback services.

Therefore, route search entry parameters are usually determined by vehicle tasks rather than task semantics determined by the road query layer. The global road layer is responsible for the query; the task layer determines what driving goal this query belongs to.

4. Vehicle route tasks: Who owns the route life cycle

4.1 The cruise mission is not “just drive”

Judging from the distribution of source code responsibilities, car cruising tasks have far greater responsibilities than environmental roaming. This article refers to it as the “car route holding layer”.

It is usually responsible for:

The life cycle of the route search auxiliary object;
Construction of node lists and following routes;
Route extension and re-planning;
Strategies related to intersections and traffic lights;
Speed zones, lanes and parking conditions;
The connection between the current route and the task performed by the vehicle.

It’s not a low-level turner, nor is it the ultimate pedal writer. It is responsible for determining the navigation goal of the current vehicle on the route and passing this goal to lower-level tasks.

4.2 The target navigation task is a dedicated entrance to the route holding layer

When the player or the mission system gives a clear goal, a “target navigation mission” may be installed on the side of the vehicle. It shares the route lifecycle with regular cruises, but requires additional handling:

Whether the target location is valid;
Whether the current road can be accessed;
Whether the target is moving;
How to end after reaching the goal;
Whether to search again after the target is invalid;
Whether to allow access policies for the current driving direction.

Therefore, the target navigation task can be regarded as the targetized entrance of the route holding layer, rather than a completely independent driving system.

The responsibilities between the two can be summarized as:

The cruise route holding layer is responsible for the general road route life cycle; the target navigation task is responsible for connecting specific targets to this life cycle.

4.3 Route exhaustion does not mean task completion

When the node list reaches the end, the vehicle task needs to judge:

The current node is just the end of the current route segment;
Whether the route can be extended;
Whether you have entered the target area;
Whether it is necessary to perform arrival judgment;
Whether the target has moved;
Whether the current route is temporarily ended due to a streaming boundary.

If you complete the task immediately after seeing that the node list is empty, the vehicle may stop prematurely at the road loading boundary, short route or temporary path end. Route completion, goal arrival, and task completion are three different events.

5. Route following: How route data becomes local targets

5.1 Route following assist does not have road search

In the source code material, the route following assistant is responsible for geometric sampling and progress management on the generated route. It can return: based on the current position, speed, route width and current progress:

Next local target position;
Recommended speed;
Remaining distance of the route;
Current route segment;
route width;
finish line or finish area;
Whether the current following segment needs to be rebuilt.

It does not determine how the entire road map is searched, nor does it own the target relationship of vehicle tasks. It handles which section of an already established route the vehicle should currently follow.

5.2 Forward looking distance changes with speed and scene

The local target cannot be fixed at a certain distance in front of the vehicle. At higher speeds, route changes need to be seen earlier; slow-speed turns, narrow roads, hitch trailers or large vehicles may require different forward sight distances.

Route holding layers typically combine:

current speed;
desired speed;
Route segment curvature;
Intersection distance;
type of turn;
vehicle dimensions;
lane width;
Whether the car is currently parked;
Whether it is in special road conditions.

In the end, the route-following helper returns a locally processed target and speed constraints, rather than a single successor node on the route.

5.3 The local target is not the final control command

P5 must maintain boundaries with P3, P6, P7, P8:

The route system provides local goals;
Driving strategies provide risk and behavioral modulation;
The avoidance system handles obstacles in front of you;
The executor writes the synthesized commands into the vehicle;
Physics system feedback actual movement.

Therefore, the local target point should not be directly equated to the steering wheel angle. The vehicle may not turn immediately towards the target point due to red lights, traffic participants, road blocks or driving style. The route only answers “Where is the navigation target?” and does not answer “How the vehicle must be controlled at this moment.”

6. Re-planning: Why does the route need continuous maintenance?

6.1 Replanning is not an abnormal path

Vehicles in the open world would quickly lose the ability to navigate if the system only searched for a route once, when the initial goal was established. Replanning may be triggered by many types of events:

The target position changes;
The target entity disappears;
The current route nodes have been exhausted;
The vehicle deviates from the route;
Road nodes or path areas have just been loaded;
Intersection or road status changes;
Routes are replaced by scripts, tasks or temporary actions;
The current road cannot be continued;
The vehicle passes a threshold that allows route extension.

Therefore, “re-planning” is part of the route life cycle, rather than an auxiliary error-recovery path.

6.2 Update determination and search execution should be separated

There are at least two different problems with the routing system:

Whether the search should be re-searched;
If it should be searched, what parameters should be used.

“Whether to search again” may be determined by target movement, route exhaustion, deviation distance and current status; the search mode is determined by vehicle type, route mode, current road direction, special tasks and available path types.

Combining the two into a huge function will cause every small parameter change to trigger a complete rebuild, and will also make the asynchronous result unable to explain why it was requested.

A more stable boundary is:

The update decision determines when to request; the search configuration determines how the request is interpreted; the route slot determines whether the result is still valid.

6.3 Old routes and new routes can coexist temporarily

The vehicle does not necessarily need to lose navigation immediately during the search for a new route. Reasonable conduct may include:

Continue along the old route;
Temporarily reduce speed;
Waiting for streaming road data;
Maintain current local target;
Enter safe parking;
Use local navigation mesh to get around;
Wait for new route verification to complete.

This depends on the mission and vehicle status. Emptying old routes immediately creates meaningless pauses; leaving old routes indefinitely allows vehicles to continue on roads that have become ineffective. The route status needs to express “the old route is still available for consumption, but the new route is being prepared”.

7. Runtime explanation of intersections, speed zones and routes

7.1 The intersection is not ancillary information of the route node

Road path data can tell vehicle connection relationships, but it also needs to be maintained when the intersection is running:

Which vehicles are currently entering the intersection;
Which vehicle is within the intersection range;
Current intersection template or rules;
signal and right-of-way status;
Vehicle entry, departure and waiting;
Local traffic coordination near intersections.

Therefore, when a route task reaches an intersection, it cannot simply read a node and continue. It must pass the route direction, turn type, stopping distance and current traffic status to the relevant intersection logic.

P5 does not expand on the complete implementation of traffic lights or multi-vehicle scheduling, which belongs to the traffic series; this article only retains the interface relationship between routes and intersections:

The route provides “which connection needs to be passed”, and the intersection determines “whether it can be passed currently” when the intersection is running.

7.2 Speed area is runtime coverage, not path search

Road speed zones can change the speed constraints of a vehicle within a specific area, but it does not have to reconstruct the entire route. The route can still be the same, with the local speed limit and look-ahead distance changed.

Therefore, path geometry and driving strategy must remain separate:

Route description link;
Speed zone describes local constraints;
Driving strategy determines behavioral intensity;
The actuator determines the control volume.

If the path is searched again every time the speed zone changes, the system will mistakenly promote local constraints to global route changes.

7.3 Method of handing the route to the lower level

Route tasks can be provided to lower levels via follow route assistance:

Current local target;
Current cruising speed;
route width;
End distance;
Current intersection or lane context;
Whether to allow the search to continue;
Whether parking should be maintained.

The lower-level goal actuator then combines this information with local avoidance, traffic response, player input, and physics feedback. The route system should not directly override all inputs from the lower layer, otherwise the command contract of P3 and the policy boundaries of P6/P7 will be destroyed.

8. Player navigation and AI navigation share capabilities, but do not share life cycles.

8.1 What is shared is the road query capability

Players input destinations and AI vehicle cruises usually require:

the same road map;
Same set of path search capabilities;
Same road connection and intersection data;
Same route sampling basis.

But the route life cycle of the two is different:

Player navigation may be driven by map objectives, mission objectives, and player reselection; AI navigation may be driven by cruise missions, chase objectives, follow objectives, or script states.

Therefore, player navigation and AI navigation cannot be merged into the same task object just because both call path search.

8.2 Player targets updated more frequently

Players may continually change objectives, temporarily cancel navigation, switch missions, or enter new vehicles. Player route requests need more attention:

target version;
Request cancellation;
Late results;
Cleaning up old routes;
Current vehicle identity changes;
Transfer of control.

AI routes place more emphasis on target persistence, cruise mode and route extension. The two can share the underlying search service, but the upper layer must preserve different request sources and recovery semantics.

8.3 Player direction input should not trigger route reconstruction

P2 and P3 have been established: after the player input is formed through input routing and commands, the vehicle’s current control window is entered. When the player changes direction during the route, it does not mean changing the navigation goal.

If the player briefly bypasses an obstacle, switches lanes, or drives off the recommended route:

Local actuators can adjust movement;
The avoidance layer can change the instantaneous direction;
The route holding layer can observe deviations;
Replanning is only necessary when there is a deviation from the attainment conditions, or when the goal is no longer consistent with the old route.

This is key to the stability of the navigation system. The route is the mid-term goal, and the directional input is the short-term intention. The two cannot cover each other on the same layer.

9. The difference between recorded routes and ordinary road routes

9.1 The recorded route is not a path search result

Recorded routes typically contain route points organized by time or progress, speed information, width, loop mode, and end status. It can provide an explicit trajectory beyond the road query, but still requires converting the trajectory into a local target that the vehicle can currently consume.

Responsibilities for recording route tasks typically include:

Initialize route progress;
Find the starting segment based on the current position;
Calculate forward looking distance based on speed;
Refresh local targets and speed;
Processing loops and end points;
Select lower level actuators between different vehicles;
Maintain route progress in low detail.

It should not be understood as a new physical controller. Ordinary cars, helicopters, and airplanes may share the recording route packaging layer, but still end up in different motions to perform tasks.

9.2 Old Recording Adapter and Modern Waypoint Route Wrapping Layer

It can be abstracted from the distribution of related responsibilities that tasks related to recording routes exist in packages of different ages and responsibilities:

The old adapter plays closer to the pre-recorded buffer and is updated mainly around automotive targets;
Modern waypoint route packaging layer maintains route progress, target refresh and selects lower-level actuators by vehicle type;
Lower level car, helicopter and aircraft actuators still each have actual motion semantics.

This gives the player an important navigation principle:

Local avoidance solves short-term spatial conflicts; re-planning solves the problem of route layer failure. If every short-term obstacle triggers a global search, the system will generate a large number of asynchronous requests and the route will jitter frequently. If all obstacles are left to local execution, the vehicle may try again when the road structure has failed.

10. Boundaries of responsibilities in source code reading

Boundary between route layer and execution layer

The following conclusions are architectural abstractions based on source code structure, calling relationships and responsibility distribution, and do not represent the only design form in public implementation.

10.1 Global road query layer

It has a road node database, route search portal and related query data. It is not responsible for:

Mission phase of a certain vehicle;
The life cycle of the player’s destination;
Vehicle local target;
Vehicle steering and pedals.

10.2 Route Holding Layer

It maintains a vehicle’s route request, search assistance, node list, route extension, route re-planning and provides local targets to lower layers. It is not responsible for:

Write directly to physics;

Handle all local obstacles independently;
Enter the system on behalf of the player;
When running in place of traffic.

10.3 Route following assistance

It is responsible for route sampling, progress, lookahead and speed recommendations. It does not own the road map and does not determine whether the mission is completed.

10.4 Local target executor

It turns local targets into vehicle-consumable motion input while handling local traffic, object, and vehicle occlusions. It does not own global routes.

10.5 Strategy function

Driving personality only affects route execution as an external strategy input. Specific risk parameters and traffic strategies will be developed in P6. It does not own the route lifecycle.

Therefore, the main line of P5 can be summarized as:

The road query layer provides the world structure; the route holding layer maintains the vehicle route; the following auxiliary generates local targets; the actuator completes local motion.

11. Route failure and recovery

11.1 Empty route does not mean no destination

When the route search is empty, the system still needs to differentiate:

The target is invalid;
The starting point is invalid;
Road areas are not loading;
There is no available connection for the current model;
Search canceled;
The search has not been completed;
The result is replaced by a new request;
The route does not exist.

If all situations are mapped to “cannot find the way”, the upper layer cannot decide whether to wait, retry, switch navigation mode or end the task.

11.2 Recovery after the vehicle deviates from the route

After being off course, recovery strategies can be graded by degree:

Still within the route corridor, only partial targets are updated;
When the deviation reaches the threshold, reconnect to the current road;
The current road cannot be accessed, search again;
The target version has changed, cancel the old request;
If the vehicle is out of control or cannot be driven, it will be handed over to the recovery layer of P8/P9.

The route system is only responsible for judging and updating route relationships, and is not responsible for handling all physical out-of-control situations.

11.3 Late route results

Late results from asynchronous searches must be able to be interpreted and rejected. At least you need to record:

Request serial number;
target version;
Vehicle entity identity;
Route generation cycle;
Search mode;

Return results;
Reason for installation or rejection.

This ties directly into P4’s source of control handover: old control source releases, player takeovers, or entity migrations can all invalidate route results on return.

12. How does the route system maintain players’ continuous experience?

Players won’t see the route slots, asynchronous search, and route holding layers, but they will feel their results:

After selecting a destination, the vehicle will not lose its current status while waiting for search;
After encountering obstacles, the route will not be cleared for no reason;
After deviating from the road, the system will find a feasible access point again;
Changing direction input will not cause the mission objective to be reset;
After the target moves, the navigation will be updated instead of continuing to chase the old coordinates;
After leaving the vehicle, switching vehicles, or control source handover, the route relationship has a clear retention or end result;
When the vehicle enters the distant view and then returns, the route progress is still continuous.

These experiences are not provided by the GPS line drawing function alone, but are the result of multiple runtime layers maintained together.

There are at least four types of continuity that a route system really needs to maintain:

Destination Continuity: The current destination and target version are still valid;
Route Continuity: Old routes, new routes and route progress can explain the current status;
Entity Continuity: The route still belongs to the current vehicle instance;
Execution Continuity: Local targets are able to continue into the correct vehicle actuator.

As long as one of the layers is covered by the error, the player will feel that the vehicle “suddenly loses its direction”.

13. Three target changes cannot use the same update path.

The most common problem with the route system is that all target changes are regarded as “modifying the end point coordinates”. In actual runtime, at least three types of changes must be distinguished.

13.1 Target position change

The target entity is still valid, just its location has changed. For example, a player is tracking a moving vehicle, or a mission target is moving along a route. At this time, there is usually no need to destroy the entire task. You only need to update the target version and determine whether the current route can still be continued.

If the new location is still within reasonable proximity of the current route, the route holding layer can continue to consume the old route and update the target in the next re-planning window. If the target has left the original road network, road access needs to be re-established.

13.2 Target semantic changes

The task changes from “go to the location” to “chasing the entity”, or from “follow” to “reach the designated area”. These are not ordinary coordinate changes. Target semantic changes will affect:

Whether the target is allowed to move;
arrival conditions;
Whether the route can be extended;
Whether it is necessary to keep distance;
Whether crossing a specific road is allowed;
Vehicle status after the mission.

Such changes require a mission version update and cannot only cover the end of the route.

13.3 Target owner changes

When a player takes over an AI vehicle, a script takes over a player vehicle, or a network entity moves from one machine to another, the goal may still be the same, but the submission rights and consumers of the route have changed. At this point the route results must re-verify the vehicle entity, current task and control source.

This is also where P4 meets P5: a control-source handover can preserve the route while changing which source may submit, update, or consume route state.

14. From request to completion: the complete life cycle of a route

14.1 Request phase

The request phase only records the target and its source, and does not promise that the route already exists. The system needs to check:

Whether the current vehicle is still the subject of the request;
Whether the current control window is valid;
Whether the target has an available representation;
Whether there are old requests that have not yet been completed;
Whether the current task allows new requests to enter.

Requests can be delayed, merged, replaced, or denied. Rejection itself is also an observable result and cannot be silently discarded.

14.2 Access phase

The vehicle’s current position is not necessarily located on a road node. It may be parked in a parking lot, shoulder, ramp, mission site, or off-road area. Therefore, the search must first solve “how to enter the road network”, and then solve “how to reach the target along the road”.

The access phase may require:

Select the nearest road in the current driving direction;
Allow reverse access within a limited range;
Exit non-road areas via the local navigation mesh;
Waiting for road data to load;
Wait for drivable connection at low speed.

This is why target-navigation tasks often require dedicated search flags. They provide the start and end points for the global query layer while also specifying the vehicle’s road-access conditions.

14.3 Route generation phase

The route generation phase may return node lists, road connections, lane directions, intersection relationships and associated speed information. The route task needs to convert the results into its own route state at runtime, rather than letting the lower executor hold the query results directly.

This has two benefits:

Search results can be verified, cached and replaced;
The executor does not need to understand the global road map and asynchronous queries.

14.4 Installation phase

When installing a route, you need to check whether the result belongs to the current request:

Whether the request sequence number matches;
Whether the target version matches;
Whether the vehicle entity is still valid;
Whether the route is still accepted by the current task;
Whether the new route is empty;
Whether the old route needs to be retained until the switch is completed.

Installation is not a simple assignment. The new route may only replace the current route segment, or it may replace the entire route; it may retain the original goal, or it may re-establish the task because the goal changes.

14.5 Execution and Extension Phase

During route execution, the vehicle will not wait until all nodes are consumed before requesting the next segment. The route holding layer needs to extend or refresh the route in advance based on the current progress, speed and remaining length.

The timing of route extensions is affected by the following factors:

current speed;
The remaining length of the current route;

target distance;
The intersection ahead;
route width;
vehicle type;
Whether it is on a circular route;
Whether the current path area is about to leave the streaming range.

The “current segment” of the route and the “complete target route” are therefore two different objects. The former serves local execution, and the latter serves task semantics.

14.6 Completion, Pause and Cancellation Phases

After the route ends, the system needs to differentiate between:

The target has been reached;
Arrive at the area but still need to park;
The recording route enters the pause point;
Circular route back to the starting point;
The task was canceled by the script;
Target failure;
The route is not recoverable.

None of these states can be derived from “the current node is empty” alone. The completion of the route is only a geometric event, and the completion of the task also needs to combine the target conditions and task stages.

15. How route search parameters affect player experience

15.1 Current direction access

The vehicle may be driving on the road when the player first takes over the vehicle. A route search that completely ignores the current direction may select a road connection that requires an immediate U-turn. While the goal is correct, players will feel that the navigation is disconnected from the current state of the vehicle.

Therefore, target navigation usually needs to provide the current driving direction, road-access direction, and permitted U-turn range. These parameters do not control the vehicle directly; they affect the stability of the route result.

15.2 Lane and intersection selection

There may be multiple lanes and multiple exits on the same road. Route search can give connections, but the final selection requires a combination of:

Current lane;
Target direction;
vehicle dimensions;

Turning rules at intersections;
Whether crossing lanes is allowed;
Whether the road ahead has entered the intersection processing stage.

Route tasks provide structure and context; the intersection and local execution layers are responsible for honoring these constraints as intersections approach.

15.3 Large vehicles, trailers and special vehicles

Route geometry can be shared between different vehicles, but route interpretation cannot be identical. Large vehicles need to handle turns earlier, towed vehicles may require wider route corridors, and ships and aircraft do not necessarily consume road nodes.

P5 retains only the compatibility boundaries of the route layer:

Car routes can consume road maps and lane relationships;
Vessels need water routes or dedicated waypoints;
The aircraft needs three-dimensional targets and dedicated routes;
Recording routes can share progress and target interfaces, but the underlying executors are different.

The specific control laws are left to P8; this article focuses on how route data is organized and delivered.

15.4 Route Mode and Mission Mode

Route capabilities are available for cruising, going to target, chasing, following, and recording routes, but their update rules are different:

Cruising pays attention to route extension and traffic regulations;
Target navigation attaches great importance to the validity of the end point and arrival determination;
Chasing and focusing on target entities and dynamic re-planning;
Following focuses on relative distance and local target refresh;
Recording routes focus on progress, looping and time sampling.

If all patterns were written as a “navigation task”, the task tree would lose the ability to explain the route life cycle.

16. Three runtime cases

16.1 Player navigates to a fixed location

Players select a fixed location on the map. The system creates the target version, submits the route request, and installs the route after the query is complete. The vehicle continues to maintain the current control source and task relationship, and the route holding layer updates the local target based on the remaining distance.

When the player temporarily changes lanes, the local actuator only changes the short-term movement; when the vehicle returns to the route corridor, the route continues to be valid. If the vehicle deviation reaches the threshold, the system will re-find road access instead of treating every turn of the player as a new navigation target.

16.2 Player Tracking Moving Targets

The player’s target is a moving vehicle. The target location is constantly updated, but the task semantics do not change. Instead of destroying and rebuilding complete tasks every cycle, the routing system should differentiate:

Whether the target entity is still valid;
Whether the current route is still close to the target;
Whether the target movement exceeds the replanning threshold;
Whether the current route can still be used as short-term navigation;
Track whether distance and reach conditions change.

When the target entity fails, the task can end, switch targets, or enter search waiting. This result is determined by task semantics, and the route system only provides feasible path status.

16.3 Road blocked

The vehicle is traveling along a route and there is a roadblock, collision or temporary closure ahead. Local avoidance may first try to avoid within the current route corridor; if a feasible local direction cannot be found, the route holding layer will re-request a higher-level path.

This order is important:

First determine whether partial execution can be solved;

Then determine whether the current route needs to be partially refreshed;
Request global replanning last.

17. Minimum set of states that should be retained during implementation

P5 does not require the immediate implementation of a complete navigation system, but to preserve future compatibility, the route layer should at least be able to express:

17.1 Target state

Target type;
target entity or location;
target version;
arrival conditions;
Target validity period;
Whether to allow moving targets.

17.2 Request status

source of request;
Request serial number;
Generation cycle;
Search mode;
Current request status;
Reason for cancellation or substitution.

17.3 Route status

Current route version;
Route nodes or sampling segments;
Current progress;
Route corridor width;
Current local target;
remaining distance;
Whether extension is allowed;
Whether re-planning is needed.

17.4 Execution Delivery Status

Target point generation cycle;
Recommended speed;
Current intersection context;
Whether it is in parking state;
Whether it is covered by temporary actions;
Whether the lower executor accepts it.

This set of states is an analytical model rather than a final class design. Its purpose is to keep distinct life cycles from being compressed into a single “current route” field.

18. The boundary between P5 and subsequent articles

P5 needs to hand over the route to the execution layer, but does not expand all the responsibilities of the execution layer:

P6 discusses driving personality, risk parameters and traffic strategies;
P7 discusses local avoidance, collision prediction and immediate recovery;
P8 discusses how actuators turn commands into motion;
P9 discusses recovery after collision, injury and loss of control;
P11 discusses pursuit and event-driven dynamic control;
P12 discusses networking, replay, LOD and multi-vehicle continuation.

P5 only retains one interface conclusion:

The route system provides updateable target and path information; the execution system determines how to act in the current cycle.

19. From the source code call chain, how does the route pass down?

The value of reading source code lies less in memorizing class names than in confirming whether a chain of responsibility exists. The call chain that P5 focuses on can be abstracted as:

In this chain, each layer only consumes the semantics provided by the previous layer and should not directly rewrite the state across layers.

19.1 The route holding layer creates lower-level tasks, but it does not mean that the lower-level tasks own the route.

In the vehicle task factory, it can be observed that the route holding layer creates car target tasks or local target tasks. This creation relationship can easily be misinterpreted as “the lower task has all the driving logic”.

A more accurate explanation is:

The route holding layer determines the type of underlying tasks;
Route holding layer provides initial target and speed;
Lower-level tasks continue to receive updated local targets from the route holding layer;
The lower-level tasks are responsible for the motion execution of the current cycle;
The route holding layer continues to have route progress and re-planning conditions.

If the lower task exits, the route holding layer can recreate it; if the route fails, the route holding layer can reselect the local target or search mode. The life cycles of the two are not the same.

19.2 Low-level target tasks are not pathfinders

Automotive goal executors typically receive a position, velocity, or route segment context. It may perform:

Turn to target;
speed limit;
waiting for traffic;
Local handling of dynamic obstacles;
Arrivals and stops.

But it does not need to know the complete road map, nor does it need to maintain versions of the target entities. Putting the road search logic into low-level target tasks will give each local avoidance the authority to re-plan the global route, thereby destroying the route life cycle.

19.3 The task wrapping layer is the selector of the navigation mode

Cruise, Go to Target, Chase, Follow and Record Routes can wrap the same set of lower-level actuators, but the wrapping layer determines:

Which route data to use;
When to refresh the target;
Whether to retain the old route;
How to calculate forwardsight;
when to complete or pause;
Whether to allow low details to continue running.

Therefore, wrapper layers are not meaningless intermediate classes. It translates different target semantics into local targets that can be consumed by the same type of executors.

20. Switching between road routes and navigation grid routes

20.1 The road network is not the only pathway for all vehicles

Cars give priority to using road nodes and intersection relationships, but road paths may not be used directly in special scenarios:

The vehicle starts off the road;
The current road area has not been loaded yet;
The target is located in an area inaccessible by roads;
The mission allows for short-distance non-road movement;
There are currently no available connections to the road network;
Vehicles belong to vehicle families with different movement spaces.

At this time, the route holding layer may choose a navigation mesh or a local spatial query as an alternative. Alternative routes do not mean that the car actuator is changed to a pedestrian actuator, but that the route data source changes, and the lower layer still needs to get local targets suitable for the vehicle.

20.2 Alternative paths cannot bypass vehicle semantics

The navigation mesh provides feasible spatial connections and does not necessarily include lanes, road priorities, intersection rights of way, and vehicle speed zones. After using the navigation mesh, the route holding layer still needs to be added:

The width through which vehicles can pass;
car body orientation;
Target access direction;
Current speed limit;
Whether reversing or turning is allowed;
Whether it is necessary to return to the road system.

Therefore, the navigation grid is a replacement for route sources, not a replacement for vehicle driving semantics.

20.3 Route mode switching requires versioning

When switching a road route to a nav mesh route, or reconnecting to a road from the nav mesh, the route mode and route version must be updated. Otherwise old route results may continue to be consumed in the new mode.

The route version needs to be able to explain:

Whether the current route comes from the road map or the navigation mesh;
When the current mode is established;
Why the old mode exited;
Whether the new mode allows the restoration of old routes;
Which mode the current local target belongs to.

This is consistent with P4’s source-of-control versioning principle: late results cannot automatically cross boundaries after a state switch.

21. The seam between vehicle route and intersection operation

21.1 Routes only provide traffic directions

Before the route reaches the intersection, the vehicle already knows the next road connection, but this does not mean that it can enter the intersection immediately. The intersection needs to be processed when running:

Whether the current vehicle has been registered;
Whether the current phase is allowed to pass;
Whether there is a waiting vehicle ahead;
Whether you need to give way when turning left or right;
Whether the vehicle has crossed the stop line;
When a vehicle is removed from the intersection member set.

Route tasks should not directly modify the right-of-way. It only provides directions and route connections that vehicles wish to pass; the intersection system decides to allow, wait, or re-enter partial parking based on real-time status.

21.2 How does the vehicle task consume intersection results?

After the route holding layer receives the intersection constraints, it may adjust:

local targets;
Forward viewing distance;
Recommended speed;
stop position;
Follow-up route segments at intersections;
Whether the current route requires waiting.

The local actuator then converts the parking or low-speed target into specific control. This way, intersections are not written directly to the vehicle physics, and vehicle tasks do not bypass the intersection state.

21.3 Waiting at the intersection is not a route failure

The route remains valid while the vehicle is waiting at the intersection. Routes only need to be replanned if road connections fail, goals change, or missions are cancelled.

If waiting is regarded as a route failure, the vehicle will rebuild the route in each red light cycle; if all stops are handed over to local execution without recording the intersection context, the vehicle may accelerate again in the next cycle. The waiting state needs to be an interpretable intermediate state between the route and the intersection.

22. Local geometry and vehicle size of route following

22.1 One point is not enough to describe how a vehicle passes

Route sampling can return a target point, but large vehicles, trailers, or narrow road scenarios require more context:

Current route segment direction;
route width;
Lateral tolerance of route segments;
front curvature;
Finish line direction;
The current direction of the vehicle;
Body length and width;
Whether deviation from the centerline is currently allowed.

Therefore, route-following assistance usually returns a set of local geometric information rather than a single point. The local actuator uses it to determine how to approach the target, while the avoidance layer evaluates whether a bypass is available.

22.2 The forward looking distance is not a fixed constant

Forward looking distance can change with speed and scene. At high speeds, the route holding layer needs to provide the front curvature earlier; when approaching a sharp turn at low speeds, it needs to avoid the target point being too far away, causing the vehicle to cut corners in advance.

Vehicle size also affects forward vision. If a large vehicle only follows the target point of a small vehicle, it may cross the boundary when turning at an intersection. The route layer at least needs to pass the vehicle category or body size to the sampling logic so that the local target can adapt to the current entity.

22.3 Route width does not allow arbitrary drift

The route corridor width can help the actuator judge whether the local deviation is still within the acceptable range, but it is not equivalent to unlimited free space. Route width may come from:

Road lane width;
Recording route width;
The scope of the task allowed;
vehicle type;
Local road restrictions.

The actuator still needs to consider obstacles, traffic rules and physical conditions to decide whether to accept the deviation. The route layer only provides boundaries and context.

23. Reduce planning, merge and cancel

23.1 Replanning cannot be directly triggered by each event

There are many events in the open world: target movement, collisions, intersection waiting, speed zone changes, entity loading, player steering. If each event submits a path search immediately, the asynchronous queue will generate a large number of requests that cover each other.

The route holding layer needs to convert the event into a re-planning intention, and then decide based on the current status:

Search now;
Delay until next safe window;
Merge into existing requests;
Continue to consume the old route;
Cancel old requests;
Only refresh local targets.

23.2 Reasons why merge requests need to be retained

When multiple events are combined into one search, only the last triggerer cannot be retained. Keep at least:

original target;
Current target version;
Collection of triggering reasons;
Request priority;
Whether to allow the old route to continue;
Installation conditions for new results.

In this way, only during diagnosis can we know whether a route reconstruction is caused by target movement, road failure or control source handover.

23.3 Canceling the result also requires entering the state machine

Cancellation paths include:

Player cancels navigation;
Mission objectives are replaced by scripts;
The vehicle leaves the current entity;
Changes in network authority;
The search results have expired;
The vehicle enters an unnavigable state.

The search slot can be released after cancellation, but the current executable route cannot be cleared unconditionally. The system needs to decide whether to keep the old route, enter a parking state, wait for a new target, or end the mission.

24. P5 engineering verification issues

P5 verification should assess route lifecycle and responsibility boundaries, rather than merely checking whether a line appears on the map.

24.1 Request consistency

Whether the new target generates a new version;
Whether old requests will be rejected when returned;
Whether there are still installation results after canceling the request;
After the vehicle entity changes, whether the route results still belong to the current entity.

24.2 Route persistence

Whether the route can be extended as needed when it is not completed;
Whether the old route can continue to be consumed while waiting for the new route;
Whether to differentiate between extension, arrival and failure when the node is exhausted;
Whether route progress is maintained after low detail restoration.

24.3 Executing Delivery

Whether the local target belongs to the current route version;
Whether the recommended speed has a generation period;
Whether the old target will not be overwritten when waiting at the intersection;
Whether the route layer enters the interpretable state when the lower executor rejects it.

24.4 Task Boundaries

Whether player input changes will not directly rebuild the route;
Whether local avoidance will not modify the global target;
Whether route failure will not disguise itself as physical failure;
Whether physical loss of control will not be mistakenly regarded as the route does not exist.

25. A route is a recoverable set of relationships, not merely a drawn line.

The stability of player navigation comes from relationship continuity, not from routes being drawn finely enough. Routes need to retain at least four types of relationships:

-The relationship between goals and tasks;

The relationship between vehicles and route versions;
The relationship between routes and road data;
The relationship between local goals and execution cycles.

When the vehicle switches control sources, the route can continue to exist, but the submitter changes; when the vehicle enters a low-detail state, the route can stop partial execution, but the progress still needs to be saved; when road data is unloaded, the route can wait temporarily, but the target relationship cannot be misjudged as ending.

This is why the route state needs to be restorable. Restoration does not necessarily mean copying the previous frame as is, but rather reinstalling a semantically equivalent route based on the target version, entity identity, and current road status.

26. Route diagnosis should explain “why to continue” and “why to stop”

When a routing system fails, recording the current location and destination alone is not sufficient. The diagnosis needs to be able to answer at least:

Which request the current route belongs to;
Whether the current request is still valid;
Why the old route was retained;
Why the new route was rejected;
Why the current node is not extended;
Why the local target is not updated;
Is the vehicle waiting for road data, or has it entered a mission and failed?
Whether the lower executor rejects the target, velocity or the entire task.

This information should be part of the route status, not a log added after the fact. Only in this way, when the player sees the vehicle parked in place, can the system distinguish between “waiting route”, “waiting for intersection”, “target failure”, “actuator rejection” and “physical status unavailable”.

27. Core migration inspiration of P5

When migrating this mechanism to another engine, preserve the following responsibility boundaries rather than any original class name:

Separate global road data and bicycle route instances;
Route requests have version, sequence number and cancellation semantics;
The route holding layer is separated from the local executor;
Targets, routes, local targets and control commands have different life cycles;
The route can be restored in asynchronous search, streaming loading, control source handover and low detail state;
Route failure, waiting, completion and cancellation have different results;
Changes in player input will not directly destroy mission objectives;
Local avoidance will not cover the global route without permission.

The focus of migration is to preserve responsibilities and timing, rather than literally copying the type hierarchy in the source code to the target engine.

28. Several common misunderstandings in route execution

28.1 Treat GPS line as vehicle route

The navigation lines on the map are for players to understand, and the vehicle routes are for runtime execution. The former can smooth, simplify and delay the display; the latter must carry nodes, road connections, progress, speed and failure reasons. Both can come from the same target, but cannot share the same lifecycle object.

28.2 Treat asynchronous search as a synchronous function

Route searches may wait for road data, routing services, or target entity status. If the caller assumes that the query will complete in the current cycle, it will misinterpret “wait” as “no route” and resubmit the request in multiple cycles. The correct approach is to retain the request status, verify the version when the results arrive, and then decide to install or reject.

28.3 Directly hand over route nodes to direction control

The nodes only describe the path structure and do not contain all the constraints of the current vehicle. Vehicles also need to consider speed, body size, intersection access, local obstacles and driving strategies. Overriding the steering input directly with the node direction bypasses the responsibility boundaries of P6, P7, and P8.

28.4 Treat replanning as a failure patch

Replanning is a normal route life cycle. It can be triggered by target movement, road loading, route extension, player deviation, and intersection status. The system should explain the triggering reasons and control the frequency of requests, rather than lumping all changes into a “pathfinding failure” branch.

28.5 Equating route completion with task completion

When the route reaches the end, it only means that the geometric path has been consumed. The vehicle may also have to stop, wait for task confirmation, approach a moving target, or switch to a new control task. Only when the target conditions and task stages are met at the same time can the task enter the completion state.

29. Minimum observable interface for route data

In order for the routing system to be verified, the runtime needs to expose at least several types of observable states: current target version, current route version, route progress, current local goal, search request status, reason for the latest replanning, route installation results, and acceptance status of the underlying executor.

These states do not need to be exposed directly to the player, but should be able to be read in a debug or test environment. This breaks down “the vehicle is not moving forward” into localizable issues: is the target valid, does the route exist, is the route waiting, is the local target updated, is the actuator rejecting, or is the physics preventing movement.

Observability should also cover temporal relationships. Each route result should be accompanied by a generation cycle and request sequence number; each local target should be traceable to the route version; and the reason should be retained for each rejection. Otherwise, late results, old target overrides, and entity switching issues that are most difficult to handle with asynchronous routing systems will all end up manifesting themselves as an unexplained “vehicle stalled.”

P5 therefore does not understand navigation as a map component, but as a verifiable data chain when the vehicle is running: the target generates a request, the request obtains the route, the route generates a local target, the local target enters the actuator, and the actuator drives the next route update through feedback.

30. The last layer between the route and player perception

What the player perceives is not the route version and search status, but whether the vehicle still understands the destination. Route updates should try to avoid unreasonable emergency stops, repeated U-turns and target jitters; route waiting should have stable local behavior; after re-planning is completed, the current target should be replaced smoothly.

This requires the route layer to maintain motion continuity while updating the geometric path. The new route can change the future target, but the current speed, parking status and control source should not be unconditionally reset. What the route system ultimately delivers is “next step executable navigation context” rather than a set of coordinates that are divorced from the current vehicle state.

The stability of the route does not mean that the route will never change. Instead, routes can be updated continuously, as long as each update accounts for the relationship between goals, versions, progress, and execution context. What the player sees is the vehicle continuing to move toward the goal; what the runtime maintains is a future that is still valid in a changing world.

In subsequent chapters, routes continue to be connected to driving personalities, local risks, actuators, and physics feedback, but none of these layers should in turn take ownership of the route. P5’s responsibilities end here: save the target semantics, maintain the route life cycle, generate local navigation context, and pass the results to the next layer.

Therefore, this article treats GPS, path search, route following and re-planning as one vehicle-runtime chain: the goal determines search semantics, the search generates route state, the route state generates the local target, and local execution plus environmental feedback determine the next route update. Only within this loop does the player’s destination become part of the vehicle’s continuous operation.

This closed loop also determines the engineering boundaries of P5: the route system does not directly write steering, pedal or physical states, nor does it rewrite player input into new navigation goals. What it provides is trackable, replaceable, and restorable route context.

Conclusion: The player gives the destination and maintains an executable future during runtime.

Players simply select a spot on the map or continue along the path. When the vehicle is running, it needs to maintain goals, road maps, asynchronous requests, route slots, intersections, speed zones, route progress, local goals and executor boundaries.

The core of P5 is the runtime process that keeps a navigation route valid:

The target is not the route; the route is not the local target; the local target is not the final control command.

There is clear ownership and lifecycle between them:

The global road query layer provides road structure;
The route holding layer maintains route requests and re-planning;
Route following assist converts the route into a local target;
The local actuator delivers the local target to the vehicle motion layer;
Traffic, strategy, avoidance and physics provide constraints and feedback.

Open-world navigation is therefore a runtime relationship that explains the vehicle’s next behavior, not a one-time search result.

P1 solves how the player obtains the driving control window; P2 solves how the input enters the vehicle; P3 solves how the input forms the driving command; P4 solves how the control source is handed over; P5 continues to solve:

How to keep the destination specified by the player as an executable route in a constantly changing world.

The next article will go into the driving behavior itself: how different drivers’ risk preferences, speed choices and traffic strategies change the way the same route is performed after the route has been given a goal.

Series navigation

P4: AI Control Handoff · P6: Driving Strategy and Risk Models