Question about structure

Development Programming & Scripting C++
1

I want to have a large library of possible components (custom components deriving from both Actor Component and Scene Component) which can be added/removed/altered on my Pawn at runtime.

I’ve come up with two possible ways of doing it, briefly tested them both, but I’m not sure in the long run (once the library of possible components runs in the hundreds and becomes quite complex) whether one method is better than the other. I would really value any opinions!

The** first method** is to have a Library component (attached to the Pawn) with all of the components already spawned and attached to it. When I want to add a component for usage by the Pawn, I duplicate it onto the main hierarchy of the Pawn, from where I can make changes to its parameters, initialise it, and use it in the game. If I wanted to reload the default version of that component, I can just delete the attached one, and re-duplicate it. So the Library versions of the components are never altered, just drawn from to create usable versions on the Pawn.

The second method is to abstract a ‘settings’ class for the components (either a UObject or UStruct) which is just data. When loading something from the Library, the settings class knows what kind of component to create, and specific parameters to set, and so creates a new component and adds it to the Pawn.

The first method seems cleaner in one sense, because there’s no need for a separate settings class. But it means that, if there were a 1000 components in the library, there will be 1000 components all already spawned and added - is that a cause of potential slow-down, or are components pretty lightweight? None of the components will be ticking, they just add functionality to the Pawn when they are actually added. So in another way, the second method seems cleaner, because the Library component just has an array of structs/objects in an abstracted form.

Which is better, or is there no real difference?

Hope this question makes sense. Perhaps there is a much better way entirely!

2

If you are manipulating 1000s of Components, both cases above are bad to have.
“Components” in UE4 are hacky classes, they’re pretty much a kind of Actor classes that can be a ‘member of other actors’, memory-wise speaking. The thing is, every time you create one new component you allocate more memory, every time you delete them you cause garbage collection… Do that a 1000 times and your game is running like ■■■■!

Whatever you’re trying to do with so many components, I bet you can do exactly the same with “GameplayTags” although I don’t know what it is you’re trying to do.

3

Ok, thanks. It’s probably too cumbersome to do it like this then.
I already have a system built for loading and saving these objects from disk. I had thought it might be prudent to load the entire catalogue into memory on program startup, but perhaps my library object should just be an array of filepath strings, and I can load the needed component/s from disk when needed.

I don’t know much about gameplay tags, but it doesn’t seem like they can offer the functionality I need. For example, adding one type of component might add an additional hierarchy of scene components, while another component might add a dozen or so new parameters for usage elsewhere in the loop. It seems like tags are for indexing and organisation, not adding structure and functionality to actors.

4

Each gameplay tag can be used as a key for a TMap where its value is a UStruct (or many UStructs) object holding the properties you need on a “Settings” UObject where you can as well save default values to a INI file if needed.
I still defend adding/removing that so many components at runtime is a waste of performance.

5

Ah, I’m not planning on adding removing that many components at once. It’s a case of adding one component at a time, just from a library of possible components. It’s more likely to be in the 100s, not 1000, but since players can create and share their own content, it’s theoretically possible the library of potential components could end up pretty large.
I’ll explore what you’re suggesting with gameplay tags though, thanks!