In this lesson, you will learn how to decide whether to write game logic inside an Actor or delegate it to an ActorComponent.
The Container vs. The Capability
Think of an Actor as the "Container" or the physical presence in your level—like a player character, a light, or a treasure chest. An Actor represents what an object is.
An ActorComponent, however, represents a capability or a specific behavior that an Actor can possess. Components are modular and reusable. If you write logic directly inside an Actor, that logic is stuck to that specific type of object. If you write it in a component, you can "plug" that same logic into many different types of Actors.
When to use which?
- Use an Actor when you need an object that can be placed directly into a level, has a transform (location, rotation, scale), or acts as the "manager" of a collection of parts.
- Use an ActorComponent when you have a piece of functionality that might be useful for multiple, unrelated Actors.
For example, imagine you have a "Health" system. If you put the health logic inside a PlayerActor class, you cannot easily give that same health system to an EnemyActor or a DestructibleBarrelActor. Instead, you create a HealthComponent.
// You attach the component to your Actor
UPROPERTY()
UHealthComponent* HealthComp;
// Because it's a component, the Actor doesn't need to know
// how health works internally; it just asks the component to manage it.
The Architectural Rule
If the code describes an object’s identity (e.g., "This is a car"), put it in the Actor class. If the code describes a functional ability (e.g., "This can take damage" or "This can be picked up"), put it in an ActorComponent. By favoring components, you keep your Actor classes slim and ensure your code remains modular, making it much easier to update or reuse features later in your project.
Key Takeaway: Actors define "what" an object is, while ActorComponents define "what an object can do," allowing you to mix and match behaviors across different game entities.