Game: running and debugging in the editor

The Game workspace shows the running game and its debugging tools. The game still runs in a separate process: its window is embedded, not its logic moved into the editor process. Use export to check a standalone build separately.

Select a launch mode

Open Game. The current interface has three mode buttons on the right, rather than two options in the older dropdown. Hover a button to read its tooltip:

The tooltips start with Run the game… and end with on the next run. The choice applies to the next launch. Stop the project, choose a mode and run again; do not expect the choice to recreate an already running window immediately.

Embedding depends on platform window-embedding support. It is unavailable for headless runs and may be blocked by fullscreen, maximized or minimized window modes. If a button is unavailable, read its tooltip, then check the project window mode and run arguments. Do not change rendering drivers at random to enable embedding.

Embedded window size

The sizing menu offers three modes:

The base size uses display/window/size/viewport_width and viewport_height. The display/window/size/window_width_override / window_height_override pair overrides the launch-window size when both values are positive.

This controls window placement in the editor. It does not replace game-content stretch settings or establish that the UI works at every resolution. Test actual target window sizes and the project UI setup.

Pause and frame advance

Suspend pauses processing in the running game’s tree. Debugging tools remain available. Without an active game session, pause is disabled; first confirm that the project is running and connected to the debugger.

Next Frame is available while the game is suspended. It temporarily resumes execution and suspends the tree again after drawing. Do not interpret it as a guarantee of exactly one physics tick: physics and displayed frames use different schedules.

To inspect a short-lived event:

1. Reproduce the situation in the running game.
2. Suspend before the event.
3. Advance with Next Frame, checking the relevant object state.
4. Resume through the pause button when done.

Debugger suspension is not your in-game pause menu and does not test that menu’s behavior.

Debug playback speed

The speed menu slows or accelerates testing; normal speed is 1.0×. Its multiplier combines with the game’s Engine.TimeScale. For example, 0.5 in code and 0.5× in the toolbar produce an effective speed of 0.25.

Reading Engine.TimeScale in code still returns the game multiplier, not its product with debug playback speed. Internal physics scheduling also accounts for the debug multiplier; the toolbar does not rewrite Project Settings. Do not use it to save game-speed settings or substitute for a performance test.

Restore 1.0× after testing. If motion is unexpectedly slow, check both the toolbar and your own Engine.TimeScale before changing character speeds or timers.

Selection and persistence

If the character stops responding, switch back to Input first. 2D/3D selection is a debugging mode, not ordinary gameplay with the same input behavior.

Edits to an object in the running process last only for that session. To retain a result, apply the intended value to the local level, prefab or resource and save its file. Debug → Synchronize Scene Changes controls sending supported local edits to the running project; it does not automatically save remote edits back to disk. C# changes and rebuilds require separate checks.

See Inspector for resource sharing and persistence.

Diagnosis

Current buttons, sizing menu and disabled pause without a session were checked in the installed editor. Active-process behavior was reviewed against source; real window embedding, remote selection and frame advance were not exercised here.