Blueprint Basics · Easy · 12 min
Debug Blueprints: Print String, Breakpoints, and Watching Values
Stop guessing why your Blueprint won't work. Print values to the screen, pause the game on a node with a breakpoint, step through one node at a time, and watch a variable change live — the exact workflow pros use to find any bug.
Before this: Event Graph Basics: BeginPlay, Nodes, and Wires Explained, Blueprint Variables: Store and Change Values to Drive Behaviour
- Use Print String to log values and confirm a piece of script actually ran
- Set a breakpoint (F9) on a node to pause the game right there
- Step through your graph one node at a time and read the highlighted execution flow
- Watch a variable's live value while paused to spot the wrong number
"Why isn't my Blueprint working?"
Every single person who learns Blueprints hits this wall: you wire something up, you press Play, and… nothing happens. Or the wrong thing happens. The instinct is to stare at the wires and hope the bug jumps out. It almost never does.
The faster, calmer way is to make the Blueprint tell you what it's doing. Unreal gives you simple tools to print messages while the game runs, to pause the game on a specific node and look around, and to read the real value inside a variable at that exact moment. Once you can do that, debugging stops being magic and becomes a short checklist: did this run? what was the value here? where did it stop?
This lesson teaches that checklist. Nothing here is advanced — it's the everyday workflow you'll reach for forever. Tick off each step as you go.
Four words you'll use constantly
Tap a card to flip it
The four debugging moves, hands-on
Open any Blueprint that misbehaves (or the Blueprint from an earlier lesson). We'll add a print, set a breakpoint, step through it, and watch a value. Tick each step so you can come back where you left off.
- 1Drop in a Print String to confirm it ran
In the Event Graph, drag off the white execution pin of the event or node you're suspicious of and search for 'Print String'. Connect it so it runs right after that node.
Type something recognisable into its 'In String' box, like 'BeginPlay fired!'. Press Play. If the message appears in the top-left corner of the game view, that part of your script definitely ran.
TipNo message on screen means that branch never executed — so the bug is upstream, before your Print String, not after it. That alone narrows the search hugely.
- 2Print an actual value, not just text
Often the script runs but a number is wrong. Drag a variable (say your Health or Speed) onto the graph as a 'Get', then drag from it into the Print String's 'In String' pin — Unreal auto-adds a small convert node so the number becomes text.
Now the printed line shows the real value at that moment, e.g. 'Health: 0'. Seeing the number is usually the moment the penny drops.
TipGive each Print String a unique label like 'A:' or 'after damage:' so when several print at once you can tell which line is which.
- 3Set a breakpoint with F9
Click a node to select it, then press F9. A small red marker appears on the node — that's a breakpoint. (Right-clicking the node and choosing 'Add Breakpoint' does the same thing.)
Press Play. The moment execution reaches that node, the game pauses, Unreal brings the Blueprint Editor to the front, and the node is highlighted. The game is frozen exactly there, waiting for you.
TipPut the breakpoint on the FIRST node you're unsure about. If the game pauses there, the script reached it; if it never pauses, execution never got that far.
- 4Step through one node at a time
While paused, look at the debugging toolbar at the top of the Blueprint Editor. Use 'Step Into' / 'Step Over' to advance a single node. Each press moves the glowing execution marker along the wires.
Watch where the glow goes. If a Branch sends the flow down the 'False' path when you expected 'True', you've found your bug — the condition is wrong. Click 'Resume' (or the continue button) to let the game run on.
TipStepping reveals the path the game actually took, not the path you assumed. Branches going the 'wrong' way is one of the most common beginner bugs, and stepping makes it obvious.
- 5Watch a variable's live value
Right-click a variable node (or a data pin) and choose 'Watch this value'. An eye-style marker is added. Now, whenever the game is paused at a breakpoint, that value is displayed right on the node.
You can also simply hover the mouse over any data pin while paused to see a tooltip with its current value. Either way, you're reading the truth — the number the game actually has, not what you hoped it had.
TipWatching the variable that 'should' change is the fastest way to catch a value that's stuck at zero, never gets set, or gets overwritten a moment later.
- 6Clean up before you ship
When the bug is fixed, remove your debug aids. Delete the temporary Print String nodes, and clear breakpoints (right-click a node → 'Remove Breakpoint', or use the Blueprint Editor's debugging menu to remove all).
Leftover Print Strings clutter the screen and the log; leftover breakpoints will keep pausing your game and confuse you (or anyone else) later.
TipPrint String has a 'Development Only' setting that's on by default, so it won't run in a shipping build — but it still clutters your editor, so tidy up anyway.
Debugging shortcuts to remember
- F9 Toggle a breakpoint on the selected node
- F10 Step Over — run the next node and pause again (default; check your editor's bindings)
- F11 Step Into — go inside a called function/macro node (default; check your editor's bindings)
- F5 Resume — continue running until the next breakpoint (default; check your editor's bindings)
- ` (backtick) Open the in-game console (e.g. to type 'stat fps') while testing
Print to the on-screen view vs. the log
stat fps ; show frames-per-second while you test
stat unit ; frame / game / GPU timings, to spot slow logic
DumpConsoleCommands ; list available console commands if you're curiousYou pressed Play but your Print String message never appears on screen. Before assuming Print String is broken, what does its silence actually tell you — and what should you check first?
Print String almost never breaks. If the message doesn't appear, the most likely truth is that the execution wire never reached it — so the bug is UPSTREAM, in whatever should have run before it.
Check the obvious first: is the Print String's white execution pin actually wired into the flow (not left dangling)? Is the event that's meant to trigger it actually firing — for example, is this Blueprint actor even placed in the level? Move the Print String earlier in the chain, or add a second one on the event itself, to find exactly how far execution gets.
Two quick gotchas: make sure 'Print to Screen' is ticked on the node, and remember the message only shows for a couple of seconds by default (raise its 'Duration' if you keep missing it).
Print String vs. breakpoints — when to use which
You want a quick yes/no: did this run? what's this value right now? It needs no pausing and you can watch a sequence of values scroll by as the game plays.
It's perfect for things that happen fast or repeatedly (every frame, on each overlap), where pausing on every hit would be maddening. You just read the printed stream.
You need to stop time and look around: which branch did it take? what are several variables at this exact instant? You can then step node-by-node and inspect everything while frozen.
It's ideal for logic that only runs once or on a specific action, and for following a confusing path through Branches, loops and function calls.
Take a Blueprint with a number variable (for example a Health or Score the earlier lessons had you create). Deliberately or accidentally, it isn't updating the way you expect. Use the debugging workflow to PROVE what's happening: confirm the script runs, read the real value, pause where it's set, and watch it change (or fail to).
Hint 1
Start with a Print String that prints the variable, placed right after the node that's supposed to change it. Does the printed number ever change?
Hint 2
If the print shows a wrong number, set a breakpoint (F9) on the node that sets the variable, press Play, and trigger the action.
Hint 3
While paused, right-click the variable and choose 'Watch this value' (or hover its pin) to see what it actually holds at that instant.
Hint 4
Step one node at a time and watch which path the execution glow takes — a Branch going the unexpected way is often the whole problem.
Add a Print String after the 'Set' node, dragging the variable into its In String so it prints the value. Press Play and trigger the action. Suppose it always prints the same starting number — the value isn't changing.
Put a breakpoint (F9) on the Set node and Play again. If the game never pauses there, that Set node is never reached: the bug is upstream — maybe a Branch above it sends the flow elsewhere, or the event never fires. Step through to see the glow take the wrong path.
If it DOES pause on the Set node, right-click the variable and Watch it (or hover the pins). Step over the node and watch the value update — if the new value is wrong, the input feeding the Set is wrong; if it's right but reverts moments later, something else is overwriting it afterwards.
Fix the cause (correct the Branch condition, the input maths, or the overwrite), then remove the breakpoint and the temporary Print String. That four-move loop — run? value? where? watch — resolves the large majority of beginner Blueprint bugs.
QuizCheck yourself
1You add a Print String after a node and press Play, but nothing prints. What is the most likely conclusion?
Print String is reliable. Silence almost always means the white execution wire never got there — the bug is earlier in the chain, so move your investigation upstream.
2Which key sets (or clears) a breakpoint on the node you've selected in a Blueprint?
F9 toggles a breakpoint on the selected node. When the game's execution reaches that node, it pauses so you can inspect everything.
3While paused at a breakpoint, what is the quickest way to see the real, current value of a variable?
Watching a value (or hovering a pin while paused) shows the live value the game actually holds at that instant — the fastest way to catch a wrong or stuck number.
You can now
If you can tick all of these, you have the everyday Blueprint debugging toolkit:
- Add a Print String to confirm a piece of script ran
- Print a variable's value (with the auto-added convert node) to read the real number
- Set and clear a breakpoint on a node with F9
- Step through a graph one node at a time and read where the execution glow goes
- Watch a variable's live value (or hover a pin) while paused
- Tidy up — remove debug Print Strings and breakpoints when the bug is fixed
Mark this lesson complete
We'll remember it on your Academy page and unlock the next lesson below.
Questions beginners ask
My Print String message flashes and disappears too fast to read. How do I keep it up longer?
The Print String node has a 'Duration' setting (default around two seconds). Select the node, open the Details panel, and raise the Duration to keep the message on screen longer. You can also tick 'Print to Log' and read it at leisure in Window → Output Log, which keeps a full history.
I set a breakpoint but the game never pauses on it. What's wrong?
Almost always, execution simply never reaches that node — which is itself a useful finding. Check that the event meant to trigger it is firing, that this Blueprint actor exists in the level, and that no Branch above it is diverting the flow. Move the breakpoint earlier in the chain to discover exactly how far execution does get.
Will my Print Strings show up in the final packaged game?
Print String defaults to 'Development Only', so it won't run in a Shipping build. That said, it's good practice to delete temporary debug prints anyway — they clutter the screen and the log during development, and leaving them in is an easy habit to regret later.
What's the difference between Step Into and Step Over?
Both advance execution one step while paused. 'Step Over' runs the next node and pauses again at the following node, treating a function call as a single step. 'Step Into' goes inside a called function or macro so you can debug its internals node by node. Use Step Over to skim the main flow, Step Into when you suspect the bug is inside a function you called.