2 world gameplay assemblies
forgejo-actions edited this page 2026-07-15 12:43:13 +00:00

World Gameplay Assemblies

What This System Is

World gameplay assemblies package related scene interactions, persistent-object presentations, and mechanism inputs into one reusable placement recipe. They complement tile prefabs: tile prefabs place visual layers, while gameplay assemblies place authoritative gameplay bindings.

Rules And Invariants

Assemblies live in assets/gameplay/world_gameplay_assembly_catalog.json. Each definition contains:

  • a stable assembly id, label, summary, tags, and suggested footprint;
  • an optional world-mechanism graph reference;
  • typed string, integer, or boolean parameters with validated defaults and ranges;
  • relative components with local ids, tile offsets, bounds, interaction references, object presentation references, priority, cooldown, and tags.

Expansion requires a placement namespace and origin. crypt_room_2 with component switch_a deterministically produces crypt_room_2.switch_a. Expansion fails before scene mutation if a generated id already exists or a parameter is invalid.

Mechanism namespaces

Reusable mechanism interactions author their instance id as $trigger_namespace. A trigger such as crypt_room_2.switch_b therefore writes to mechanism instance crypt_room_2. Graph object outputs use $mechanism_instance.<local-id>, so $mechanism_instance.door resolves to crypt_room_2.door.

This keeps every input and output in one placed assembly together while allowing another copy, such as crypt_room_3, to run independently from the same interaction and mechanism assets.

How Authors Use It

In the Scene Trigger workbench:

  1. Shift-drag a world selection to choose the assembly origin.
  2. Choose an assembly under Gameplay Assemblies.
  3. The editor expands and queues every component in one action.
  4. The generated triggers are selected as a batch for immediate movement or inspection.
  5. Save the scene through the normal scene workflow.

Button previews show the footprint and component count. The expansion API also exposes resolved trigger bindings, parameter values, and footprint data for other editor surfaces.

Validation And Debugging

Every expansion can produce a rename plan mapping all old trigger ids to a new namespace, and a delete plan listing the entire generated trigger set. Both plans detect conflicts before mutation. The authoring dependency graph registers the assembly catalog and its interaction, world-object, and mechanism catalog dependencies, while server startup rejects unresolved cross-catalog references.

Examples

  • Lever + Door
  • Multi-Switch Gate
  • Pressure Plate Room
  • Ordered Runes
  • Timed Bridge
  • Persistent Reward Chest
  • Respawning Resource Node
  • Activity Board