I want to...

Start with the thing you are trying to build. The links below put the existing pages in a useful order, so you do not have to know the API tree before you know the engine.

I want to make a health bar

Read in this order:

1. Create Widget + Add to Viewport
2. create the HUD widget once, give it the right owning player, store the reference, and put it on screen.
3. Updating a Widget: Bindings vs Events
4. update the bar when health changes instead of polling from a binding every frame.
5. Buttons, Progress Bars, and basic UMG events
6. feed progress bars 0.0 to 1.0, update text deliberately, and keep UI events from searching the world.
7. Clamp / Map Range Clamped / Normalize To Range
8. keep health legal, convert it to a bounded 0..1 ratio, and guard a zero maximum instead of hiding invalid range data.
9. Actor Components as reusable gameplay
10. put shared health state and OnHealthChanged behavior in one reusable component instead of copying variables into every character/enemy/prop.
11. HealthComponent and damage response pattern
12. keep health math, clamping, death gates, UI broadcasts, and replication hooks in one reusable owner.
13. Nameplates, floating health bars, and damage numbers
14. put health bars over enemies, read PlayerState names/teams, and keep floating UI from owning the health value.
15. HUD state from replicated and local data
16. rebind the local HUD after respawn and combine pawn, PlayerState, and GameState values without replicating widgets.
17. Event Dispatchers - put OnHealthChanged on the character or health component, then bind the widget to it.
18. Cast, Interface, or Dispatcher? - understand why the character broadcasts and the widget listens.
19. Event AnyDamage / Apply Damage
20. receive damage and change the health value that drives the UI.
21. Blueprint variables and references, Is Valid, and Accessed None - debug empty character or widget references.

Usual shape:

PlayerController BeginPlay
-> Create Widget WBP_HealthBar
-> Bind widget to HealthComponent.OnHealthChanged
-> Initial UpdateHealth
-> Add to Viewport

Character takes damage
-> HealthComponent clamps Health
-> HealthComponent calls OnHealthChanged(Health, MaxHealth)

I want buttons, menus, or UI bars to work correctly

Read in this order:

1. Create Widget + Add to Viewport
2. create the widget once, give it the right owning player, and store the reference.
3. Buttons, Progress Bars, and basic UMG events
4. use OnClicked/OnPressed/OnReleased deliberately, feed progress bars normalized values, and update text without fighting bindings.
5. Set Text, Format Text, and Text vs String vs Name
6. update labels from one owner, preserve typed/localizable placeholders, and choose Text instead of display-facing String or Name conversions.
7. Set Visibility: Hidden, Collapsed, and hit testing
8. choose whether a panel paints, keeps layout space, or lets itself and its children receive pointer input.
9. Updating a Widget: Bindings vs Events
10. push gameplay changes into widgets instead of polling or searching from UI bindings.
11. Remove from Parent and widget lifetime
12. close widgets without confusing removal, destruction, stored references, Construct/Destruct, or dispatcher cleanup.
13. Set Input Mode & Show Mouse Cursor
14. pair interactive menus with input focus, cursor state, pause, and restore logic.
15. Enable Input / Disable Input / Set Ignore Move and Look Input
16. decide whether the menu should only change focus or also lock movement and camera look.
17. Set Game Paused - stop and resume the game world separately from showing the widget, routing input, or focusing UI.
18. Event Dispatchers
19. let buttons request actions from their owner and let gameplay broadcast UI updates.
20. Widget Component and World-Space Widgets
21. choose actor-attached UI when the widget should live in the world instead of the player's viewport.
22. Widget Interaction Component
23. use a virtual pointer when a player needs to hover or click world-space Widget Components.

Usual shape:

PlayerController opens menu
-> Create/store WBP_Menu
-> bind menu dispatchers to controller functions
-> Add to Viewport
-> Set Game Paused true if this is a pause menu
-> UI Only + cursor true

ResumeButton OnClicked
-> menu calls ResumeRequested
-> controller removes widget
-> Set Game Paused false
-> Game Only + cursor false

I want a crosshair, prompt, nameplate, or floating damage number

Read in this order:

1. Create Widget + Add to Viewport
2. create local reticle and prompt widgets once and update the stored instance.
3. Crosshair, reticle, and interaction prompts
4. split fixed screen UI, camera/cursor traces, prompt data contracts, priority, input-device text, and server interaction requests.
5. Line Trace By Channel
6. find the world target the prompt or reticle is describing.
7. Blueprint Interfaces
8. let doors, pickups, terminals, and NPCs answer the same prompt/interact questions without a cast chain.
9. Widget Component and World-Space Widgets
10. attach labels, bars, and panels to actors when the UI belongs in the world.
11. Widget Interaction Component
12. click and hover actual world-space UMG panels.
13. Nameplates, floating health bars, and damage numbers
14. read HealthComponent, PlayerState, and GameState values, face/hide labels, and pool transient hit numbers.
15. Project World Location to Widget Position and off-screen markers
16. project through the owning player's camera, keep DPI/player viewport coordinates consistent, and add pivot-safe clamping and occlusion policy.
17. HUD state from replicated and local data
18. combine local prompts, pawn state, PlayerState, GameState, and RepNotify in one local HUD.

Usual shape:

PlayerController creates WBP_HUD once
-> local interaction trace finds an interactable target
-> target returns prompt data through an interface
-> HUD updates the reticle/prompt
-> Interact input sends a server request when gameplay state should change
-> replicated state refreshes local bars/nameplates/HUD rows

I want to reuse health, inventory, team, or interaction logic

Read in this order:

1. Blueprint variables and references
2. understand value variables, object references, class references, and why a typed variable still needs assignment.
3. Arrays, Sets, Maps, and ForEach
4. choose lists, unique membership, or key-value lookup for inventory, overlap, and team data.
5. Structs, Enums, and Switch on Enum
6. group related values and replace contradictory booleans with named states.
7. Actor, Scene, and Primitive Components
8. learn which parts have transforms, collision, rendering, or just behavior.
9. Actor Components as reusable gameplay
10. move shared health/inventory/team/interaction state into a component with clear owner and widget communication.
11. HealthComponent and damage response pattern
12. make the health component own clamping and broadcasts while each actor decides what death means.
13. Status effects and damage-over-time with timers
14. keep poison, burn, slow, stun, and timed buffs in one receiver-side owner with explicit stack, refresh, and cleanup rules.
15. Small Inventory Architecture
16. split item definitions, world pickups, inventory entries, equipped actors, UI, and SaveGame data.
17. Add, Remove, Stack, and Broadcast Inventory Changes
18. make inventory mutation explicit and notify widgets from one owner.
19. UMG Inventory Slots, ListView/TileView, and Drag/Drop
20. display inventory state without making slot widgets the authority.
21. Add Component by Class / Child Actor Component
22. decide when a component should be designed into the Blueprint or added at runtime.
23. Data Tables vs Data Assets
24. move repeated item/enemy/ability definitions out of copied Blueprint defaults when tuning data grows.
25. Cast, Interface, or Dispatcher?
26. choose how the component talks to owners, widgets, and other actors.
27. Gameplay Tags, Actor Tags, and Component Tags
28. classify actors/components without mistaking labels for behavior.
29. Actor Has Tag / Component Has Tag / Get Components by Tag
30. run the concrete plain-name tag checks on the correct actor or component storage without confusing them with Gameplay Tags.

Usual shape:

BP_Enemy / BP_Player / BP_Barrel
-> HealthComponent
-> component owns health math and OnHealthChanged
-> each actor decides what death means
-> widgets/listeners bind to the component

I want to organize inventory, enemy, ability, or tuning data

Read in this order:

1. Blueprint variables and references
2. separate values, object references, class references, and asset references before choosing a data shape.
3. Get Class / Class Is Child Of / Is Valid Class
4. distinguish a live object from its class and validate class-driven spawning/default access without treating validity as spawnability.
5. Arrays, Sets, Maps, and ForEach
6. decide whether the data is an ordered list, unique membership, or key-value lookup.
7. Structs, Enums, and Switch on Enum
8. bundle related item/enemy fields and model modes with named enum values.
9. Data Tables vs Data Assets
10. choose table rows for spreadsheet-like lists or data assets for authored per-item/per-ability definitions.
11. Get Data Table Row / Row Found / Row Not Found
12. resolve one typed row, handle missing keys, and keep invalid table/schema setup separate from normal lookup failure.
13. Data Table row names, row handles, and stable IDs
14. choose durable row identity, SaveGame values, and explicit rename migrations without using display text as a key.
15. Soft Object/Class References and async loading
16. defer heavy asset/class loading, validate completion, retain results, and account for cooked content.
17. Small Inventory Architecture
18. decide which item data is a definition, pickup, runtime entry, equipped actor, UI view, or SaveGame value.
19. Add, Remove, Stack, and Broadcast Inventory Changes
20. model stack updates, duplicate IDs, full inventory, and refresh events.
21. UMG Inventory Slots, ListView/TileView, and Drag/Drop
22. decide whether the visible inventory should be manual slots, a ScrollBox, or a virtualized ListView/TileView.
23. Game Instance and Save Game: Create / Save / Load Game to Slot
24. decide which runtime values survive level travel or quitting.
25. Updating a Widget: Bindings vs Events
26. push inventory/shop data into UI without hiding world searches in bindings.

Usual shape:

ItemId from pickup
-> Get Data Table Row DT_Items
-> add FInventoryItem struct to Inventory array/map
-> broadcast InventoryChanged
-> widget refreshes visible slots

I want to open a door when the player overlaps it

Read in this order:

1. Collision presets, channels, and responses
2. make sure the trigger and player can overlap in the first place.
3. On Component Begin / End Overlap
4. use the event pins and filter Other Actor.
5. Get Overlapping Actors / Components / Is Overlapping Actor
6. re-check current occupancy after pair-based End Overlap events and choose an array or set when several actors can hold the door open.
7. Blueprint variables and references
8. assign the placed door reference instead of expecting a BP_Door variable type to find one.
9. Structs, Enums, and Switch on Enum
10. model Closed, Opening, Open, and Closing as one enum instead of several booleans.
11. Actor, Scene, and Primitive Components
12. understand the trigger component, door mesh, and root transform.
13. Cast To X or Blueprint Interfaces
14. choose whether the trigger needs this exact player class or any interactable actor.
15. Delay, DoOnce, Gate, Sequence, and latent flow
16. avoid using DoOnce or Gate to hide a missing door-state reset.
17. Breakpoints and watch values
18. prove the overlap fired and inspect the actor reference.
19. Timelines / Add Timeline / Play / Reverse / Finished
20. play and reverse the authored door motion and handle Finished deliberately.
21. Lerp, FInterp To, and moving things smoothly
22. understand the alpha/math that the Timeline usually drives.

Usual shape:

DoorTrigger BeginOverlap
-> Other Actor
-> Cast/Interface filter
-> Play door-opening Timeline or call OpenDoor

I want to interact with the thing I am looking at

Read in this order:

1. Line Trace By Channel - shoot the query from the camera or player view and get the hit actor.
2. Line Trace For Objects / Multi Line Trace For Objects
3. use selected object categories when that is the real filter, and account for walls whose unselected object type will not occlude the query.
4. Break Hit Result
5. read the exact actor, component, contact point, normal, and trace distance only after the trace reports a valid hit.
6. Collision presets, channels, and responses
7. choose which objects the trace can hit.
8. Blueprint Interfaces
9. send one Interact message to the hit actor instead of casting through a list of possible classes.
10. Cast, Interface, or Dispatcher? - confirm that this is a one-target contract, not a dispatcher.
11. Print String and the Output Log and Breakpoints and watch values
12. prove what the trace hit.

Usual shape:

Input Interact
-> Line Trace By Channel
-> Branch Return Value
-> Hit Actor
-> Interface Message: Interact

I want to pick up an item

Read in this order:

1. On Component Begin / End Overlap or Line Trace By Channel - decide whether pickup happens by touching the item or looking at it.
2. Blueprint Interfaces
3. make pickups, doors, and switches answer the same Interact call.
4. Blueprint variables and references
5. store HeldItem, CurrentPickup, or item data deliberately.
6. Arrays, Sets, Maps, and ForEach
7. keep inventory slots, overlapping pickups, or item counts in the right container.
8. Structs, Enums, and Switch on Enum
9. bundle item fields into one inventory entry instead of parallel loose variables.
10. Data Tables vs Data Assets
11. move item definitions and tuning values out of pickup actor defaults.
12. Small Inventory Architecture
13. separate the world pickup from the inventory entry it creates.
14. Add, Remove, Stack, and Broadcast Inventory Changes
15. make AddItem report accepted/rejected counts before the pickup destroys or hides itself.
16. Equip, Use, and Drop Item Flow
17. decide when the item stays as data, becomes equipped, is consumed, or returns to the world as a pickup.
18. UMG Inventory Slots, ListView/TileView, and Drag/Drop
19. show slots and drag/drop item requests without letting UI mutate the bag.
20. Attach Actor To Component
21. attach held items to a hand socket or component.
22. Ownership and lifetime - understand why a held item reference can go stale if the item is destroyed or replaced.
23. Destroy Actor / Set Life Span
24. remove consumed pickups or temporary spawned items cleanly.
25. Is Valid - guard optional held-item references.

Usual shape:

Interact target receives Interact
-> validate player inventory reference
-> AddItem(ItemId, Quantity)
-> Branch AcceptedCount > 0
-> destroy/hide/reduce pickup
-> InventoryComponent broadcasts OnInventoryChanged
-> optional EquipItem later spawns and attaches held actor

I want to hide, show, disable, or remove something

Read in this order:

1. Set Actor Hidden In Game / Set Visibility
2. decide whether you only mean visual hiding, one component's visibility, or whole-actor hiding.
3. Collision presets, channels, and responses
4. understand which collision settings decide blocking, overlap, and traces.
5. Set Collision Enabled / Response / Profile Name
6. disable or change collision when invisible objects should stop blocking or overlapping.
7. Destroy Actor / Set Life Span
8. remove actors for real, or schedule their cleanup after a delay.
9. Create Widget + Add to Viewport and Remove from Parent and widget lifetime
10. remember that widgets are viewport objects, not actors, and removing a widget is not the same as destroying an actor.
11. Blueprint variables and references
12. clear or rebuild references when hidden/removed/destroyed objects change.

Usual shape:

Pickup collected but will respawn
-> hide actor visuals
-> disable collision
-> set respawn timer

Temporary impact actor
-> Set Life Span 8.0

Menu closed
-> remove/hide widget
-> restore input mode

I want a cooldown, poison tick, delayed respawn, or one-time trigger

Read in this order:

1. The frame: Tick, timers, and timelines
2. understand when work runs every frame, later, repeatedly, or along an authored curve.
3. Set Timer by Event / Clear Timer by Handle
4. schedule callbacks, store timer handles, clear looping timers, and avoid treating timers like threads.
5. Status effects and damage-over-time with timers
6. make poison, burn, slow, stun, and timed buffs start, stack, refresh, tick, expire, and clean up in one owner.
7. Timelines / Add Timeline / Play / Reverse / Finished
8. use authored curve playback for doors, fades, charge bars, and reversible motion instead of callback timing.
9. Delay, DoOnce, Gate, Sequence, and latent flow
10. use one-off waits and flow gates without hiding missing reset/state bugs.
11. Structs, Enums, and Switch on Enum
12. model cooldown-ready, poisoned, dead, respawning, or door states as named values when the state matters.
13. Breakpoints and watch values
14. prove the set, clear, reset, and callback paths ran on the same instance.

Usual shape:

StartPoison
-> Set Timer by Event ApplyPoisonTick looping every 1.0
-> store PoisonTimerHandle

StopPoison
-> Clear and Invalidate Timer by Handle

ApplyPoisonTick
-> Apply Damage

I want to make a pause menu or inventory

Read in this order:

1. Create Widget + Add to Viewport
2. create and store the menu widget.
3. Buttons, Progress Bars, and basic UMG events
4. wire Resume, Equip, Drop, and slot buttons to widget/controller functions.
5. Set Input Mode & Show Mouse Cursor
6. route input to the UI, show the cursor, and restore game input on close.
7. Enable Input / Disable Input / Set Ignore Move and Look Input
8. lock movement/look separately from UI focus, and avoid stacked ignore calls that never unlock.
9. Set Game Paused - pause or unpause the game world and branch on the return value instead of assuming the menu state and paused state match.
10. Remove from Parent and widget lifetime
11. close the menu without losing track of the widget instance, input restore, or dispatcher bindings.
12. Add Mapping Context - add a temporary menu context if your Enhanced Input setup uses menu-specific controls, then remove it on close.
13. Input Action Event and Enhanced Input Action Values
14. bind the pause/menu action, allow it while paused when intended, and keep local input separate from authoritative gameplay requests.
15. showdebug enhancedinput and Input Debugging
16. prove whether the menu context and action work before changing widget focus, pause, or the receiving Blueprint instance.
17. Arrays, Sets, Maps, and ForEach, Structs, Enums, and Switch on Enum, and Data Tables vs Data Assets
18. model inventory slots, item entries, and item definitions before drawing them.
19. Small Inventory Architecture, Add, Remove, Stack, and Broadcast Inventory Changes, and Equip, Use, and Drop Item Flow
20. keep UI buttons talking to one inventory owner instead of mutating slots directly.
21. UMG Inventory Slots, ListView/TileView, and Drag/Drop
22. choose manual slots, ScrollBox, ListView, or TileView before wiring drag/drop.
23. The Blueprint survival kit - keep open, close, and toggle logic out of one giant event graph.
24. Updating a Widget: Bindings vs Events
25. push data into inventory/HUD widgets instead of hiding gameplay work in bindings.
26. Accessed None - debug missing menu references.

Usual shape:

Input Pause
-> if menu closed: create/show widget, add menu context if needed, pause, UI Only, cursor true
-> if menu open: remove/hide widget, remove menu context, unpause, Game Only, cursor false

I want to play a sound or loop ambience

Read in this order:

1. Play Sound 2D / Play Sound at Location / Spawn Sound Attached
2. choose local UI sound, one-shot world sound, or an attached audio component you can stop later.
3. Sound Cue vs MetaSound vs Sound Wave
4. choose a raw clip, simple variation graph, or procedural/parameter-heavy sound source before overbuilding the asset.
5. Sound Attenuation and spatialized audio
6. make world sounds fall off with distance, pan/spatialize, and use the local listener correctly.
7. Audio Component controls: Play, Stop, Fade, Volume, and Sound
8. keep a live sound reference when a loop needs Stop, Fade Out, Set Sound, or volume changes.
9. Physical Materials for surface-specific feedback
10. choose footstep or impact sounds from the surface a trace/hit found.
11. Actor, Scene, and Primitive Components
12. understand why audio can live as a component on an actor.
13. Add Component by Class / Child Actor Component
14. add optional runtime audio components when the actor does not always need the sound source.
15. Attach Actor To Component
16. understand sockets, components, and relative transforms when a sound follows a hand, weapon, engine, or torch.
17. Spawn Niagara System at Location / Attached
18. pair sound with local VFX for impacts, loops, muzzle flashes, or surface puffs.
19. Open Level and Level streaming basics - decide whether travel destroys the old world or the persistent world keeps running.
20. Replication basics - in multiplayer, replicate the gameplay state that should cause clients to play local audio.

Usual shape:

Short UI click
-> Play Sound 2D

Explosion at a point
-> Play Sound at Location
-> attenuation asset controls distance/spatialization

Looping engine hum
-> Spawn Sound Attached
-> store AudioComponent
-> Fade Out or Stop when engine turns off

I want impact sparks, bullet holes, footsteps, or surface-specific feedback

Read in this order:

1. Line Trace By Channel or Event Hit
2. get the hit result that contains Impact Point, Impact Normal, hit actor, hit component, and optionally Physical Material.
3. Break Hit Result
4. distinguish Location from Impact Point, read the actor/component safely, and request a physical material from the producing query when needed.
5. Physical Materials for surface-specific feedback
6. understand why the physical material can be empty, and how surface types choose sounds, decals, and effects.
7. Spawn Niagara System at Location / Attached
8. spawn impact bursts at a world point or attach loops/trails to a component you will control later.
9. Spawn Decal at Location and impact feedback
10. place projected marks using Impact Point and Impact Normal with a cleanup lifespan.
11. Play Sound 2D / Play Sound at Location / Spawn Sound Attached
12. add the audio half of the same feedback event.
13. Material Instances and Dynamic Material Instances
14. flash or dissolve the mesh that was hit when changing the surface itself is the better feedback.
15. Replication basics
16. replicate the gameplay result or impact event, then let each machine spawn its local presentation.

Usual shape:

Trace or hit event
-> Break Hit Result
-> Surface Type from Physical Material
-> choose sound/VFX/decal data
-> Spawn Niagara at Impact Point
-> Spawn Decal at Impact Point aligned to Impact Normal
-> Play Sound at Location
-> Apply Damage separately if gameplay requires it

I want to make a weapon or projectile hit something

Read in this order:

1. Line Trace vs projectile vs overlap weapon hits
2. choose hitscan, projectile travel, overlap hitboxes, blocking hits, or thick/multi traces by the behavior the weapon needs.
3. First weapon fire pattern and impact cleanup
4. place input, cooldown, ammo checks, muzzle transforms, hit detection, damage, feedback, cleanup, and multiplayer authority in the right owner.
5. Projectile Movement Component and first projectile actor
6. build a spawned projectile with a root collision component, initial speed/velocity, local direction, gravity, bounce, homing, and cleanup.
7. Sphere Trace, Capsule Trace, and Multi Trace basics
8. give melee, shotgun, and interaction traces thickness or multiple returned hits without damaging the same actor several times.
9. Line Trace By Channel - build precise camera or muzzle traces and read the hit result.
10. Spawn Actor from Class - create projectile actors and set instigator/owner deliberately.
11. Get Forward Vector & Find Look at Rotation
12. make muzzle transforms, aim directions, and local X+ projectile travel agree.
13. Collision presets, channels, and responses, Event Hit, and On Component Begin / End Overlap
14. decide what blocks, overlaps, ignores, and reports the impact.
15. Event AnyDamage / Apply Damage
16. send simple generic damage after the hit is valid.
17. Apply Point Damage / Apply Radial Damage / Damage Type
18. use point damage for exact impact data, radial damage for explosions, and damage types for category-specific receiver behavior.
19. Spawn Niagara System at Location / Attached, Spawn Decal at Location and impact feedback, Play Sound 2D / Play Sound at Location / Spawn Sound Attached, and Physical Materials for surface-specific feedback
20. play local impact feedback from the hit point, normal, and surface.
21. Replication basics - keep the server in charge of trusted weapon hits and replicated projectile actors.

Usual shape:

Input Fire
-> choose hit model
-> check cooldown/ammo
-> line trace or spawn projectile from muzzle
-> filter hit actor / component / owner / already-hit set
-> apply damage if appropriate
-> spawn local impact feedback
-> destroy or expire temporary projectile/hit state

I want to track score, objectives, waves, or win/loss

Read in this order:

1. GameMode & friends, single-player edition
2. understand the framework owner that decides start, respawn, score, and win/loss rules.
3. Get Game Mode / Game State / Player State
4. read the active framework objects without confusing server-only GameMode with client-readable GameState or replicated PlayerState.
5. Score, objectives, and win/loss state
6. place score, match phase, objective progress, end screens, SaveGame results, and multiplayer-readable state in the right owner.
7. Objective and Wave Manager Actors
8. coordinate generators, levers, waves, checkpoints, spawners, doors, and reset/save rules without hiding everything in Level Blueprint or GameMode.
9. Get All Actors with Interface / Get All Actors with Tag
10. discover placed objective participants or tagged checkpoints once, then keep a manager-owned registry instead of scanning every frame.
11. GameState and PlayerState in practice
12. keep public match state in GameState and public per-player score/team state in PlayerState.
13. HUD state from replicated and local data
14. make HUDs, scoreboards, objective text, and end screens read gameplay state instead of owning it.
15. Death and defeat cleanup flow
16. award score and objective credit once from a guarded death transition.
17. Event Dispatchers
18. let generators, enemies, doors, and checkpoints notify a manager when their local state changes.
19. Save Game: Create / Save / Load Game to Slot
20. save completed objective IDs, best scores, stars, and durable results as plain values.
21. Does Save Game Exist / Delete Game in Slot / Async Save Game to Slot
22. check profile slots, delete/reset progress, and save asynchronously from results menus without overlapping requests.
23. Replication basics, Blueprint Custom Events as RPCs, and RepNotify variables and local presentation
24. keep score/objective authority on the server and update client UI from replicated state.

Usual shape:

Enemy dies or generator completes on the server
-> actor broadcasts local event once
-> objective/wave manager updates local progress
-> GameMode validates score or win/loss rules
-> GameState / PlayerState stores public state
-> local HUD reads replicated state and shows score/objective/end screen
-> SaveGame records durable results only at deliberate save points

I want my project to spawn the right character

Read in this order:

1. GameMode & friends, single-player edition
2. set the active GameMode, Default Pawn Class, PlayerController Class, HUD Class, and understand why a map override can beat project settings.
3. Level Blueprint vs Actor Blueprint vs Manager Actors
4. keep spawn/setup rules in the framework owner instead of hiding reusable gameplay in a one-map script.
5. Player Start, Restart Player, and checkpoints
6. place safe PlayerStart actors and understand who chooses the spawn point.
7. Possession - make sure the PlayerController actually possesses the pawn you expect.
8. Get Player Character / Pawn / Controller
9. inspect the runtime references after the map starts.
10. Create Local Player / Get Num Player Controllers
11. add split-screen/local co-op players without confusing local player slots with online clients.
12. Input Actions & Input Mapping Contexts and Add Mapping Context - confirm the local player has the controls for the spawned pawn.

Usual shape:

Project Settings or World Settings
-> active GameMode
-> Default Pawn Class = BP_PlayerCharacter
-> PlayerController Class = BP_PlayerController
-> Play
-> PlayerController possesses spawned pawn

I want my character to move and face the right way

Read in this order:

1. Input Actions & Input Mapping Contexts
2. understand why UE5 movement is usually one IA_Move Axis2D action instead of four separate key events.
3. Add Mapping Context - make sure the local player actually has the gameplay mapping context active.
4. Input Action Event and Enhanced Input Action Values
5. bind IA_Move, choose the correct trigger event, and read its Axis2D value on the owning local player.
6. Enhanced Input Modifiers: Negate, Swizzle, Scalar, and Dead Zone
7. build signed WASD axes and tune gamepad drift without changing the shared action's meaning.
8. Add Movement Input - send camera-relative or actor-relative movement requests to the pawn.
9. Get Forward Vector & Find Look at Rotation
10. choose actor forward vs control/camera forward and flatten pitch for ground movement.
11. Character Movement Component: the knobs that matter
12. tune speed, acceleration, braking, jumping, air control, and movement mode.
13. Why won't my character face where it's moving?
14. choose whether the body faces movement, camera/aim, or tank-style actor forward.
15. Spring Arm + Camera - set the follow-camera boom distance, collision pull-in, and control-rotation behavior.
16. Jump & Launch Character - add normal jumping, double-jump tuning, launch pads, or knockback.
17. Possession - make sure the pawn you are watching is actually controlled by the player or AI.
18. Set Input Mode & Show Mouse Cursor
19. debug menu states that stop gameplay movement input from firing.
20. Enable Input / Disable Input / Set Ignore Move and Look Input
21. distinguish UI focus, actor input, and controller movement/look gates.
22. showdebug enhancedinput and Input Debugging
23. inspect contexts, priorities, action values, trigger state, possession, UI focus, and the exact PIE client before rewriting movement logic.
24. Get Velocity - read the motion result that animation and movement debugging usually care about.
25. Root Motion vs Character Movement
26. decide when animation should drive a short authored movement action instead of normal input/AI movement.
27. Aim Offsets and look/aim variables
28. keep aim pose variables aligned with camera/control rotation and weapon trace direction.
29. Breakpoints and watch values
30. inspect the input value, direction vector, and character rotation without guessing.

Usual shape:

IA_Move Triggered
-> get 2D action value
-> get control yaw or actor forward/right
-> Add Movement Input
-> Character Movement consumes input
-> rotation settings decide body facing
-> Spring Arm decides camera position

I want to push a prop or knock back a character

Read in this order:

1. Add Impulse / Add Force - use impulses for one-time shoves, forces for continuous pushes, and confirm the target component is simulating physics.
2. Jump & Launch Character - use Character Movement for launch pads and knockback on normal Characters.
3. Get Forward Vector & Find Look at Rotation
4. build the shove direction from actor, component, or camera/control forward.
5. Attach Actor To Component
6. debug held items that fall off when Simulate Physics is enabled.
7. Replication basics - make the server own authoritative multiplayer shoves.

Usual shape:

Push loose crate
-> get crate Static Mesh Component
-> Add Impulse(Direction * Strength)

Knock back Character
-> Launch Character(KnockbackDirection * Strength + UpVector * Pop)

I want to switch cameras or play a cutscene shot

Read in this order:

1. Spring Arm + Camera - know what your normal gameplay camera rig is before switching away from it.
2. Set View Target with Blend
3. blend the PlayerController's view to a CameraActor, death camera, inspect camera, or back to the possessed pawn.
4. PlayerCameraManager and Camera Shake
5. add local recoil, impact, landing, or explosion shake without changing possession or view target.
6. Possession - understand why changing the view does not change which pawn receives input.
7. Possess / Un Possess / Get Controller
8. use possession only when control should move to another pawn.
9. Get Player Character / Pawn / Controller
10. get the controller or current pawn reference you need for the switch.
11. Set Input Mode & Show Mouse Cursor
12. pair camera-only views with UI/focus changes when the player should stop driving gameplay.

Usual shape:

Start cutscene or death camera
-> Get Player Controller
-> Set View Target with Blend to CameraActor
-> optionally Start Camera Shake on the local PlayerCameraManager
-> optionally ignore input or set UI input mode

Return to gameplay
-> Set View Target with Blend to controlled pawn
-> restore input/cursor state

I want my Animation Blueprint to know how fast the character is moving

Read in this order:

1. Try Get Pawn Owner - get the pawn whose mesh this Animation Blueprint is animating.
2. Cast To X - turn the broad Pawn reference into your character class when that is truly what the AnimBP is built for.
3. Event Blueprint Update Animation
4. gather animation data on the normal game-thread update.
5. Animation threading and Property Access
6. move stable repeated reads into Property Access/thread-safe animation functions after the normal owner/data path is proven.
7. Get Velocity - read actor velocity and turn it into ground speed with Vector Length XY.
8. Vector Length / Vector Length XY / Normalize
9. turn velocity into 3D or ground speed and keep zero-direction handling separate from magnitude.
10. Blend Spaces in Animation Blueprints
11. feed GroundSpeed into a 1D/2D Blend Space for idle/walk/run poses.
12. Animation State Machines and transition rules
13. use the variable in transition rules and debug preview-vs-runtime differences.
14. Possession - understand why the editor preview is not your live possessed pawn.

Usual shape:

Initialize Animation
-> Try Get Pawn Owner
-> Cast To BP_YourCharacter
-> store OwnerCharacter

Update Animation
-> Is Valid OwnerCharacter
-> Get Velocity
-> Vector Length XY
-> set GroundSpeed
-> Blend Space / transition rule reads GroundSpeed

I want attacks, reloads, footsteps, or hit windows in animation

Read in this order:

1. Animation State Machines and transition rules
2. keep locomotion modes and transition variables clear before adding action layers.
3. Blend Spaces in Animation Blueprints
4. understand the locomotion pose the action will often layer over.
5. Animation Montages / Play Montage
6. play one-shot attacks, reloads, emotes, and sectioned actions through the correct mesh and slot.
7. Cached poses and Layered Blend Per Bone
8. reuse locomotion once and layer upper-body action poses over the right bone chain.
9. Montage slots layered over locomotion
10. make sure montage slots actually reach the final pose and decide whether the action is full-body or upper-body.
11. Animation Notifies and Notify States
12. time footsteps, particles, sounds, combo windows, and melee hit windows from the animation itself.
13. Root Motion vs Character Movement
14. decide whether an authored attack/vault/lunge should move the capsule or remain normal Character Movement.
15. Aim Offsets and look/aim variables
16. align aim yaw/pitch, additive upper-body pose, and weapon trace direction.
17. Play Sound 2D / Play Sound at Location / Spawn Sound Attached and Line Trace By Channel - drive the common sound/trace work a notify triggers.
18. Spawn Niagara System at Location / Attached, Spawn Decal at Location and impact feedback, and Physical Materials for surface-specific feedback
19. add particles, marks, footsteps, and surface-specific impact feedback.
20. Replication basics - keep damage and authoritative gameplay results on the server in multiplayer.

Usual shape:

Input Attack
-> Play Montage AttackMontage on Mesh
-> montage Slot appears in AnimGraph
-> cached locomotion feeds upper-body layered blend
-> Notify State MeleeWindow begins
-> weapon trace/damage window opens
-> Notify State ends
-> cleanup on Completed or Interrupted

I want to spawn something during play

Read in this order:

1. World vs relative transforms - understand world locations, actor forward, and why "in front of me" is not the same as adding to world X.
2. Break/Make Vector and Rotator / Transform Location / Inverse Transform Location
3. convert parent-, component-, or socket-local positions into the world without treating directions like locations.
4. Get Forward Vector & Find Look at Rotation
5. build the spawn point from location plus forward vector times distance.
6. Spawn Actor from Class - create the actor and handle the possibility that the return value is None.
7. Spawn Default Controller and Auto Possess AI
8. create or verify the AIController when the spawned actor is an enemy pawn.
9. Get Owner / Set Owner
10. decide whether the spawned actor needs an owner for networking, owner-only visibility, or RPC permission.
11. Projectile Movement Component and first projectile actor
12. add movement, collision, lifetime, and impact cleanup when the spawned actor is a projectile.
13. Add Component by Class / Child Actor Component
14. decide whether the runtime thing is really a separate actor or just a new component on an existing actor.
15. Spawn Niagara System at Location / Attached
16. use a visual effect spawn when the runtime thing is feedback, not a gameplay actor.
17. Construction Script vs BeginPlay
18. keep runtime spawning out of Construction Script.
19. Event BeginPlay / Tick / EndPlay / Set Actor Tick Enabled
20. put runtime setup and cleanup in the spawned actor without hiding repeated work on Tick.
21. Event Dispatchers - bind to notifications on the actor you just spawned.
22. Attach Actor To Component
23. attach spawned equipment or effects to a component/socket when needed.
24. Get Actor Of Class / Get All Actors Of Class
25. understand why repeatedly searching for the spawned actor is usually the wrong follow-up.
26. Get All Actors with Interface / Get All Actors with Tag
27. use setup-time discovery or manager registration instead of repeated world scans for spawned actors.

Usual shape:

Gameplay event
-> choose a world spawn transform
-> Spawn Actor from Class
-> Is Valid Return Value
-> configure returned actor
-> store or pass the reference

I want to respawn the player after death

Read in this order:

1. HealthComponent and damage response pattern
2. make health reach zero through one reusable owner and broadcast death once.
3. Event AnyDamage / Apply Damage
4. detect death when health reaches zero.
5. Death and defeat cleanup flow
6. disable input, movement, collision, AI, timers, and stale references before respawn or cleanup.
7. Enable Input / Disable Input / Set Ignore Move and Look Input
8. lock player movement/look on death and make the unlock path explicit.
9. Set View Target with Blend
10. switch to a death camera or spectator shot without confusing view with possession.
11. PlayerCameraManager and Camera Shake
12. play local impact/death feedback without treating camera shake as gameplay state.
13. GameMode & friends, single-player edition
14. use the framework's spawn/restart owner instead of burying respawn in the dying pawn.
15. Player Start, Restart Player, and checkpoints
16. choose the checkpoint/PlayerStart and restart the controller through GameMode.
17. Set Timer by Event / Clear Timer by Handle and Delay, DoOnce, Gate, Sequence, and latent flow
18. choose a clear delayed-respawn pattern and avoid hidden one-time gate bugs.
19. Possession - separate the player controller from the pawn body that can be destroyed and replaced.
20. Possess / Un Possess / Get Controller
21. verify which controller drives the new pawn and why view target is not the same thing as possession.
22. Destroy Actor / Set Life Span
23. clean up the old pawn or temporary death actor intentionally.
24. Spawn Actor from Class - create the new pawn or respawn actor at runtime.
25. Get Player Character / Pawn / Controller
26. know when player-slot getters help and when the controller reference is already the better starting point.
27. Add Mapping Context - debug Enhanced Input mappings that were added to the old pawn, wrong local player, or a temporary death/menu mode.
28. Create Widget + Add to Viewport
29. keep player UI on the controller/HUD path so it survives pawn replacement.

Character dies
-> optional death camera view target
-> GameMode chooses checkpoint / PlayerStart
-> controller stops using old pawn
-> Restart Player at Player Start
-> controller possesses new pawn
-> confirm gameplay mapping context and action bindings
-> UI rebinds to the current character

I want a value to survive changing levels

Read in this order:

1. Game Instance - store runtime values that should survive Open Level, and learn why actor references are the wrong thing to carry across maps.
2. Blueprint variables and references
3. separate plain saved values from live actor/widget/component references.
4. Open Level - understand that normal map travel destroys old-world actors and starts a new map/world setup.
5. Save Game: Create / Save / Load Game to Slot
6. copy durable values into a SaveGame object when the data must survive quitting and launching later.
7. Does Save Game Exist / Delete Game in Slot / Async Save Game to Slot
8. check for slots, delete/reset profiles, and save asynchronously without racing menu clicks.
9. GameMode & friends, single-player edition
10. understand why GameMode and level actors are recreated with the map.
11. Get Player Character / Pawn / Controller
12. rebuild live references in the new map instead of reusing old actor references.
13. Is Valid - guard optional references while you prove the travel handoff.

Before Open Level
-> copy plain values into BP_GameInstance
-> optionally Save Game to Slot for durable progress
-> Open Level
-> new map starts
-> Get Game Instance
-> read values
-> rebuild live actor/widget references in the new world

I want to stream an interior without changing maps

Read in this order:

1. Level streaming basics - persistent level, streamed sublevels, Load/Unload Stream Level, and when streaming is worth the setup.
2. Load Stream Level / Unload Stream Level
3. use the latent load/unload nodes, visible-after-load flag, and persistent level ownership deliberately.
4. Open Level - compare streaming to full map travel so you do not preserve state by accident or destroy state by accident.
5. Game Instance - know which data survives full Open Level travel and which data can stay in the persistent world instead.
6. On Component Begin / End Overlap
7. trigger streaming from a doorway, hallway, or volume.
8. Replication basics - for multiplayer, decide how clients learn which streamed state matters.

Usual shape:

Persistent-level doorway trigger
-> player enters load volume
-> Load Stream Level("L_ShopInterior", Make Visible After Load = true)
-> player exits later
-> Unload Stream Level("L_ShopInterior")

I want an enemy to see and chase the player

Read in this order:

1. Possession - understand why the enemy pawn needs an AIController before AI movement can drive it.
2. Spawn Default Controller and Auto Possess AI
3. make sure placed and spawned enemies actually create their AIController.
4. Possess / Un Possess / Get Controller
5. prove the enemy pawn has the AIController you think it has before debugging movement.
6. AI Move To & the NavMesh - set up the NavMeshBoundsVolume, AIController, Acceptance Radius, and success/fail handling.
7. Get Random Reachable Point in Radius
8. choose simple random patrol destinations and branch on the success Boolean before Move To.
9. Seeing the player: Pawn Sensing & AI Perception
10. start with On See Pawn, then learn when AI Perception is the better system.
11. Behavior Trees and Blackboards for Blueprint Beginners
12. move beyond one sensing event into patrol/chase/search/attack branch structure.
13. Run Behavior Tree, AIController Setup, and Blackboard Keys
14. start the tree from the AIController and let perception set Blackboard facts instead of directly running every behavior.
15. Move To Task, Decorators, Services, and Observer Aborts
16. understand why a Behavior Tree branch starts, stops, keeps moving, or immediately switches when Blackboard facts change.
17. Simple Patrol, Chase, Attack, and AI Debugging
18. assemble the first practical patrol/chase/search/attack loop and debug it without guessing.
19. Nav Link Proxy and navigation modifier boundaries
20. fix jumps, drops, doors, costly areas, and agent-fit issues in the NavMesh instead of rewriting Move To.
21. EQS query basics after the first Behavior Tree
22. add generators, contexts, tests, and scores when the AI needs a "best" cover/patrol/attack point instead of a random point.
23. StateTree vs Behavior Tree for Blueprint beginners
24. decide whether a state-machine asset is useful, or whether the working Behavior Tree should stay.
25. Gameplay Debugger and AI Debugger for Blueprint Beginners
26. use the apostrophe overlay to inspect NavMesh, AI, Behavior Tree, Blackboard, EQS, and Perception data on the selected actor.
27. Visual Logger, EQS Debugger, and ShowDebug Boundaries
28. choose recorded timelines, EQS query views, or console overlays when live prints are not the right evidence.
29. Get Forward Vector & Find Look at Rotation
30. face the player or reason about sight direction and yaw-only rotation.
31. Dot Product, Angle, and Facing Checks
32. turn normalized directions into front/behind or field-of-view tests without mistaking an angle check for range, occlusion, or perception memory.
33. Line Trace By Channel - add explicit line-of-sight checks when sensing needs a precise blocker test.
34. Print String and the Output Log and Breakpoints and watch values
35. prove the sensing event fired, the target is valid, and the move request or Behavior Tree branch returned a useful result.

Usual shape:

Enemy has AIController and stands on green navmesh
-> simple patrol uses Get Random Reachable Point or authored patrol points
-> Pawn Sensing On See Pawn or AI Perception Successfully Sensed true
-> set Blackboard TargetActor / LastKnownLocation
-> Behavior Tree selects chase, search, attack, or patrol
-> EQS chooses scored cover/attack points only when random/authored points are not enough
-> Nav Link Proxy or modifiers fix broken nav data, not Behavior Tree logic
-> decorators and observer aborts switch branches when the Blackboard changes
-> Move To task or AI Move To uses the NavMesh
-> debug controller, blackboard, tree branch, and movement result
-> use Visual Logger or EQS debug views only when the live facts need history
   or query scoring evidence

I want to add basic multiplayer

Read in this order:

1. Multiplayer roles - learn which machines have GameMode, GameState, PlayerState, PlayerController, Pawn, UI, and GameInstance.
2. Replication basics - understand Replicates, replicated variables, RepNotify, server-spawned actors, RPCs, relevancy, and why widgets do not replicate.
3. Create Local Player / Get Num Player Controllers
4. understand why split-screen/local-player counts are not the same as online client/player counts.
5. Get Game Mode / Game State / Player State
6. use GameState and PlayerState for client-readable public state instead of trying to read server-only GameMode everywhere.
7. Get Owner / Set Owner
8. understand the owner chain behind owned server RPCs and owner-only replication.
9. Replicating Actor Components
10. make HealthComponent, InventoryComponent, team, status, and interaction state replicate through a real actor/component/server path.
11. Replicate Movement vs replicated variables
12. separate actor/root movement from health, ammo, movement mode, and other gameplay state.
13. Blueprint Custom Events as RPCs
14. turn Custom Events into Run on Server, Run on Owning Client, or Multicast messages with the right ownership path and reliability choice.
15. Reliable vs unreliable RPC budget
16. spend Reliable on rare important messages, not Tick, held input, or state that should be replicated.
17. RepNotify variables and local presentation
18. update local UI, audio, materials, and VFX when replicated state arrives.
19. GameState and PlayerState in practice
20. keep match state in GameState and public per-player state in PlayerState.
21. Actor relevancy, owner-only, and dormancy basics
22. decide which clients should receive an actor, owner-only data, or a multicast before changing update rates.
23. HUD state from replicated and local data
24. build local HUD and scoreboard widgets from replicated pawn, PlayerState, and GameState values without trying to replicate widgets.
25. Nameplates, floating health bars, and damage numbers
26. display replicated public player/team/health state locally on each client.
27. Has Authority / Switch Has Authority / Is Locally Controlled
28. separate server authority from owning-client UI/input branches.
29. Possess / Un Possess / Get Controller
30. keep pawn switching and controller ownership on the authority path.
31. Multiplayer PIE debugging basics
32. prove which window, world, actor copy, and machine ran the graph.
33. Network Emulation for beginner replication checks
34. add latency and packet loss after the clean PIE client/server path works.
35. GameMode & friends, single-player edition
36. revisit framework ownership with the new server/client audience rules.
37. Spawn Actor from Class - make runtime gameplay actors server-spawned when everyone should see them.
38. Projectile Movement Component and first projectile actor
39. spawn replicated gameplay projectiles from the server while keeping local muzzle feedback cosmetic.
40. Get Player Character / Pawn / Controller
41. avoid treating player index 0 or PlayerController as "get any player."
42. Event AnyDamage / Apply Damage
43. keep authoritative gameplay results on the server.

Usual shape:

Client presses Fire
-> Run on Server event on owned pawn/controller
-> server validates
-> server spawns replicated projectile
-> replicated projectile/ammo/state reaches clients
-> RepNotify/local UI/audio updates on each client
-> print net mode, authority, and local control in PIE when it fails
-> add Network Emulation after the clean remote-client path works

I want to debug red Blueprint errors

Read in this order:

1. Accessed None - read the error as "this reference was empty here," not as a random crash.
2. Print String and the Output Log
3. print the values and instance names that prove your graph is running.
4. Event BeginPlay / Tick / EndPlay / Set Actor Tick Enabled
5. prove whether setup, per-frame work, or cleanup actually ran.
6. Breakpoints and watch values
7. pause the right Blueprint instance and inspect pin values.
8. Is Valid - guard optional references only after you understand who was supposed to assign them.
9. Get Actor Of Class / Get All Actors Of Class
10. avoid "fixing" missing references by searching the whole world every time.
11. Get All Actors with Interface / Get All Actors with Tag
12. understand empty search arrays and tag/interface setup before using a world scan as a debug shortcut.

Usual debug loop:

Read the exact error
-> identify the empty variable/pin
-> breakpoint where it should be assigned
-> watch the value
-> fix the assignment or guard the optional path

I want to know what to read next

If the thing you want is not mapped above yet, use the roadmap. It is ordered by beginner value, not by engine category. The top item is the next missing page, and shipped pages leave the list.

This index grows as pages ship. For now, it links only to pages that already exist, plus the roadmap when a needed piece is still waiting its turn.