The gameplay class hierarchy¶

The one diagram that makes half the API make sense.

Almost every confusing pin type in Blueprint — Object, Actor, Pawn, Character — is a rung on one ladder. Each rung is everything above it, plus extras. This page is the ladder.

The ladder¶

classDiagram
    UObject <|-- AActor
    AActor <|-- APawn
    APawn <|-- ACharacter
    AActor <|-- AController
    AController <|-- APlayerController
    AController <|-- AAIController
    class UObject { any engine object; no place in the world }
    class AActor { a thing that exists in the level }
    class APawn { an actor a Controller can possess }
    class ACharacter { a pawn with built-in walking, jumping, a capsule and a skeletal mesh }
    class AController { a brain that possesses one pawn }

Class	What it is	Subclass it when…
`UObject`	Any engine object: assets, data, anim instances. No transform, not in the level.	You need pure data/logic with no world presence.
`AActor`	Something that can be placed or spawned in a level. Has a transform and components.	You're making a thing in the world: pickup, door, projectile.
`APawn`	An actor that a Controller (player or AI) can possess and drive.	Your thing is controllable but doesn't walk like a human — a car, a turret, a drone.
`ACharacter`	A pawn with a `CharacterMovementComponent` (walking, jumping, falling, networked movement), a capsule collider, and a skeletal mesh — all pre-wired.	A humanoid-ish creature that walks around. This is the usual choice.

The prefixes are just naming convention: U = UObject-derived, A = Actor-derived, F = plain struct. Blueprint hides them ("Pawn" means APawn).

"Is a" — the sentence that resolves most confusion¶

Because ACharacter inherits from APawn:

Every Character is a Pawn, and also an Actor, and also an Object.
A pin or variable typed Pawn will happily hold your Character. Nothing is lost or converted — it's the same object, viewed through a narrower lens.
The reverse is not true: not every Pawn is a Character (a possessed car is a Pawn but not a Character).

So when a node like Try Get Pawn Owner returns a Pawn, and your game uses a Character, you are getting your Character back — the pin's type is just the narrow lens.

What "Cast To" actually does¶

Cast To BP_Hero does not convert anything. It asks a yes/no question at runtime: "is this object actually a BP_Hero (or a child of it)?"

Yes → you get the same object through the wider lens, so the Hero-specific variables and functions become visible. Execution leaves through the top pin.
No → the cast fails: you get None and execution leaves through Cast Failed. No error, no crash, no log. Failure is an answer, not an accident.

Rule of thumb: cast down the ladder (Pawn → your Character) when you know what the object should be. If a cast fails somewhere it "should" work, you're usually holding a different object than you think — or you're in an editor preview world, where your real classes don't exist (see the Try Get Pawn Owner failure section).

The supporting cast (you'll meet these immediately)¶

Class	One-liner
`AController`	The brain. Possesses exactly one Pawn at a time. Survives when the pawn dies.
`APlayerController`	A human's brain: input, camera, the network connection. One per player.
`AAIController`	An NPC's brain: runs behavior trees, navigation.
`UActorComponent`	A capability bolted onto an actor (no transform of its own).
`USceneComponent`	A component with a transform — can be attached in a hierarchy.
`UPrimitiveComponent`	A scene component that renders or collides (meshes, capsules).

Who owns, controls, and outlives whom is split across two topics: Possession for controllers vs pawns, and Ownership and lifetime for actors, components, networking, and garbage collection.