2 world mechanism and puzzle graphs
forgejo-actions edited this page 2026-07-15 12:43:13 +00:00

World Mechanism And Puzzle Graphs

What This System Is

World mechanisms are reusable, server-authoritative signal graphs for doors, switches, pressure plates, ordered puzzles, and timed traversal objects. They build on persistent interactive world objects: the graph owns puzzle memory, while its output nodes change the same replicated object states used by ordinary interactions.

How Authors Use It

Graphs live in assets/gameplay/world_mechanism_catalog.json. A graph declares a stable id, an ownership scope, typed nodes, and directed edges. Scene triggers do not copy graph logic. They reference a world interaction such as interaction:mechanism.lever_door; that interaction selects one graph input.

Supported nodes are:

  • input: a named external signal.
  • all: latches incoming branches until every branch has fired.
  • counter: fires at an authored count and may reset.
  • sequence: accepts authored input ids in order and can reset on mismatch.
  • condition: evaluates shared gameplay-condition expressions.
  • timer: persists a delayed downstream signal and schedules an authority wake-up.
  • set_object_state: changes a placed persistent object's presentation/collision state.
  • emit_event: records an event for quests and other condition consumers.
  • set_scene_variable: publishes an authored runtime value.

Graphs must be acyclic. Validation rejects duplicate ids and inputs, missing endpoints, unreachable nodes, invalid conditions, unusable gates/counters/timers, and invalid output object or state references. Output objects must use the same scope as their graph.

Rules And Invariants

The server derives graph memory keys from the graph instance and its per_player, per_party, per_instance, or global scope. Shared graphs reserve their key while executing so simultaneous inputs cannot lose latch, counter, or sequence updates.

Accepted execution stores:

  • monotonic graph revision;
  • all-gate latches;
  • counter values;
  • sequence cursors;
  • durable delayed signals;
  • last accepted input and update time.

Object outputs use the normal authoritative world-object registry, condition snapshot, quest refresh, replication, and durable gameplay-state persistence path. Mechanism state also projects mechanism:<instance>:revision, mechanism:<instance>:last_input, and mechanism:<instance>:scheduled scene variables for runtime inspection and conditions.

Validation And Debugging

The scene trigger workbench includes recipes for Lever + Door, Multi-Switch Gate, Pressure Plates, Ordered Runes, and Timed Bridge. Selecting a trigger that references a mechanism displays its typed graph below the ordinary trigger flow. Multi-input recipes ship separate interaction ids for switch A/B/C and rune A/B/C, so each placed trigger selects a clear input while all placements share one scoped graph instance.

The shipped catalog is intentionally small and executable. Copy a graph, give it a new stable id, point output instance ids at the placed persistent objects, add world-interaction entries for each external input, and validate the gameplay catalogs before placing triggers.

Examples

  • puzzle.lever_door
  • puzzle.multi_switch_gate
  • puzzle.pressure_plate_room
  • puzzle.ordered_runes
  • puzzle.timed_bridge