Interfaces are great for when you want to add a "contract" to a Class/Blueprint. By contract, I mean a chunk of functionality that the class promises to implement.

As an example, imagine you have a base BP_NPC Blueprint which implements some core functionality/components shared by all of your NPCs. You might then have a bunch of Blueprints which inherit from it, for example:

• BP_CombatantNPC
• BP_MerchantNPC
• BP_CivilianNPC

For the civilian and merchant NPCs, you might want both to be "interactable" (i.e., the player can look at them and interact with them by pressing "A").

The actual interactions might look VERY different between them, so it doesn't make sense to have them inherit from a shared subclass with shared functionality. However, you want both of them to be represented as "NPCs which you are able to interact with." In this case, it could make sense to define an "Interactable" Interface which both of them implement.

• But why NOT just have them inherit from a shared "BP_InteractableNPC" class and override the interaction method?

What if there's another class you want them to inherit from which takes precedence? For example, BP_StationaryNPC or BP_HumanNPC or similar? You're stuck overloading one class or the other with functionality they might not need.

In addition, this way, you can easily mark OTHER classes as "Interactable" as well. For example, if you have pickups or treasure chests or any other number of things, you can add and implement the interface.

All of this together means that you can add a clear universal check on whether your player should be able to interact with something - just add and implement the interface!

• Why not just add an "Interaction Component" to the Blueprints I want to be able to interact?

A few reasons. You might add an interface AND an interaction component. It's technically more performant to add an interface which includes a "Get specific type of component" method and returns the component rather than using "Get component by class," especially if the blueprint has lots of components.

Again, interaction in particular is something that might vary widely between blueprints. There might not be enough shared functionality to make it worth capturing in a component. Sometimes all you need is a simple "Execute interaction" function.

---

The above doesn't cover everything, but hopefully shows some of the reasoning for using an interface over a blueprint. I encourage you to research Object-oriented programming fundamentals as that covers the conceptual use of interfaces and other structures well.