When creating complex state-based logic
systems in an animator controller
it can greatly help organisation to use
a hierarchy of state machines.
To create a state machine right click
on the background on the animator window.
and select Create Sub-State Machine
This will create a state machine within the current
layer or state machine level.
Note the hexagonal shape of sub-state machines
versus the standard rounded rectangular shape
of individual states.
Let's look at an example of when they are useful.
Here we have an animator controller
that's starting to look cluttered
so before many more states are added to it
it should be tidied up.
To do this some of the states
can be placed in to a state machine.
In this case we could group all of the
states that are to do with being Airborne
in to one sub-state machine.
To do this, first we make the state machine
by right clicking on the background of the
animator window and selecting Create Sub-State Machine.
We can rename the state machine by clicking on
it and changing it's name in the inspector,
just like single states.
Next we need to put some states in to this new state machine.
We do this by selecting all the
states that we want to move and dragging them
on to the state machine.
For this example we want to move Leap Takeoff,
Leap Airborne, Falling and Landing states.
Note the + icon that appears next to
your cursor as you are dragging.
When the states have been added to the state machine
they will disappear from the current state machine or layer.
To see them again in order to edit
any of their properties for example
simply double click on the sub-state machine.
To go back to the containing layer
or state machine double click on the Up node.
Note that the breadcrumb at the top of the window
shows you where abouts you are
within the state machines.
State machines can be used in a hierarchical structure.
This means that within each layer of an animator
controller there could be several state machines.
Each of those could, in turn, have
sub-state machines within them, and so on.
Transitions can go from states outside
to those inside a state machine.
We can see from this example that when
our states were added to the sub-state machine
their transitions were retained.
To make a new transition to a state machine
right click on the state or state machine
from which you are transitioning
and select Make Transition.
Then left click on the state machine you wish
to transition to.
>From here a pop-up menu will appear
offering you the choice to transition to any state,
or state machine within the selected state machine.
This includes the state machine itself.
One way to transition out of a state machine
is to use the Up node.
This works like a link to all states
and state machines that are not contained
in the current state machine.
The up node is labelled Up
followed by the name of the parent state machine.
If there is not parent state machine
it will show the name of the layer it is in.
In this example there was no parent
state machine so the up node is labelled
(Up) Base Layer.
To make a transition out of a state machine
right click on the state or state machine
that you wish to transition from
and select Make Transition
then left click on the up node.
You are then offered the same choices as
when transitioning in to a state machine.
Only this time it is a choice of the states
and state machines above the
current one you were viewing.
In every layer and state machine
there are green entry and red exit nodes.
These are used to encapsulate state machines
so that they have less dependence on
states or state machines.
They represent an alternative to using the up node.
Transitions to and from state machines
can either use the up node or
the entry and exit nodes.
Using the up node,
transitions happen directly from
state to state or from state to state machine.
When using entry and exit nodes
the transitions are to and from
the state machine itself.
A transition to a state machine
will come in at the entry node
and leave via the exit node.
This may mean designing your transitions
in a very different way.
Instead of having a single transition through the up node
there maybe be many.
Let's take a look at an example.
This is the same controller we saw in our earlier example.
But the Locomotion and Airborne states
have been put in to their own state machines.
However instead of using transitions
between each of the states as before
entry and exit nodes are used.
In the previous example there were transitions
from Standing Locomotion to Leap Take Off and Falling.
And a transition from Landing
to Standing Locomotion.
The condition to go from Standing Locomotion
to Leap Take Off is the Jump trigger.
However, once we have encapsulated a
locomotion state in to a state machine
it no longer matters what state we are
transitioning to.
Instead it just matters that we no longer
want to be in this state machine.
So we transition to the exit node
with the jump trigger as a condition.
Back in the complex animator controller
the condition to go from standing locomotion
to Falling is that the parameter
"Grounded" is false
In the entry and exit node example
the same condition is required for a second
transition to exit the locomotion state machine.
Since we only have two state machines
we can assume that if we are leaving one state machine
we want to go in to the other
As such there are no conditions for transitions between them.
We have two transitions from the entry node
of the Airborne state machine.
The first is the default transition
from the entry node.
We can see this because it is orange in colour,
instead of the normal white.
This transition will be used when no other transition
from the entry node can be used
or if it's the only available transition.
The other transition is greyed out.
When a transition is grey like this
it means that it has no knowledge of the state
it is coming from.
This particular transition
is coming in to the state machine from
the entry node, so it doesn't know which
state it is coming from, as it could be from any source.
We can see that the transitions between the locomotion
and Airborne state machines were also greyed out.
Again this is because they don't know
which state they are transitioning from.
When a transition is greyed out, the only
editable aspect are it's conditions.
Since the transition doesn't know which state
it is coming from any other details
about the transition would be meaningless.
To control the duration and other aspects
use the transition from the originating state.
The transition to Falling has the condition
that "Grounded" is false.
These two transitions combined
mean that when we enter this state machine
if grounded is false Falling will be played.
Otherwise the default transition will be used
and "Leap Take Off" will be played.
The benefit of using entry and exit nodes
to encapsulate state machines like this
is reusability.
If a particular animator controller has a
state machine that could be used elsewhere
then the state machine can simply be copied
to the other animator controller.
Because the state machine is self-contained,
i.e. it doesn't have any dependencies outside of itself
it doesn't matter what other states or
state machines are in the other animators
that you copy to.
For more information on animators and
animator controllers please see the information linked below.
Subtitles by the Amara.org community