When should you create a custom Component instead of a custom AActor?

Coming from a Unity background, I’m used to adding custom C# components to GameObjects. UE4 seems to offer the same functionality by allowing you to create custom Component classes and then attaching them to AActors.

However in most tutorials I’ve seen so far, people implement their custom functionality by creating a custom AActor rather than a custom Component. Even in the UE4 for Unity Developers tutorial, it mentions that you can create custom Components just like in Unity, but then, shortly after, proceeds to give a code comparison between a C# MonoBehaviour and a C++ AActor instead of a custom C++ Component.

So my question is when should you create a custom Component instead of a custom AActor?

1 Like

I also had trouble with this coming from Unity. I view it as such:

  • A full bit of functionality, an entire object that can exist on its own, should be an actor. For instance a chest that can open and close, a gun, a collectible.
  • A piece of functionality which can be used across different actors that enhances their capabilities should be a component, like a shared script to respond to user interaction. Visual elements and colliders are also components (static mesh component, box collider, etc) - they are the pieces that form the actor.

Another example: you want to have a security camera that can follow the player around. The camera itself is an actor: it is a fully functional item, which will be placed in the world. It is built up out of several components, primarily static meshes, a collider, a spot light, etc. It has logic which is only relevant to the camera, such as changing the spot light color when it sees the player. This code goes into the actor.

The look at functionality can easily be used in different actors though - an automated turret would use the same bit of logic. Therefor, you can create a look at component, and add it to any actor which needs to be able to look at the player or another object.

I’ve now gotten so used to the Unreal framework that I’ve started to split my Unity scripts into two folders - actors and components.

Maybe a recent example would help: I wanted to implement weapons for my game, trying the usual actor-only approach at first. I soon ran into a problem where I had units whose weapon wasn’t really a separate object, but say their hands. So kind of like “integrated” weapons, whereas other characters had traditional guns and such, and were also able to switch between them at will. However, I still had the weapon meshes and materials, and figured those would have to remain as being actors.

What I ended up doing was create a very generic “WeaponMode” component that I could attach to practically anything - pawns, actors, weapon actors, you name it. The weapon meshes themselves got shoved into their own, individual actors, and depending on the type of unit I was designing (i.e. one with an integrated weapon vs. one with external weapons), I would either place the WeaponMode component on the weapon actor or on the character/pawn itself.

This way, the WeaponMode component is really more of an abstract idea of causing damage, and if need be, could also be added to say a house or a rain cloud… It handles dealing damage, projectiles, melee, etc. and is completely decoupled from the rest of my game’s logic.

Couple this with a Health component and now anything in your game can be destroyed, i.e. the Health component listens to the pawn’s OnTakeAnyDamage delegate and keeps track of health bars, while the WeaponMode component doles out the damage.

So I’d say try & make a component out of anything that “does” something vs. everything else that “is” something. To take that further, your actor’s “verbs” should correspond to its components, while the “nouns” should remain being the actor itself. I hope this wasn’t too convoluted :slight_smile:

1 Like

Actor 是容器。

Actor is container。