Advanced Interaction

Use this page when you want to understand deeper Interaction architecture, extension points, and future-facing design direction.

Some items here describe current behavior. Others describe planned or candidate directions. Those are called out so you can tell the difference.

Extension Model

Interaction is designed to support more than one level of customization.

Blueprint Extension

Blueprint users should be able to:

• configure interactable properties
• react to focus and unfocus events
• respond when interaction is requested
• supply display text
• enable or disable interaction
• connect project-specific results

This path should not require rewriting core detection and dispatch logic.

C++ Extension

C++ users can work directly with the runtime contracts.

Potential C++ paths include:

• implementing IInteractable
• subclassing reference implementations when useful
• calling interaction APIs directly
• integrating Interaction with project-specific gameplay systems
• replacing or extending target discovery when that API is formalized

Data-Driven Extension

Future versions may move more interaction metadata into structs or data assets.

That could make repeated interaction patterns easier to reuse without turning simple interactables into heavy configuration projects.

Runtime Plugin Vs Example Content

The runtime plugin is the part real projects build against.

Runtime pieces include:

• interaction components
• public contracts and interfaces
• generic interaction data
• core dispatch logic
• optional prompt support
• logging

Example content exists to teach or demonstrate the plugin.

Example content may include:

• AInteractableActor
• example Blueprint interactables
• example input setup
• example prompt styling
• small demo maps or actors

Example content should not become a hidden dependency. Your project should be able to use Interaction without rebuilding itself around the examples.

Multiplayer Direction

Multiplayer behavior is not finalized yet.

The current architecture should still avoid choices that make networking painful later. Likely multiplayer concerns include:

• which machine performs target discovery
• server validation of interaction requests
• preventing clients from authoritatively granting rewards or changing protected state
• replicating interactable state when necessary
• avoiding duplicate interaction execution
• handling interactions whose results are player-specific versus globally visible

A likely model is responsive local discovery and presentation, followed by server-authoritative validation for gameplay consequences.

Exact RPC ownership and replication behavior will need to be documented once the multiplayer contract is finalized.

Design Boundaries

Interaction should stay focused on generic interaction.

It should not become the system that calculates loot, modifies inventory, awards skill XP, advances quests, performs dialogue logic, or owns resource depletion.

Those systems can respond to interaction. They should not be absorbed into Interaction.

Practical rules:

• avoid casts to project-specific player classes for core interaction behavior
• keep dispatch separate from gameplay consequences
• prefer components and interfaces over required inheritance
• let projects choose input bindings and discovery policy
• treat optional UI as presentation
• revalidate volatile targets rather than trusting stale references forever
• add features only when they improve generic interaction

Candidate Future Features

These features are not guaranteed APIs yet, but they describe likely areas of exploration.

Interaction Context

A generic context structure could carry information such as initiating actor, target actor, interaction source, hit or location data, and optional gameplay tags.

This would make it easier to add detail to an interaction request without continually changing public function signatures.

Multiple Interaction Options

A target may eventually expose several actions.

Door
|-- Open
|-- Lockpick
`-- Inspect

This needs a clean option model rather than hard-coded action-specific functions.

Hold Or Timed Interaction

Timed interactions may be useful for gathering, reviving, unlocking, repairing, or other actions that should not complete instantly.

Interaction Priority

Dense scenes may need explicit rules for choosing between overlapping interactables.

Gameplay Tag Metadata

Tags could describe generic interaction categories or requirements while keeping systems loosely coupled.

Network-Aware Validation

Server-authoritative request and validation patterns should be added once the core interaction contract is stable enough to support them cleanly.

Accessibility And Presentation Hooks

Future prompt data may expose richer presentation information without tying Interaction to one UI style.

Open Questions

These areas are still being evaluated:

• whether target discovery should remain built into UInteractorComponent or become a swappable strategy
• whether UInteractableComponent should own simple text directly or expose a broader data structure
• whether interaction execution should return a structured success or failure result
• how to represent multiple options without making simple one-action objects complicated
• what minimum networking API belongs in the first multiplayer-ready version
• which prompt features belong in runtime versus optional UI/example content

Long-Term Interaction Definitions

A future Interaction Definition could describe reusable behavior at the generic interaction level.

Possible definition areas:

Interaction Definition
|-- Identity / Presentation
|-- Execution Mode
|-- Generic Requirements
|-- Targeting
`-- Lifecycle Hooks

Definitions could help many actors share prompt text, hold behavior, cancellation rules, interaction points, and lifecycle events.

They should not replace Inventory, Gathering, Quest, Skill, Progression, or other gameplay owners. Feature-specific requirements and consequences should remain with the systems that own them.

Long-Term Editor Tooling

A dedicated Interaction Definition Editor may become useful later.

The editor could provide focused areas for presentation, timing, targeting, lifecycle hooks, validation warnings, preview tools, and optional Dynaros integrations.

That tooling would sit above the runtime architecture. Interaction definitions should remain usable from code or data even if a project never opens a custom editor.