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!