Learn Interaction

Use this page to understand how Dynaros Interaction thinks about interactors, interactables, prompts, and requests before you jump into exact API details.

The Core Idea

Interaction separates the request from the result.

The interactor says:

I want to interact with this target.

The target or owning gameplay system decides:

Here is what interaction means for me.

That is why the same interaction plugin can support doors, NPCs, switches, resource nodes, crafting stations, pickups, and project-specific actors without needing to understand every possible outcome.

Main Pieces

UInteractorComponent

UInteractorComponent lives on the actor that initiates interactions.

Most projects will put it on the player character or pawn, but it does not have to be player-only. AI actors or other gameplay objects can also initiate interactions if your project needs that.

In practice, this is the component that gives an actor the ability to look for or receive an interaction target and request interaction from it.

UInteractableComponent

UInteractableComponent adds reusable interaction-facing behavior to a world actor.

It can hold common information such as prompt text, enabled state, and focus-related events. This keeps simple interactables from needing to duplicate the same setup over and over.

The component does not need to own the final gameplay result. A door still owns door behavior. A resource still owns resource behavior.

IInteractable

IInteractable is the contract a target fulfills when it can receive an interaction request.

The interactor does not need to know whether the target is a door, NPC, switch, ore node, or crafting station. It only needs a stable way to say, “handle this interaction request.”

Conceptually:

Interactor: "You are interactable. Handle this request."
Target:     "I know what interaction means for me."

AInteractableActor

AInteractableActor is a reference/example actor that demonstrates the component and interface pattern.

It can be useful to inspect or subclass when it fits your project, but it is not meant to become a required base class for every interactable object.

Existing actors should be able to opt into Interaction without being rebuilt around a Dynaros inheritance tree.

Interaction Lifecycle

A useful way to think about Interaction is as a lifecycle, not just a button press.

1. Discovery

The interactor finds or receives a possible interaction target.

Different projects may use different discovery policies: traces, overlap volumes, proximity, camera-centered targeting, AI selection, or an external targeting system.

2. Validation

Interaction checks whether the target can participate at the generic interaction level.

Examples:

• Is there a valid target?
• Does it expose the interaction contract?
• Is interaction currently enabled?

Feature-specific rules belong elsewhere. For example, “does the player have the correct axe?” belongs to a resource, gathering, inventory, or project gameplay system.

3. Focus And Presentation

When a target becomes the active candidate, Interaction can expose generic prompt information.

Examples:

• Harvest Berry Bush
• Open Door
• Talk
• Use Workbench

The UI can display this without casting to a project-specific target class.

4. Request

Input or another caller tells the interactor to perform the current interaction.

5. Dispatch

The request reaches the target through the shared interface or public interaction API.

6. Gameplay Response

The target or owning gameplay system performs the actual behavior.

7. Refresh

After the action, Interaction may need to refresh prompt data, eligibility, or the current target if the world changed.

Interaction Flow

Input / Gameplay Request
        v
UInteractorComponent
        v
Target Discovery
        v
Interaction Validation
        v
Current Target + Prompt Data
        v
IInteractable Contract
        v
Target Receives Interaction
        v
Owning Gameplay System Responds
        v
Interaction State Refreshes

Interaction Eligibility Vs Gameplay Eligibility

There are two different kinds of validation.

Interaction-Level Eligibility

Interaction can reasonably answer:

• Is the target valid?
• Does it implement the interaction contract?
• Is interaction enabled?
• Is the target in an acceptable generic discovery state?

Gameplay-Level Eligibility

Another system or the target actor should answer:

• Does the player have the correct tool?
• Is this resource depleted?
• Has this quest step been unlocked?
• Does the player have enough currency?
• Is this crafting recipe available?
• Is the building owned by this player?

Keeping these separate prevents Interaction from becoming the universal rule engine for every feature that starts with an interact button.

UI And Prompts

Interaction prompts consume interaction state. They should not be the source of interaction logic.

A prompt widget can use generic data such as display text, whether a target is currently interactable, and optional presentation metadata as the product matures.

The widget should not need to cast to a project’s player character, resource actor, NPC class, or other game-specific type just to show a prompt.

Optional UI

Interaction can provide default or example prompt UI, but the runtime plugin should remain useful if your project supplies its own UI.

A packaged prompt widget can be:

• a ready-to-use default
• a reference implementation
• an example of consuming the API correctly

It should not become mandatory for the interaction logic itself.

Input

Interaction supports Enhanced Input, but your project owns its input choices.

Your project decides:

• which key or controller button triggers interaction
• whether there are alternate interaction inputs
• when interaction input is enabled
• which input mapping contexts are active

Interaction exposes callable behavior. Your project decides how input reaches it.