What A Variant Controls
A variant is an authored state inside a point or linked group. Each FInteractionRuntimeVariantDefinition can provide command rows, requirements, editor-facing Enter Requirements, UI payload overrides, projection overrides, proximity overrides, participation policy overrides, and transition delay settings. Runtime prompt, route, and save data identify variants with FInteractionRuntimeVariantId.
Use variants when the same physical interaction point should behave differently without swapping actors or duplicating target definitions. A door handle can expose Open while locked, Unlock while the player has a key, and Close after the door opens. A loot container can expose Search before it is emptied and Inspect after it has no loot. A terminal can expose different command rows for powered, unpowered, and administrator states.
Default Variant Behavior
The target definition editor creates starter interaction content so a new definition can begin with one point, one variant, and one command row. With only one variant, the variant id can remain empty and the runtime treats it as the fallback active variant. That is the right starting point: assign a point id, assign a command id, assign input, and make the first interaction work before adding state.
Add explicit variant ids when the point has more than one state or when Blueprint/C++ code needs to set, save, compare, or display a specific state. Once variants are named, keep the tags stable. Variant ids can appear in route identity, prompt presentation, save snapshot records, Blueprint comparisons, and runtime queries.
What Belongs In A Variant
Put state-specific command rows in the variant. Put state-specific availability checks in variant requirements. Put automatic state-choice checks in the Variant Details panel under Enter Requirements. Put state-specific prompt widget selection in the widget payload override. Put state-specific placement or screen behavior in projection overrides. Put state-specific range and view-dot behavior in proximity overrides.
A variant should describe the interaction state, not the entire actor state. If a door has health, material, animation, and sound state, the variant only needs to represent the parts that affect interaction prompts and execution choices.
Choosing A Selection Strategy
Use EInteractionRuntimeVariantSelectionMode Manual when gameplay code owns the state. This is common for doors, machines, switches, puzzle steps, and saved world state. Runtime code can call SetPointVariant for shared state or SetLocalPointVariant for player-local state.
Use Automatic when the runtime should evaluate the Variant Details Enter Requirements rows and choose a candidate. Automatic selection is strongest for UI-facing state that follows existing conditions: player count, local quest state, requirement-gated prompts, or per-interactor affordances. Automatic selection can be shared or per-interactor through EInteractionRuntimeVariantSelectionScope.
How Variants Relate To Other Systems
- Requirements decide whether a point, variant, selection candidate, or command is available.
- Prompt providers can read the resolved variant id from prompt context and build state-specific copy.
- Widget payloads can be authored per variant to choose a custom widget or push state-specific visual data.
- Execution actions can change target state after a command completes, including enabling/disabling content or setting a variant.
- Save import/export can preserve saved variant overrides when target and owner save ids are stable.