Implementing the City Simulation Runtime in UE5: Task Execution, Scripted Commands, and Knockdown Recovery

A scripted character is told to meet beside a vehicle. It must navigate around a barrier, stop beside the vehicle, and report completion. A hold command must preserve the destination; a redirect must discard the old route. In another scene, a civilian flees a burning object, is knocked down by a second impact, and continues escaping after recovering. Task intent must survive changes in execution while terminating correctly on failure or cancellation.

The previous article, Implementing the City Simulation Runtime in UE5: Pedestrian Spawning, Retirement, Reuse, and Local Avoidance, covered how pedestrians are created, retained, retired, and reused. This article follows active pedestrians through rendezvous, scripted commands, escape recovery, and reassignment after failure. The world retains the entity; scene objects supply destinations and the physical environment. The focus is the state held by task intent, movement execution, and body control, and how results pass between them.

These scenes come from an existing UE5 prototype. The implementation described here is fixed to the delivered source snapshot, runtime records, and continuous engine recordings; later workspace changes are excluded. The prototype implements a bounded directive parent task, native movement and path requests, a finite escape policy, and safe handoff after physical knockdown. A complete polymorphic task tree, environmental perception, damage system, and full movement repertoire are not covered by this implementation and its tests. Getting up uses an explicitly labeled pose-blend placeholder, without an authored get-up animation.

Intent and execution in a rendezvous task

The rendezvous clip shows uninterrupted execution: the character goes around a barrier, stops beside the vehicle, and then completes the parent task. The vehicle is an actual static scene object. The character approaches a point beside it; vehicle entry is not shown.

Video 1: Approaching the rendezvous object, approximately 11.53 seconds. Continuous PIE footage; the object position and barrier participate in actual queries. Movement returns Arrived after stopping, then the parent completes. No moving-target tracking or vehicle entry is demonstrated.

Intent must outlive an individual path

Meeting beside an object is persistent intent. It exists before a path returns and remains valid through turning, obstacle avoidance, waiting, and approach. Paths are execution data that new obstacles or changed body positions can invalidate. Equating intent with the path array would lose the goal whenever a query was canceled. Letting the executor choose another object would remove the script’s authority over failure decisions.

The parent stores the source entity, session, destination, accepted-command count, failure count, and parent-task state. Movement stores position, heading, goal, path points, corner index, query generation, motion state, and blocking timers. Both contain Goal to verify that execution still belongs to the same intent, not to select destinations independently.

Animation and physics have separate responsibilities. Presentation reads a clip and sample time for starting, walking, stopping, and turning; native execution commits normal displacement. During knockdown, physical feedback supplies position and walking loses writing permission. Task lifecycle determines whether intent survives, independently of the animation playing.

State or record Owner State retained across updates What ends or changes it
Rendezvous directive Directive parent Source, session, goal, commands and failures Completion, cancellation, lost eligibility, or redirect
Movement task Pedestrian movement executor Goal, actual position, path, corner index, motion state Arrival, failure, cancellation, or new goal
Path request Navigation service and host Handle, generation, pending result Return, cancellation, invalidation, or generation change
Safety response Event-consumer parent Threat source, tag, destination, response state Safe arrival, failure, cancellation, or source invalidation
Body recovery Independent recovery leaf Session, physical age, stable time, pose progress Safe transition completes; does not decide task resumption
Motion presentation Pose evaluator and proxy Clip, sample time, blend state Native motion updates or physical recovery
Contents
Ownership of intent, movement, recovery, and animation
Figure 1: Responsibility diagram. Connections show data consumption, not a universal task tree covering every character behavior.

Task source and session identity

The vehicle determines the destination; the source identifies who issued the directive. The entry point creates a world-owned logical source and records task type, source, script command, and session tag in the primary slot. Hold, continue, and redirect retain parent identity. A new query does not start a new task session.

Command checks include task tree and priority position, type, owner, script flag, command type, and session tag. The parent must remain active and its Goal must agree with movement. A pedestrian handle alone does not authorize changing its task.

Another source’s active or pending primary task prevents installation. Occupancy, vehicle intention, and entry/exit interaction also prevent ordinary rendezvous movement. Cancellation closes only matching parent and movement tasks, preserving external state rather than clearing the tree to regain control.

These are explicit sources and bounded sessions with locally generated tags, not a complete script VM or global generation system. Cross-host ordering, replication, arbitrary task cloning, and script-resource lifetimes remain separate work. Startup does not roll back every host-side effect. Failure handling must distinguish cancellation at the outer event entry from installation of the parent task.

Converting a scene object into a path goal

A vehicle center may be inside collision geometry and unsuitable for standing. The entry point accepts an actual object and local approach offset, reads its transform at command time, and converts the offset into a world goal.

goalWorld = objectTransform.TransformPosition(approachOffsetLocal)

The transform includes translation, rotation, and scale; a fixed world vector is insufficient. The delivered vehicle asset faces local +Y and uses offset (-200, 0, 0) cm. This locates a point beside this asset; -X does not define the rear of every vehicle. The vehicle stays stationary and its command-time transform resolves the request.

The entry point receives an Actor, but movement stores a world position. Later vehicle movement does not automatically update it. Following requires validity checks, sampling or prediction, re-request timing, and changing arrival conditions. This clip verifies static-object approach and stopping, excluding pursuit and entry.

A valid object does not guarantee a usable path

The outer entry checks existence, world membership, destruction state, offset, and pedestrian index. These checks permit a goal attempt; projection, connectivity, and body clearance follow later.

RequestGoal advances query generation, stores the goal, clears path and corner index, resets motion and blocking records, and enters pending-query state. It removes timed standing and command hold and resets motion. New execution updates Goal, path, and progress together.

The host separately stores queued query handles. AbortQuery cancels the service handle and removes the host record; generation protects result consumption. Cancellation does not imply every already-produced result has disappeared. Acceptance still rejects generation mismatches.

The neutral summary below omits index, source, and finite-value checks; it cannot replace the full function:

replaceGoal(newGoal):
    cancelOutstandingQuery()
    generation += 1
    goal = newGoal
    clearPathAndProgress()
    clearCommandAndTimedHolds()
    needsPath = true

acceptPath(reply):
    if reply.generation != generation or !pathPending:
        return StaleReply
    pathPending = false
    if reply.failed or reply.points.empty or endpointOutsideTolerance:
        movement = Failed
    else:
        installPath(reply.points)
        movement = Walking
Object snapshot, offset, generation, and arrival checks
Figure 2: Configuration and mechanism diagram. The snapshot supplies a goal; results have independent identity and integrity checks. Endpoint acceptance and actual arrival use different geometry.

Path endpoints and arrival use different tests

pathEnd.Equals(goal, 15) requires every XYZ component difference to be no greater than 15 cm, defining an axis-aligned region. Final arrival requires three-dimensional pedestrian-to-Goal distance no greater than 15 cm. Equal values describe different geometry.

An accepted path does not finish execution. The character follows it, passes the final position check, and, when enabled, finishes its stopping phase before publishing Arrived. An accepted endpoint does not permit arrival from farther away; a stopping pose alone does not establish world-space arrival.

The run records goal (10930.00, 14050.00, 25.00) cm and position approximately (10930.83, 14046.32, 25.00) cm, consistent with tolerance. Parent session is 1, command count 1, failure feedback 0; stopping precedes native arrival. These describe this run, not universal parameters.

Connecting tasks, movement, and results within an update

A UE host advances native state. Actors provide objects, physics, and an update entry; world entities retain identity and slots, while native execution retains paths and motion. This entry point uses neither a UE Behavior Tree to replace the parent nor NavigationSystem/Recast as query authority. The native service handles connected surface projection and requests. Navigation generation is outside this article; its request interface with tasks is the focus here.

Update order determines when results can be consumed

AdvanceWalk processes recovery, directive parents, and safety responses, then reconciles relationships to determine movement eligibility. Turning and actual movement follow, then navigation and new query submission. Reconciliation runs again before safety responses and directive parents consume results.

The early parent pass maintains intent and eligibility; the later one reads new arrival or failure. A successful movement return and parent completion are recorded separately. Knockdown requires recovery and reconciliation to revoke position authority before movement executes.

Navigation processes existing work and available results before queuing new requests. Submission does not overwrite state through an immediate inline callback. AcceptPath checks generation and pending status. The queue supports cancellation. Background execution and other asynchronous scheduling models are outside this implementation.

Recovery, parents, reconciliation, movement, and results
Figure 3: Call-order summary for this entry. The host arranges reads and submissions while native state retains intent and results. It does not establish a project-wide central scheduler.

Reconcile position authority before suspending movement

Reconciliation checks movement ownership, higher-priority movement, external primary tasks, suppression, vehicle relationships, and recovery. Blocking suspends movement, zeros speed, and reads position from the logical entity. Entering suspension cancels the query and advances generation; a pending task retains its need to request again.

When eligibility returns, actual heading is read, motion reset, and replanning starts from current position rather than an old path index. Physical rolling may preserve the destination while invalidating the old start.

A directive or safety parent passing full identity checks is recognized as this movement’s legitimate parent; other primary tasks suspend it. This exception checks type, source, and session, not merely the existence of an active primary task.

LastChildGeneration records the last observed movement generation for diagnostics. It is not an independent token every command must submit. Control also depends on parent identity, ownership, and goal agreement. LastChildGeneration does not provide a global version check. A future unified arbiter would need to review these interfaces.

What hold, continue, and redirect change

The next clip follows commands within one session: position is retained during hold, Continue resumes movement, and Redirect sends the character to the alternate vehicle.

Video 2: Scripted hold, continue, and redirect, 15.40 seconds. Commands share one parent session. The demonstration sends Continue after approximately 3.5 seconds; runtime hold has no countdown. Objects remain stationary, and redirect takes a new transform snapshot.

Hold retains the goal; Continue releases that hold

Hold is accepted while the parent is traveling and retains control eligibility. RequestCommandHold enables the hold, clears speed and suggested turning, and requests direction reevaluation. It does not advance generation, modify Goal, or clear the path. The parent enters WaitingForSignal and records the command.

A queued result can still arrive and pass identity checks, but command hold prevents execution. A successful query does not release the hold. The exit condition belongs to the directive layer rather than being inferred from speed becoming positive.

Continue requires the same parent in WaitingForSignal. After control checks, it clears command hold and returns to Travelling. It does not restart movement through RequestGoal or advance generation. Subsequent motion still checks the scene and follows its replan policy; retaining a path does not bypass new obstacles.

The record covers approximately 3.4667 seconds of held samples with 0 cm root drift. Continue retains generation and movement follows. Command times, samples, and captions have discrete sampling differences, so the external wait is described as approximately 3.5 seconds, not a runtime countdown.

Redirect replaces execution without restarting the session

Redirect cancels the outstanding query handle, updates parent Goal, and calls RequestGoal for the new approach point. Generation advances, path and progress clear, and command hold and timed standing are removed. The entry’s movement slot is reactivated. The parent retains its session, increments command count, and returns to Travelling.

Redirecting one script intent therefore differs from another task taking over. The former retains session while replacing query generation; the latter establishes new parent source and session ownership. Final destination alone cannot distinguish them; logs need business and execution identities.

A late old result cannot install its path after redirect. Acceptance rejects a generation mismatch. This protects path consumption, without claiming animation notifications, scene callbacks, and all future events carry the same token. The conclusion applies to the implemented request chain.

Session and query effects of commands
Figure 4: Command mechanism diagram. The parent session persists while path generation changes with new requests. Completion and failure are execution results, not fixed-duration outcomes for every command.
Operation Parent session Goal and path Query generation Release condition
Hold Retained Retained Retained Same valid task receives Continue
Continue Retained Original destination retained Continue itself does not advance it Other constraints also permit motion
Redirect Retained New goal; old path cleared New goal creates a generation Query and motion checks pass
Timed standing Intent not replaced Retained Standing itself does not advance it Runtime deadline reached
Body/relationship suspension Retained while valid Goal retained; execution rechecked Old request invalidated; replan on resumption Body and relationships allow execution
Cancel Intent ended Old route no longer executes Old results invalidated New task requires authorization

Cancellation handles only this entry’s tasks

Cancel ends the directive without repeating work for completed, canceled, or unstarted parents. Otherwise it checks movement ownership and goal agreement before withdrawing the query and movement. The primary slot is also terminated only after ownership checks.

If an external task has acquired movement, ending the old parent preserves that slot. Retirement, vehicle relationships, and directives inspect state at different stages; cleanup must respect ownership. These are bounded matching rules, not universal references tracing arbitrary hierarchies.

Cancellation, temporary movement ineligibility, and parent completion need separate records. Cancellation must not appear as arrival, and suspension must not imply the business task ended. The recovery supplements test this directly: the body may recover without restoring a canceled goal.

Travel, hold, and redirect sampled from the same clip
Runtime stills 1: Independent frames from Video 2, preserving original captions and scene. They identify stages; goals, generation, and session come from same-run records. A still cannot establish the cause of waiting. Source captions remain in Chinese.

Different causes of stopping need different release conditions

A stationary character may be waiting for a command, standing for a limited time, blocked, controlled by a higher-priority task, or physically knocked down. Collapsing them into one Paused state and clearing it on any recovery event would release constraints that should remain.

Command hold, timed standing, and body suspension retain separate state. Movement first checks body and relationship suspension, during which native walking does not advance. Otherwise it checks command hold, timed standing, and movement lifecycle. With a motion profile, a stopped character can evaluate a stop-tail pose without translation.

A release event removes only its own constraint

Continue releases command hold without clearing recovery. Body recovery does not issue Continue for the script. A standing deadline clears only its own timing state, not another source’s task. Each constraint needs an owner and release condition to explain combined stopping causes.

This separation exists in update structure, but tests have a narrower scope. Main clips show command waiting and body recovery separately; supplements test cancellation and blocked standing. They do not exhaust all combinations of holds, takeovers, vehicle relationships, and body states. Separate storage reduces interference without establishing acceptance of every combination.

Independent release conditions for stopping states
Figure 5: State and lifecycle diagram. Similar stationary images can have different causes. Releasing one condition permits only that part; other relationships remain checked.

Waiting does not implicitly create a timed task

Reference mechanisms distinguish finite pauses and persistent standing. This entry point uses Hold/Continue for business waiting; native timed standing separately records a deadline. Their visual results resemble one another but their contracts differ: one waits for another decision maker, the other ends through runtime time.

An automated counterexample advances simulation for 10 seconds without Continue. Position and generation stay unchanged and the parent remains WaitingForSignal. This supports absence of automatic release at the clip’s wait duration, not an infinite-duration formal proof or validation of every external Continue producer.

A scene can schedule Continue so the demonstration reaches later stages. That is an input plan. Encoding its timing into hold would change the contract to automatic resumption. Likewise, the delay before reassignment reflects upper-layer input rather than a hidden movement fallback policy.

How motion data constrains path execution and step distance

Movement involves more than interpolating path points. Characters face a direction, start and loop, then decelerate within remaining distance. Resources provide shape and rhythm; surfaces, bodies, and obstacles determine whether each step is accepted.

Resources provide data; native execution chooses sample time

The isolated resource adds running start, loop, and stop clips alongside idle and turning on the same skeleton. An isolated FBX pipeline imports them without an entire external gameplay framework. Loading validates mesh, skeleton, clip count, and curve durations, rejecting incompatible configuration.

Extraction divides each clip into 120 intervals and stores 121 samples including endpoints. Forward data measures root horizontal displacement from the first frame and applies a running maximum for monotonicity. It does not integrate frame-to-frame trajectory length. This works as a distance parameter for these predominantly forward clips; backward or looping trajectories require reassessing extraction.

Turning accumulates shortest angular differences between neighboring root rotations and normalizes by total turn. Runtime multiplies progress by actual current-to-target heading difference. A nominal 90 or 180 in a clip name is not every task’s logical rotation.

Each character owns motion phase, clip time, cycle time, and motion serial. Escape changes that character’s running profile and speed without putting state into shared resources. Other entry points and population consumers retain their policies; this does not migrate all population motion to one system.

Starting and stopping derive budgets from distance curves

Let d(t) be sampled distance, scale its scale, and speed desired speed. Start and moving-stop phases propose a time using playback rate, then compare curve distance with the speed budget:

playRate = clamp(speed / referenceSpeed, 0.1, 2.5)
candidateTime = min(duration, clipTime + dt × playRate)
curveDistance = max(0, d(candidateTime) − d(clipTime)) × scale
distanceBudget = max(speed, 0) × dt

If curve distance exceeds budget, bounded binary search shortens the time proposal; the current count is 12 iterations. Pose time and associated distance are constrained together, preventing acceleration peaks from proposing excessive steps. This adjusts native motion time, rather than letting animation move the root and inferring task progress afterward.

Loop movement generates distance from desired speed and advances sampling using accepted travel:

cycleTime = fmod(cycleTime + acceptedDistance / referenceSpeed, cycleDuration)

acceptedDistance is the positional change that passed checks. Idle or settling poses during holds provide no fictitious loop travel. Start/stop phases may, however, update motion time while proposing a step. There is no promise of atomic rollback of all motion fields on rejection. Blocking triggers stopping presentation; position and loop travel consume only accepted displacement.

Reference running speed is approximately 594.324 cm/s; task speed is 330 cm/s, giving nominal playback approximately 0.555. This relates resource distance to speed, not a guarantee that each step achieves that ratio: turning, endpoints, or obstacles may shorten or prevent displacement. A teaching timestep dt=1/60 s gives a 5.5 cm budget, without claiming real-time video execution at 60 fps.

Curves, budgets, accepted steps, and poses
Figure 6: Formula and consumer diagram. Curves contribute to native budgets, scene checks constrain movement, and pose evaluation reads results. This is the current adaptation, not a complete motion network or arbitrary-terrain system.

Goal stopping differs from command stopping

A moving stop begins when remaining route distance enters the authored stopping range. The ratio of remaining distance to authored stop distance becomes this stop’s scale. Scaled increments carry movement toward the endpoint, where stopping must finish before Arrived.

A hold or obstruction cannot consume the full stopping distance. Advancing because a clip requires room could cross a barrier. Hold selects the stop tail, finishing pose without translation. Its start is where remaining curve distance approaches zero, approximately 0.7 seconds in this resource. This is clip time, not hold duration.

Large heading changes enter turn clips: sampled angular progress updates heading without translation. Smaller moving turns use a rate limit; insufficient alignment can also produce rotation-only steps. Blocking/no-progress timing distinguishes intentional turning from a stuck path.

Surface and body checks precede position submission

Motion proposes direction and distance. The executor projects the candidate and checks traversability and body clearance. Finite local directions are evaluated; beside static blocking, a sidestep must leave an onward local passage. First steps and post-corner first steps use the same filtering, preventing repeated path acquisition from advancing incrementally into an obstacle.

Rejection leaves position unchanged while timers and direction reevaluation continue. Acceptance writes position, measured speed, and distance. Longer elapsed intervals split into movement substeps no greater than 0.05 seconds, rather than one unchecked displacement for a long render frame.

Pose evaluation uses explicit sample time, ignores engine Root Motion, and removes execution-root transforms from ordinary poses to avoid double application. Start/loop/stop display blending preserves skeletal continuity but cannot change native position or arrival.

Who chooses safety when the burning object appears?

The scene begins with ordinary walking. Fire triggers running, then a second impact causes a physical knockdown. Recovery is followed by continued escape and safe stopping. The clip labels the pose placeholder separately from real Chaos knockdown.

Video 3: Continuing escape after knockdown, approximately 11.53 seconds. Fire and impact inputs are scripted; runtime selects the destination. The same response persists. Getting up uses the labeled pose placeholder, not complete perception, fire damage, or an authored get-up animation.

A threat position is not an approach goal

Rendezvous supplies a point to approach; escape begins with a threat to avoid. Sending the threat to approach would move toward danger. The entry point first invokes a policy using current position, threat, and safety distance to select a reachable endpoint, then passes it to event response and movement.

This policy sits between intent and navigation. The script supplies threat and distance, not refuge B; selection checks validity and reachability. It is a bounded prototype policy, not the full reference escape search. The response retains the selected endpoint, without reevaluating all candidates each update or continuously tracking a moving threat.

Filter candidates before scoring distance and route cost

Initial direction is the horizontal unit vector away from the threat. Coincident horizontal positions use an explicit default forward direction. This avoids zero-vector degeneracy without inferring an optimal direction from surrounding threats.

away = normalizeXY(start − threat)
candidate = start + rotateAroundUp(away, angle) × candidateLength

Angles are 0°, ±30°, ±60°, ±90°; lengths are safeDistance+100, safeDistance+300, and safeDistance+550 cm, yielding at most 21 combinations. The count follows current enumeration, not complete coverage of direction and distance; changing parameters changes it.

Projection onto the native walking surface must have horizontal error no greater than 50 cm. This prevents a distant walkable region from replacing an invalid candidate. Endpoint space must be clear and threat distance strictly greater than safety distance plus 30 cm. A complete path is then required, with at most 2048 polygon expansions per candidate.

Precheck is bounded and synchronous. Formal execution separately obtains a path through its request service, establishing query identity and results. Both use native query capability, but selection cannot replace execution-time checks. New obstacles can still cause failure.

Qualified candidates use:

routeLength = sum(lengthXY(path[i] − path[i−1]))
score = distanceXY(projectedCandidate, threat) − 0.05 × routeLength

projectedCandidate is the projected point after successful space, safety, and full-path checks, not the theoretical unprojected candidate.

Distances are centimeters and 0.05 is dimensionless. Scoring favors distance from threat with a small detour penalty. It is not milliseconds of runtime and does not combine obstacle danger, visibility, and crowding. Replacement is strictly greater; ties retain the first candidate, making enumeration order relevant.

Candidate construction, projection, reachability, and scoring
Figure 7: Finite escape-policy formulas and checks. The main scene uses 650 cm safety distance and records 1 qualified candidate. That count and the final distance are scene results, not guarantees for arbitrary maps.

If no candidate qualifies, the entry returns not accepted, without an unchecked fallback. No response exists yet. This differs from an active escape returning Failed; diagnostics and upper decisions must distinguish them. Precheck rejection does not necessarily mean a parent reported failure, since it may never have started.

Safety distance is checked at several boundaries

Selection requires strict safe+30 cm; generic event queuing requires a supplied goal beyond safe+15 cm; after Arrived the parent requires actual pedestrian-to-current-threat horizontal distance strictly greater than safe. Different interfaces and times must not become one chain-wide tolerance.

This entry point passes the stricter policy before generic queuing. Final checks use actual position, so safety during selection cannot establish safety at arrival. The response can observe threat-source position, but the policy does not continuously reselect direction. The stationary-threat clip does not validate complete moving-threat handling.

Configured distance is 650 cm and final distance approximately 1017.25 cm. This run reaches outside safety distance, not necessarily the world’s farthest point. Qualification, reachability, and enumeration bounds constrain selection; visible direction does not replace query records.

How an event establishes persistent escape intent

After selection, the event-to-task bridge establishes the response. The entry point creates a logical threat source and records type, source handle, tag, threat position, selected endpoint, and safety distance. Fire and impact explain visible behavior without constituting complete perception or damage propagation.

Queuing an event and starting its response are separate

Queue checks existing queued/active responses, source and tag, position and distance inputs, and the expected base movement task. An incompatible event-to-task mapping is rejected, not overwritten. An absent mapping is registered for this bounded scene. Success sets Queued and submits a sourced, tagged event to pedestrian intelligence.

Process then checks current event identity, matching Pending primary slot, suppression, vehicle relationships, and other blocking tasks. A matching type name alone cannot grant execution permission.

On success the response stores the replaced daily Goal for diagnostics, cancels old query and movement, installs the selected endpoint, and activates matching movement and primary slots. It becomes Active, saves initial generation, and increments StartCount. The old daily goal is not registered for automatic restoration after recovery.

Stimulus, selection policy, event bridge, safety parent, and recovery
Figure 8: Event and task ownership diagram. Selection supplies the endpoint, the bridge establishes identity, and the parent retains intent. Recovery acquires body control without restarting that response.

One parent can use several movement queries

StartCount stays 1 after escape starts in the main clip. Knockdown recovery does not restart the response, but movement generation may change: body displacement invalidates the old start and requires a new query. Persistent parent identity and replaceable execution have different roles.

While Active, the parent checks its slot ownership and source availability. Arrived triggers safety-distance checking and completion; Failed or Cancelled closes corresponding task state and event. Cleanup matches event type, source, and tag instead of clearing all events to end one response.

Recovery neither requeues the threat automatically nor repeats initial selection. The original endpoint persists and actual body position becomes the new query start. This is the implemented continuation, not all reference escape cloning, reevaluation, and termination behavior.

Preserving intent during knockdown

The second impact occurs during running. Chaos simulates the body with velocity and impulse while an independent recovery task acquires the project’s higher-priority movement slot. Walking is suspended and its query canceled and invalidated. The safety parent remains active in the primary slot.

Check tasks and resources before body takeover

Knockdown requires a valid game world, pedestrian index, and motion profile. It rejects retired characters, characters suspended by other relationships, and already recovering characters. Occupancy, vehicle intent, and entry/exit interaction also reject this ordinary path. In-vehicle ragdoll and other control modes are not covered.

The entry point acquires skeleton, physics asset, and recovery slot, begins a session, enables physics, and verifies actual pelvis simulation. Failure removes simulation and its recovery slot and returns to inactive. Calling SetSimulatePhysics alone does not establish execution.

Initial linear velocity comes from heading and speed, followed by an impulse. Magnitude is bounded at the entry; the example value is scene configuration, not complete explosion-damage calculation. Effects, impulse input, and actual rigid-body motion provide separate evidence. An effect alone does not establish damage.

Recovery priority 90 is a project slot convention, not a universal reference priority. The tag includes session identity; cleanup matches character and session so an earlier recovery cannot clear a newly acquired slot.

Physical feedback supplies the logical anchor

The pelvis and upper body can leave the old route. Recovery reads pelvis position, traces down for a walkable surface with acceptable normal, and confirms the location through native projection. Feedback updates the logical anchor while walking remains suspended; the old route cannot also write position.

Core linear speed is the maximum of pelvis speed and half the upper-spine speed. Angular speed comes from the pelvis. This reduces sensitivity to limb jitter that could otherwise prevent settling, but remains a criterion for this body and physics asset, not every pose.

Absent support does not force standing. Surface and clearance still qualify recovery. Physical rolling and settling jitter do not follow ordinary walking step limits; comparing them directly would misdiagnose speed.

Stability, support, and clearance jointly permit recovery

State stores physical age, continuous stable time, blend progress, recovery position, and session. Physics lasts at least 1.3 seconds, core linear speed must be at most 35 cm/s and pelvis angular speed at most 90 degrees/s, with supported stability for at least 0.35 seconds before the standing-space decision. A timeout alone cannot establish safety.

settled = supported
       && finite(linearSpeed) && 0 <= linearSpeed <= 35 cm/s
       && finite(angularSpeed) && 0 <= angularSpeed <= 90 degrees/s

stableTime = settled ? stableTime + dt : 0
canLeaveRagdoll = age >= 1.3 s && stableTime >= 0.35 s

This summary omits phase and input checks and is not compilable C++. Instability resets stable time. Insufficient standing space sets WaitingForSpace even after stability is satisfied; elapsed stable time does not bypass clearance.

Physics, stability, standing clearance, blending, and completion
Figure 9: Recovery phases and parameters. Stability still requires standing clearance; losing safety during transition freezes progress. Values are current project configuration.

The standing test builds a capsule from the supporting surface, checks scene occupancy, and checks horizontal body ranges of other non-retired pedestrians. The neighbor branch does not implement complete multi-floor classification. This is not a general solution for vertical cities; both main and supplementary acceptance use the current flat scene.

Rebuilding movement after pose recovery

Entering transition converts physical state into animation input. The implementation captures physical pose and world transform, establishes the display component at the recovery position, converts the snapshot root to that basis, disables simulation, and blends to idle.

What the placeholder provides

The transition bridges poses over 0.8 seconds. Normalized a produces smooth animation weight, leaving the remainder to the fallen snapshot:

a = clamp(blendTime / transitionDuration, 0, 1)
animationWeight = a² × (3 − 2a)
snapshotWeight = 1 − animationWeight

This reduces abrupt pose changes but does not select an authored get-up clip or analyze foot support and body trajectory. Real knockdown physics and complete getting-up animation require different resources and acceptance. The placeholder does not replace the latter.

Coordinate conversion also matters. During physics the skeletal component may shift and rotate relative to its proxy. Applying that pose at a new component position without root correction introduces extra displacement. After disabling physics and reattaching, the old component’s transform relative to the new component is incorporated into the snapshot root. Blending uses the corrected snapshot. This serves the current skeleton and assets, not finished recovery quality from every fallen pose.

Safety checks continue during blending

Blending does not rely only on the initial support and clearance. If either becomes unsafe, BlendTime stops and existing pose progress is preserved. Physics is not automatically reenabled; there is no rollback into a new ragdoll. This freezes the pose transition rather than initiating another physical knockdown.

Once safe, progress resumes. At duration, Complete clears the snapshot and matching recovery slot. It releases its own constraint without canceling or completing other tasks, or claiming arrival at their destinations.

Blend weights, current position, and continuation eligibility
Figure 10: Pose weights and handoff. Body recovery releases body constraints. Task lifecycle and relationships still determine whether movement resumes.

Request a new path from actual position

When reconciliation sees suspension end, it reads actual position and heading, resets motion, and replans to the retained goal. The safety endpoint persists; old generation and starting point no longer describe execution.

Triggering escape again could reselect a goal, reset counts, or restore the wrong daily task. Here the safety parent persists while movement replaces data using actual position. StartCount remains 1 while generation can change, distinguishing intent retention from execution recovery.

If canceled, the original task does not return to Walking. Body recovery may finish while the character remains stationary. Ended intent and unfinished recovery can coexist. A single completion state would obscure cancellation and risk reinstalling old commands in a recovery callback.

Actual knockdown and stopping after recovery
Runtime stills 2: Frames from Video 3 retain the placeholder label. They identify stages; same-run records establish parent identity, cancellation, and replan origin. Those facts cannot be inferred from images alone. Source captions remain in Chinese.

Historical supplements check forbidden resumption

Supplement: Cancel during ragdoll checks that recovery does not reactivate canceled intent. The historical record observes approximately 2 seconds after recovery with 0 cm root drift. This validates that case, not every cancellation interface.

Supplement: Blocked standing space uses a colliding crossbar to delay recovery. After approximately 2 seconds of waiting, the script removes it and a new path is requested to the valid goal. Recovery does not remove obstacles itself.

These clips retain earlier-build evidence and are not recordings of the same final build as the main clips. They add cancellation and clearance counterexamples. Both use the labeled pose placeholder and provide no authored get-up asset.

Returning an unreachable result to the upper layer

The final main clip closes the route with a barrier. Bounded retries fail; a new upper directive then selects the alternate vehicle. The barrier remains at final arrival.

Video 4: Upper-layer reassignment after an unreachable goal, 18.40 seconds. Three replan retries are configured. Exhaustion returns Failed, the parent records one failure, then awaits a new directive. The barrier remains; automatic removal and unlimited alternates are outside the clip.

Local waiting, replanning, and failure are distinct

A blocked step can wait and reevaluate direction. The entry accumulates blocking time and monitors progress toward the current corner. Blocking strictly longer than 1.5 seconds or no progress strictly longer than 2 seconds may trigger replanning. Turning retains its timing exceptions.

Replanning increments count; within the limit it discards the path, advances generation, and requests again. Count greater than 3 sets Failed. This is project policy, not a universal reference rule. No complete path, service-capacity failure, or another explicit query failure can end execution earlier without requiring three blocking retries.

A rejected step therefore differs from failed movement. The first still has permitted waiting/retries; the second returns a parent result. Endless local blocking on a closed route would deny the upper layer a failure decision. Ending the parent on every minor obstruction would discard movement’s own recovery opportunities.

The parent consumes failure once

Failed causes the directive parent to store the reason, increment FailureCount, and enter AwaitingDecision. Further updates with the child still Failed do not increment again. Deduplication depends on the parent state. It does not handle arbitrary retransmissions or distributed idempotency.

if child.status == Failed and parent.status != AwaitingDecision:
    parent.failureCount += 1
    parent.lastFailure = child.reason
    parent.status = AwaitingDecision

Source, session, and control checks are assumed to have passed. Without them another task’s or old execution’s failure could alter this parent. The full implementation performs those ownership checks; the short example omits them.

AwaitingDecision retains source and original goal, not permission for old movement to execute. It creates no alternate vehicle, removes no barrier, and does not silently reset failure and restart the path.

Blocked route, movement failure, decision wait, and redirect
Figure 11: Failure and decision diagram. Feedback differs from session termination. A new goal needs fresh query and motion checks; no generic automatic fallback is implied.

Reassignment retains the session

Redirect to the alternate vehicle checks control eligibility, takes a transform snapshot, cancels the old query, and establishes new generation. The parent returns to Travelling from AwaitingDecision with its failure count retained. Alternate execution must independently finish or fail.

The run retains session 1 with command count 2 and failure feedback 1. After approximately 1.4667 seconds of waiting, the upper layer sends its alternate directive; the character then stops beside vehicle 2. The scene schedules that input, rather than a parent countdown choosing from a list.

An unreachable alternate still fails explicitly. This is not a complete retry tree or multilevel dispatch policy. The verified chain is movement failure, upper-layer retention and reassignment, then renewed query and movement checks.

Read parameters with consumers, phases, and units

Values are retained to connect explanations to consumers. Equal values at different interfaces can have different meanings, while waiting may end through time, a command, or a relationship. These belong to the delivered branch, not universal reference constants.

Parameter or record Value or condition Consumer and meaning
Approach offset (-200, 0, 0) cm Object-local offset transformed at command time
Accepted endpoint Each component difference no greater than 15 cm AcceptPath uses FVector::Equals, not spherical distance
Final arrival Three-dimensional distance no greater than 15 cm Actual position; enabled motion also requires stopping
Curve sampling 120 intervals, 121 samples Import extraction, not runtime frame rate
Running reference speed Approximately 594.324 cm/s Resource distance/duration for sample rate and loop matching
Escape speed 330 cm/s This character’s budget, not all population
Safety distance 650 cm Main-scene configuration with separate interface margins
Projection tolerance Horizontal distance no greater than 50 cm Prevents projecting to a substantially different location
Candidate search bound 2048 polygon expansions Per-candidate precheck, not a universal service budget
Escape request priority 10 Project request priority, not a universal reference index
Movement substep At most 0.05 s Movement/scene checks, not shared logic/physics/video rate
Recovery priority 90 Independent recovery-leaf slot convention
Minimum physical age 1.3 s Combined with support, stability, and clearance
Continuous stability At least 0.35 s Resets on instability; requires valid feedback
Core speed/angular speed At most 35 cm/s and 90 degrees/s Separate physical measurements
Pose transition 0.8 s Placeholder blend; freezes if unsafe
Replan allowance Three retries, then failure This movement policy, not every task

Characters retain motion progress, queries, and recovery sessions; assets retain reusable curves and clip references. Parent source, event source, and recovery session cannot become one controller field without risking stale events, queries, or recovery completion modifying a new task.

Names alone do not establish unexecuted capabilities. A sourced command is not a script VM; Pending/Active slots do not establish an arbitrary polymorphic tree. Curves and ragdoll do not establish a full motion network or every get-up animation. Each consumer is described with its tested scope, so the presence of a field does not imply that the larger system has been verified.

Verify task identity separately from execution

The delivery records a successful build and 158 regression items: 73 succeeded, 85 succeeded with existing warnings, 0 failed, and 0 not run. This is not 158 warning-free passes. Test count measures neither video scenarios nor reference-system coverage.

An independent six-character city check passed over 1494 frames and 49.80 simulated seconds, with maximum normal step approximately 4.333 cm, minimum separation approximately 63.386 cm, and near/far turning work counts 41/8. These belong to that check, not universal per-sample limits for the main clips or real-time/crowd performance measurements.

Footage shows the process; records establish identity and gates

Main clips are continuous real PIE recordings without cuts, retiming, or composited characters, encoded at 1280 by 720 and 15 fps. Captions summarize stages rather than timestamping every transition exactly. Source, samples, and footage have separate roles: a visible stop cannot identify command hold, and standing again cannot establish intent validity.

Main clip Duration Principal same-run results Limits
Rendezvous Approximately 11.53 s Same character; session 1; stopped at completion; failure feedback 0 No entry or moving-object tracking
Hold, continue, redirect 15.40 s 0 cm hold drift; Continue retains generation; Redirect invalidates old query; session 1 Approximately 3.5-second external input delay is not a runtime timer
Escape and recovery Approximately 11.53 s Runtime selection; StartCount=1; real knockdown; resumed movement and safe completion No complete perception, damage, escape algorithm, or authored get-up
Reassignment after failure 18.40 s Failure feedback 1; waits for explicit directive; completes with barrier retained No automatic clearance or unlimited fallback

Correct continuation checks pedestrian handle, parent source/session, goal, generation, body phase, position, and outcome together. Resumed motion might belong to the wrong task; correct parent counts cannot replace collision and footage. Separate observations avoid hiding execution behind one success counter.

Automated checks cover persistent hold, stale-result rejection, single failure reporting, external-slot protection, finite selection, and parent retention. They verify interface semantics; scene evidence checks physics, visibility, and placeholder presentation. Each form of evidence supports its own claims; together they still do not establish a complete reconstruction.

Reference mechanisms, UE adaptation, and remaining scope

Mechanism analysis provides parent-owned intent, separate waiting/cancellation, query identity, parent-consumed failure, and continuation after recovery. Native C++ state and slots implement those relationships. UE supplies scene objects, collision, animation, and physics. Class names are neutralized; original anchors remain in review material.

The implementation remains limited to current directive commands, finite escape candidates, scripted threats/impacts, documented pose blending, and flat-scene motion. Full scene behavior, script resources and cloning, complex crowds, replication, moving-target tracking, and production damage need separate implementation and acceptance.

Main clips use the delivered source/build fingerprints; supplements preserve historical versions. Delivery notes state that the original map was not saved with modifications and retain its fingerprint. Writing only read material and checked media; it did not rebuild, rerun all regressions, or record demonstrations. Test figures come from delivery records.

Extending behavior from this rendezvous

Persistent intent is stored separately from replaceable execution. Commands release holds; redirects replace queries but preserve the task session. Physics temporarily controls the body; only valid intent resumes. Failed movement leaves its parent waiting for a decision.

A fuller script/event system can replace the parent, navigation can add surfaces and links, and authored animations can replace the recovery placeholder. Each change must recheck source retention, writers surviving cancellation, failure termination, and position/pose alignment.

Those extensions remain future work. The delivered task subset can be observed in the scene and checked against source. Players see rendezvous, waiting, escape, and recovery; source, session, queries, position, and outcomes explain them.

AI collaboration retrospective

Writing used frozen source, functional contracts, events, and frame records, organized around scenes before expanding calls, formulas, and failures. AI organized material, made diagrams, and checked references. Completed functionality was neither modified nor rerecorded.

Historical material required care. The generic safety interface accepts externally supplied endpoints, as older comments describe. The current clip calls a selection policy before that interface. Separating them avoids mislabeling the clip as script-selected refuge or claiming automatic selection for every response entry.

Animation’s role also needs precision. Playback does not write logical movement, but execution consumes extracted root-distance and turning curves. Separating resources, native budgets, physical checks, and pose evaluation preserves this relationship, which explains starting, moving stops, and immediate stopping.

The final review separates what each form of evidence establishes: one parent can use a new query; real knockdown can coexist with placeholder recovery; source can prove calls without proving visual quality. Formula diagrams explain consumers; stills and clips are recorded evidence. Labels preserve those distinctions for review.

Leave a Comment

Discover more from AI Native Game Development

Subscribe now to keep reading and get access to the full archive.

Continue reading