App Mode Bootstrap And Lifecycle
App mode bootstrap assembles the engine into editor, runtime, local playtest, standalone, and support-tool modes. It decides which plugins are shared, which are mode-specific, and which authority or prediction policies are active.
Purpose
Use this page when adding a plugin, changing startup mode behavior, debugging a system that runs in the wrong shell, or deciding whether a feature belongs in foundation, shared runtime, multiplayer, editor, or standalone layers.
Mode Selectors
App mode selection should be explicit. The mode determines plugin layers, window defaults, runtime presentation settings, local service assumptions, and exit behavior. Do not infer mode from a random feature flag after the app is already assembled.
Plugin Layers
Foundation plugins provide platform, assets, schedules, and rendering basics. Shared runtime plugins provide scene, UI, input, and presentation systems. Multiplayer plugins add networked authority and replication. Mode-specific plugins add editor, standalone, or preview-only behavior.
Authority And Prediction Matrix
Editor preview can simulate. Standalone can run client flows. Game server remains authoritative for online player state. When adding a system, document whether it is local-only, predicted, server-authoritative, or purely presentational.
Window And Backend Defaults
Bootstrap owns WGPU/backend defaults, window setup, and render-surface safety. Mode-specific code should not silently override platform defaults unless the mode is intentionally specialized.
Centralized Exit Flow
Exit behavior belongs in the shared exit path. Systems should request exit or shutdown through the central flow so background tasks, windows, and runtime resources are cleaned up consistently.
Boundary Tests
Mode boundary tests should catch plugins that drift into the wrong app mode, render guards that are missing from a shell, and exit behavior that bypasses shared cleanup.