Object Lifecycle

For every UClass, Unreal creates exactly one Class Default Object — a real, allocated instance built once when the class first loads. It's the template holding default property values: when you spawn a real instance, the engine uses the CDO's values as the starting point, then applies any per-instance overrides on top.

Consequences worth internalizing

Your C++ constructor runs on the CDO first, at class-load time — before any gameplay instance exists, before the world exists, with no guarantee other actors are around. So the constructor is for setting defaults only.

Defaults set in the constructor land on the CDO:

AMyActor::AMyActor()
{
    Health = 100.f;
    bIsHostile = true;
}

Every future instance inherits these unless overridden.

• Designer "Class Defaults" edits are edits to the CDO. Changing a default in a Blueprint's Class Defaults panel, or an EditDefaultsOnly field in the Details panel, edits the Blueprint-generated class's CDO — not any live instance.
• You can read it directly. GetClass()->GetDefaultObject<AMyActor>() hands you the CDO, letting you read a class's defaults without spawning anything — for example reading a projectile's default damage off a ProjectileClass before you ever fire it. Handy for data-driven code.
• The CDO is a GC root and lives as long as the class is loaded. So it's never collected out from under you — but it also means any hard reference resolved in the constructor stays resident in memory for the class's lifetime, because the CDO is holding it. That's the mechanism underneath "hard references are eager" (Chapter 7).

"Constructor for defaults, BeginPlay for logic" is the conclusion. The pipeline between them is what explains it — and there are several useful hooks in the gap.

// Spawning an instance of a Blueprint class derived from your C++ class

  1.  C++ constructor chain          // base -> derived. Native defaults,
                                     // CreateDefaultSubobject. NO world.
  2.  Serialized / Blueprint values  // designer-authored defaults applied
                                     // to the instance, over the top
  3.  PostInitProperties()           // first point those values are readable
  4.  Simple Construction Script     // components added in the BP Components
                                     // panel are created here
  5.  PostActorCreated()             // spawned; PostLoad() if loaded instead
  6.  OnConstruction()               // the Construction Script
  7.  Component registration         // -> InitializeComponent() on each
                                     // component that wants it
  8.  PostInitializeComponents()     // all components exist and are initialized
  9.  BeginPlay()                    // world is live, gameplay has started

The step that causes the most confusion

So a designer setting Health = 250 in a Blueprint's Class Defaults is invisible to this:

AMyActor::AMyActor()
{
    Health = 100.f;
    MaxHealth = Health * 2.f;  // always 200. Never 500.
}

MaxHealth is computed from the native default, not the designer's value, because the designer's value hasn't arrived yet. PostInitProperties() is the first hook that can see it — that's what it's for.

What each hook is good for

Placed vs. spawned

The two diverge in the middle:

• A spawned actor gets PostActorCreated().
• A placed actor, loaded with the level, is deserialized from the map and gets PostLoad() instead. Its OnConstruction has typically already been re-run many times in the editor before the game ever starts.

Both converge again at component registration, and BeginPlay fires for both when play begins.

Why you can't spawn an actor in a constructor

The constructor runs on the CDO at class-load time. There is no world at that point — GetWorld() returns null. Spawning requires a world to spawn into, so the call has nothing to work with.

It's worth being precise about the failure, because it's easy to write a constructor that appears to work: the CDO is constructed once at load, so a spawn attempt there fails or asserts long before any gameplay path runs it. And even if a world existed, you'd be spawning an actor per CDO construction — which is not what anyone means to do.

Why non-determinism is a real problem, not a style note

The constructor's results land on the CDO, and the CDO gets serialized. Randomizing a value there means the saved class defaults differ run to run, which produces nondeterministic cooks and spurious diffs on assets nobody edited. Per-instance randomization belongs in BeginPlay, or in OnConstruction with a seeded stream if it genuinely needs to be visible in the editor.

Where to do it instead

Adding Components in the Constructor

Attaching native components is the standard, recommended pattern, and it's the clearest illustration of "configure the object itself":

AMyActor::AMyActor()
{
    PrimaryActorTick.bCanEverTick = true;

    RootMesh = CreateDefaultSubobject<UStaticMeshComponent>(TEXT("RootMesh"));
    RootComponent = RootMesh;

    Collider = CreateDefaultSubobject<USphereComponent>(TEXT("Collider"));
    Collider->SetupAttachment(RootComponent);
}

• Always CreateDefaultSubobject<T>() here, never NewObject<T>(). CreateDefaultSubobject registers the component with the CDO, which is what makes it editor-visible, serialized, and correctly inherited by Blueprint children. NewObject doesn't hook into any of that.
• The TEXT("Name") argument is the component's internal name and must be unique per class.
• Setting RootComponent and calling SetupAttachment() works here specifically because everything is still template/CDO form — not a live world object yet.

ConstructorHelpers::FObjectFinder<T> and FClassFinder<T> grab an asset by path inside a constructor:

static ConstructorHelpers::FObjectFinder<UStaticMesh>
    MeshAsset(TEXT("/Game/Meshes/SM_Rock.SM_Rock"));

if (MeshAsset.Succeeded())
{
    MeshComponent->SetStaticMesh(MeshAsset.Object);
}

• Only legal inside constructors. They rely on the CDO construction pass; using them elsewhere asserts. CreateDefaultSubobject carries the same restriction for the same reason.
• The static keyword matters. It caches the resolved pointer after the first call, during CDO construction, so the expensive asset-registry and disk lookup doesn't re-run on every spawn. The rest of the constructor body still executes on every instantiation — only the lookup is cached.
• That hardcoded path is a hard reference. The asset loads whenever the CDO is constructed, just as surely as assigning it in the editor would — and because the CDO is a GC root, it then stays resident.

• The Class Defaults panel is the real counterpart to setting values in a C++ constructor. Editing it edits the CDO, declaratively. This is where a designer's "constructor equivalent" work actually happens.
• The Construction Script is OnConstruction. Despite the name it is not a constructor — it runs much later in the pipeline, it runs repeatedly, and it runs in the editor.

The comparison that matters

Components added in Blueprint don't exist in the C++ constructor

Dropping a component into a Blueprint's Components panel adds it to that class's Simple Construction Script, which runs at step 4 — after the native constructor chain has finished. A C++ constructor therefore cannot see, configure, or cache a pointer to it.

If your C++ needs a handle on a component a designer added, take it in PostInitializeComponents, where everything is guaranteed to exist.

Construction Script pitfalls

• It re-runs constantly in the editor. Every property tweak, every drag in the viewport. Expensive logic here makes the editor feel broken, and the cost is paid by whoever is placing the actors — usually a designer, not you.
• Don't spawn actors from it. They aren't cleaned up the way the script's own output is, so every re-run risks duplicates and orphans accumulating in the level.
• Don't put gameplay in it. It runs at edit time, in the editor, on actors that are not playing. Gameplay goes in BeginPlay.
• Randomness re-rolls on every edit. A designer nudging an actor gets a different result each time, which reads as a bug. Seed it, or move it to BeginPlay.

Which hooks Blueprint can actually reach

Blueprint exposes two points in the pipeline directly: the Construction Script and Event BeginPlay. The intermediate hooks — PostInitProperties, InitializeComponent, PostInitializeComponents — are C++-only.

Unreal runs a mark-and-sweep garbage collector over UObjects. The key idea to internalize:

Calling Destroy() doesn't wipe the object immediately — it sets an internal flag: Garbage in UE5, previously PendingKill in UE4. Memory and the pointer value persist until the GC's next pass reclaims them. In that window, a raw pointer is non-null but logically dead.

When does a reference become None?

If it's a UPROPERTY in C++ or an exposed Blueprint variable, the GC nulls it for you — but on the GC's schedule, not the frame Destroy() was called.

Raw C++ pointers not wrapped in UPROPERTY get no such courtesy. They dangle, and dereferencing one is a hard crash rather than a clean null.

IsValid() is what the Blueprint Is Valid node calls under the hood, with its separate valid and not-valid exec pins.

Equality is identity, not liveness

== on object references compares pointers, not aliveness:

• Two different destroyed actors compare false, because they're different objects.
• A reference compared to itself before and after Destroy() still returns true, because the pointer value hasn't changed — only the flag has.

The variable does not become None the instant you destroy it.

TWeakObjectPtr is the C++ tool for a reference that reports its own death without waiting on GC nulling — it checks liveness against the object's internal serial number.