I want my AI to have a contract(interface) that defines all the required functions I need to implement a “special mechanic” in the game. However, the implementation is in a blueprint function library.
“Interface_Initialize Boss” implementation will actually call “BFNL_InitializeBoss” in my Blueprint Function Library in all the AI that implements the Boss fight interface. What are your thoughts, is there a better way to implement a Contract+Blueprint function library? ( I don’t want to have all this code in the Base class).
I would recommend you break the logic up into components you attach at the base class level.
For example an inventory component used in this manner can consolidate all the management of your items.
An Attribute component could be responsible for managing everything from hits given to damage taken.
In this example, you may consider using the dispatch events to complete integration allowing you to only implement the portions of the interface you select.
Also, the controller should be used to manage logic flow enabling you to invoke behavior tree’s as you see fit.
I would also recommend you veer away from heavy blueprint inheritance. Opt instead to implement a dynamic interface at the base class that is more feature packed. This can be done using components and/or objects.
Thank you for taking time to answer this question. You have been extremely helpful. After I posted this question, I was looking into more of this and I found that components would be a good fit. I am already playing with components for Math related calculations as I write this. However I do have few more questions based on your answer.
- “In this example, you may consider using the dispatch events to complete integration allowing you to only implement the portions of the interface you select.” - Can you please explain more on what you were referring to as partial interface implementation. Did you also mean fire event in component-> receive in base class and execute that sees fit?
- “the controller should be used to manage logic flow” - This is something I’ve made a mistake on, I’ve had most of the logic in the pawn itself. I already see the biggest difference is getting a blackboard (I pass a key in controller as opposed to a name in pawn). What is the difference otherwise?
- When you say Dynamic interface → You mean a base class + a component (that has all the necessary functionalities)?
Thank you once again for helping me out. I am new to Unreal, I’ve learnt a lot in the last 2-3 months, I am still thinking in Unity’s perspective. I just realized component in UE4 can easily be a C# script component in Unity. All these days I was looking at the event graph in actor = C# component in Unity (and then Blueprint function library like a static class, but not exactly? cuz I can’t have variables or macros). My mind is getting more clearer now.
Glad to be a help,
1.) An example could be to create an event, assign a method to it and then later if you determine it applies you can invoke it. Another usage would be to create the event and not assign it, but call it. Then later determine if you should have some code assigned to it, these facilities enable you to write logic in a way that allows a generic interface.
2.) Basically I would give my reasonology as this: with the code in the controller I am free to keep the pawns code related to direct interactions / animations while retaining all the boilerplate logic at the controller level. For me it is more intuitive this way, I then utilize a behavior tree variable that I use to interchange the root behavior for the various pawns invoking the controller.
3.) We can go further, we can add components dynamically that change the implementation of the base class using the dispatch system.
But most importantly, keep it simple when you can, reserve complexity for complex problems that you solve using small discreet simple solutions.
Thank you very much ! I now see more clearly how we can utilize the paradigms in UE4 
