How to have swappable geometry for an actor?

TLDR: I want to be able to set down towers and select their look with a single click and have the geometry be correct.

The actor class AShooter handles the logic of targeting other actors and spawning projectiles. Conceptually the AShooter has a base (purple), a turret (red) and a projectile spawn point (green):

What is the best C++/BP/Actor hierarchy or composition to allow selecting the visuals and geometry configuration of a specific AShooter instance?

This used to all be contained in a single actor class but the logic of the shooting should be separate from the geometry representation which should be easily swappable in the editor. However, the projectile spawn point is needed by the logic in AShooter and will depend on the geometry of the base and turret. So there should be a hierarchy of transforms which doesn’t seem to work with data assets.

Switching the geometry will necessitate the manual moving of the spawn point. It would be nice to have a handful of presets that can be selected for a shooter. The presets should be manually editable.

Defining an actor component which holds the base, turret and spawn point components does not allow setting their relative locations in the editor.

Is there a way to have a BP actor class of just these components which is then owned by the AShooter? This would necessitate spawning an actor which is not ideal.

The requirements:

  1. The base, turret and spawn point are defined together for all presets (no mix and match)
  2. The turret mesh component is rotatable from within AShooter
  3. The spawn location is attached to the turret so it inherits its transform
  4. The spatial configuration of base, turret and spawn point are configurable in a viewport
  5. The preset of any AShooter can be swapped/selected in the editor separately for any instance in the world
  6. Avoiding hard references if possible to keep the classes small
  7. Swappable/selectable requirement is only for editor. No changes in packaged game.

Hey @volumetrix, I think you were on the right direction when you were working with Data Assets for the configuration. At Construct you should have everything needed to async load your soft references and set the offsets. For specific behaviors (without using inheritance), your best partner should be the Strategy design pattern.
Please let me know if you’re able to solve your issue and feel free to post any further questions on this thread!

Data assets do not allow you to configure the geometry in a viewport. Setting the relative positions of the elements and also making sure they are in a tree hierarchy where transforms apply to children.

The problem is that it’s not just about the meshes but also the spatial and hierarchy information. Data assets are not ideal.

Not exactly, it mainly depends on the proficiency level of your team of game designers. I am honestly against over-engineering, so if your team is able to script just a little bit, you could just go with inheritance and configure the childs manually.

If you don’t want to enforce the (base → turret → spawn) component nesting, you can create a function to register them on the parent class without actually creating them there.

On the childs you can have any type of hierarchy and then call the parent function to set the required references during construction, so you’re dependency injecting them on the parent class or perhaps any other actor or component which might manage the turret behavior.