Dynamic City | City Population Runtime (Part 2): Task Execution, Scenario Behavior, and Presentation Boundaries

This is the second pedestrian-focused installment in the How to Build an Open-World Game series. Part 1 covered scheduling and decision-making up to the point where an event has produced a task slot. This article covers the other half: how a task becomes observable behavior, how scenario points populate the environment, and where locomotion, animation, and physics take over.

The material comes from a long-running, source-level reverse-engineering read of the engine and client code of a mature commercial open-world game, with roughly 700+ source-level notes. The article is anonymized for publication. It describes the original mechanisms at the level supported by the notes, then maps them to a UE5 prototype. The prototype status is stated explicitly: the behavior, scenario, animation, and ragdoll systems discussed here are not yet implemented in the prototype unless a section says otherwise.

Every subsystem follows the same three-part structure: how the original is organized → what should be built or reused in UE5 → what is implemented, planned, or still a blind spot.

Introduction: From Decision State to Continuous Behavior Presentation

Terminology note: this article uses leaf task for a concrete task at the end of a task tree, and transition wrapper for the intermediate layer that prepares the current context for execution. They describe different responsibilities—execution and entry conditions—and do not introduce additional behavior systems.

Part 1 ended with an event being adjudicated and converted into a pending task in a task slot. A task slot contains intent, not execution. “Flee” still has to become a route away from the threat, an accelerating locomotion state, a stumble when the character is hit, and, if the route passes a scenario point, a controlled transition into a short ambient activity.

The task slot is the interface between the two articles. Part 1 guarantees that the slot contains an adjudicated, deduplicated, traceable intent. This article asks how that intent is executed without losing ownership, interruption, lifecycle, or recovery semantics.

The execution side is broad. It includes task families, scenario ecology, locomotion, and physics presentation. Its evidence on the original side is substantial, but its prototype implementation is intentionally thin. The useful output here is therefore not a claim that the systems are already built. It is a migration map with enough resolution to identify task names, state transitions, ownership, entry conditions, and exits.

The article is divided into four chapters:

1. Task execution: the structure beneath a task slot, using selectors, transition wrappers, and executors.
2. Scenario ecology: how scenario points, metadata, clusters, exclusion volumes, coverage validation, and entity-generation bridges produce ambient behavior.
3. Locomotion and animation: the boundary between movement intent and the engine’s presentation stack.
4. Ragdoll and physical reactions: how physical takeover remains a formal task state rather than an absence of task control.

The companion UE5 implementation articles will cover concrete code, engine subsystem integration, pitfalls, and verification. This article remains a design and migration document.

I. Task Execution: From a Task Slot to Behavior

The question for this chapter: how does a Pending task slot become executable pedestrian behavior? What structure allows a task to complete while remaining interruptible by a higher-priority event? Why does a short-lived startle response still benefit from three distinct task responsibilities?

① How the Original Is Organized

Part 1 established that tasks advance in a fixed intelligence-processing stage and that one NPC can carry several parallel task trees: primary, secondary, movement, and animation-related work. The important distinction here is that a task is not a one-frame function call. It is a cross-frame state machine with lifecycle, interruption, retry, recovery, provenance, and explicit completion states.

The execution pattern is a layered structure:

• An outer strategy selector decides which response family and execution path apply.
• A transition wrapper prepares the context in which that path can run.
• A concrete executor owns the actual behavior state machine, timing, orientation, interruption handling, and completion semantics.

The passive-fear response family makes the division clear. A high-level threat selector evaluates the threat, chooses a route or response mode, and distinguishes between fleeing, surrendering, taking cover, and remaining in a vehicle. It does not own the concrete implementation of those responses.

The transition wrapper handles conditions that are neither strategic choice nor final performance. A driver who is threatened may need to leave a vehicle before a surrender executor can start. That exit chain can fail, can take time, and has its own state transitions. Putting it inside the selector would contaminate the strategy layer with execution details. Putting it inside the executor would force a surrender task to understand every vehicle context.

The executor owns the actual surrender behavior: its animation state, timer, facing, interruption path, and continuity under network cloning. It may have more than one entry point—scripted sequences and event routing can request the same executor—but the runtime retains one execution definition.

This separation also explains why some fear responses reuse the scenario system. A long-lived “take cover in place” performance can resolve to a scenario path. The wrapper prepares the context; the scenario execution model provides the performance. A startled pedestrian crouching beside a wall and a pedestrian sitting on a bench are different contents using the same scenario runtime.

The three layers solve problems that change at different rates:

The selector changes with design decisions, the wrapper changes with context, and the performance changes with assets. Keeping them separate prevents strategy tuning, contextual preparation, and content expansion from becoming one dependency chain.

The same organization appears in vehicle entry, pursuit, movement, and threat response. The terminology changes, but the responsibility boundary remains: the outer layer owns policy and state orchestration; the leaf task owns one concrete operation; the executor owns the operation’s lifecycle and outputs.

The interruption model is equally important. A higher-priority event does not merely switch a branch. It enters through the response table, claims a task slot according to priority, and causes the displaced task to follow its own clean exit path. If a seated NPC is hard-switched into a flee state without releasing its scenario occupation, the bench remains occupied from the scenario system’s point of view. After sufficient runtime, the city accumulates invalid occupations.

The solution is not a special-case cleanup for every behavior. Every state transition needs an authority, every interruption needs an exit path, and every wrapper that owns continuity needs a return point or an explicit decision that the previous occupation is released.

② Why Off-the-Shelf Solutions Do Not Fit (and What to Reuse)

The task organization is a good candidate for a custom runtime layer because it carries ownership, interruption, provenance, lifecycle, and slot semantics. The leaf implementation should reuse engine facilities wherever those facilities already own the relevant mechanism:

• Navigation and movement components can provide path following and movement execution.
• The animation system can provide action playback and locomotion presentation.
• The vehicle system can provide entry and exit chains when a pedestrian response crosses into a vehicle context.
• Existing task-slot and event-bridge semantics should remain the authority for priority, suppression, and interruption.

The prototype should not create a second interruption system for scenario behavior. A scenario task should occupy an existing task slot, and a higher-priority response should enter through the same event bridge used elsewhere. The scenario wrapper can retain a scenario handle, usage style, and sequence number so that a valid return remains possible after the interruption.

The migration order follows dependency direction:

1. Movement tasks, because fleeing and scenario behavior both depend on movement.
2. Scenario behavior, because it depends on movement and scenario data.
3. Response families, because they must interrupt and compose with the first two.

That order produces an important milestone: a pedestrian can walk, occupy a scenario point, react to a gunshot, and return to the scenario without requiring the entire response family to be implemented.

③ Prototype Status and Plan

The prototype currently contains only the task-slot progression skeleton for this layer. The existing intelligence pipeline advances counters and slot lifecycle state; it does not yet execute subtasks, movement, animation, or vehicle entry.

The current migration plan is:

• Build the leaf-task state machine with explicit success, failure, interruption, and cancellation outputs.
• Reuse the existing task-slot priority and lifecycle path instead of introducing a behavior-specific scheduler.
• Implement one concrete response executor first, then add the transition wrapper and selector around it.
• Keep the response-table layer as the prototype’s existing selector skeleton.
• Reuse UE navigation and animation components inside execution tasks while keeping orchestration and ownership in the custom task runtime.

The response selector and transition wrapper are therefore planned structures. The response table skeleton exists; the concrete response execution layer does not. The scheduling algorithm for multiple task trees remains a deliberate blind spot and is left to a later implementation article.

Additional mechanism notes: response families and entry semantics.

The passive-fear example is only one branch of a larger response family. Other branches include combat responses, investigation, searching, evasion, confrontation, and movement-related reactions. Their content differs, but the separation between selection, contextual preparation, and concrete execution remains useful.

The response table and the selector answer different questions. The decision layer asks whether an event deserves a response at all. It can legally produce no response. The selector runs after that decision and chooses the response shape. “Should this NPC react?” and “what should the reaction be?” are independent decisions.

That separation permits combinations that would otherwise be difficult to express. A brave NPC may still surrender when the context forces a vehicle exit and the available response policy selects surrender. A cautious NPC may choose cover instead of fleeing. The decision value and the selected execution family do not have to be collapsed into one personality branch.

The selector also determines the cost of content expansion. Adding “record the incident, then flee” should add a selector option and a new executor. It should not require rewriting the entry conditions of every existing surrender, cover, and flee task. If the choice logic is embedded in every executor, the mutual-exclusion rules become distributed and each new response increases the cost of reviewing all existing branches.

The transition wrapper protects the same boundary from the opposite direction. A vehicle-bound NPC may need to leave the vehicle, establish a valid stance, face the threat, and only then create the surrender executor. Each step has a possible failure and may span multiple frames. That is an execution-context problem, not a policy problem.

The executor is the only owner of “what surrender looks like.” It owns timing, orientation, animation requests, interruption, network continuity, and completion. Script, event routing, or a scenario wrapper may request it, but they do not fork the definition. This is why multiple entry points do not imply multiple behavior implementations.

Additional mechanism notes: task trees, slots, and cross-domain handoffs.

The pedestrian runtime does not contain one universal task tree. A character can have several parallel trees or channels, each with its own slot and priority relationship. The execution layer therefore needs to preserve both local task state and cross-tree ownership.

The task tree controls a sequence such as “move to a location, face the threat, raise hands, maintain the pose, then exit.” A vehicle entry chain can appear as a child chain of a pedestrian response, but the vehicle system remains authoritative over the entry and exit relationship. The pedestrian selector owns the decision to request the chain; it does not own the vehicle’s seat occupancy or door lifecycle.

This is the ownership rule that keeps the pedestrian and vehicle articles compatible: relationship state belongs to the system that defines the relationship, while behavior choice belongs to the system that initiates the behavior. A flee response may request a vehicle escape, but the seat and entry chain remain vehicle-owned.

The same rule applies to animation and physics. A movement task produces a movement intent, but the locomotion system owns the conversion into movement state. A hit task requests physical control, but the physical bridge owns the solver handoff. At every boundary, the caller retains the reason for the request and the callee retains the mechanism it is responsible for.

Additional mechanism notes: interruption, cancellation, and recovery.

Interruption is not one outcome. A task may complete successfully, fail because an entry condition cannot be established, be cancelled by its owner, or be preempted by a higher-priority task. These states should remain distinguishable because the wrapper and the caller may make different recovery decisions.

For example, a scenario-backed cover task can fail because the cover point is no longer available, while it can be interrupted because a vehicle has collided with the NPC. The first case may select another cover point. The second may install a physical-reaction task and retain the original scenario occupation for later recovery. Treating both as “false” destroys the information needed to preserve continuity.

The minimum execution contract should therefore expose:

• an explicit entry state and readiness check;
• an active state with observable progress;
• success, failure, cancellation, and interruption exits;
• an owner or source identifier;
• the state required for return or cleanup;
• a deterministic result that the parent wrapper can consume.

This contract is more important than whether the concrete executor is implemented as a UE state machine, a custom C++ object, or a data-driven task asset. The implementation can change while the lifecycle semantics remain stable.

II. Scenario Ecology: How Scenario Points Drive Environmental Behavior

The question for this chapter: where do entities performing location-specific behaviors—smoking beside a storefront, sitting on a bench, working behind a stall, or standing against a wall—come from? Manual placement cannot scale. The harder engineering question is how the runtime maintains consistency when the bench is not streamed in, a point lies inside a scripted exclusion volume, or several points must form one coherent group.

① How the Original Is Organized

The original uses a data-driven scenario-point system. The world contains a large number of points, each with metadata describing what can happen there: sit on a bench, lean against a wall, read a newspaper, or perform another ambient activity. The runtime generates or assigns NPCs to these points and attaches the corresponding behavior.

The system is more than “points plus tasks.” Its major responsibilities are:

• Scenario-point storage: persistent point and zone data, loaded by streamed region.
• Scenario metadata: the behavior, animation, and conditions associated with a point.
• Runtime coordination: point activation, streaming pressure, clustering, coverage queues, generation range, and release decisions.
• Entity coverage validation: reconciliation between a point and the world entity it references, such as a bench or stall.
• Vehicle scenario generation: a parallel production path for vehicles that belong to a scenario group.

The point database answers where a point exists. Metadata answers what that point means. The coordinator answers which points are active now. This is the same static-location, author-rule, dynamic-activity pattern that appears in road networks and intersection templates.

The dispatch bridge converts abstract point data into a live NPC in three steps:

1. Class dispatch: map the scenario identifier to a concrete task class.
2. Control-wrapper construction: place the bare scenario task inside a wrapper that supports interruption, awareness, and continuity.
3. Scenario generation: perform model, collision, streaming, and population-validity checks, then generate or assign the entity and attach its scenario-control task.

The wrapper is what prevents a seated NPC from being only a seated animation. It retains the “daily state” around the scenario task, including the return point and occupation state. If the NPC is startled, the wrapper can route into a cover or response task and later attempt a normal scenario re-entry. Re-entry goes through the same validity checks as the original entry; it does not receive a permanent exception because it held the point earlier.

Scenario supply has two complementary paths:

• Point-driven generation creates a new entity for a point when the population system permits it.
• Active-entity matching assigns an existing wandering entity to a nearby compatible point.

The first path consumes population budget. The second consumes scanning and matching work. Together they keep the environment populated without requiring every scenario point to create a new NPC.

The world-side ecology adds four important constraints:

• Clusters coordinate groups of points and their dependent assets. A four-person card game either appears as a coherent group or does not appear.
• Exclusion volumes apply to both new generation and already active scenarios. A scripted area can remove an active scenario rather than merely blocking future spawns.
• Entity coverage validation handles streamed-world timing. A point may exist before its referenced bench, stall, or interior entity is available. The validator classifies states such as working, degraded, damaged, or unavailable rather than reducing everything to valid/invalid.
• Vehicle generation supplies vehicles that belong to a scenario group while still passing through population and placement constraints.

The scenario runtime is therefore a five-part ecology. The point itself is only the content-facing entry; the rest of the system is responsible for production, grouping, constraints, reconciliation, and lifecycle.

② Which Existing Facilities Can Be Reused and What Must Be Built

UE5 Smart Objects are a strong fit for the point data and claim/query layer. They can represent where an interaction is available, expose editor workflows, and support spatial queries. They should not own the pedestrian runtime, task-slot priority, interruption, or continuity semantics.

The intended boundary is:

• Smart Objects provide point location, claim state, and query support.
• The custom task runtime owns the behavior after the claim: wrapper state, continuity, interruption, task lifecycle, and return.
• The population system remains the authority for entity budget and legal generation.
• World streaming and coverage validation remain explicit runtime responsibilities.

This is a data/query reuse decision, not a decision to hand runtime scheduling to an external framework. The same boundary applies to navigation: UE navigation can provide pathfinding, while the task runtime decides when the movement task enters, what it owns, and how it exits.

③ Prototype Status and Plan

The scenario system has not yet been implemented in the prototype. It is intentionally later in the pedestrian roadmap, after the entity runtime, physical representation, and Ped/Vehicle/Object foundations are stable.

The existing foundation provides several future attachment points:

• Entity creation and first-task assignment are separate responsibilities.
• The task-slot pipeline already has priority, lifecycle, and event-bridge semantics.
• World streaming can provide the data layer for scenario points.
• Smart Objects can provide claim and query support.
• Scenario control can be implemented as a wrapper around existing task ownership rather than as a separate scheduler.

The planned implementation uses world-partition data for point storage, data assets for metadata, Smart Objects for claim and query, and the custom runtime for scenario execution and continuity. Persistent point storage, precise streaming triggers, cluster coordination, active matching, and vehicle scenario generation are still unimplemented. They remain explicit planning items rather than implied completion.

Additional mechanism notes: the five-part scenario ecology.

The five parts should be designed as separate owners even when they are delivered in one package.

Point storage owns the persistent location and the streaming identity of a scenario point. It does not decide whether the point is currently eligible, which NPC should use it, or what performance should run there. Its contract is storage, region membership, and load/unload visibility.

Metadata owns the content description: scenario class, animation or performance family, entry conditions, required world state, preferred occupation style, and any group relationship. It does not generate entities. It describes what an eligible point means.

The runtime coordinator owns current activity. It evaluates distance and streaming pressure, refreshes conditions, schedules claims, asks for cluster expansion, and routes invalid or released points into the appropriate queues. It is the owner of “what should be active now,” not of the individual task’s internal performance.

Coverage validation reconciles data with the streamed world. A point can remain in the data layer while its referenced bench, stall, vehicle, or interior is unavailable. The validator must distinguish at least “working,” “degraded,” “damaged,” “referenced prop unavailable,” and “interior not streamed.” These are different content decisions. A degraded point may admit fewer occupants; a damaged point may be disabled; an unstreamed interior may be deferred rather than invalidated permanently.

Scenario generation turns a valid point or cluster request into an entity and its first behavior. It performs model selection, placement checks, collision validation, population-budget admission, and initial task assignment. It is a bridge into the population system, not an independent population source.

This decomposition also explains why a scenario point cannot be treated as a static decoration. The point participates in streaming, resource budgets, world constraints, entity lifecycle, task ownership, and recovery. Its content description is small; its runtime ecology is not.

Additional mechanism notes: clusters, exclusion volumes, and group integrity.

Clusters exist because some scenarios are meaningful only as groups. A card game, a street-side conversation, a small queue, or a vehicle-based activity may require several points, several entities, and several assets to become available together.

A cluster coordinator can validate member points, collect streaming dependencies, wait for required assets, schedule vehicle generation, admit entities through the population budget, track generated members, and release the group as one unit. It should be an explicit state machine rather than a one-shot function because assets arrive at different times and because the group may be invalidated while waiting.

The cluster state should expose at least:

• discovered and valid member points;
• streaming dependencies requested and available;
• entity and vehicle generation requests;
• waiting-for-assets state;
• active member count;
• group release and cleanup result;
• density and player-influence gates.

The density gate prevents a busy region from opening unlimited new groups. The player-influence gate lets content or gameplay temporarily suppress a group near the player. Both gates belong to the world-side producer because they regulate resource consumption, not the semantic content of an individual point.

Exclusion volumes apply to both incremental and existing content. A mission or cutscene may reclaim an area from the environment system. The runtime must therefore query the exclusion table when generating a point and also notify active occupants when an exclusion becomes active. If only future generation is blocked, the supposedly closed area continues to produce ambient behavior from the existing population.

Additional mechanism notes: generation, matching, and population contracts.

Point-driven generation and active matching solve different budget problems. Generation creates an entity and consumes population capacity. Matching assigns an existing wandering entity and consumes a scan, a query, and a behavior transition. The coordinator can use them as complementary supply paths: matching can keep dense areas productive under tight spawn budgets, while generation can fill sparse areas where no compatible entity is nearby.

The entity-creation boundary must remain separate from first-task assignment. The factory creates and registers the entity. The population handoff computes its initial wandering or default task, optionally applies a scenario assignment, and enters it into the runtime. This division prevents every new entity-generation path from acquiring its own behavior initialization logic.

The same boundary covers point generation, cluster generation, cover binding, and other world-entry routes. Their creation mechanisms differ, but their first behavior should pass through one population handoff contract. This is the point at which initial task ownership becomes explicit.

The generation bridge should report more than success or failure. It should distinguish invalid point data, missing streamed dependencies, collision failure, population-budget rejection, model unavailability, and successful entity admission. Those states are needed for diagnostics, retry policy, and content authoring. A single “spawn failed” result would erase the difference between a bad point and a temporary streaming delay.

Additional mechanism notes: scenario recovery as a lifecycle problem.

The return path is not an optional convenience. A seated NPC that is startled, takes cover, and later resumes the bench is a multi-stage lifecycle: original claim, interruption, alternate performance, threat resolution, admission check, and re-entry. The wrapper must retain enough state to determine whether the original occupation remains valid and whether the point is still available.

Short interruptions may retain an occupation reservation. Long interruptions may release it so that another NPC can use the point. The policy should be explicit and sequence-numbered. Otherwise, a point may be released by one task while a delayed recovery callback later reclaims it using stale state.

The recovery contract should include the point handle, usage style, reservation sequence, interruption reason, release policy, and re-entry result. A failed re-entry should return to a valid default behavior rather than leaving the NPC in an unowned intermediate state.

III. Locomotion and Animation: Establishing the Boundary

Why this chapter remains short: tasks decide what should happen, locomotion decides how the character moves, and animation decides how that movement is presented. This article defines the responsibility boundary between task execution and motion intent; it does not expand the internals of an animation blend tree. Those belong to engine implementation and the later landing article.

The question for this chapter: should walking, running, and turning animation be built or reused? Where does the behavior layer stop and the animation layer begin? The short treatment is deliberate: a correct seam reduces the amount of behavior-specific animation work.

The conclusion is to reuse the engine presentation stack and keep it downstream of behavior. The original structure that matters here is the interface: behavior produces a movement intent; the locomotion system consumes it; animation turns the locomotion state into a pose. The internal blend-tree algorithm is a blind spot and remains an engine-owned concern.

① How the Original Is Organized (Structural Level)

The task layer does not own bones. It produces intent such as destination, speed, gait, posture, and source identity. The movement system arbitrates competing intents and produces locomotion state. The animation system consumes that state.

This boundary allows a task to be interrupted without forcing it to understand animation internals. It also allows the animation implementation to change—from a state-machine-based animation blueprint to motion matching—without changing the ownership of movement intent.

The adjacent physical-reaction system reinforces the same conclusion. A physical reaction eventually exits through a dedicated task that blends the character back into animation. “Return to animation” is therefore an explicit task boundary, not an implicit frame-level switch.

② Why the Engine Presentation Stack Should Be Reused

UE5’s animation stack—Animation Blueprints, Motion Matching, Control Rig, IK, and related systems—already owns the expensive presentation mechanisms. Rebuilding them would duplicate engine responsibilities and make the task runtime dependent on presentation details.

The custom layer should own only:

• the movement-intent package;
• source and priority metadata;
• readiness and validity conditions;
• arbitration between movement tasks and higher-priority responses;
• the adapter contract that consumes intent and produces locomotion input.

The seam is stable across animation implementation choices: intent enters, pose exits. The concrete animation selection can be deferred to the landing phase.

③ Prototype Status and Plan

The locomotion task itself is not connected in the prototype, so the animation layer is intentionally later. The planned intent package contains target, speed, gait, posture request, source type, source tag, and readiness state. Missing target or gait data makes the package not ready.

The adapter should initially be a record-only implementation that does not play animation. This makes the seam testable before the downstream animation stack is connected. Acceptance tests should verify readiness, revision numbers, diagnostic snapshots, and the rule that adapters do not execute animation by themselves.

The original movement state machine, turn prediction, gait selection, and blend-tree internals remain outside the current evidence boundary.

Additional mechanism notes: the motion-intent package.

The motion-intent package should be treated as a versioned handoff object rather than a collection of direct animation calls. A minimal package can contain:

• target position or target direction;
• desired speed and speed range;
• gait or locomotion mode;
• posture request;
• source task and source type;
• priority and arbitration metadata;
• readiness and invalidation state;
• revision number for diagnostics and reconciliation.

The task layer writes the package. The locomotion layer validates and consumes it. The animation layer remains free to choose the pose implementation. If the target disappears, the path becomes invalid, or the gait is unavailable, the package reports not-ready or invalid rather than silently issuing a partial animation request.

This package also gives interruption a stable boundary. A movement task can be preempted by a fear response without the fear response needing to know whether the previous movement was implemented by a navigation component, a custom controller, or a future motion-matching system. The movement owner closes its intent, the response owner submits a new intent, and the locomotion system arbitrates the active source.

Additional mechanism notes: adapter and acceptance strategy.

The first adapter can deliberately record intent without playing animation. It should capture the latest package, source, revision, readiness result, and rejection reason. That makes the behavior-to-animation seam testable before any animation asset or blend tree is connected.

Acceptance cases should include:

1. a valid movement intent reaches the adapter;
2. missing target or gait is rejected with an explicit reason;
3. a higher-priority response replaces the movement source;
4. an interrupted movement task closes its intent cleanly;
5. the adapter never becomes the owner of task priority or task lifecycle;
6. the same package can feed different downstream animation implementations.

The important result is not a particular pose. It is that behavior can make a precise request, locomotion can report whether it is ready, and animation can evolve without taking ownership of behavior scheduling.

IV. Ragdoll and Physical Reactions: Establishing the Physical Boundary

The question for this chapter: what is the task-system identity of the few seconds during which an NPC is hit by a vehicle, thrown by an explosion, or falling from a height? Is physical takeover an interruption of behavior, or a behavior state in its own right?

This chapter sits between a design decision and a deep dive. The algorithmic core of physical control is a blind spot, and the prototype has not implemented the system. The surrounding structure is nevertheless detailed enough to specify task identity, input dimensions, degradation levels, and the bridge back to animation.

① How the Original Is Organized (Structural Level)

Physical presentation is not one generic task. It is a family: short hit reactions, falls, high falls, relaxation, injured-on-ground states, and other specialized responses such as explosions, fire, electrical shock, carrying, dragging, crawling recovery, and standing up from a physical state.

Each is a formal task occupying a task slot at the same organizational level as walking or using a scenario. Physical takeover therefore remains a task state. Existing priority, interruption, lifecycle, serialization, and script-orchestration rules continue to apply.

This immediately provides two capabilities:

• Network cloning can synchronize that the NPC is currently in a particular physical-reaction task.
• Scripts can request a physical reaction as a task instead of manipulating individual rigid bodies one by one.

A short hit task carries more information than “apply force.” It converts impact-point data into context, redirects an existing reaction when another hit arrives, selects parameter sets from weapon metadata and attacker actions, applies armor, stairs, fatal-hit, player-death, and weapon-carrying modifiers, and scales impulse using weapon, player strength, relative velocity, and hit location.

The visible variety of a hit reaction therefore comes primarily from input dimensions and parameter selection, not from an entirely new presentation algorithm for every case. Repeated hits update the task’s target in place instead of reconstructing the task on every impact. High-frequency changes update parameters; they do not rebuild the lifecycle object.

The transition protocol is explicit:

• Balance succeeds: enter a dedicated task that blends from physical state back into animation.
• Balance fails: attach the appropriate failure handling and context-specific parameterization.
• Vertical velocity crosses a threshold: degrade into a high-fall or other lower-level reaction task.

“Stumble → fall → high fall” is a task-level ladder. Each transition has a condition and a destination. The return-to-animation task has its own lifecycle and can itself be interrupted. If another hit arrives during the blend-back phase, the blend task is interrupted and a new reaction task takes ownership. Without that explicit task, the interval between physical state and animation would be an undefined state window.

The retirement of an old reaction task follows the same contract discipline. A retired task may be disabled at compile time, assert in its constructor, remain in a commented type enumeration, reject a script entry point, and automatically redirect to a safe replacement. This is not merely file deletion. Old scripts, saves, or network peers may still refer to the type, so every external entry must fail explicitly and degrade safely.

② What Should Be Reused and What Should Be Built

The task identity, ownership, transition ladder, input schema, and return-to-animation protocol belong in the custom behavior runtime. The physical solver, skeletal physical asset, and low-level physical-control implementation should be supplied by the engine or a dedicated physical-control layer.

The migration boundary is:

• custom task: why physical takeover begins, which response family owns it, and when it ends;
• physical bridge: how the task activates physical control and receives state feedback;
• engine physical system: collision resolution, body simulation, and low-level control;
• return task: how the character becomes eligible for animation again.

③ Prototype Status and Plan

The prototype has not connected entity transforms to real physical simulation. The downstream physical adapter is still null, and ragdoll is scheduled after the broader presentation layer.

The current output is therefore a specification: build the handoff protocol, reuse the physical foundation, and keep the physical-control core as a blind spot until its implementation is justified. Connecting a ragdoll asset is not equivalent to implementing a complete hit-reaction system.

Additional mechanism notes: detailed task-family behavior.

The useful evidence is not limited to the existence of a “ragdoll” label. The task family exposes a more precise organization. Short impact reactions, stumble states, falls, high falls, injured-on-ground states, relaxation, and recovery from physical control are separate task-level responsibilities. They can share a physical presentation layer while retaining different entry conditions, parameters, transition rules, and exits.

That distinction matters for authoring and for multiplayer state. A character struck by a low impulse should not enter the same task as a character whose vertical velocity has crossed a high-fall threshold. A character that remains balanced should not be serialized as an injured-on-ground state. The physical solver may be shared, but the task identity determines how the runtime interprets the solver’s result.

The short hit task also illustrates parameter granularity. Its inputs can include the impact position, impact direction, weapon metadata, attacker action, armor state, whether the character is on stairs, whether the hit is fatal, whether the character is a player, whether the character is carrying a weapon, relative velocity, and the affected body region. These inputs are not interchangeable flags. They form distinct modification layers over a base reaction.

The result is a parameterized family rather than a collection of unrelated animations. Armor can reduce the visible response; a stair context can change the balance parameters; a weapon in the character’s hands can introduce a weapon-preservation posture; the body region can change the impulse scale. The performance family stays stable while its input context changes.

The same principle appears in repeated impacts. Rebuilding the task for every hit would repeatedly pay initialization cost and discard continuity. Updating the target of the active reaction task preserves the lifecycle object and treats a sequence of hits as a sequence of inputs. This is the same design pattern as continuously rewriting a pursuit destination instead of rebuilding the pursuit task each frame.

The transition ladder is therefore an observable contract:

Condition	Task-level result	Responsibility
Impact is received	Start or redirect a hit-reaction task	Convert impact context and select parameters
Balance remains recoverable	Enter balance or return-to-animation work	Preserve physical-to-animation continuity
Balance fails	Add failure handling or enter a fall task	Keep the failure state explicit
Vertical speed crosses a threshold	Degrade into a high-fall task	Change task identity according to physical context
Return blend is interrupted	Cancel the blend task and install a new response	Keep the interruption traceable

This table is the part that can become a UE5 acceptance specification before the physical solver is available. The solver remains replaceable because the task layer cares about inputs, outputs, and transitions rather than its internal numerical method.

Additional mechanism notes: why physical takeover is not the end of the behavior system.

There are two tempting but incomplete implementations. The first is a global collision hook that immediately switches a character into a physical state. The second is a one-way handoff that waits for the player to move away before deleting or resetting the character. Both hide ownership and lifecycle.

The task-oriented design makes the handoff explicit. A task decides when physical control is appropriate, the physical bridge reports whether balance or recovery is possible, and a return task decides when animation authority can be restored. A scripted fall can request the same family through the task interface. A network clone can serialize the task identity and its relevant parameters. A later interruption can replace the physical task through the normal priority path.

The physical system therefore remains a presentation mechanism, but it is not an unmanaged escape hatch. It is a downstream owner with a defined entry, an observable middle, and a defined return.

Evidence, blind spots, and migration confidence.

The original-side evidence is strongest at the task boundary and weakest inside the physical-control solver. The task names, task relationships, input dimensions, state transitions, and retirement behavior are supported by the current notes. The internal balance controller, muscle-drive calculation, and solver integration are not.

That split changes the wording of the migration plan. It is justified to specify a task family, an input schema, a transition ladder, a physical adapter, and a return task. It is not justified to claim a particular solver, controller, or parameter curve without a separate implementation study. The UE5 landing article must therefore start from the seam and acceptance cases, not from an assumed solver implementation.

V. Four Cross-Cutting Lines in the Pedestrian Runtime

Task identity: sitting, fleeing, taking cover, and ragdoll are not isolated rendering states. Every observable state should have a task identity in the runtime.

The four chapters share four boundaries:

1. Decision and execution are separated by explicit routing. Event-to-response routing, selector-to-wrapper routing, and metadata-to-task dispatch all preserve a replaceable mapping layer.
2. Every behavior has an owner. The selector owns policy, the wrapper owns entry conditions and continuity, the executor owns the concrete performance, the scenario system owns point content, and the physical bridge owns the handoff into simulation.
3. A handoff preserves three responsibilities: entry conditions, observations during the handoff, and the exit that returns authority.
4. Physical takeover does not remove task identity. Interruption, priority, serialization, and scripting remain meaningful while physics is active.

The practical test is simple: if a visible state exists without a task identity, part of the behavior has escaped the scheduler. That state will eventually create an ownership or cleanup defect.

VI. Behavior-chain Example: From Perception Event to Execution State

Consider one NPC sitting at a bench. The scenario point and dispatch bridge created the occupation, and the control wrapper retains the return handle. A gunshot enters the event candidate queue and is adjudicated as passive fear rather than a full flee response. The selector chooses cover. The transition wrapper prepares the context, and the scenario execution model supplies the crouch-and-cover performance.

Before the threat is resolved, a vehicle clips the bench. The impact event promotes the NPC into a physical-reaction task. The hit task selects parameters from impact location and relative speed, activates physical control, and reaches a balance outcome. The return-to-animation task then restores locomotion authority.

Once the threat is gone, the scenario wrapper attempts to re-enter the original bench occupation. If the bench is occupied or the area has entered an exclusion volume, re-entry is rejected through the normal admission path and the NPC falls back to default wandering. Recovery is subject to the same validity rules as initial entry.

This is an original-system coordination example, not a claim that the complete chain already runs in the prototype. In the prototype, the event candidate, response-table, task-slot, and suppression skeleton exists from Part 1. The execution side described here remains a specification and an end-to-end acceptance scenario.

The missing pieces are equally instructive:

• without adjudication, the entire street may react at once;
• without three layers, contextual cover logic spreads through the flee task;
• without scenario continuity, the bench occupation is lost after interruption;
• without physical task identity, network peers see an unexplained fall;
• without the return bridge, the skeleton jumps from a physical pose to the first animation frame.

These are more useful acceptance checks than the subjective question of whether the street “feels alive.”

VII. Migration Trade-offs and Delivery Checklist

Area	Original mechanism	Prototype status	Migration decision
Task execution	selector → transition wrapper → executor	③ Not started	build the task organization; reuse navigation and animation inside leaf execution
Response family	response table and passive-fear task family	response-table skeleton only	implement one executor first, then wrapper and selector
Scenario points	storage, metadata, coordinator, dispatch bridge	③ Not started	use world-partition data and Smart Objects for point data and claims
Scenario continuity	wrapper, occupation handle, return path	③ Not started	reuse task-slot lifecycle and explicit occupation state
Scenario ecology	clusters, exclusion volumes, coverage validation, vehicle generation	③ Not started	build as world-side producers and validators, not as point-local scripts
Locomotion	movement intent → locomotion → animation	③ Not started	custom intent package and adapter; reuse UE animation stack
Physical reactions	task family, input dimensions, degradation ladder, return task	③ Not started	custom handoff protocol; reuse physical foundation; leave solver internals as a blind spot

The first playable pedestrian milestone does not require the complete response family. It requires movement, scenario occupation, event adjudication, interruption, and recovery: people walk, some sit, a gunshot interrupts them, and a valid scenario occupation can be restored.

The article has no line marked “① implemented” for the execution and presentation side. That is deliberate. Its deliverables are three explicit seams—task orchestration versus engine facilities, movement intent versus animation, and behavior versus physics—plus two reuse decisions, Smart Objects and the UE animation stack, and a set of acceptance-ready structures: passive-fear layering, scenario-backed cover, wrapper continuity, scenario ecology, physical-reaction ladders, and the return-to-animation bridge.

Three General Rules for the Pedestrian Execution Layer

First, treat a new behavior as content of an existing mechanism whenever the ownership and lifecycle fit. Cover can be scenario content; it does not automatically require a new presentation runtime. Physical reaction can be a formal task; it does not require a second scheduler. The operational question is: which existing owner can carry the complete lifecycle?

Second, interruption requires continuity. Clean exit prevents stale state. A return handle preserves the possibility of recovery. Occupation state must also be retained or released according to interruption duration; otherwise a short interruption gradually converts a populated street into a set of invalid scenario occupations.

Third, handing control to physics does not mean abandoning control. Physical presentation is a managed journey with inputs, degradation levels, and a return bridge. Every handoff—animation, navigation, Smart Objects, or physics—should preserve entry conditions, in-flight observation, and a valid exit.

AI Collaboration Review

AI is responsible for establishing the specification; people are responsible for deciding the specification. The useful output of this article is not a larger pile of original-system details. It is the separation between structures that should become migration specifications and details that remain blind spots or future planning items.

The review consolidated the strategy-versus-execution pattern across the pedestrian and vehicle articles, aligned the ownership chain of scenario storage, metadata, coordination, and dispatch, and identified reusable correspondences: invalid scenario occupation versus invalid vehicle occupation, cover as scenario content, clusters as world-side assemblies, and movement intent as the pedestrian counterpart of driving commands.

Two initial judgments changed during the deeper read. First, ragdoll was initially treated as a short design-position chapter; the task identity, transition ladder, return bridge, and input dimensions support a structural deep dive, while the solver remains a blind spot. Second, the scenario system was initially described as points plus tasks plus wrappers; clusters, exclusion volumes, coverage validation, and vehicle generation complete the world-side ecology.

The central boundary remains unchanged: prototype progress and original-system evidence depth are independent variables. A subsystem can be unimplemented in UE5 while still providing a precise, testable migration specification.

Honest boundary.

The following remain blind spots or future landing-article topics:

• animation blend-tree internals;
• navigation and pathfinding internals;
• physical-control solver internals;
• the scheduling algorithm for multiple parallel task trees;
• detailed gait state machines and turn prediction;
• precise streaming triggers and cluster coordination in the prototype.

These boundaries are intentional. The article records the responsibilities, state transitions, parameters, and seams that can be supported by the current evidence. It does not present unimplemented UE5 behavior as completed work.