GameConfig

The singleton boot config for a 6-DOF space mission — mode, level, and URL-override policy — carried on the world/director entity.

What it does

GameConfigComponent is three plain, serializable boot values: testMode, the level to run, and whether a ?test URL may override the mode (honorUrlParams). It re-homes the loose CreateGameOptions + App.tsx URL parsing the old Wingman cabinet read by hand into a real ECS citizen. GameConfigSystem resolves it once — on initialize, or when the config entity is added — guarded by a WeakSet so it never re-runs per frame. When honorUrlParams is on and a DOM is present, it consults the pure urlRequestsTestMode helper and flips testMode on (never off) for a ?test=1 / ?mode=test query, then emits wingman.config.ready with the resolved { testMode, level }. It runs at priority 100 so it settles before the WaveDirector (priority 70) reads testMode off the world entity to choose between the full wave schedule and a single hand-test target.

Use it in a scene

{
  "World": {
    "tags": ["world"],
    "components": {
      "GameConfig": {
        "testMode": false,
        "level": "default",
        "honorUrlParams": true
      }
    }
  }
}

Props

• testMode (boolean, default false) — drop the orbital fleet / wave schedule down to a single hand-test target so per-part collision and destruction can be verified without chasing a fleet.
• level (string, default "default") — which level / wave schedule the WaveDirector should run.
• honorUrlParams (boolean, default true) — allow the System to flip testMode on from a ?test=1 / ?mode=test URL parameter. Leave off in headless tests so the runner's URL can't leak into the run.

Events

• Emits wingman.config.ready (GameConfigEvents.READY) once on resolve — { testMode, level }, the settled boot config after any URL override.
• Listens for nothing — it's a one-shot resolver, not a reactive component.

Dependencies

None. It's a standalone singleton — declare it on the world/director entity (tag world) alongside the other directors. Downstream systems like the WaveDirector read the component straight off that entity by type; there's no hard component dependency to satisfy.

Notes

• The URL override is one-directional: a ?test query flips testMode on, but a config that shipped testMode: true is never turned off by the absence of the param.
• Reading the URL is treated as environment input, exactly like the keyboard systems reading window: it's guarded on both honorUrlParams and a present window, and the predicate itself lives in the pure urlRequestsTestMode (GameConfig.core) so it unit-tests without a DOM.
• Put it on the world/director entity, never the player — it's a one-of-a-kind singleton, and the resolver expects a single config component per world.
• Renderer-agnostic: zero @babylonjs / three imports. The only environment touch is the guarded window.location.search read.