Blueprint Interfaces

At a glance

Lives in: Blueprint API / Blueprint Communication - Returns: whatever the interface function declares; an event-style interface message often returns nothing - Fails by: doing nothing when the target does not implement the interface, while execution continues - Main inputs: the target object reference, the interface asset, and the function's own parameters - Official docs: Blueprint Interface, Implementing Blueprint Interfaces, and Does Object Implement Interface

The one-minute version

• A Blueprint Interface is a contract: "any class that implements this has these callable functions."
• Implementing an interface does not make two actors find each other. You still need a target reference from an overlap, trace, saved variable, spawn return value, widget owner, or another real source.
• The envelope-icon Interface Message call is safe to send to a plain object reference. If that object does not implement the interface, no receiver runs and no error is printed.
• Use Does Object Implement Interface when the graph needs a visible branch before sending the message.
• Use an interface when the caller knows the behavior contract but should not care whether the target is a door, chest, NPC, pickup, or damageable prop.
• If the caller truly needs variables or functions from one specific class, use Cast To X instead.

What an interface actually adds

A Blueprint Interface asset is not another actor and it is not a component. It is a list of function signatures: names, inputs, and outputs. The interface asset itself cannot hold normal member variables, components, or timeline graphs. The state and real behavior live in each class that implements it.

When BP_Door implements BPI_Interactable, that class promises it can answer the interface's functions, such as Interact.

BPI_Interactable
    Interact(Interactor)

BP_Door implements BPI_Interactable:
    Interact -> open or close the door

BP_Chest implements BPI_Interactable:
    Interact -> play unlock logic and show loot

BP_NPC implements BPI_Interactable:
    Interact -> start dialogue

The caller does not need to know which class it hit. It only needs an object reference and the question "does this object implement BPI_Interactable?"

This is the part beginners usually miss: an interface removes the need to know the exact class, not the need to know the target object.

Interface messages

The Blueprint call you usually want from a broad object reference is the interface message node, shown with an envelope icon in the Blueprint graph.

Input Interact
-> Line Trace By Channel
-> Branch Return Value
-> Break Hit Result
-> Hit Actor
-> Interface Message: Interact

The message node behaves like this:

pseudocode of the engine behavior - not engine source

function SendInteractMessage(Target, Interactor):
    if Target is None:
        return

    if Target's class does not implement BPI_Interactable:
        return

    call Target's implementation of Interact(Interactor)

That no-op behavior is a feature. It lets a trace hit a wall, floor, tree, or unrelated actor without throwing errors while the interactable things still respond.

The tradeoff is visibility. A message that does nothing looks the same as "the target was not interactable" unless you add your own branch, print, or debug breakpoint. While building the graph, it is often clearer to check first:

Hit Actor
-> Does Object Implement Interface (BPI_Interactable)
-> Branch
    true:  Interface Message: Interact
    false: Print String "Hit actor is not interactable"

Once the logic is stable, many teams remove the false-side print and keep the message as the clean runtime path.

Does Object Implement Interface

Does Object Implement Interface returns a Boolean. It asks whether a live object's class supports the interface you named. It does not call the interface function and it does not tell you whether that function's implementation will do useful work.

Use it when:

• you want a visible true / false branch for debugging,
• the graph has different fallback behavior for non-implementers,
• you need to filter a list of actors before calling an interface function,
• you want to avoid relying on the message node's silent no-op behavior while learning.

You do not have to call it before every interface message. If doing nothing is the correct behavior for non-implementers, sending the message directly is a normal Blueprint style.

When an interface beats a cast

Use an interface when the caller knows the verb, not the concrete class.

Situation	Better tool	Why
A character presses Interact on doors, chests, NPCs, and pickups.	Interface	The character only needs Interact, not four different class casts.
A projectile damages enemies, crates, and target dummies.	Interface or damage event	Many unrelated classes can answer ReceiveHit or TakeDamage.
A widget needs to read one known player character variable.	Cast or stored typed reference	The widget is truly tied to that character class.
A spawner just created a BP_Key and needs to set key data on it.	Spawn return value, maybe cast	You already know the class you spawned.
A lever should notify anything listening that it changed state.	Event dispatcher	The lever should not know who all the listeners are.

Casting is not "bad." A cast is honest when the graph requires one class. An interface is cleaner when several classes should provide the same behavior without sharing a parent class just for that behavior.

When it fails (and what failure does)

The common beginner failure is not a crash. It is nothing happens.

Common causes:

1. The target reference is None. The message has no object to call. Fix the reference source or guard it with Is Valid when None is possible.
2. The target does not implement that interface. Add the interface in the class's Class Settings, or route non-implementers through a different path.
3. You implemented the function on the wrong Blueprint. The actor hit by a trace may be a child actor, component owner, proxy, or placed level actor that is not the class you edited.
4. The implementation is empty. Implementing the interface only creates the slot. The class still has to put real logic inside it.
5. The signature changed after implementation. If you rename inputs, outputs, or the function itself, inspect each implementer and refresh stale call or implementation nodes.
6. You expected a return from an event-style function. Interface functions with outputs behave like functions because the caller expects values. No-output entries are often implemented like events. If a result matters, design the interface function with explicit outputs and handle the no-receiver case.
7. You sent the message on the wrong machine. Interfaces do not replicate by themselves. In multiplayer, the interface call runs only where you call it; authority and RPC rules still decide what should happen on the server or clients.

For a message call, non-implementers do not trigger a Cast Failed pin, print an Output Log warning, or search for another actor that might implement the interface. Execution simply continues.

What Blueprint Interfaces do not do

• They do not find actors for you.
• They do not broadcast to every listener. That is an Event Dispatcher job.
• They do not store state. Store state on the implementing actor, component, subsystem, or data object.
• They do not share component setup, meshes, collision, or default variables. Use inheritance or components when shared structure matters.
• They do not guarantee useful behavior. An empty implementation still counts as "implements interface."
• They do not make a client call authoritative in multiplayer.

The pattern everyone actually uses

For a first interaction system:

BPI_Interactable
    Interact(Interactor)

BP_Door:
    Class Settings -> Implemented Interfaces -> BPI_Interactable
    Interact -> open or close

BP_Chest:
    Class Settings -> Implemented Interfaces -> BPI_Interactable
    Interact -> open loot UI

Player Character:
    Input Interact
    -> Camera Location
    -> Camera Forward Vector
    -> Line Trace By Channel
    -> Branch Return Value
    -> Break Hit Result
    -> Hit Actor
    -> Does Object Implement Interface (BPI_Interactable)
    -> Branch
        true: Interface Message: Interact(Self)

The trace answers "what object is in front of the player?" The interface answers "does this object know how to be interacted with?" Keep those two questions separate and the graph stays easy to debug.

The C++ twin, for the curious (our own example code):

void ATrainingCharacter::TryInteract()
{
    AActor* Target = FindInteractTarget();
    if (!IsValid(Target))
    {
        return;
    }

    if (!Target->GetClass()->ImplementsInterface(UInteractable::StaticClass()))
    {
        return;
    }

    IInteractable::Execute_Interact(Target, this);
}

Lookalikes - which one do I want?

Tool	Question it answers	Use when
Interface Message	"If this object implements the contract, ask it to do this."	You have a broad object reference and non-implementers should do nothing.
Does Object Implement Interface	"Can this object receive that interface message?"	You need a visible branch, filter, or debug print before calling.
Cast To X	"Is this object this exact class family?"	You need variables or functions that only exist on one class.
Direct function call	"Call this known object's function."	The variable is already typed as the class or interface you need.
Event Dispatcher	"Tell whoever bound to me that something happened."	The sender should not know its listeners.
Actor Component	"Give several actors shared state and reusable behavior."	You need reusable implementation, not just a callable contract.
Inheritance / base class	"These classes are the same kind of thing."	They should share default variables, components, and core behavior.

Rule of thumb: cast when you know the class, use an interface when you know the contract, use a dispatcher when the sender should not know who is listening.

Going deeper

• Line Trace By Channel - a common way to get the target object for an interaction interface.
• Cast To X - the class-specific alternative to an interface.
• The Blueprint survival kit - how functions and events differ before you add communication between Blueprints.
• Accessed None trying to read property - why a missing target reference is a different problem than a non-implementing target.
• Official docs: Blueprint Communication Usage, Actor Communication, Blueprint Interface, Implementing Blueprint Interfaces, and Does Object Implement Interface.
• Engine source (requires engine access - we do not reproduce it here): interface message nodes are represented by UK2Node_Message in Engine/Source/Editor/BlueprintGraph/Classes/K2Node_Message.h; normal function call nodes use UK2Node_CallFunction in Engine/Source/Editor/BlueprintGraph/Classes/K2Node_CallFunction.h; interface checks route through class/interface metadata such as UClass::ImplementsInterface in Engine/Source/Runtime/CoreUObject/Private/UObject/Class.cpp; the Blueprint utility node for interface checks is implemented by UKismetSystemLibrary::DoesImplementInterface in Engine/Source/Runtime/Engine/Private/KismetSystemLibrary.cpp.