Pawn with subcomponents holding meshes and logic

Hi everyone,

I started porting my helicopter flight simulator to UE. I just came across some best practice issues.

My Helicopter should be of type Pawn. Next I want to add sub-components such as rotor and rotorblades.
I’m a little bit confused, which type of C++ sub-component to use.
I want to achieve, that each sub-component may hold a static mesh (in case of the component for rotorblades) and it’s assigned logic. In this way, all logic will be part of the component that is responsible for it.

Final result should be, that a rotor is attached as subcomponent to the helicopter pawn. A rotor itself consists of multiple rotorblades attached as subcomponents to it, which should be represented by some physics and it’s designated geometry.

The helicopter pawn will receive the joystick input and pass it to the sub-components for the physics calculations.

Overview:

  • Helicopter Class [Pawn]
    • Fuselage [StaticMeshComponent]
    • MainRotor
      • Rotorblade1
      • Rotorblade2
      • Rotorblade3
      • Rotorblade4

Thank you

You can make your own component extending USceneComponent (which extends UActorComponent).

You can check for more suitable candidates from the links provided.

Happy coding :slight_smile:


P.S.

I think you are missing the point of the component based decoupling pattern. One of the main reasons for components to even exist is to separate the gameplay logic from the mesh (rendering) and physics. This maintains “locality of reference” in order for your game to take advantage of the CPU cache.

There is a great book on Game Programming Patterns from Robert Nystrom which might provide more insight on game engine architecture.

Thank you for your feedback. I will have a look on the book recommendation. What is your approach on where the actual behaviour should be put in to, if not into the actual component which also have some reference to the geometry?

The logic should be put on an ActorComponen. ActorComponents have no transform, no mesh and are not really a part of the hierarchy (other than belonging to a pawn). They are pure logic.

However, only common logic should go there. There is no point in having an unique component. They should be reused by all your helicopters no matter how different they are and this makes those components quite hard to design.

My approach would be to have a large part (including the rotors and blades) of my helicopter as a skeletal mesh parented to a collider. I’ll put only the parts that can be changed during gameplay on different components and attach them to sockets on my main body mesh. (like weapons or destructible parts)

I would create a Helicopter Movement component to handle all the physics and flight dynamics. It should hold a reference to the mesh and dictate the rotors’ speed and the blades’ angle of attack through animations. (similar to how the character movement component works in the templates)

I would probably have another Actor Component which handles the weapons and how they fire, how many ammunition they have and all the logic in them.

These component (movement and weapons) would be replicated on the network because although I don’t care weather the enemy player’s helicopter blades have the correct angle I need to make sure that their helicopter position and the position of their rockets is as close to uniform as possible for all players.

That being said you can also make those Actor Components create or change some of the meshes (weapons for instance) based on player choice or damage taken. You can also make the Movement component spawn a dust particle emitter beneath the helicopter when it flies too low to dusty ground.

I really hope this helps you.

Happy coding :slight_smile:

Thank you very much. I appreciate your help a lot. The last part regarding the dust particle emitter is one feature I have on my todo-list.