Scene Triggers
What This System Is
Scene triggers are authored volumes that turn tile visits and interactions into gameplay outputs: music changes, unlocks, runtime events, NPC dialogue, scene transitions, encounter spawns, and authority requests. The scene document owns the authored trigger records; the client runtime decides which authored triggers are eligible; the game server owns the final decision for server-authoritative actions.
The trigger runtime starts with a SceneTriggerTileVisitRequested input, resolves matching authored triggers and NPC interactions, arbitrates overlap, checks trigger state memory, then either commits locally, predicts locally while requesting authority, or waits for authority before applying the result.
How Authors Use It
Triggers are authored under the scene trigger records: TRIGGER_LAYER, TRIGGER_CONDITION_PRESET, and TRIGGER. A TRIGGER record carries these author-facing groups:
- Identity and ownership:
id,name,group_id,state_profile_id,archetype_id,trigger_class,permission_policy, andtransition_pair_id. - Spatial shape:
x,y,width,height, andshape. Shapes support rectangle, polygon, line, and facing cone contracts. - Activation and memory:
enabled,activation,once,once_scope, andcooldown_ms. Activation modes areenter,exit,stay, andinteract. - Authority and arbitration:
authority,priority,overlap_group,blocks_lower_priority, andoverlap_policy. - Actor filters:
actor_ownership, actor tags, context tags, and other condition inputs. - Behavior:
conditions,sequence_next_trigger_ids,action_target,action_pipeline, andaction.
Start from built-in archetypes when possible. door is an authority-only interaction transition. ambience_zone is a stay trigger for music. unlock_gate applies an unlock once. checkpoint emits an event. npc_dialogue starts NPC dialogue. cutscene_gate emits a one-shot cutscene-style event. scripted_event is the generic authored event trigger.
Conditions And Actions
Trigger conditions include actor tags, context tags, scene tags, weather, time ranges, dwell time, facing-interact ticks, presence counts, synchronized interaction, consumed-trigger checks, quest flags, inventory counts, party tags, faction reputation, scene variables, presets, and all/any/not groups.
Use shared-kernel conditions when the same rule must work in editor preview, offline runtime, and server authority: quest_flag, inventory, party_tag, faction_rep, and scene_var. Scene-runtime-only conditions such as dwell time, weather, synchronized interaction, and presets are useful for local authoring behavior but need extra care when paired with authority-only actions.
Trigger actions are tokenized by family:
music:<cue>for preview/runtime music behavior.unlock:<unlock_id>for shared gameplay unlock state.transition:<scene_path>-><entry_point>for server-authoritative scene transitions.dialogue_npc:<npc_id>|<topic_id>for server-authoritative NPC dialogue starts.event:<event_id>for shared gameplay events.spawn_encounter:<spawner_id>*<count>for server-authoritative encounter spawns.
Action pipelines can add delay, guard, and target steps before the final action. Keep pipelines small and readable; if a behavior needs many branches, prefer explicit triggers with named condition presets.
Rules And Invariants
Trigger ids, state profile ids, group ids, and referenced runtime event ids must stay stable once other content or save data refers to them.
once and cooldown_ms are remembered through a scope key. Pick once_scope intentionally: per-actor, party, account, session, and scene-reset scopes produce different replay behavior. Use state_profile_id when a set of triggers should share consumed/cooldown memory.
Overlap arbitration only makes sense inside an overlap_group. priority_stack can allow multiple triggers to fire, but blocks_lower_priority stops lower-priority members. first, highest_priority, nearest_center, interaction_target, and exclusive_group each encode a different authoring promise; do not mix unrelated trigger purposes in the same group.
Permission policy and actor ownership are both meaningful. trigger_class provides defaults such as doors being player-only and admin triggers being admin-only, while permission_policy and actor_ownership make an individual trigger stricter or broader.
For authority-only actions, the client request is not trusted as source of truth. The server projects a trigger authority catalog from the runtime scene manifest, verifies the source zone and spatial request, rejects disabled or unknown triggers, rejects non-interaction use of interaction-only triggers, and replaces mismatched requested actions with the canonical authored action before resolving.
Validation And Debugging
Use scene validation after changing trigger fields, condition tokens, action tokens, transition targets, dialogue targets, or runtime event ids. Use trigger preview to inspect local eligibility, overlap, cooldown, once state, authority mode, pending requests, and selected action.
If preview works but online play does not, compare these layers:
- Authoring: the scene
TRIGGERrecord and any condition preset it references. - Runtime projection: the trigger entry in the baked/runtime scene manifest.
- Client delivery: whether the local runtime predicted, waited for authority, or held a pending request.
- Server authority: rejection reasons such as
unknown_trigger,trigger_disabled,trigger_requires_interaction,trigger_spatial_mismatch, unavailable source zone, or pending session transfer. - Reconciliation: accepted authority resolutions are replayed on the client and can report stale or mismatched local predictions.
Transitions, NPC dialogue, and encounter spawns need online/server testing. Music, unlocks, and shared events can be meaningfully previewed locally, but still need an authority pass when they sit inside an authority-only trigger.
Examples
A door trigger usually uses the door archetype, activation=interact, authority=authority_only, permission_policy=player_only, a small rectangle around the doorway, and a transition:<scene_path>-><entry_point> action. Verify it in preview for interaction targeting and overlap, then verify it online so the server accepts the trigger and applies the canonical transition.
An NPC dialogue trigger usually uses npc_dialogue, activation=interact, overlap_policy=interaction_target, a high priority, and dialogue_npc:<npc_id>|<topic_id>. The NPC id and topic must resolve through the dialogue/NPC authoring loop, not just the trigger token.