Custom Requirements

Create A Requirement Class

Subclass UInteractionRuntimeRequirement in Blueprint or C++. The class is Blueprintable, edit-inline, default-to-instanced, and designed to be placed directly inside target definition requirement arrays. Override Evaluate and return true when the interaction should pass for the supplied FInteractionRuntimeRequirementContext.

Make the class name describe the gameplay question it answers: Has Key, Has Quest Flag, Is Team Member, Is Machine Powered, Has Enough Currency, or Is Local Player Count. Avoid generic names that force designers to open the Blueprint graph to understand what the requirement means.

Implement Evaluate

In Blueprint, override the Evaluate event and return true when the current point, variant, selection candidate, or command should pass. Return false when the requirement should block it. In C++, override EvaluateNative; the BlueprintNativeEvent implementation forwards to that native function by default.

Evaluate can be called more than once while the UI is being rebuilt or while automatic variants are being resolved. Treat it as a pure query over current state.

Read The Context

The context provides the interactor component, target component, instigator actor, allowed instigator actors, target actor, point index, point id, command id, requirement lists from the active point/variant/command, and evaluation stage. Use point and command ids for content-specific branching, and use the component references to read project state that lives on the actor or pawn.

Use EInteractionRuntimeRequirementEvaluationStage when the same class can run in more than one layer. For example, a power-state requirement can return true at point stage so the point remains visible, return true for a Powered selection requirement when the machine is powered, and return false for a Repair command when the machine is already repaired.

Keep Evaluation Predictable

Requirement evaluation should answer a question; it should not change gameplay state. Avoid spawning actors, changing inventory, setting variants, writing save data, or triggering commands from Evaluate. Those behaviors belong in execution actions. Deterministic requirements produce stable prompt UI and make automatic variant selection easier to reason about.

If a requirement depends on expensive project state, cache that state in a subsystem, actor component, ability system, or game-state object and read the cached answer from Evaluate. Prompt rebuilds and selection checks should stay responsive.

Blueprint Workflow

1. Create a Blueprint class derived from UInteractionRuntimeRequirement.
2. Add editable variables for the state the designer should configure, such as a required gameplay tag, key id, team id, item id, or minimum count.
3. Override Evaluate and branch on the FInteractionRuntimeRequirementContext fields that matter.
4. Set Client Deny UI Policy and Block Scope on the requirement instance in the target definition.
5. Add a requirement prompt text provider if the blocked prompt needs custom copy.

C++ Workflow

UCLASS(BlueprintType, EditInlineNew, DefaultToInstanced)
class UMyHasKeyRequirement : public UInteractionRuntimeRequirement
{
    GENERATED_BODY()

public:
    UPROPERTY(EditAnywhere, BlueprintReadWrite, Category="Interaction")
    FName RequiredKeyId;

protected:
    virtual bool EvaluateNative(const FInteractionRuntimeRequirementContext& Context) const override;
};

Use C++ when the check belongs to shared gameplay code, needs strong typing, or is reused across many target definitions. Keep Blueprint subclasses available for designer-authored project checks.

Failure Text

Attach a UInteractionRuntimePromptTextProvider to the requirement when its failure should display custom text. Requirement providers receive the blocking requirement in FInteractionRuntimePromptBuildContext, so the provider can build copy from the requirement’s configured variables.

Testing Matrix

• Point-stage failure: the point should hide or show blocked according to UI policy.
• Selection-stage failure: automatic variants should fall back or choose another valid candidate.
• Command-stage failure: the command row should be unavailable without breaking unrelated rows.
• Prompt text: the blocking requirement should produce the intended unavailable copy.
• Server execution: client-visible success must still be validated where authority-owned execution runs.