Tala Esenlikler

Initial UE 5.7 release

Requirements

Requirement authoring, built-in requirement types, failure behavior, and custom Blueprint requirement workflows.

Interaction Framework 1.0.0 UE5.7

Where Requirements Fit

Requirements are reusable availability checks for interaction content. A requirement can hide or block a point, choose an automatic variant, make a command unavailable, or provide the failure context used by prompt text. The base type is UInteractionRuntimeRequirement; authoring stores requirements as FInteractionRuntimeRequirementEntry values on point, variant, selection, and command rows.

Use point requirements for broad access rules, variant requirements for state-specific availability, Variant Details Enter Requirements for automatic variant choice, and command requirements for the final action gate. The same requirement class can be reused in more than one layer because each evaluation receives an FInteractionRuntimeRequirementContext with the current stage, interactor, target, point id, and command id.

Evaluate Function

Every requirement class answers its condition through Evaluate. Return true when the current context should pass and false when it should fail. The runtime calls the same function for point, variant, selection, and command checks, so use FInteractionRuntimeRequirementContext and its evaluation stage to understand why the requirement is being evaluated.

Requirement evaluation can run while building UI prompts, resolving automatic variants, and validating activation. Keep Evaluate side-effect free: read gameplay state, but do not consume items, set variants, save data, spawn actors, or trigger commands. Put state changes in execution actions after a command outcome.

Authoring Model

A requirement entry combines one instanced requirement object with an EInteractionRuntimeRequirementOperand, expression indent, and optional inversion. This gives designers a small expression system for common Blueprint logic without turning every interaction into a custom Blueprint graph. Failed requirements return an FInteractionRuntimeRequirementFailurePolicy through the evaluation service so UI can decide whether a prompt is inactive, forced into point-of-interest display, or hidden.

Built-In Requirements

UInteractionRuntimeAlwaysPassRequirement and UInteractionRuntimeAlwaysFailRequirement are useful for authoring placeholders, validation, and explicit disabled states. UInteractionRuntimeLocalPlayerCountRequirement checks a local player count using its configured comparison, count source, and player count fields.