Some Questions About Blueprint Interfaces

Hey Guys, I have some questions about BPI

  1. What’s the point of creating several BPI if you can use only one, add it to every blueprint you need and just add as much functions you need to the same BPI?

  2. Is it “efficient” to use BPI?

1 Like

Does every actor needs to know about every function? Think of those comms as of a Need-To-Know only job.

If I have a BPI asking the UI to RefreshAllTextField or RecolorBorderFrames, I’m never going to use them in my player damage class; I’d have a dedicated BPI with relevant functions that matter there.

Is it “efficient” to use BPI?

It’s convenient. But also has a tendency to create utter mess. It’s a tool - do you need to talk to unrelated classes in the same way? If so, use an Interface.

1 Like

Thanks for your reply!

I understand it from a “programmer design” point of view, but using your example: will damage class use additional memmory or will there be additional computations because of this? won’t it just ignore functions that it has nothing to do with?

1 Like
  1. There is something called Interface Segregation in SOLID principles we use a lot in programming, the biggest plus side of having multiple interfaces as opposed to one is modularity, lets say for the sake of just making up something you have two classes Sparrow and a Dog, you have created a single interface for both of them which includes function definitions such as “Eat()” and “Fly()”, in the case of Dog you will be forced to keep the Fly() implementation empty as we all know dogs can’t fly. hence multiple interfaces are useful, Sorry for this bad example but you can look up Interface Segregation online.

  2. Yeah I very much prefer them, they can become a bit hard to track but they are very helpful more making a more modular and easy to change system later on if requirements change.


In a way, yes. There is no implementation in the interface itself so It’s probably negligible but I don’t want to see 300 functions here, ready to be implemented:



Thanks for your explanation!

Sometimes I just think that adding 4-5 BPIs might slow down the perfomance, I don’t know why and I haven’t done much research on it, but it feels like if I have 2 BP that I want to connect, If I use 3 BPI it takes more memmory because of so many connections

1 Like

If I use 3 BPI it takes more memmory because of so many connections

you should not worry about this at all, in case you are making something with possibly 10,000s of actors or a massive RTS. the performance impact is minimum and yes calling methods via interface is a tiny bit slower but I would still recommend good design over minimal performance gain.

Interfaces can also help you decouple stuff, so the higher level modules don’t directly interact with lower level module but communicate via an interface so in future if something gets changed you don’t have to tweak your base classes over and over again.

Of course there is over doing it so much that you end up in a mess, but think of them like a filter, when your programmer is trying to get something via interface from another class he shouldn’t have to play guess games or go look up the implementations regarding what’s implemented or not.


Thanks again! I understand it much better now

1 Like

Can this even be measured somehow? It sounds a bit like:


Which one is faster?

9/10 ppl will tell you that multiplication is faster. But it turns out that processors can’t even do multiplication, they just add and subtract really fast. BPs call math libraries that always converts it to multiplication under the hood anyway and there’s bitshifting the closer we get to the metal.

Apologies for a silly example but in the end it does not matter in 99.9999% scenarios and one’s time is better spent elsewhere. :innocent:

If I can cast, I’ll always cast. If it’s too cumbersome, it’s Interface time.

Casts go brrrr…


Good example! Thanks! Now I feel safer about my usage of casting and BPI :slight_smile: