Runtime Scene Manifests And Zone Authoring

What This System Is

Runtime scene manifests project authored scenes into the data game servers and control-plane routing need for hosted zones, transfer targets, entry points, navigation, collision, assets, and catalog dependencies.

How It Works

Manifest baking reads authored scene IDs, paths, bounds, entry points, transition targets, navigation/collision projections, asset dependencies, and catalog references. Game servers load named zone runtime data from the manifest, while the control plane resolves instance and zone targets for transfers.

Dependency signatures help detect when runtime data no longer matches authored content.

How Authors Use It

Use canonical scenes/... .scene references for transition targets. Keep entry point IDs stable. After changing scene paths, entry points, bounds, or transfer destinations, run validation and bake so manifests and server routing agree.

Rules And Invariants

Hosted zone names must resolve to real scene data. Transition targets must be canonical and stable. Manifest navigation and collision sections must match the authored scene used by runtime. Asset and catalog dependencies should change only when content references change.

Validation And Debugging

If a transfer lands in the wrong scene or fails to resolve, inspect the authored transition, baked manifest, game-server zone runtime load, and control-plane scene lookup. If runtime collision differs from editor behavior, compare manifest sections with scene validation output.

Examples

When renaming a scene file, update transition targets to the canonical scenes/... .scene path, run validation, bake manifests, and confirm the hosted zone still resolves. When adding an entry point, verify both the scene document and baked manifest list the same stable ID.