Good Morning. I’m trying to wrap my head around a few principles and I want to make sure I’m starting with good practices… Please forgive my random spread of questions just what I have not been able to find in my googling…
I want to create a game with a bunch of monsters, I would make a Base monster that would have all the stats that all monsters need (Health, etc)… Then I would make different monsters that inherit from that and add specific behavior to that. For instance a “web” attack for a spider (just spitballing here…)
Does anyone know a good tutorial on something like this that I can check out? Thank you!
You’ve got the right idea. If there are variables (like health, skeletal mesh, etc.) that are sharable among different monsters, it makes the most sense to create a parent class that each monster would inherit from. This not only applies to variables, but events/functions/interface calls as well.
This simplifies your life in several ways:
Implementation - you only need to worry about building a single class with all (or most) the functionality required for a monster. For each child class that inherits from this, will only need cosmetic, AI, and unique behavior added.
Referencing is much easier. Using functions like “Get All Actors of Class” or checking if a line trace hits a monster only needs to reference the parent class (interfaces are great for this type of interaction too as it breaks any hard references between classes in blueprints).
Related to the last, you can utilize polymorphism that can be handy. Basically, you can create an event in the parent class (w/ or w/o being implemented), then the child blueprints can implement their own versions of that same event. An example of how this can be useful; if two monsters require different things to happen with the same event (like with dying; one of them just burns up and the actor is destroyed and the other turns to ragdoll), you can create the unique implementation in the child classes, but when referencing the parent class you only need to call the one event. This makes it possible to only have to reference the parent to call the event, rather than referencing the other classes that have unique events.
Generally, it is advised to create a C++ class, then create a child blueprint class from that. This allows you to push functions into C++ for the performance boost if necessary. Even if you don’t at the moment plan to write any C++ code, it is still good to set it up this way for the future.
Most of the time, I’ll create this structure, prototype the entire class in the child blueprint, then add the functionality into C++ to clean up the spaghetti blueprints nodes and improve performance.
I found this talk to be very helpful when I was first learning. Goes over much more than what you are asking here, but it is important to understand with regards to how UE works.
