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.