This is the documentation for Arbor 3.2.4 and earlier.
See Arbor Documentation for the latest documentation.
Contents
What is a State Machine?
A state machine refers to a mechanism that changes the state according to the condition with the behavior as one state.
In Arbor, you can use state machine by adding ArborFSM component to GameObject.
Example: Switch and light
Consider the switch and electric light.
- If the switch is off, the light goes out.
- If the switch is on, the light turns on.
- The state of the light switches with the switch as a condition.
Temporarily assembling with ArborFSM results in the following.
When a Destroy message is sent, a behavior to give an explosion effect and to destroy the light is temporarily assembled.
We will do detailed comment later.
Node component
Start state
This is the first state to be executed when ArborFSM starts.
One graph requires one starting state.
State
It is a normal state.
It is executed by transitioning from the start state or another state.
Resident state
It is a state that is always executed regardless of the running node.
Perform some kind of interrupt judgment.
Also, because it is always running, it is possible to transition from resident state to other states, but can not transition from other state to resident state.
Reroute Node
It is a node for adjusting the connection line route.
It is used when connecting lines cross and it is difficult to see.
The direction of the line can also be adjusted with this node.
StateBehaviour scripts
It is a script for handling state behavior.
It can be set to all states of start state, normal state, resident state.
Since you can add more than one StateBehavior to a state, you can combine behaviors to create states.
For creating StateBehaviour script here.
Built-in StateBehaviour
Pre-built behaviors such as ActivateGameObject and OnTriggerEnterTransition in examples are also described in the StateBehaviour script.
For reference on the built-in StateBehavior see here.
ArborReference : StateBehaviours
About StateLink
Use StateLink to do state transitions.
When you declare a StateLink field in StateBehaviour, the field appears in the Arbor Editor.
By connecting, state transitions are performed at the time of execution according to the description of the StateBehaviour script.
Method of operation
| Operation | Method |
| Connect | Drag & Drop |
| Disconnect | Right click on the connection line and select “Disconnect”. |
TransitionTiming
The transition timing is not instantaneous, but it follows the specification of TransitionTiming.
TransitionTiming can be done by clicking on the StateLink gear icon with the setting window that opens.
The behavior of TransitionTiming is as follows.
 Late Update Overwrite |
Reserve to transition when LateUpdate. If the transition is already reserved in the same frame, overwrite it. |
 Immediate |
Transit instantaneously at transition call. If the transition is looping, there is a possibility of infinite looping, so use with caution. |
 Late Update Dont Overwrite |
Reserve to transition when LateUpdate. (Default) If the transition is already reserved within the same frame, do not overwrite it. |
Explanation of examples
Let’s take a look at the previous example again.
- “Light Off” state
- First, it starts from the Light Off state of the start state.
- ActivateGameObect changes the Spotlight object to inactive.
Arbor Reference : ActivateGameObject - OnTriggerEnterTransition transitions to the Light On state when an object of the Player tag enters.
Arbor Reference : OnTriggerEnterTransition
(In order to use OnTriggerEnterTransition, you need to set Collider etc. on GameObject with ArborFSM)
- “Light On” state
- ActivateGameObect changes the Spotlight object to active.
- By OnTriggerExitTransition, when an object of the Player tag comes out, it transits to the Light Off state.
Arbor Reference : OnTriggerExitTransition
(In order to use OnTriggerExitTransition, you need to set Collider etc. on GameObject with ArborFSM)
- “Wait Trigger” state
- Since it is resident state, it is always executed regardless of which state is being executed.
- By TriggerTransition, when a Destroy message comes, it transits to the Explosion & Destroy state.
Arbor Reference : TriggerTransition- To send the Trigger message, use SendTrigger.
Arbor Reference : SendTrigger
It uses a SendTrigger from another FSM and indirectly issues a transition instruction.
- To send the Trigger message, use SendTrigger.
- “Explosion & Destroy” statea
- InstantiateGameObject instantiates prefab.
Arbor Reference : InstantiateGameObject
(It is an assumption that you set up particles etc., although nothing is set for the temporary set) - DestroyGameObject destroys the LightFSM object (its own GameObject).
Arbor Reference : DestroyGameObject
- InstantiateGameObject instantiates prefab.
I think that I understand the flow that combines behaviors into state and transitions when it matches the transition condition.
If it is a simple example like this one, I think some people may find it easier to write MonoBehaviour directly,
When multiple states become confused, it will be a great advantage to visualize in graph form.
How to use State Machine
For details on how to use, please click here
Script customization
For details on script customization, please see here