Core
Finite-state machine definitions and transition metadata.
State machines model queued discrete phase changes whose commit boundaries matter to schedule execution.
Use this module when gameplay depends not only on the current mode, but also on exactly when a mode change becomes committed and which schedules should run around that boundary. Menus, rounds, encounter phases, pause flows, and restart/reset pipelines are the canonical cases.
// Model a gameplay phase whose transition timing matters.
const GameFlow = Machine.StateMachine("GameFlow", ["Menu", "Playing"] as const)
// Gate one system so it only runs in the committed playing phase.
const isPlaying = Machine.inState(GameFlow, "Playing")Creates a schema-bound finite-state machine definition.
readDeclares that a system wants to read the current committed state.
writeDeclares that a system wants to queue the next state.
transitionDeclares that a system wants access to the last applied transition payload.
readTransitionEventDeclares that a system wants to read committed transition events for one machine.
inStateCreates a condition that only passes in one exact machine state.
stateChangedCreates a condition that passes when the machine changed during the current schedule execution.
notNegates another condition.
andRequires every child condition to pass.
orRequires at least one child condition to pass.
Public constructors for machines, conditions, and explicit transition bundles.
Creates a schema-bound finite-state machine definition.
This is the intended default for gameplay phases and other discrete modes where the transition boundary itself matters.
Prefer a machine over Descriptor.State(...) when code depends on:
Declares that a system wants to read the current committed state.
Use this for the current committed phase value. Queued updates remain hidden until the schedule reaches applyStateTransitions(...).
Declares that a system wants to queue the next state.
This is the machine equivalent of "request a phase change later". The change becomes committed only at applyStateTransitions(...).
Declares that a system wants access to the last applied transition payload.
Declares that a system wants to read committed transition events for one machine.
Use this when later systems need to observe that a transition happened after the schedule has already committed it.
Creates a condition that only passes in one exact machine state.
Use this to gate systems or schedule entries by the committed gameplay phase. If you need this kind of gating, the value should generally be modeled as a finite-state machine rather than a plain state descriptor.
Creates a condition that passes when the machine changed during the current schedule execution.
Negates another condition.
Requires every child condition to pass.
Requires at least one child condition to pass.