Developer Workflows

Module Dependencies

Add only the modules your project code uses directly. Runtime gameplay code that includes target components, interactor components, target definitions, requirements, execution actions, prompt providers, save types, or settings needs the runtime module and its public dependencies.

PublicDependencyModuleNames.AddRange(new string[]
{
    "Core",
    "CoreUObject",
    "Engine",
    "GameplayTags",
    "DeveloperSettings",
    "EnhancedInput",
    "InteractionFrameworkAPI",
    "InteractionFrameworkRuntime",
});

UI code that subclasses prompt widgets or uses the UI manager should depend on the UI module and UMG.

PublicDependencyModuleNames.AddRange(new string[]
{
    "Core",
    "CoreUObject",
    "DeveloperSettings",
    "Engine",
    "InteractionFrameworkAPI",
    "InteractionFrameworkRuntime",
    "InteractionFrameworkUI",
    "UMG",
});

Editor integrations should stay in editor modules and depend on the editor module plus Unreal editor libraries.

PrivateDependencyModuleNames.AddRange(new[]
{
    "CoreUObject",
    "Engine",
    "Slate",
    "SlateCore",
    "InputCore",
    "EnhancedInput",
    "UnrealEd",
    "AssetTools",
    "PropertyEditor",
    "AppFramework",
    "ContentBrowser",
    "Projects",
    "EditorFramework",
    "GameplayTags",
    "InteractionFrameworkAPI",
    "InteractionFrameworkRuntime",
    "InteractionFrameworkUI",
    "InteractionFrameworkEditor"
});

Public Include Areas

• InteractionAPI: shared ids, input type enums, and interactor state structs.
• Authoring: target definitions, variants, command rows, policy profiles, projection settings, payload authoring, and validation-facing data.
• Targeting: target component and target-side runtime state.
• Interactor: interactor component, focus, visible handles, projection, progress, and activation request data.
• Requirements: requirement base class and built-in requirement classes.
• Execution: execution action base class, trigger policies, cooldown/disable policies, and built-in actions.
• Prompt: prompt text provider and prompt build context.
• Persistence: save snapshot structs, interfaces, auto-export handle, and Blueprint library.
• UI: widget payload base in runtime, UI manager and widget base in the UI module.

C++ Extension Points

C++ projects can subclass the same extension points as Blueprint projects: UInteractionRuntimeRequirement, UInteractionCommandExecutionAction, UInteractionRuntimePromptTextProvider, UInteractionRuntimeWidgetPayload, and UInteractionUIWidgetBase. Use UINTERFACE/IInterface pairs correctly: the U type exposes reflection and Blueprint metadata; the I type contains implementation functions.

Authority Guidance

When C++ code calls target or interactor state-changing functions, respect the same authority boundary used by Blueprint. Read paths can support UI and diagnostics. Writes to shared target state, command execution outcomes, save import, route state, cooldowns, disables, and variant overrides should be made through server-owned gameplay flow.

Practical Integration Pattern

1. Depend on the smallest module set needed by the code being compiled.
2. Keep runtime gameplay code out of editor modules.
3. Keep editor customizations out of runtime modules.
4. Use public ids and context structs instead of reaching into private target/interactor state.
5. Prefer target definition data for content and C++ subclasses for reusable behavior.

Runtime Versus Editor Module Boundary

Runtime modules can be loaded in game builds and should not depend on editor-only APIs. Editor modules can depend on UnrealEd, AssetTools, PropertyEditor, and editor services. If project integration needs custom authoring tools, put that code in an editor module. If it needs gameplay behavior, put it in a runtime module.

Public API Discipline

Use public headers, Blueprint-exposed functions, and documented structs. Avoid reaching into private runtime/editor implementation details even if the source is visible in the plugin directory. Private helpers may change without being part of the public integration surface.

C++ Review Checklist

• Build.cs dependencies match the headers being included.
• Runtime code does not include editor-only headers.
• Authority-only functions are not called as if they were local cosmetic updates.
• Interface implementation uses the IInterface side for C++ functions and the UINTERFACE side for reflection exposure.
• Custom subclasses are reusable and configured through properties where designers need control.