Looking for a little clarity on ActorComponents and Controllers

Hi folks,

Over the years I’ve worked in every version of UE, but over the last little while I’ve been off in some other engines (proprietary ones as well as the last year or so in Unity).
Now, coming back to UE I’ve been trying to reacquaint myself with the relationship between actors, pawns, components and controllers.

The relationship between actors and components generally maps to the “conventional” engine wisdom of these days. However the concept of extending Actor directly rather than adding components seems to break that mold. Which leads to the Pawn and Controllers who’s relationship seems to be suitable to be supplemented with a few extra components attached to an actor.

So I guess my questions are;

  1. Why isn’t Actor “sealed” with all the meaty bits living in Components?
  2. Why are controllers Actors instead of Components?
  3. Are there some best practices or rules of thumb for when to extend from actor, pawn, controller or component?

Cheers,

Kyle

Two pages you might find useful as you’re learning about Actors, Components, and Pawns are:

Just to pull out some of the information there that may help to answer your questions, Actors are the placeable gameplay objects that act as containers for components, like you’ve mentioned. By extending the base Actor class, you’re essentially building upon that container, which you can then fill with any components you need. Pawns and Controllers do have additional behavior built in, and that behavior should determine which class you want to extend. For instance, if you want an avatar for your player, you might pick Pawn (or Character, if you want the avatar to have built-in running, jumping, and other movement behaviors). Controllers (both PlayerControllers and AIControllers) come with basic behavior for possessing and controlling Pawns, so if you’re working with AI, or a reusable control scheme, those would be good to use.

Components can be reused in many different types of Actors - so that would be a good extension point for functions and variables that could be reused by Actors that don’t necessarily share a common hierarchy. For example, a CameraComponent could be used in a CameraActor, but also used in a Character to set its viewpoint.

Hopefully this helps out as you learn more about the different framework classes! :slight_smile:

So the general idea here is that you’re supposed to get the best of both worlds rather than being locked strictly a entity/component architecture? I can see how that can be useful to have your actor glue the components together rather than having large groups of components depend on each other anyway.

One aside, In the Controller doc. It says.

However the only documentation I’ve found to working with tick order is the TickGroups in Actor Ticking where it appears to be the default behaviour anyway. Is there some other more granular tick order control that is yet to be documented?

Thanks,

Kyle