TLDR: What is the best way to group multiple objects into a single entity like vehicle parts into a car?
As an example, lets take Kerbal Space Program: it allows you to build spacecraft from multiple parts. The spacecraft itself is obviously a pawn, as you can control it as with a single entity.
But its parts can’t be fully represented by simply an array of static meshes - they can at any moment become a part of a new spacecraft (e.g. if the original spacecraft breaks in half/I undock a module). So the immediate thought would be to represent them as actors.
This then asks a new question: how should these actors be grouped into a single pawn? How can the pawn communicate with these actors and vise-versa? What would be responsible for spawning the actors and how a scenario like ‘break into 2 spacecraft’ should be handled?
I think this is something any game with a craft-build-system faces, and I want to know approaches to handling this problem. Maybe there is a completely different approach and I’m looking wrong at it?
But the reason I’d use actor is because that way you’re attaching an entire blueprint actor (and all data that entails) to another blueprint actor, which gives you the most flexibility (e.g. each ‘attachment’ can have it’s own separate logic). It is the most expensive way though.
Attach component to component is cheaper but it means you have to implement all the logic from within a master blueprint, and if you’re gonna do it that way anyways, might as well create the static meshes from within the blueprint too by doing something like this:
And to break into separate spacecraft, you would need the master blueprint to be a pawn or character class (the ksp equivalent for this would be the cockpit module, which you always have to start with) then to switch between those separate spacecraft (as in player controlling them) you’d need to simply possess them.
Thank you for your answer!
Just to “keep track of all the options”, right now I see these possible approaches:
1 - Child actors - I’ve completely disregarded this approach, as something as simple as a physics constrain turns into a setup nightmare and this approach is very complex in general, with limited resources/tutorials available.
2 - Each part is an actor, but some are pawns (like cockpits) + attach actor to actor - I’m not sure how adding physics constrains will work with this, could you elaborate? Just keeping the relative position is not enough if your goal is to have complex physics simulation (e.g. allow high overload to break connections). Other than that, seems like a very versatile approach, maybe with a downside of performance.
3 - A craft is a single pawn, all parts are just Static Mesh Components (discussed here) - this should give the best performance and managing parts. However, this approach has quite a few limitations or hidden pitfalls, some are mentioned in the discussion linked above.
this is the first time u mention physics constraints in this thread, it’s beyond the scope of your original question (where did you get that idea?)
You can think of a physics constraint as a hinge or a rope, or a strut like in KSP.
Setting them up will always be a nightmare, they are very complex tools. But they are versatile, you can tether an actor to another actor, or an actor to a component, or a component to another component with them. and control the flexibility of that tether, so you should be able to use them with any and all of the above approaches.
If you’re planning on using physics constraints a not i suppose that could be a way of doing it, just tether all the separate actors together with physics constriants, it’d be a nightmare to set up for sure but i believe it would get you the most similar results to KSP. (Parts can break off from the rockets, and physics constraints have some logic applied to them that allows them to break under X amount of force and so on)
It’s a valid approach, lets say you’re making a thruster, you make an actor, put the static mesh in, put whatever logic you want, then you slap a physics constraint on it’s viable mountpoints (probably the top, maybe the sides) and when you place them on another actor in the builder just make it use those constraints to attach them to each other.
I truly haven’t mentioned physics constraints in the original question, as they seemed so important to me, that I’ve considered them an obvious requirement, plus you can’t imagine KSP without them, which is also why I’ve used it as an example.
However, I don’t agree that setting them ‘will always be a nightmare’, as adding them between Static Mesh Components proved very easy, and the only time they were a nightmare was when I had child actors. This forces you to add them during begin play, as child actors are fully initialized only then - and that’s the core reason they were so difficult to work with and debug.
And it seems like with your approach, even though child actors are still not used, there is a similar approach with physics constraints - you can’t set physics constrains between actors - only between their static meshes (am I wrong here?). This again forces you to do so at runtime, which is a lot harder to debug.
