Unreal's Core Classes

2. Which Class Should I Derive From?

The single most common beginner question. Match what you're building to the left column:

3. UObject — the Base of Everything

UObject is the root of Unreal's managed object system. Deriving from it (and tagging your class with UCLASS()) buys you four things plain C++ classes don't get:

• Reflection — the engine knows your class's properties and functions at runtime. This is what makes the editor's Details panel, Blueprint access, and serialization work. You opt fields in with UPROPERTY() and functions with UFUNCTION().
• Garbage collection — you never delete a UObject. The GC frees objects that are no longer referenced by any UPROPERTY() pointer.
• Serialization — properties save/load automatically with assets, levels, and (with SaveGame) save files.
• Networking support — property replication and RPCs are built on the same reflection data.

Creating UObjects

// NEVER: UMyData* Data = new UMyData();   — invisible to the GC, will crash or leak
// ALWAYS:
UMyData* Data = NewObject<UMyData>(this);   // 'this' becomes the Outer (owner)

// And keep a UPROPERTY reference so the GC knows it's still in use:
UPROPERTY()
TObjectPtr<UMyData> MyData;

The Class Default Object (CDO)

At startup the engine constructs one instance of every UCLASS — the Class Default Object — as the template for all future instances. Your C++ constructor runs on the CDO, long before any level exists. That's why constructors must only set defaults and create default subobjects, never touch the world. (More in the Execution Order guide.)

What a plain UObject can't do

• No transform — it has no position, rotation, or scale
• Can't be placed in a level or spawned into the world
• Doesn't tick by default (actors and components do)
• GetWorld() returns null unless its Outer chain leads to something in a world

If you find yourself needing any of those, you want an actor or a component instead.

4. AActor — Things in the World

An AActor is anything that can exist in a level: placed by hand in the editor, or spawned at runtime. Actors are the unit of gameplay — they tick, they can be replicated over the network, and they own components.

Spawning and destroying

// Spawn at runtime (from any actor or component):
FActorSpawnParameters Params;
Params.SpawnCollisionHandlingOverride =
    ESpawnActorCollisionHandlingMethod::AdjustIfPossibleButAlwaysSpawn;
AMyProjectile* Proj = GetWorld()->SpawnActor<AMyProjectile>(
    ProjectileClass, MuzzleLocation, MuzzleRotation, Params);

// Remove from the world (GC frees the memory later):
Proj->Destroy();

Every actor runs through a fixed lifecycle: construction → registration → BeginPlay → Tick every frame → EndPlay → garbage collection. The Execution Order guide covers every step in detail — the short version: gameplay setup goes in BeginPlay, cleanup goes in EndPlay, and the constructor is only for defaults and default subobjects.

Actors and multiplayer

Replication is actor-centric: the server owns the authoritative copy of a replicated actor and pushes property changes to clients. If a thing needs to exist across the network, it's almost certainly an actor (components replicate as part of their owner).

5. Components — Behaviour You Compose

Components are how actors get their parts. There are three tiers, each adding one capability on top of the last:

The root component and the attach tree

Every actor placed in a world has exactly one root component (a scene component). The root's transform is the actor's transform; every other scene component attaches under it, moving with its parent like bones in a skeleton. Plain actor components (no transform) sit outside this tree — they're owned by the actor but not attached to anything.

Creating components

// In the constructor — the standard way to define an actor's parts:
AMyTurret::AMyTurret()
{
    Base = CreateDefaultSubobject<UStaticMeshComponent>(TEXT("Base"));
    SetRootComponent(Base);

    Barrel = CreateDefaultSubobject<UStaticMeshComponent>(TEXT("Barrel"));
    Barrel->SetupAttachment(Base);          // child of the root

    Health = CreateDefaultSubobject<UHealthComponent>(TEXT("Health"));
    // no attachment — UActorComponent has no transform
}

// At runtime, on an already-spawned actor:
UHealthComponent* HC = NewObject<UHealthComponent>(SomeActor);
HC->RegisterComponent();                    // required for runtime-added components

6. Pawns, Characters & Controllers

Unreal splits "the player" into two objects: the body (a pawn in the world) and the brain (a controller that drives it). The link between them is called possession.

• APawn — an actor that can be possessed by a controller. Use it directly for vehicles, turrets, drones — anything controllable that doesn't walk like a person.
• ACharacter — a pawn with the humanoid kit pre-installed: a capsule for collision, a skeletal mesh for the body, and UCharacterMovementComponent for walking, jumping, falling, swimming — with client-server movement prediction built in. If your pawn is a person, start here.
• AController — the brain. APlayerController turns hardware input into pawn commands and owns the local player's camera; AAIController runs behavior trees instead of reading a gamepad.

Pawn or Character?

Input bindings live in APawn::SetupPlayerInputComponent, which runs when a player controller possesses the pawn. The exact sequence of possession callbacks is in the Execution Order guide §12.

7. The Gameplay Framework

Around your pawns and controllers, the engine spins up a standard cast of framework objects for every game session: AGameModeBase, AGameStateBase, APlayerController, APlayerState, UGameInstance, and the UWorld they all live in. You don't create these yourself — you subclass them and tell your project which subclasses to use.

This topic now has a guide of its own: what each class is for, who creates what, what replicates where, and why the whole design is multiplayer-first — see The Gameplay Framework guide.

8. Widgets — UI Outside the World

UI in Unreal is built from widgets, and widgets are not actors. They don't live in the world, have no world transform, and are laid out in 2D screen space by UMG (Unreal Motion Graphics). Under the hood UMG is a friendly wrapper over Slate, the engine's low-level C++ UI framework — you'll rarely need to touch Slate directly.

• UWidget — one control: a button, a text block, a progress bar, an image. These are the building blocks you drag into the UMG designer.
• UUserWidget — a composition of widgets: your HUD, your main menu, one row of your inventory grid. When you create a Widget Blueprint, you're subclassing UUserWidget. This is the class you derive from in C++ to add logic behind a designed widget.

Creating and showing a widget

// Typically from your PlayerController or HUD class:
UUserWidget* HUDWidget = CreateWidget<UUserWidget>(PlayerController, HUDWidgetClass);
HUDWidget->AddToViewport();       // now it renders on screen

HUDWidget->RemoveFromParent();    // hide/remove it again

Widgets have their own lifecycle (NativeConstruct / NativeTick / NativeDestruct rather than BeginPlay/Tick/EndPlay) and their own coordinate system. Positions are managed by layout panels (canvas, vertical box, grid) rather than transforms — to connect a widget to something in the world (a health bar over an enemy's head), you project the world position into screen space each frame.

9. Common Gotchas