♪♪♪
Third Person Blueprint Game: 9. Intro to State Machines
Hello everyone and greetings.
In the previous video, we quickly introduced animation Blueprints.
Before we continue with our animation Blueprint however,
I wanted to take a moment to talk a little bit about State Machines
as creating a State Machine is going to be our next step.
But I am going to assume that most of you do not know what a State Machine is,
so I thought I would take just a moment here to kind of go over the concept
to help make things clearer for when we start to put ours together.
Hopefully, everything will come together and make a little bit more sense.
So first of all, what are State Machines?
So, State Machines are technically a process
by which you could track the current state of any logical process,
like a computer program for instance.
You could track what state a program is in and it can move from state to state,
which is exactly what a State Machine is in Unreal Engine 4 as well.
The problem with defining it that way, however, is if you are a programmer
you kind of already know what a state machine is and
when I say that our animation system uses a State Machine,
you probably already know what to expect and how it can be applied.
However, most animators or designers to some extent, not all but most,
are not programmers.
They lean more towards the artistic side of things,
so the term State Machine may not fully resonate with them.
So what we are going to do is generalize things and simplify them down
so that hopefully this is approachable by everyone
and it kind of makes a little bit more sense.
Now, disclaimer time. State Machines are a really complex topic
and you could go really high-end crazy overboard with them.
You could make a State Machine that drove just a single part of a Character's body,
like his arm, if you really wanted to. We are not going to do that.
We are going to keep things very simple and take things step-by-step here.
But the point is that a State Machine essentially is really just a graph.
That is it. It is a graph that charts out the Character's current activity.
So when you say what is the Character doing right now?
The answer to that question in most cases, not all, can generally be thought of
that Character's state.
This would include things like running, for example,
or jumping, or swimming, or any number of different things.
Now depending on how you are looking at your Character...
I would imagine if you are watching this video
you already have a game that you want to make.
You already have a Character you want to include and
you have a laundry list of things that you want your Character to be able to do.
So let's say you wanted your Character to be able to punch, right?
Well you might be asking yourself,
shouldn't my Character have a state that is punching?
You know, that seems like a logical decision to make.
Well chances are
you probably won't want your Character to be able to just punch and that is it.
Typically in most games if a Character is punching,
they could also be moving around, or jumping,
or doing any number of different things while they are punching.
So if you try to describe that or actually say what a Character is doing in a sentence.
If I said a Character was running around and punching
I would probably write that out something like the Character is punching while walking.
Or maybe the Character is punching while standing still,
or punching while running.
There are all different kinds of things he could be doing while he is punching.
It is really the while part here that is the most important aspect.
This would actually be considered the Character's state
and the punching activity would actually be layered on top of it.
That would just be an extra thing.
So this is where State Machines can get a little bit complicated.
I don't want you to get too bogged down in that.
What I like to do is keep things very simple while we first get started here.
We are going to build a very simple State Machine to kind of get things going.
Then over time as you come up with more things for your Character to do,
then you can start seeing how you can add in more states
and make things more complex.
So we are going to have...
Actually, let's just step through the process here together
to kind of help visualize things.
We are going to have a few very, very simple states.
So let's start out with our first state here.
We are going to call this state the Idle_Walk_Run state.
Now as the state suggests, it is going to handle our
idle, walking, and running animations.
You might be asking yourself well
why is this one state going to handle all of these things?
Well, that is because we already set up all of those activities, if you recall,
into our Blend Space.
So that Blend Space is going to be self-contained inside this state,
which means as long as the Character is doing any one of those,
he could be standing still, he could be walking or he could be running,
he would be considered in this particular state.
Now you might be asking yourself also,
well why didn't we just make 3 separate states?
One for idle, one for walking, and one for running.
Well, there is really nothing stopping you from doing it this way.
You could totally set it up that way if you prefer.
The problem with doing it that way, however,
is that you don't have the nice, smooth blend ability that a Blend Space offers.
That is why we took those 3 motions and instead of making them separate states,
we put them into a single Blend Space.
Now that Blend Space can drive a single state and we get nice blending.
Whereas if we had something more like say for instance we had
an "Idle" state, we had a "Walk" state, and we also had a "Run" state.
We could totally also set up some rules and say like okay,
when the Character is moving at a Speed that is greater than 95,
then we want the Character to start walking.
As soon as the Character's Speed is greater than or equal to 375,
then he could start running.
Obviously when Speed is 0, he would go back to idle.
We could totally do it this way;
there is no real problem with setting up that way.
The only catch is
we wouldn't have that nice blend animation
that our Blend Space offers between those states.
That is the real hassle there.
Since we needed blending, we put everything into a single Blend Space node.
That one Blend Space node, which holds all 3 of those animations,
can be used for the state for our Character to enter.
Now the other main thing, since we are not going to worry about swimming here,
let me go ahead and kill that. We don't have any swim animations anyway,
so we are really only worried about running and jumping.
Now jumping is kind of fun. There is a bit of a catch to it.
We have a problem to solve.
We never really know the answer to this question here.
How long is the Character going to be jumping?
How long is he going to be in the air?
We really don't know.
The only way to solve this problem is say for example,
let's take a jump here.
So that is our jump motion.
Here is our Character who just got finished jumping or dancing,
depending on how you look at my drawing there.
But he is happy because he just got finished jumping.
We are going to take this jump and cut it up into 3 parts.
We are going to have a Jump Start, a Jump Loop, and a Jump End.
Now the reason we are going to do this is,
we could have a scenario where the Character jumps on a flat surface similar to this
and then we would have the exact same jump time. That is really not a problem.
But what if the Character is doing something a little more like this
where the Character had to start up here and jump all the way down like so?
Then our Jump Start time is always going to be the same,
our Jump End would be relatively close to the same as well,
but it is this time in the middle here that could really be any amount.
It could be really far or it could be really short.
You know, the Character jumping off of a tall building versus
jumping off of a curb, for example.
That is really a variable.
So, what we are going to do is actually just take this Jump Loop here
and as the name suggests, loop it over and over again
to make up for any amount of time that the Character must fall.
Now the other nice, useful part of this is,
as I slide my examples over here a little bit,
let's say we had a big ledge
and the Character happens to be walking and not paying attention
and walks right off the ledge.
He is still going to need to do some sort offalling motion.
That falling motion will be consumed by our Jump Loop as well.
Afterwards, he can go into his Jump End or his landing.
So in this way by taking our jump and breaking it up into 3 different things,
we can play each one as long as we need to.
All right so now with that in mind,
we know that a State Machine is a graph of our Character's current activity,
but there is a little bit more to it than that.
It is also a series of rules called Transition Rules
and these control how you get from one state to another.
So we are going to, say for instance, have another state here
and we are going to call this state the Jump Start.
At any point, the Character could go from Idle_Walk_Run
to that Jump Start state.
So the behavior moves in this direction, but how do we get there?
Under what circumstances would he go into Jump Start?
Well, we will simply ask the game a question.
Let me kill this Blend Space here to make more room as well.
Our question to the game is going to be is the Character in the air; yes or no?
If the Character is in the air, then we can go ahead and
start playing the Jump Start animation.
Then we would have another state, which we will call Jump Loop.
The Character will always go from Jump Start to Jump Loop.
It is just the next thing that he is going to do; it is the nature of the transition.
But how, under what circumstance, and what is the Transition Rule to get there?
Really, we are going to keep it very simple and all we are going to say is
when the Character gets near the end of the Jump Start animation,
continue on to the Jump Loop automatically.
Now remember how we took our jump and we cut it up into 3 parts?
Once we get towards the end of the Jump Start animation,
we can just automatically go ahead and move him over to the Jump Loop animation.
So following the Jump Loop, the next logical state we would have is our Jump End state.
The Jump End is simply going to be fired by asking are we still in the air?
If the answer is no, then we are going to go to the Jump End animation.
So let's actually put that in parentheses here for clarity;
are we not in the air?
Finally, our next transition out of Jump End
would be to go back to our Idle_Walk_Run state here since we are no longer jumping.
The Transition Rule for that would be
are we near the end of our Jump End animation?
If so, go ahead and proceed to the Idle_Walk_Run state.
So really with that if you step back and look at it,
our State Machine would have 4 states.
But really, there are 2 different things he is going to be doing.
We have moving and we have jumping.
Really if you wanted to, you could make a State Machine that did this
and had one Transition Rule
that went this way and another that went back the other way.
What you could say is the Character still in the air?
If they are, start playing the jumping animation.
As soon as you are not, go back to the moving state there.
The catch with this is that
it would not take into account all the different ways in which you could jump
because you could jump up onto something and spend very little time in the air
or you could jump down from something else and have a lot longer time in the air.
So this is why we took that jump and split it up.
Then the nice Blend Space that we have
is just a way for us to get nice, smooth blending based on a Speed value,
the speed of our Character.
Had we used 3 different states for "Idle", "Walk" and "Run",
which could be done; I don't want to say that it can't,
it just wouldn't give us that nice, smooth blend ability
that our Blend Space offers.
So with all that wealth of knowledge under our belts,
I know that was a lot to take in.
Recapping really quickly here before we close.
State Machines are just a way to take the general stack of activities
that your Character is going to be doing
and then create a graph of each one of those activities.
Then also, they create a series of rules
that allow the Character to move from one of those activities to another.
Now that we have gone through that, we are actually going to pause here.
When we come back, we will hop inside the editor
and go through the process of creating our State Machine,
which is going to look almost identical to the one on the left of our screen here.
So the process should be relatively quick.
So with that, let's go ahead and pause
and we will continue setting up our State Machine in the next video.
We will see you then.
unrealengine.com cafe.naver.com/unrealenginekr