Door Interaction

Goal

This recipe builds a simple door-style interaction: the player focuses a door handle or panel, sees an Open prompt, presses the command input, and the command changes target/gameplay state through an execution action.

Author The Definition

1. Create a UInteractionRuntimeTargetDefinition asset.
2. Use the starter point, starter variant, and starter command row if the editor created them.
3. Assign a stable FInteractionRuntimePointId such as Interaction.Point.Door.Handle.
4. Keep the single default variant unnamed unless the door needs locked/unlocked variants now.
5. Assign a stable FInteractionRuntimeCommandId such as Interaction.Command.Open.
6. Set the command to an interactive instant input pattern and assign a Boolean input action.
7. Add prompt text through the command prompt provider or template.

Attach Runtime Components

1. Add UInteractionRuntimeTargetComponent to the door actor and assign the definition.
2. Add a point binding from the point id to the handle or panel component when the prompt should follow a mesh/socket.
3. Add UInteractionRuntimeInteractorComponent to the player pawn if it is not already present.
4. Confirm the local UI manager uses a widget based on UInteractionUIWidgetBase.

Add The Door Outcome

For a reusable data-only outcome, use a built-in action such as UInteractionCommandDisableInteractionAction if the door prompt should disappear after use, or UInteractionCommandSetTargetEnabledAction if another target should become enabled. For project-specific door animation, subclass UInteractionCommandExecutionAction and trigger the door’s gameplay event on completion.

Verify In Play

• The prompt shows at the handle or panel, not the actor origin.
• The Open command shows the intended input.
• The command activates once per input press.
• The execution action runs only on the intended outcome.
• After activation, any disabled/cooldown/variant state is reflected in the next prompt update.

Common Problems

No prompt usually means missing target registration, missing point id, wrong point binding, range/view threshold, or UI binding. Prompt without activation usually means missing input action, failed requirement, cooldown, busy state, or authority rejection.

Optional Locked Door Variant

After the basic Open command works, add a locked state as a second variant. Give the locked variant a stable FInteractionRuntimeVariantId. The locked variant can expose a locked prompt, a requirement-gated unlock command, or a different execution action. Use target component variant override functions when gameplay should switch between locked and unlocked states.

Optional Persistence

If the door should remain opened or unlocked after loading, assign a stable target save id before shipping. Persist the state through Save And Restore Interaction State. Do not rely on display text or actor label as save identity.

Door Recipe Test Matrix

• Fresh level load: door prompt is in the default state.
• Focus from several angles: prompt remains stable near the handle.
• Activation: command fires once and execution action changes state.
• After state change: prompt updates, disables, cools down, or switches variant as authored.
• Multiplayer: server state change replicates to clients.
• Save/load if enabled: opened, disabled, cooldown, or variant state restores.

Blueprint Wiring

For a Blueprint-only door, bind OnCommandEvent on the target component or implement a custom UInteractionCommandExecutionAction Blueprint. The delegate route is useful when one actor owns the response. The execution-action route is better when designers should reuse the same behavior across several definitions.

Door State Choices

• One-time door: disable the command after success.
• Reusable door: apply a short cooldown after success.
• Locked door: use a locked variant with a requirement or a separate Unlock command.
• Remote door: use an execution action that changes another target or project system on authority.

Content Review Questions

Can a designer tell which point is the handle, which command opens the door, which input activates it, and what state changes after success? If not, improve ids, prompt text, theme color, or action naming before adding more logic.