I will use a animal analogy. The idea is to make a super animal that has all the logic like swim, dig and fly. I know if the super animal is the parent class its a burden on all the animals because they are carrying code they are not using.
I want to still make super animal but this time put all the code on an independent empty actor. When a bird flies it gets the fly logic through the interface and from the super animal actor. I can also give a pig the fly logic if i need because all logic is stored on the super animal.
Is this a good or bad idea? What kind of performance impact would this make?
Classes have more overhead than interfaces because they can contain variables. Interfaces only contain functions in BP. The difference in performance though is really negligible. You should really just use the best tool for the job.
If you’ll have variables, use a parent class. If the parent class will never be instanced, only child classes, then make the class abstract (can only be inherited from). If your children will only share functions then use an interface.
Generally interfaces are best used in BP for communication between classes (to avoid having to load class instances by casting) and parent classes work best for inheritance.
I’m not sure exactly but I think your question reads as: do I pay a cost for having code inside an actor that isn’t used?
as you may expect, the answer is “wtf are you even asking?”
No. You don’t incur costs from having a lot of unused functions. You do incur the cost when the functions are used.
Also, in your use case what you want to use is an actor component that holds the relevant logic.
You want the thing to fly? Add a flying component to the actor, set it up, and thats that.
Want to dive underwater? Add a swim component and set up. Done.
Components hold code only. Child actors allow you to add other actors which may include anything, be it meshes or collision capsules.
If you really wanted to, you could also force the main actor to generate collision or whatever else via construction script by reading off the component. This comes handy if you want to implement some sort of custom movement - say a parkour movement component, but you don’t want to use a child actor.
you can do so in begin play as well, if you are ok with not actually adding parts to the actor but having them spawn at runtime.
So coupling between classes refers to dependencies between classes. If a class uses a cast to another class, then that other class must also be loaded. For example, if your hero notifies an enemy when it is hit by calling a specific method or component on that enemy, then when your hero class is loaded into memory, it must also load the enemy class. This can easily result in sprawling hierarchies and long level load times.
You can easily visualize these dependencies using the built-in Reference Viewer. (right-click asset, Reference Viewer).
