Parent/Child classes vs Actor Component with Blueprints

Development Programming & Scripting
1

Hi, to set the context of the question :

I want to make customisable weapons, set up a lot of different ones ahead, with different bases, etc…
I then played with “Create a child Blueprint Class” and that went rather fine. I then stocked the variables inside a single Structure, most of the time (I don’t know if it’s efficient performance wise, but at least it’s orderly)
Later I “found” that Actor Component Blueprint class and played a little with it…

I’m wondering if I can’t achieve the exact same thing with those and creating child classes.
It can stock different variables of a given set… so… It even looks even more similar as I am using structures in my classes.

I can eventually create Child classes of the Actor Components to even more blow up my brain.
Well, so, my question is : Is a way more suitable to do it ? Is there fundamental differences performance wise ? Will I encounter problems later on ?
note : I’m not a pro, so it may look irrelevant, I apologize if it’s the case.

2

Use both.

Stick with classes for the weapons and use components to add extra functionality to the classes representing them.

Components are best used as reusable, modular blocks of script one can add/remove to/from any actor (during run-time, too!). This allows you not to cram all potential functionality that weapons may have into a single blueprint.

For example, you could create a Jamming Component; initially no weapon has it but when a gun gets dirty, the component is added to the weapon. Whenever a dirty gun is fired, it checks whether the Jamming Component is present. This component contains logic responsible for handling the jammed scenarios and returns values representing what happens when jamming occurs.

Cleaning the gun (also contained in the component) = destroying the component and freeing the memory it occupied.

This allows you to avoid overhead of including the jamming code in the base class, that is all the guns. It makes maintenance a bit easier further down the line as well.

Depending on the scope of what you’re creating, components are not a must but can be a great tool when generating actors with random or very specific functionality. Think weapons the players modify themselves.

Temporary de/buffs are also a great way to utilise components. Projectiles hitting target can spawn a Bleeding Component which will gradually reduce hit points of any eligible owner and destroy itself once its timer is up. Or even destroy the unlucky owner…

Components are much lighter than actors but have limitations, they cannot house other components - so no static mesh, no timelines…

More info here, a great intro to components and how to use them:

I then stocked the variables inside a
single Structure, most of the time (I
don’t know if it’s efficient
performance wise, but at least it’s
orderly)

Definitely the way to go. You will need the structs to save data anyway and they mesh well with Data Tables.

Also, if you plan to use components, consider looking into Event Dispatchers - it’s a solid communication solution for actors and their components.