Targets
A target is an actor with UInteractionRuntimeTargetComponent. The component owns the runtime state for an interactable actor: registration, enabled state, point bindings, target reference ids, cooldowns, busy state, variant overrides, multi-participant routes, and save ids. It is the authority-owned side of command execution.
Interactors
An interactor is an actor component, usually UInteractionRuntimeInteractorComponent, that discovers registered target points, scores focus, keeps visible handles, builds resolved command surfaces, tracks prompt progress, and requests activation. In a player setup, the interactor usually lives on the pawn.
World Subsystem
UInteractionRuntimeWorldSubsystem stores registered target points and provides runtime lookup plus interaction save import/export support. Target components register with it. Interactors use the registered data to find focus candidates. Save helpers use it to capture and restore world interaction state.
Target Definitions
UInteractionRuntimeTargetDefinition is the authoring asset. It describes points, variants, command rows, linked groups, composite groups, requirement entries, execution actions, widget payloads, prompt providers, theme colors, and policy profiles. Runtime components consume this asset; designers should not treat component defaults as the main authoring surface.
Point Ids, Variant Ids, And Command Ids
Point ids name authored affordances. Command ids name user actions. Variant ids name alternate point states when a point has more than one variant. Point ids and command ids are required for real content; a single default variant can remain unnamed.
Variants
Variants let a point present different commands and overrides without creating a separate target component. A variant can override proximity, projection, policy, payload, and command configuration. Variants may be selected automatically from the editor-facing Enter Requirements list, exposed in API as SelectionRequirements, or set manually through target component APIs.
Linked Groups And Composite Points
Linked groups coordinate related points through shared group data. Composite points build a surface from multiple child points so the player can interact with a grouped object as one resolved command surface. Use these when the user-facing interaction is one choice made from several authored locations or sub-points.
Resolved Surfaces
A resolved surface is the interactor’s prompt-ready view of a point or composite. It contains command entries, prompt text, control entries, paging state, proximity state, availability state, route state, and widget payload data that the UI should display.
Prompt Projections
Projection data turns world or component locations into screen positions for prompt widgets. UI settings provide default clamp and alignment behavior, while point, variant, payload, and widget settings can override projection behavior for specific prompts.
Authority-Owned Execution
Commands are validated and executed through the target side. Client-side UI can show prompts and request activation, but state-changing calls such as enabling a point, setting a variant, applying cooldowns, disabling commands, and exporting authoritative state belong to the authority flow. Blueprint code that changes target state should run from the authoritative context unless the function explicitly supports local-only behavior.
End-To-End Data Flow
Content starts in UInteractionRuntimeTargetDefinition. The target component reads that content, registers point handles, and owns target state. The world subsystem stores registered point handles. The interactor queries those handles, resolves focus, and produces surfaces. The UI manager presents surfaces through widgets. Activation requests return to the runtime validation path and can execute actions. Save helpers export the resulting persistent state.
Authoring Data Versus Runtime State
Definitions are reusable authored data. Runtime state is what is currently enabled, focused, on cooldown, busy, selected, saved, or in a route. A common integration mistake is trying to edit the definition asset during play to change one actor’s state. Use target component state APIs for actor state and keep the definition as the reusable content source.
Id Stability
Target ids, point ids, command ids, variant ids, linked group ids, and save ids are not cosmetic once Blueprints, runtime handles, prompts, routes, or saves reference them. Treat them as product data. Rename display text freely; rename ids carefully.