Runtime Debug Overlays And Developer Options
Runtime debug overlays and developer options expose the live presentation state that artists, designers, and engineers need while previewing scenes. They are shared by editor play, local playtest, standalone shells, and player-preview synchronization.
Purpose
Use this page when adding a debug overlay, a CLI or environment option, or a presentation setting that should behave consistently across editor and standalone runtime surfaces.
Overlay Descriptors
Overlays should be descriptor-backed rather than one-off UI branches. A descriptor gives the overlay a stable id, label, initial state, and integration point. That keeps editor toggles, standalone defaults, and runtime presentation sync from drifting.
Use overlays for runtime facts that help diagnose the running world: presentation state, schedule simulation, current scene, camera state, player-preview sync, and similar information. Do not use them as a substitute for validation errors.
CLI And Env Inputs
Developer options may come from command-line arguments, environment variables, standalone shell defaults, or editor viewport toggles. Route them into the shared runtime-presentation state before systems read them.
If a flag is useful in local playtest and standalone preview, document it in the option parser and keep the default safe for normal gameplay.
RuntimeWorldPresentationState
RuntimeWorldPresentationState is the bridge between running world state and presentation/debug UI. Systems that mutate presentation state should do so through the shared state rather than by reaching into an editor-only panel.
This matters for player preview: preview synchronization can mirror runtime presentation choices only when they are represented in the shared state.
Editor Play, Local Playtest, And Standalone
Editor play is embedded and should keep authoring controls available. Local playtest should behave close to runtime while still surfacing debugging overlays. Standalone shell should prove that the packaged runtime can run without editor-only services.
When adding a debug option, decide which of the three should expose it and which should only consume the default.
Debugging
If an overlay works in the editor but not standalone, inspect the developer option source and bootstrap path. If standalone shows stale presentation state, inspect runtime_presentation_sync. If a viewport toggle has no runtime effect, confirm it writes the shared presentation state instead of an editor-local boolean.
Examples
A schedule simulation toggle should be available in editor viewport tools and local playtest. It should write the same runtime presentation state that scene scheduling reads, then the overlay can display the simulated time source.