Skip to main content

Optional Systems-Heavy Reference Profile

STAGE does not require one runtime architecture. This profile is an inspection question set and one possible design for systems-heavy games. Project-native ownership and lifecycle always win over this shape.

Planes​

Authored Intent
  definitions, catalogs, configs, scenes, prefabs, data assets
        |
Composition And Lifecycle
  dependency wiring, startup, reset, transitions, teardown
        |
Runtime Kernel
  state, rules, systems, schedules, registries
        |
Engine Shell
  views, physics, rendering, input, audio, persistence, middleware

Control And Observation cross every plane:
  existing authoring paths, diagnostics, tests, scenarios, logs, live views
  and optional captures for decision-bearing artifact consumers

Authored Intent​

Authored intent describes desired content and tunable behavior. It should be inspectable without entering a live run and should not silently become shared mutable runtime state.

Common implementations include ScriptableObjects, Unreal DataAssets, Godot Resources, JSON, tables, prefabs, scenes, and custom editors.

Composition And Lifecycle​

Composition identifies what exists, how dependencies are provided, and when objects start, pause, reset, transition, and dispose.

Dependency injection is optional. Explicit constructors, engine subsystems, scene roots, or composition functions are valid when ownership remains clear and composed startup can be verified.

Runtime Kernel​

The runtime kernel owns game decisions and state transitions. A custom loop is optional, but timing and order should be explicit where they affect behavior.

Useful roles include:

  • runtime state records;
  • deterministic rules;
  • orchestration systems;
  • factories and pools;
  • registries and queries;
  • lifecycle coordinators.

Role suffixes are navigation aids, not quotas. A domain does not need one class of every role.

Engine Shell​

The engine shell performs work that is naturally engine-bound: transforms, physics, rendering, particles, animation, input, audio, serialization, and scene integration.

Engine types may cross inward when isolation would cost more than it returns. The boundary should be deliberate rather than ideological.

Control And Observation​

Every important domain should be understandable through its canonical state, existing project routes, and relevant production consumer. Dedicated controls are optional. Add them only when an observed recurring job or risk earns their maintenance cost.

Useful responses include:

  • human authoring controls when people repeatedly tune the domain;
  • diagnostics for important hidden state or recurring invisible failures;
  • deterministic or repeatable rehearsal when risk or recurrence warrants it;
  • a stable agent operation only for a named repeated operation with understood readiness, failure, reset, and teardown; and
  • a declared human review point for subjective quality.

Repository search, existing editor state, logs, direct game routes, and manual operation may already be sufficient. Do not create one authoring tool, diagnostic surface, or agent API per domain to satisfy this profile.

Domain Package Shape​

A mature domain can be understood through seven questions:

  1. What vocabulary defines it?
  2. What is authored?
  3. What changes at runtime?
  4. Which rules and systems own those changes?
  5. Which engine or middleware adapters perform side effects?
  6. How is it operated and inspected?
  7. What evidence proves its claims?

The answers can span many files or one small module. Optimize for legibility and change risk, not uniform directory depth.

Runtime Alternatives​

MonoBehaviour-Oriented​

Compatible when ownership, lifecycle, diagnostics, and verification remain explicit. Local component behavior does not need to be extracted merely to appear architectural.

ECS Or DOTS​

Compatible when authoring, governance, tooling, and evidence remain first-class. ECS can implement the runtime kernel without replacing the STAGE operating method.

Custom Engine​

Compatible when data formats, schedules, adapters, and operation APIs provide the same project qualities. STAGE is concerned with control and evidence, not engine branding.

Engine-Native Scenes And Resources​

Compatible when scenes, Nodes or actors, Resources or assets, signals, and engine lifecycle callbacks are the actual ownership model. Do not rename them into services or systems merely to match this profile.

Session Or World Framework​

Compatible when Sessions or worlds own component data, Resources, schedules, and reset behavior. Map the schedule and retained state directly; the renderer or host engine may be an adapter rather than the application architecture.

Last updated on