I’ve hit a very confusing dilemma. While components are used as sub-objects for things such as actors, what would I do if the component itself needed a component?
Let’s say I’m making an interstellar game with extraterrestrial civilizations and Planet is an actor class, with a Landmass component. What would be done if I wanted the Landmass component to hold data such as cities, which itself should be a component that holds data such as population, maybe a reference to an actor object designated as its leader, etc? I’d want this sub-component to have UE4’s reflection all the same, so it’d be declared as a UCLASS, instead of a standard C++ class.
Your suggestion sounds like you are looking for a way to organize a lot of data, not build a hierarchy of actors/components (this would be useful if you were constructing, for example, a big machine). Therefore what your example needs is a solid foundation of C++ that stores all the necessary information, relations between actors etc. If you are wondering how the actors stay on their planet, you can most likely use gravity as a helper; that’s how reality does it, too. But other than that, do not confuse data relations (stored in, e.g., an Excel table) with optical/physical relations like they are provided by the concept of (sub-)components.
I took a look around and decided to use structs instead. I think I got the concept wrong initially. So, it’s more like APlanet->ULandmassComponent->FCity
That won’t solve anything. There’s reasons why game engines are scene/level based.
If you really want to overcomplicate things like that, I’d go with subclasses instead.
Well, after much thought, I think an array of a struct type would do. These are just structs of variables. They don’t actually do anything other than instantiate a set of their variables. I got the idea after looking at stuff like the ProceduralMesh plugin which has the FMeshTriangle struct and uses an array of instances of it in a component class.