PixelBullet  0.0.1
A C++ game engine
Loading...
Searching...
No Matches
Runtime And Scene Play

Application And Layer Lifecycle

pixelbullet_entrypoint owns process entry and application launch wiring. Concrete executables build an ApplicationSpecification, create focused services, and install application Layer instances. Generic layer lifecycle uses OnAttach, OnDetach, OnUpdate, OnEvent, and the UI-toolkit-neutral OnUiFrame.

Application startup adapts launch configuration into neutral filesystem, window, graphics, audio, logging, and asset state. Domain systems do not depend on the application aggregate merely to access another subsystem.

Scene-Play Runtime Stack

The framework separates runtime logic from the application adapter:

Surface Responsibility
SceneRuntimeSession One active scene's simulation, controllers, progression state, inspection, and presentation-facing outputs
ScenePlayClient Headless scene loading, run/reload/restart/transition orchestration, input policy, progression, and presentation-frame production
ScenePlayLayer Engine Layer adapter that binds window/input, cursor capture, graphics resources, renderer installation, and a ScenePlayClient
ScenePlayPresentationFrame Client/editor-facing render, UI, audio, and cue snapshot
SceneRuntimePresentationSnapshot Runtime-shell current-state snapshot copied into the presentation frame

BulletSketch uses ScenePlayClient directly for Play in Viewport. Application-style authored-scene execution may use ScenePlayLayer. The authored-scene workflow defines when BulletSketch or the generic runner owns the surrounding process.

Scene Sources And Registration

A scene-play run may start from a logical scene path or an already loaded Scene. Logical-path starts allow scene transitions; embedded editor snapshots may disable them. Scene-play creation uses the framework component registration set, including gameplay components and schema. Prefab loading preserves that registration context across nested resolution.

Scene loading resolves authored dependencies through Filesystem and the asset/scene integration facades. Authored YAML remains the source of truth; generated binary sidecars may accelerate compatible prefab loads without changing authoring semantics.

Runtime Responsibilities

SceneRuntimeSession owns scene-scoped frame orchestration and delegates to focused controllers for physics, locomotion, inventory, missions, behavior, combat, animation, presentation, and runtime UI. Controllers keep transient per-scene state; the session exposes coherent inspection and event streams.

ScenePlayClient owns run-level behavior around the session:

  • load, reload, restart, and allowed scene transitions;
  • progression snapshot capture and load;
  • focus-aware input capture and runtime controls;
  • pause/completion menus and cursor-capture intent;
  • conversion into one presentation frame for renderer, UI, audio, and tooling.

The runtime reports requested cursor capture; the application/window boundary applies native capture. Focus loss releases active capture without erasing the request.

Presentation Ownership

Gameplay state remains in scene play. Once data crosses the presentation boundary:

  • framework/scene_play/presentation owns presentation snapshots and the projection from gameplay state;
  • framework/ui owns runtime UI value and render-input types;
  • renderer and audio presenters consume the presentation frame;
  • editor preview data stays editor-owned and adapts into the same focused presentation contracts.

Current Boundary

Scene play runs authored scene sessions. It does not provide a product composition root, a product-wide RunSession, matchmaking, front-end flow, or product package lifecycle. Those responsibilities belong to a genuine product, not to ScenePlayLayer or the generic scene runner.