Single Variant Points
A point that has one variant is the simplest state model. Keep the starter variant unnamed unless another system needs a stable tag. The point still uses that variant’s command rows, requirements, UI payload override, projection override, and proximity override. The empty id is not a problem for the default fallback path; it becomes a problem only when more than one authored state needs to be addressed independently.
This is the recommended first step for every new interaction. Build the point, command, prompt, and execution flow with one variant. After that works, split the command surface into named variants only where the product actually needs state.
Multiple Variants
When a point has multiple variants, give each variant a stable FInteractionRuntimeVariantId. Avoid changing those tags after content ships because prompt state, route identity, save snapshots, and Blueprint comparisons can depend on them. Keep one clear fallback variant for the normal state so the interaction still has a useful command surface when special states stop passing their checks.
Do not duplicate the same command rows across variants unless the command really changes by state. If the command is identical and only the prompt text changes, prefer a prompt text provider or widget payload. If the command availability changes, use command requirements. If the entire command surface changes, then a variant is the right tool.
Manual Shared Selection
Manual shared selection is best for state owned by gameplay code: opened doors, disabled machines, filled containers, puzzle steps, or any state already replicated by an actor. Set the shared point variant through SetPointVariant when every interactor should see the same state. Use SetSavedPointVariant when the override should be exported into interaction save data.
Clear shared overrides with ClearPointVariantOverride or ClearSavedPointVariantOverride when the target should return to its authored default or automatic resolution path. Use GetResolvedVariant to inspect the current target-level variant for a point.
Manual Local Selection
Use local manual selection through SetLocalPointVariant when the same target should show different state to different interactors. Local variants are useful for personal quest prompts, player-specific hints, local-only accessibility variants, split-screen player state, or inventory state that differs per player.
Local overrides are keyed by target id and point id. Clear them with ClearLocalPointVariantOverride when the personal state should stop applying. Use SetSavedLocalPointVariant and ClearSavedLocalPointVariantOverride when local overrides should participate in interaction save data.
Automatic Selection
Automatic selection uses the point or linked group Variant Selection Mode and the selected variant’s Enter Requirements list in the Variant Details panel. In API, those rows are stored as SelectionRequirements. The selection stage evaluates entries with EInteractionRuntimeRequirementEvaluationStage Selection, so a custom requirement can distinguish variant picking from point visibility or command activation. Use EInteractionRuntimeVariantSelectionScope Shared when the selected variant should be resolved at the target level and replicated as target state. Use PerInteractor when the selected variant depends on the interactor.
Enter Requirements should be lightweight and stable. They may run during runtime refresh, focus resolution, and prompt rebuilds. Keep expensive checks outside the requirement when possible, and feed the requirement with cached game state instead. If a selection requirement needs local player data, use per-interactor selection so the target does not resolve a single shared answer from local-only state.
Enter And Exit Delays
EInteractionRuntimeVariantTransitionDelayPolicy controls whether automatic variant changes apply immediately or wait for the authored enter/exit delay. Use immediate transitions for deterministic state changes such as a puzzle switch. Use delayed transitions to reduce prompt flicker when an automatic requirement may toggle quickly, such as a range-sensitive, player-count-sensitive, or rapidly changing condition.
Enter delay waits before a candidate becomes active. Exit delay waits before the current candidate leaves. In Manual selection mode, the editor warns that Enter Requirements and enter/exit transition settings are ignored. Keep those rows empty and delay policies immediate when the point is manual.
Runtime Queries
ResolveEffectiveVariantForInteractor reports the effective variant for a specific interactor, including whether it came from default, shared override, local override, shared automatic selection, or local automatic selection through FInteractionRuntimeEffectiveVariantResolution and EInteractionRuntimeEffectiveVariantSource.
Validation Checklist
- One-variant points can keep the starter variant unnamed.
- Multi-variant points need stable variant ids.
- Automatic variants need Variant Details Enter Requirements rows that can be evaluated from the available runtime context.
- Per-interactor variants need an interactor path; shared variants should not depend on local-only state.
- Manual points should not rely on Enter Requirements or automatic transition delays.
- Saved variant overrides need stable target save ids and owner save ids.
- Delay policies should be tested around the moment the requirement changes so prompts do not feel stuck or noisy.