Isolated runtime testing without touching authored data.
Play mode
Play mode runs your game inside the editor so you can try a level the moment you finish editing it. It exists to shorten the loop between "I placed a jump pad" and "the jump pad feels right" to a single button press. The rule that makes it trustworthy: play mode runs in an isolated runtime world and must never mutate the authored scene data you were editing.
Why isolation matters
When the game runs, scripts move entities, spawn enemies, change HUD values, and write saves. If that live state leaked into the document under edit, one test run would rewrite your level. Play mode therefore executes against a separate runtime world:
- Entity positions, health values, spawned objects, and runtime hierarchy changes live only for the play session.
- Runtime hierarchy, debug, and profiler state must not silently mutate authored scene data.
- Stopping play restores the authored document exactly as it was — no undo cleanup required.
Saves written by the running game go to platform user-data, never into the project or the document you have open. That separation is the same one shipping builds obey.
Entering and leaving play
Play mode is a toggle in the editor workspace (see Workspace & panels):
- Open the registered scene you want to try.
- Start play. The editor builds an isolated runtime world from the current document and begins executing scripts and simulation.
- Interact in the viewport with keyboard, mouse, gamepad, or virtual controls — the same input actions your shipped game uses.
- Stop play. The runtime world is discarded; the authored document is unchanged.
Edits made while playing do not write through to the source document. Stop play, make the edit in authoring mode, and start play again to test the new state.
Game View displays only the rendered game, with no editor status or input-hint overlays. It is blank when stopped. Use the toolbar for Play controls and status, and Console for runtime diagnostics.
Click Game View to focus gameplay input. Ctrl+D releases mouse capture and detaches game input so you can use the editor again; click Game View to resume. Switching away or losing window focus also releases capture. The runtime Inspector remains read-only while Play is active.
What runs during play
Play mode is the real runtime, not a preview approximation:
- Script lifecycle runs as in a shipped game:
on_create,on_start,on_update,on_fixed_update,on_destroy. - Physics steps at the project's fixed timestep, so what you feel in play mode is what players will feel. Deterministic settings are described in Simulation & seeds.
- Input is sampled from live devices through the project's actions and bindings (Input bindings).
- HUD nodes respond to actions and display values your scripts set.
Because play mode uses the same runtime as demi run, a bug that only reproduces in play mode is a real game bug, not an editor artifact.
Observing without interfering
While playing, the workspace panels become observation tools:
| Panel | During play |
|---|---|
| Hierarchy | Shows the runtime world, including spawned entities. Read-only with respect to the authored document. |
| Inspector | Shows live component values as simulation updates them. |
| Viewport | Draws the running game with optional debug overlays: colliders, contacts, grid, entity IDs, draw order, UI bounds, profiler. |
| Diagnostics | Reports runtime and validation issues with the same stable codes as demi validate. |
| Profiler | Shows frame time and per-scope cost while the game runs. |
Debug overlays can also be forced for one launch outside the editor:
demi run \
--debug-overlays colliders,contactsrun— launches Skyforge from the command line.--debug-overlays colliders,contacts— comma-separated overlay names for this run, overriding the project's debug flags.
Returns 0 on a clean run.
Play mode versus demi run
| Question | Play mode | demi run |
|---|---|---|
| Where does it run? | Inside the editor window | As its own application |
| Best for | Fast iteration while authoring | Player-like sessions, replays, headless smoke runs |
| Isolation | Discarded runtime world; authored data untouched | Full game; saves go to platform user-data |
| Extra flags | Overlays and profiler in their panels | --max-frames, --input-replay, --e2e-tests, --profile-report, and more |
Command-line launch details are in Create & develop.
A practical loop
- Edit the scene in the authoring stage.
- Play and try the change.
- Watch the profiler panel if the frame time rose; the measurement workflow is in Replay & profiler.
- Stop play, adjust, repeat.
- When the behavior is right, lock it in with E2E tests so it cannot regress silently.
The read-only Runtime Inspector reads current native component fields, including transforms changed by scripts or physics. These are local transform values when an entity has a parent. Fields without a live inspection codec are explicitly marked unavailable; they are not substituted with saved values. This view does not expose arbitrary Lua instance variables or renderer/physics internals.
Debug, Release and E2E runs
For normal authoring and performance tests, launch the optimized native editor with ./build/linux-release/demi editor --project path/to/project. The native linux-debug build is intended for C++ engine debugging and can be much slower. This is separate from your game's scripts or authored data.
After rebuilding native engine/editor code, close and relaunch the editor before measuring the change. Stopping and restarting embedded Play creates a fresh game world but does not reload the editor executable.
Run & Test in the toolbar launches a standalone Debug or Release runtime. This chooses an actual compiled executable; embedded Play always uses the editor's own build. The panel looks for matching build directories, and Runtime location lets you select an installed CLI executable. Missing builds are reported before launch.
Run project and Run E2E tests save authoring sessions before launch. E2E uses the same runtime harness as the CLI and requires scripts/tests/e2e.lua. Set both a simulation frame limit and a wall-clock timeout for longer scenarios. The panel shows the process output and pass/fail status; Stop cancels the owned process. Pause and single-step controls apply to embedded Play; standalone game pause is controlled by the game. Only the most recent MiB of console output is retained. Close the panel to keep working while a test finishes, or reopen it for the result.