Events

 
Events are what a FSM needs to change state: when an object is in a state and receives an event it changes state.
How does object know what state to pass to?
The answer is: Transitions.
 
Events are shared among all FSMs of a game scene.
 
There are some default events that are generated by the system, other events can be generated by Animation Keyframes and by Cutscenes, all other events can be generated by Actions.
Default system events are the following:
 
  • START:This event is generated one time after a FSM is instanced and initialized.
  • FINISHED:This event is generated when a state finishes processing. A state finishes when all its actions finish, actions that have everyFrame set to true do not finish. Other actions are temporized, they finish after a given time interval, some other actions finish after one frame they are executed.
  • AWAKE: This event is generated when an object is Awaken. It is sent to the awaken object.
  • ENTER_VOLUME:This event is generated when an object enters a volume. The volume must be linked to a trigger. The event is sent to the trigger to which the volume is linked.
  • INSIDE_VOLUME: This event is generated everyframe an object is inside a triggered volume. The event is sent to the trigger. The event is sent to the trigger to whicch the volume is linked.
  • EXIT_VOLUME: This event is generated when an object exits from a triggered volume. The event is sent to the trigger.  The event is sent to the trigger to whicch the volume is linked.
  • ANIMATION_FINISHED:This event is generated when an animation finishes. NOTE that loop animations generate this event every time they reach last frame
  • PLAY_CUTSCENE:This event is generated when a cutscene starts playing
  • STOP_CUTSCENE:This event is generated when a cutscene stops playing
  • PAUSE_CUTSCENE:This event is generated when a cutscene pauses playing
  • HIT:This event is generated when an object is hit by a Projectile or a raycaster or when a RayCast action is performed.
  • COLLIDED:
  • CHARACTER_COLLIDED:
  • CONTACT:
  • PATH_FOUND:
  • PATH_NOT_FOUND:
  • TARGET_REACHED:
  • BUTTON_CLICKED: This event is generated every time a Button widget is clicked (see GUI ). There are other version of this event generated for recognizing what button has been clicked. See GUI logic using GameMachine for more info.
  • BUTTON_PRESSED:This event is generated every time a Button widget is pressed (see GUI ). There are other version of this event generated for recognizing what button has been pressed. See GUI logic using GameMachine for more info.
  • BUTTON_RELEASED:This event is generated every time a Button widget is released (see GUI ). There are other version of this event generated for recognizing what button has been released. See GUI logic using GameMachine for more info.
  • ACTION:
  • AIMED:
  • GAME_PAUSED:
  • GAME_RESUMED:
  • ENTER_WATER:
  • EXIT_WATER:
  • INSIDE_WATER:
  • IN_EDITOR:
  • GAME_LOADED:
  • GAME_SAVED:
  • START_SAVE_GAME:
  • GAME_STATE_EXISTS:
  • LEVEL_LOADED:
  • ENTER_TRIGGER:
  • INSIDE_TRIGGER:
  • EXIT_TRIGGER:
  • CURSOR_OVER:
  • AGENT_BLOCKED:
 
To create a new custom event see Events Tab.
 
TRANSITIONS
A transition is a couple (event,state) that associates an event that an object can receive when it is in a given state and the state in which the object must pass if it receives that event.
In other words Transitions define the FSM behaviour, i.e. the new state to pass to in response to an event basing on previous state.
 
What means "basing on previous state"?
Transitions are defined for every state, so previous state means the state that contains the transition while new state means the state transition point to. So when object is in a given state it can pass only to states pointed by transitions contained into that current state, this means that for every state only some events produce a transition to another state. The number and type of transitions for every state is the basic of FSM programming.
 
In the GameMachine graph viewport Transitions are represented as curved oriented lines connecting one event of a state to another state, as showed into the following image:
4.1.3. Events
1

Transition

1. Transition
In this case the transition is connecting the lockEnemy event of state WAIT_FOR_ATTACK to state DEAD01. In other words this means that if the object is inside WAIT_FOR_ATTACK state and receives the lockEnemy event it passes to DEAD01 state.
The color of the transition line is the same as the color of the source state (green in the abpove example).
 
GLOBAL TRANSITIONS
There is a special kind of transition that we call global.
Global transitions are transition that doesn't depend on the current state.
In other words they don't need a previous state to work, this means that global transitions can happen in every state, at any moment, from any source (for example: from other objects FSM, from an animation, from a cutscene, etc...) independently by what the current state is performing.
The only condition they depend on is the event they are associated to occur.
 
A typical example of Global Transition is the transition generated by event START when FSM begins. Thanks to this features Global transitions can help to reduce graph node connections and number of nodes(states) necessary to implement response to an event.
 
In GameMachine global transition are represented as orange comboboxes on top of a state node, as showed into the following image:
4.1.3. Events
1

Global Start transition

1. Global Start transition
This is the global transition triggered by the START event. The FSM starts running from here...

A GameMachine FSM must have at least one global transition to work. The common event to start a FSM is the START event

 
See Edit Transitions in GameMachine graph viewport to know how to create transitions by adding events to a state and connect states.