Blueprint Integration Route
Blueprint users can build most project-facing behavior without writing C++. The recommended route is: author a target definition, add runtime components, confirm prompt UI, then add Blueprint subclasses for project-specific availability, execution, prompt text, widget payloads, widgets, and save storage.
Definition And Component Nodes
Use UInteractionRuntimeTargetDefinition for authored content. Add UInteractionRuntimeTargetComponent to interactable actors and UInteractionRuntimeInteractorComponent to pawns or actors that interact. Target component nodes manage target state; interactor nodes manage focus, visible surfaces, activation requests, paging, and local presentation state.
Requirement Blueprints
Subclass UInteractionRuntimeRequirement when command availability depends on project state. Examples include inventory checks, quest state, local player count, permissions, or external gameplay tags. Keep requirement logic side-effect free so it can be evaluated for prompt display and activation validation without changing game state.
Execution Action Blueprints
Subclass UInteractionCommandExecutionAction when a command outcome should change state. Use built-in cooldown, disable, and set-target-enabled actions before writing custom actions. Custom actions should read the execution context, apply project changes on the correct authority path, and avoid hard-coded actor references when reused across definitions.
Prompt Provider Blueprints
Subclass UInteractionRuntimePromptTextProvider when the text for available, unavailable, progress, cooldown, or participant states should be computed. Use FormatPromptTemplate to keep standard token replacement for custom provider output.
Widget Payload And Widget Blueprints
Subclass UInteractionRuntimeWidgetPayload for project-specific prompt visuals. Subclass UInteractionUIWidgetBase for the actual UMG prompt. Payloads carry display data; widgets render runtime state; neither should become the authority owner of target state.
UI Manager Nodes
UInteractionUIManagerSubsystem normally binds to the local pawn interactor automatically. Use BindInteractor for custom interactor ownership, non-pawn tools, or debug UI. Use widget base events to update visuals instead of polling target definitions.
Prompt Suppression Nodes
Use the prompt suppression Blueprint helpers when another local UI flow needs to hide Interaction Framework prompts without clearing focus or changing target state. Call SuppressInteractionPrompts before a full-screen overlay, reply animation, inspection screen, or blocking UI takes over. Call ClearInteractionPromptSuppression when that flow ends.
For focused UI flows that should keep the active prompt visible but hide unrelated nearby prompts, call SuppressNonFocusedInteractionPrompts on entry and ClearNonFocusedInteractionPromptSuppression on exit. Use stable reason names such as Inventory, Inspection, or ModalFlow so overlapping systems do not clear each other by accident.
Save Blueprints
Use UInteractionRuntimeSaveBlueprintLibrary to import, export, summarize, and schedule save snapshots. Implement IInteractionRuntimeSaveSnapshotStorage on a project save object when Blueprint save flow should own storage.
Blueprint Build Order
- Get one default command working with target/interactor components.
- Add a project widget based on
UInteractionUIWidgetBase. - Add requirements for project availability checks.
- Add execution actions for state changes.
- Add prompt providers and payloads for better presentation.
- Add save helpers once ids are stable.
Blueprint Debugging Route
Blueprint debugging is easiest when each layer has one responsibility. Put availability in requirement Blueprints, side effects in execution action Blueprints, text generation in prompt provider Blueprints, display-only data in widget payload Blueprints, and visual layout in widget Blueprints. If a Blueprint does more than one of these jobs, failures become harder to locate.
Event Binding Discipline
Bind delegates such as target command events, focused point changes, save state changes, and widget release events at the owner that can respond safely. Target command events are useful for gameplay systems that need to react to command outcomes. Widget events are useful for visual state. Save events are useful for scheduling persistence.
Blueprint Review Checklist
- No requirement Blueprint mutates gameplay state.
- No widget Blueprint changes replicated target state directly.
- Execution action Blueprints run only for the intended outcome.
- Prompt provider Blueprints return useful user-facing text.
- Save helper Blueprints use stable ids and import at the right time.