Use Simulate to Watch Runtime Actors in the Editor
If you need to inspect spawned actors, AI movement, or live transforms from the editor viewport, use Simulate instead of expecting a second editor viewport to behave like a runtime game camera. It gives you a much better debugging surface for non-destructive runtime inspection.
Overview
- Choose the right play mode for runtime inspection
- Use Simulate to keep the editor world interactive
- Possess and eject when you need to switch between gameplay and inspection
- Combine it with Blueprint debugging and world outliner inspection
A common frustration for developers coming from other engines is expecting a second editor viewport to live-update with runtime-only actors during normal PIE. In Unreal, the most practical workflow for inspecting spawned objects, transforms, and component state from the editor side is Simulate, not a passive second viewport.
Pick the Right Runtime Mode
PIE, Standalone, and Simulate are not equivalent. If your goal is to play the game exactly as a user would, PIE or Standalone is fine. If your goal is to inspect runtime state from the editor while the world ticks, Simulate is the mode I reach for first.
- PIE: best for normal gameplay iteration
- Standalone: best for cleaner runtime behavior and perf checks outside editor overhead
- Simulate: best for inspecting spawned actors and editor-visible runtime state
Use Simulate for Live World Inspection
Simulate lets the world run while keeping the editor inspection tools active. That means you can click actors in the World Outliner, inspect components, watch transforms change, and verify whether runtime spawns are landing where you expect without losing the editor context.
- Click the Play dropdown in the toolbar
- Choose Simulate
- Run your spawn or gameplay event
- Inspect new actors in the World Outliner and Details panel
Possess and Eject When You Need Both Views
A good Unreal workflow is switching between control and inspection instead of trying to keep two fully synchronized editor views. Possess the player when you need input-driven behavior, then eject to inspect the runtime world after the event reproduces.
- Start in PIE or Simulate
- Trigger the gameplay event you want to inspect
- Eject to return to editor-style camera control
- Select the spawned actor and inspect state live
Pair It with Blueprint Debugging
Simulate is even more useful when paired with Blueprint breakpoints and watch values. You can pause execution on a spawn path, inspect variables in the Blueprint debugger, then jump back to the editor world to confirm the actor exists and has the expected components and defaults.
- Set a breakpoint on SpawnActor or the construction path you're debugging
- Use the Blueprint Debugger to inspect parameter values
- Resume execution and confirm the actor appears in the runtime World Outliner
- Check Details panel values against what the Blueprint claimed it set
Use Standalone for Final Verification
I still validate tricky issues in Standalone after using Simulate to inspect them. Simulate is a fantastic editor debugging mode, but final behavior should be checked in a more game-like runtime path once you've isolated the issue.
"C:\Program Files\Epic Games\UE_5.3\Engine\Binaries\Win64\UnrealEditor.exe" "D:\Projects\MyGame\MyGame.uproject" /Game/Maps/TestMap -game -log
# Running with -game gives you a cleaner runtime pass after you've used Simulate to inspect the issue.
Where This Fits in a QA Workflow
This is one of those small editor habits that saves a lot of debugging time. When a bug depends on runtime spawns, AI movement, or transform updates, Simulate gives you a better inspection surface than fighting the viewport layout. I keep it in the toolkit for quick repro, state verification, and Blueprint-side debugging before escalating to deeper profiling or logging.
Source Reference
Inspired by a discussion on r/unrealengine (6 upvotes, 25 comments)