Choose The Layer
Author point requirements when the whole point should be hidden or unavailable. This is the right layer for broad access checks such as distance-independent visibility, actor state, locked interaction zones, or permission rules that should affect every command under the point.
Author variant requirements when one state should exist but only be usable under a condition. This is different from Enter Requirements: a variant requirement blocks use of the variant, while an Enter Requirements row helps the runtime choose that variant automatically.
Author Enter Requirements in the Variant Details panel when automatic variant selection should choose that variant. Enter Requirements are evaluated at EInteractionRuntimeRequirementEvaluationStage Selection. They should answer “is this the active state for this context?” rather than “can this command execute?”
Author command requirements when only one command row should be unavailable while the point and other commands remain visible. This is the right layer for missing key, story progress, no ammo, insufficient skill, or already-busy checks that should affect one action choice.
How Evaluation Works
Each requirement entry calls UInteractionRuntimeRequirement::Evaluate with an FInteractionRuntimeRequirementContext. Return true to pass the requirement and false to fail it. The entry can then invert the result when bInvert is enabled, and the expression service combines rows with the authored AND/OR operands and indentation.
The context includes the evaluation stage, interactor, target component, target actor, instigator actor, allowed instigators, point id, command id, and the active point/variant/command requirement lists. Use those fields to read project state and choose the correct branch. Do not perform gameplay side effects inside Evaluate because it may run during prompt building, automatic variant selection, and server validation.
Requirement Entries
Each FInteractionRuntimeRequirementEntry contains an instanced UInteractionRuntimeRequirement, an EInteractionRuntimeRequirementOperand, expression indent, and inversion flag. Start with a flat AND list. Add OR entries only when a designer needs alternatives such as keycard OR admin role. Use inversion for small negative checks; if the requirement graph becomes hard to read, split the condition into a purpose-built requirement class.
In the editor, each requirement row exposes an IF/AND style row, a requirement object picker, a Must Pass/Must Fail result control, and row actions for adding or removing entries. Expression indent supports lightweight grouping in the editor. Keep groups shallow and readable. A requirement list is part of content authoring, so another designer should be able to read the row and understand why a point, variant, or command is blocked.
Failure UI
EInteractionRuntimeRequirementUIPolicy controls how a failed client-side requirement should be represented. Inactive keeps the prompt visible as blocked. ForcePOI can keep point-of-interest presentation visible. Hide removes the prompt or point from UI. The failure policy also records the blocking requirement class and object so prompt text providers can build specific locked or unavailable copy.
Use one deny UI policy per scope when possible. Mixed policies in a single requirement list are harder to predict and the editor validation warns about mixed policy masks. If one requirement should hide and another should show inactive, consider moving one check to a different layer or creating a single requirement that owns the final policy decision.
Built-In Requirement Types
UInteractionRuntimeAlwaysPassRequirement is useful as an explicit placeholder while a designer is wiring content. UInteractionRuntimeAlwaysFailRequirement is useful for disabled test states or content that should be intentionally blocked. UInteractionRuntimeLocalPlayerCountRequirement compares a configured player count against local or session player counts using its count source, comparison operator, and player count fields.
Prompt Text For Failures
Each UInteractionRuntimeRequirement can own a UInteractionRuntimePromptTextProvider through its Prompt Text Provider field. Use that for failure copy that belongs to the requirement itself, such as locked door text, party-size text, missing-key text, or “requires two local players.” Command-level prompt providers remain responsible for normal available text.
Placement Examples
- Locked room volume: point requirement, Hide or Inactive depending on whether the prompt should be revealed.
- Door locked versus unlocked: Enter Requirements rows on Locked and Unlocked variants.
- Open command requires a key: command requirement with a requirement prompt text provider.
- Two-player local switch: command requirement or multi-participant route configuration, depending on whether both players must participate in the interaction flow.
- Quest-specific extra command: variant or command requirement, depending on whether the whole state or only one command changes.
Authoring Checklist
- Keep broad visibility checks at the point layer.
- Keep state choice checks in Enter Requirements.
- Keep action-specific checks on the command row.
- Return true for pass and false for fail from Evaluate.
- Set UI policy intentionally so blocked prompts either stay visible, become point-of-interest only, or disappear.
- Give important blocking requirements a prompt text provider when the default failure text is not specific enough.
- Keep requirement evaluation free of gameplay side effects.