2 scene documents
forgejo-actions edited this page 2026-07-11 10:33:50 +00:00

Scene Documents

What This System Is

Scene documents are the line-oriented .scene source files for authored maps. The current format starts with ZigGameScene v1, parses into SceneDocument, validates cross-section and cross-catalog references, then projects into runtime scene manifests and server-readable summaries.

The requested validation module path src/scene/document/validation/mod.rs is not present in this checkout. Validation submodules live under src/scene/document/validation/* and are wired by src/scene/document/validate.rs.

How Authors Use It

The schema-owned v1 sections are:

Section Record Kind Purpose
scene key/value fields Scene header, ids, bounds, player layer, environment, lighting defaults
lighting_time_overrides LIGHTING_TIME Hour-specific lighting overrides
lighting_states LIGHTING_STATE Triggered lighting states
lighting_volumes LIGHTING_VOLUME Spatial lighting regions
entry_points ENTRY Arrival points used by transitions and previews
npcs NPC Scene-local NPC placements with catalog npc_id references
mob_spawn_areas MOB_SPAWN_AREA Scene-local encounter geometry
mob_spawners MOB_SPAWNER Encounter lifecycle, memory, safety, and spawn tables
farming_fields field Authored farming field rectangles and crop constraints
navigation_zones NAV_ZONE Navigation and traversal zones
lights LIGHT Placed light emitters
sounds SOUND Placed sound emitters
post_process_volumes POST_PROCESS_VOLUME Visual effect volumes
preview_scenarios PREVIEW_SCENARIO JSON preview fixtures
cutscenes CUTSCENE JSON cutscene definitions
triggers TRIGGER_LAYER, CONDITION_PRESET, TRIGGER Trigger metadata, condition presets, and actions
tilesets TS Tileset asset references
graph NODE Scene graph hierarchy and layer tilemaps
tiles TILE Authored tile placements

[meta] is accepted as an ignored compatibility section, but it is not part of the v1 schema and does not populate SceneDocument.

Rules And Invariants

Scene-local ids are owned by the document and should remain stable for editor selection, validation, transitions, and runtime projections. Examples include entry point ids, trigger ids, condition preset ids, NPC placement ids, mob spawn area ids, mob spawner ids, farming field ids, navigation zone ids, placed light/sound ids, post-process volume ids, cutscene ids, preview scenario ids, graph fids, layer indexes, and tileset ids.

Catalog or external references point outside the scene document. Examples include npc_id, mob spawn-table mob_id, dialogue topics, runtime events, cutscene action references, crop ids, sound cues, tileset asset paths, and canonical transition target paths such as scenes/example.scene.

Keep that split explicit when refactoring dependent content: local ids are repaired or renamed inside the scene; catalog references need catalog validation, migration support, and authoring diagnostics.

Parse And Write Flow

Parsing starts by tokenizing the whole document with SceneDocumentTokenStream. Tokenization builds the source map for sections, records, fields, and JSON fields before semantic parsing runs.

parse_scene_document dispatches by version. V1 parsing walks tokenized lines, switches on schema-owned section handlers, and parses each record into SceneDocumentParseState. finish then constructs the final SceneDocument with header data, environment, navigation zones, entry points, NPCs, mobs, farming fields, lights, sounds, post-process volumes, preview scenarios, cutscenes, triggers, tilesets, tiles, and graph nodes.

Writing is deterministic. Section handlers define write order and stable sort keys, so diffs remain reviewable: content sections write first, while tilesets, graph, and tiles write last.

Validation And Debugging

validate_scene_document loads current NPC, dialogue, mob, NPC-service, game-data, runtime-event, and scene registry context, then pushes diagnostics into one SceneValidationReport.

The current domain order is:

  1. catalog load health
  2. header bounds and entry points
  3. environment lighting
  4. NPC placements
  5. trigger layer header
  6. navigation zones
  7. cutscene definitions
  8. farming fields
  9. preview scenarios
  10. mob areas and spawners
  11. placed lights
  12. condition presets
  13. triggers and trigger action payloads
  14. scene audio
  15. lighting states and post-process hooks
  16. transition graph and transition pairs
  17. scene graph and bounds
  18. footstep surface mappings

The scene report preserves push order separately for errors and warnings. Load logging prints warnings before errors, while load-failure summaries use the first validation errors in validator insertion order. Shared authoring projections emit errors before warnings and may sort and deduplicate issue identities for cross-panel presentation.

Runtime Manifest And Bake Flow

Runtime scene loading parses the scene text, prunes missing unused tilesets, validates the document, logs diagnostics, and fails the load if validation errors remain.

After validation, scene_summary_projection_from_document creates the canonical runtime summary from the parsed document. runtime_scene_manifest_resource feeds that projection plus the shared validation report into bake_runtime_scene_manifest_from_projection, serializes canonical JSON, and stores a SceneRuntimeManifestLoadState.

Missing source text, bake failure, and serialization failure are represented as explicit manifest load states instead of silent success.

For dependent-content refactors, prefer extending the schema handler, parser/writer, validator, summary projection, and runtime manifest projection together. Avoid reparsing raw scene text when a validated SceneDocument or summary projection is already available.

Known compatibility debt: app .scene farming fields currently use lowercase field records, while older raw world-domain summary paths and tests still mention FARMING_FIELD. Keep both paths in mind until the summary parser is fully retired or aligned with the app document schema.

Examples

assets/scenes/scene_1.scene shows a compact scene header, one entry point, one NPC placement, three mob spawn areas, three trigger-burst spawners, three spawn_encounter triggers, then the large tileset/graph/tile payload.