Blueprint Interfaces Explained

I was super confused as to when to use blueprint interfaces, and when I finally figured it out (in contrast to event dispatchers); I decided to make a quick guide on this matter because I feel a lot of the video guides out there mistake its use akin to that of an event dispatcher, which it’s not.

So first you have to know what an interface is; an interface in programming is a set of function names which you define based on a class. As an example lets say you have two classes: dog and cat. And within these two classes you want to implement a function called eat. So what the interface allows you to do is implement separate "eat"s for dog and cat. Then when you define the function itself, you do it inside of the individual blueprints themselves, in the example above you’d define the function in the dog as “eat dog food” and for cat “eat cat food”.

Then lets say you want to send data from one class to another, meaning in this case dog to cat or vice versa, you need to use a message to do so, and this is because they both use the same interface. If only one of the classes uses the interface then you’d simply use a reference you created to call the function. Remember according to…ces/index.html , the two criteria for Blueprints to communicate via an interface is if:

  • Both Blueprints implement the same interface with the required function.
  • The calling Blueprint knows the name of the in-game instance of the other Blueprint.

I’ve implemented a little demo to show how this works; here I have a YellowBorderCube in my world whose reference is defined by an inherited version of ThirdPersonBP through the details panel via the world outliner. So I’ve gone ahead and made a Blueprint Interface (BPI) and the only function I have in it is FunctionInside. And when I defined it, I defined it to simply lift the cube up in the Air 50 cm. This is in the targetBP (receiver). In this Blueprint I set the BPI inside of the class settings.


And in my working BP (sender); I have this:

Way (2) is simply put if I set the BPI in my class settings for MyCharacter BP, and I would have my own version of FunctionInside implemented in MycharacterBP (this method is called sending a message). And way(2) is simply referencing the function from the reference the normal way you would with any reference. Realistically, knowing this opens the door to understanding function libraries, and macro libraries.

You’re right an Event Dispatcher has nothing to do an interface.

Event Dispatcher.

  • The caller of the event dispatcher does´t need a reference to the receiver
  • The receiver needs to know the type of the caller


  • The caller needs to have a reference to the receiver but doesn’t care about its type
  • The receiver needs to implement the interface


  • The caller needs a reference to the receiver and cast to its type

Why would you chose an interface over inheritance? The answer is that interfaces allows you to decouple blueprints from each other. As soon as you cast to a type you make a hard reference to this type. Interfaces avoids this by making an indirect call through an interface class.

Before you make everything into interfaces you should consider that interface functions are all public and will clutter up your search for specific functions if you are not careful. This is why interface functions should have general purpose names and not deviate from their purpose hinted at with the name so they can be reused in many different types of blueprints.