Recommendation
Use an Actor for an independently placed or spawned world entity, an Actor Component for reusable behavior owned by an Actor, and a UObject for reflected data or logic that does not need a world transform.
Compare the options
Actor
Choose when
- The object needs independent world presence.
- It must be placed, spawned, destroyed, replicated, or made relevant on its own.
- It owns a component hierarchy and world transform.
Tradeoffs
- Actors have a world-owned lifecycle.
- They carry more machinery than a plain UObject.
- Blueprint
- Create an Actor-derived Blueprint.
- C++
- Derive from AActor and create instances with UWorld::SpawnActor.
Actor Component
Choose when
- Stateful behavior attaches to several Actor types.
- The behavior follows its owner lifecycle.
- Each owner needs its own instance.
Tradeoffs
- A Component has no independent world identity.
- UActorComponent has no transform, while USceneComponent does.
- Blueprint
- Create an Actor Component Blueprint and add it to an Actor.
- C++
- Derive from UActorComponent, USceneComponent, or UPrimitiveComponent.
UObject
Choose when
- The type needs reflection, serialization, garbage collection, or Blueprint exposure.
- It does not need placement or a world transform.
Tradeoffs
- A UObject has no automatic world presence or Actor replication.
- An owner must keep a reflected reference while the object is needed.
- Blueprint
- Create an Object-derived Blueprint when its base class is Blueprintable.
- C++
- Derive from UObject and create instances with NewObject<T>().
Requirements
UObject is part of CoreUObject. Actors and Actor Components are part of Engine.
Example
Make a turret an Actor, reusable health logic an Actor Component, and an inventory entry runtime model a UObject.