Hey guys,
i recently started a new project and this time i decided to implement the input movement in pure c++ as i thought that it might be quicker than doing it in blueprints. To my surprise i spent a few hours wasting time while i was messing with C++ Interfaces. This is really messy, the compiler throws you tons of errors that don’t even remotely give you any hint what’s wrong. I was able to tackle the issues but i noticed that the whole way interfaces work is pretty time-consuming and messy.
You have to add all functions of your interface to every single actor that uses it and if there is a single function or actor missing a virtual override the compiler is about to explode. Do you guys actually work with these interface ? I’m doing something wrong in their implementation ? So far when coding in C++ i just compared the class or casted to the correct child-class needed, then built custom functions.
On a sidenote, the documentation on interfaces is a mess as well, i found 3 totally different examples and none of them worked with their original code (even the official one at https://docs.unrealengine.com/en-us/…nce/Interfaces)
So far my experience with interfaces has been awful, question is if it pays back later in the project… Thanks!
Interfaces are useful for actors/objects that are different in their base classes but have at least some common behavior.
For example, a class “Consumable” has no real similarities with a “CarPart” base class.
However, if you want to both to have certain aspects to still be the same despite being completely different in their base classes, for example, being able to be picked up by the player, you’d define a “Pickupable” interface with a function “Pickup()”.
Pickup needs then to be implemented in both Consumable and CarPart classes.
What you then can do is, on pressing the pickup-button, do a line trace forward and check via class cast if its an object of the type “Pickupable”. If so, you can execute the “Pickup” function on that object (which, for example, could attach the object to the players hands). If its not an object with the Pickupable interface then you can’t pick it up so you don’t try to excute the function.
The need for interfaces however entirely depends on how you manage your class inheritance. If your objects with the same behavior features share a same base class then and if it makes sense to program that common behavior in one of the base classes then you don’t really need an interface for them, you can just put the implementation in the common base class and, if needed, override that behavior via virtual functions.
Interfaces are only really needed if you want classes of totally different base classes still have some common similarities and want to class-cast/treat them as the same category.
I started our project with using Interfaces as this is the normal way to do things. After a while I ended up doing strange code to communicate with blueprints so I dropped Interfaces and started using Components instead, much better.
The Components adds functionality that can easily be accessed from both C++ and Blueprints. They are easy to use for designers, just drop into any Actor and you get the functions you want, no messing around with implementing interface stuff in Blueprint.
One part the Components can’t do is to mark an Actor with “functionality-API” as Interfaces does, to simulate this you can either use GamePlayTags on the Actor or custom Collision channels.
I started out using interfaces but this just results in a huge mess. Well maybe not so much a mess as a lot of unnecessary boilerplate. I have started using more actor components to store functionality and possibly have an interfaces with just one function (to efficiently cast get the actor component)