00:00We all know behavior trees, but state trees are a new and exciting way to get our AI behavior, and actually a lot of other fun stuff, working in Unreal

00:06So, let's enable it

00:13We go into the plugins

00:19If you don't have the plugins tab yet, you can go up into edits and enable it right there, and we will look for the state tree plugins where we will enable both the gameplay state tree and normal state tree plugins

00:26Restart the project to load them in, and then we can get started

00:33So state trees, by default, will actually work very similarly to behavior trees in a lot of ways, but give you a lot more flexibility because

00:38They also support pretty much the exact same way of transitioning between different states or tasks as a state machine would

00:45That's why they're called state trees, because they are a combination of state machines and behavior trees

00:51So let's make one, and we can start looking at all the bells and whistles that we have with them

00:57So you can just make them by going into the artificial intelligence and state tree

01:02Now that we have this thing enabled, then we get the schema that we can pick

01:07We can either pick a normal state component or a state tree AI component

01:10If you're working with C++, I do believe you can

01:14Make custom schemas that will also show up here

01:18I haven't looked into that because, by and large, that's not necessary to do

01:23If you have certain state trees that really need to only be used on certain types of actors that have certain, like, unique data that the state tree is going to need to use, it might be nice to have that all automatically provided in with a custom schema, but it's by no means necessary

01:40So, we're not going to bother with, like, any of that stuff in here

01:46So, we're limited to the normal state component and the state AI component

01:51As a general rule, the only difference is the schema that It uses, so the default data that it provides, and also on what kind of objects it runs

01:58The state tree component schema will run on state tree components that are on the actors themselves

02:05The wonderful thing about that is that it doesn't need an AI controller to function

02:13So unlike something like a behavior tree that needs to be run on an AI controller, so it needs to be working with a pawn, it can't work with a normal, just regular actor

02:21State trees can run on regular actors without the need for any AI controller related stuff

02:28State tree AI components, uh, run on the AI controllers, which can be nice if you

02:35Have a specific controller that needs to give behavior to a bunch of different possessed actors that just share the same type of controller

02:42So, if you have like just basic animals in your game that just need to wander around and run away when the player gets near, something like that, you can just make an AI controller that has the state tree for that on it

02:54And then anything that has that AI controller will behave like that

03:01In this series, we're going to mostly uh use the normal state tree component

03:05I'll show you the differences between the two in a moment

03:09Uh, and we're going to still do some AI

03:13Controller-based stuff, because the examples that I'm going to show are going to be like moving around, which requires an AI controller, but I like personally putting these things on the actors themselves

03:19So, let's open up the state tree and let's look at what the interface, uh, has to offer, because there's quite a few things here to talk about

03:26And immediately, let's start off with, uh, the schema, because that is, again, effectively the only difference, uh, between the state tree component and the state tree AI component

03:32After you make one of these, uh, as you can see, you can just switch back and forth between

03:38The two different schemas, anyway, or whatever other schemas you might have custom made in C++

03:44So if I change to the AI component one, this will make this expect to be run on an AI controller, and we'll see that the contact variables here, which has only actor in it, will change to having the actor and AI controller, which also changes the fields that we have down here from only one thing for the actor class to two things for the actor class and the AI controller class

04:08So what are these? These are the classes for the context variables

04:15And what are the context variables? The context variables are Variables that we can automatically supply into our tasks for whenever we need, like something to reference the actor that we're working with

04:27That will become a little bit more clear in the next video when we actually dive into making custom tasks, though

04:33Uh, for now, all that we need to really worry about is the fact that we can either keep this very generic so that it can run on a variety of different things, or we can do something like, I'm just going to make a, like, character here, and we'll call that state tree character, and I will populate all these things in a moment

04:50Uh, but we can also just change the actor

04:56Class here to specifically state character, which will now allow us to access specific variables created on the state tree character class, either within the individual tasks or within this interface

05:04Again, this will become more relevant in the next video

05:13If it doesn't fully make sense right now, don't worry, as you will see examples, hopefully it'll start making a little more sense

05:22Uh, for now though, we are going to stick with the normal state tree components, uh, which will also reset this exoclass thing, but again, we'll worry about like setting all that up properly once we actually get into the Examples of things

05:28Next up down the list, we have the parameters, which, uh, is exactly what it sounds like

05:34It's just effectively variables for your state tree, except that these are variables that aren't necessarily meant to change

05:40Uh, unlike something like a blackboard with blackboard keys that are effectively also variables for your behavior tree, these are meant to mostly just be set once and then not be touched anymore

05:49There are ways, either in C++ or in recent updates also through blueprints, uh, to set these as well

05:58It is possible

06:05Uh, in my experience, that causes a lot of crashing in packaged

06:12Builds because the state trees, uh, have some kind of bug in them, uh, where it's not properly referencing, uh, these values

06:19If you're watching this in the future, I'm sure that that's been fixed, uh, but for now, we're going to avoid setting these parameters

06:25We're only going to be reading from them

06:30You can set them, uh, just in this interface, no problem, right? We can just make this and call this like walk distance or something like that, very badly spelled

06:36You can set them to whatever you want here, like you can set them up in advance, you just shouldn't set them on runtime

06:41There's a lot of workarounds for

06:46That, that we'll discuss, and in the future, maybe it'll work

06:50But if you're going to be messing with these things before you get in too deep, package your game, make a standalone build, and test whether or not it actually works in that as well, because in my experience, there is a bit of a discrepancy between how they function in editor and how they function in a standalone build when you're trying to set these during runtime

07:08Uh, we're going to ignore evaluators and global task for the time being because those can be videos all to themselves

07:11So let's move on to the theme

07:14Uh, these are just pretty little

07:16Colors that you can give your states in your state tree

07:19So we can say we want to have a red color, uh, for when they are angry, and then we want to have maybe a, I don't know, yellow color

07:25I like yellow, uh, for when they are scared, and so on and so forth

07:29These functionally don't do anything

07:34These are just there, uh, to make your state tree more readable, uh, for you as a developer

07:38So if we go into one of these states, which finally we're talking about state trees, right? Let's go into one of the states and look at the details that we have for those

07:45Uh, we can set the color, right, from angry to scared, uh, to default to whatever

07:51We want, not all that relevant

07:58You can see that each state in itself also has some parameters

08:05Ideally, once these are actually settable and they don't crash the game when you set them, uh, this might be a cool way to effectively have like local variables within a state that you can set and, uh, reference back to

08:12Uh, for the time being, again, setting these on runtime is a little bit tricky and not very stable, so don't worry so much about these parameters

08:24Uh, for the time being, we have an enter condition, uh, and some transitions, which we'll make a separate video about, and then we have got tasks, which again, I'll Make a separate video about this

08:29This is just an overview for you to understand how the structure of all the states works

08:34The next video will be about tasks, and after, we'll talk about, like, conditions and that kind of stuff

08:40For now, I want to talk about the different type of selection behavior first, and then we'll talk about the different types of states as well

08:46So the selection behavior is mostly, mostly to do with being selected and what it selects

08:54So if we go through the route, we can make a couple of child states

08:59So you can right-click and add states this way, or you can add states just through the add state

09:03button

09:07Uh, but this is a little bit more precise where you can add either sibling states, so that's a state on the same hierarchical level as the state that you're currently uh clicking on

09:12So, in this case, these are uh part of the same parent state

09:17In this case, that's no parent state, or you can add a child state, which adds a state that is linked to this as a child

09:28It is important to realize that once this state is selected, this state is not considered unselected necessarily

09:35When a child state is selected, it also counts as the parent state being selected, and the reason that's important is because You can explicitly go immediately into a child state, which will also activate every parent of that state in turn

09:47That'll probably make sense a little bit later, if it doesn't right now

09:59So let's add a couple more child states to this, uh, to show off what "try select children in order" does, because this is the root, and the state tree is effectively just going to start off with the root state, and the root state is just the topmost state in this interface

10:11So if I make a sibling state to this, and I put that here, it's going to try to enter this one first

10:14It's just whatever is in this position is the first thing that's

10:18getting entered

10:21So then, when this thing is selected, uh, it will try to select its children in order

10:24So it's going to try to select this one first, and based on its enter conditions, it's going to check, "Hey, can I enter this, yes or no?" If no, it's going to move on to the next, and it does the same thing until it finds something that it can enter, which is exactly the way that a behavior tree would function

10:36So, by default, if you don't have any transitions whatsoever, it's just going to behave like a behavior tree

10:43And as you can see here, at the end of every state, we have this thing that says, "back to root." So after a state is Done, it's going to go back to root and do everything all over again

10:49Once again, exactly the way that a behavior tree functions

10:55A state tree is just a state machine that behaves like a behavior tree

11:00It's the best of both worlds

11:04But selection behavior doesn't just stop with trying to select the children in order

11:08We also have none, which makes this state unselectable

11:11I frankly have no idea why you would do this, straight up

11:15No idea why this exists, but it does, so doing this makes it unselectable

11:22If we just go into here and we make a transition real quick, uh, you can see that it gives you an error

11:28Because you can't enter the root state, I suppose if you want to explicitly enter one of these states, and then also want this to be considered active because it has some tasks on it that you don't want to directly be able, uh, to only do this, that's where none comes in

11:42Uh, I don't see too much use for that, but it is technically a possibility

11:49I guess the much more useful version of that is try enter

11:55What this will do is it will just enter this state, but not try to activate any of the child states, so we can explicitly just enter this and do whatever tasks are on this state without bothering with any of the child

12:01States, if we go into any of the child states, it will do both whatever it is on this and the child state

12:08As a fair warning, that also means that if this completes before whatever child state, uh, completes, that this is going to be marked as completed, and it's going to do its transition, which either is going to go back to like root or restart the tree or whatever, and it doesn't necessarily wait for the child to be finished

12:27The other way around as well, it's just whichever one finishes first is going to do its transition

12:32Then we have the try selecting children in order, which we talked about, and we have try

12:39Follow transitions

12:46This is effectively just a, "Hey, I want to set up my own logic for what you should do, just like make my own transitions with conditions and all that kind of stuff." The difference is, for try follow transitions, is that if it finds any transition that it can do, it will do that instead of its own task

12:53So it never actually starts with its own task if it can transition through, whereas when you do try enter, at least the task will get started and then it will start doing transitions, which brings us to the types of states that we can do

13:06Um, the most basic one, which most of the states are going to be, is a State

13:13This is a state that can contain child states, like all of these, and this can nest as deeply as you want, right? So you can make a child state and a child state and a child state, and they can all, like, whenever we do this, it'll also have this and this and this all active

13:24So that's child states

13:31Uh, but it can also contain tasks, which is like actual, like, code to run, which is what the behavior is going to, like, be based on

13:35Then we have a group

13:39A group is effectively just a state without tasks

13:44You can see as I go back and forth between a state and group, it just, uh, makes the task little thing here disappear

13:47This is

13:50Purely for organizational, uh, purposes

13:53So let's set this back to try, uh, and select an order

13:56We can select this as a state to go to

14:00It won't have any code, uh, of its own to run

14:03It'll just be a redirector to, like, whatever child state that we're going to go in, quite useful

14:07Next up, though, we have linked, and for linked, we need to, uh, talk about subtree first

14:10So you can mark a specific state here

14:17Uh, let's say this one as a subtree, and let's call this, uh, subtree

14:24Usually, it makes more sense, uh, to make this, like, an actually, like, separate thing altogether from the tree that we're working with, but it doesn't have to

14:30And when we set this to uh being linked, we can link it to anything that is marked as being a sub tree, and what it will effectively do is whenever we get to this state, so it would make more sense to do that on like a child state like all the way down here like linked

14:44When we get to this, it's just going to run whatever sub tree we link it to as this state

14:58So a state tree has this concept of being able to be finished as one of its transitions, so we can say uh here if we like on state complete, we can mark this as instead of transitioning to something as the whole tree having succeeded or failed, and when it does

15:12That, it finishes the sub-tree, and it marks this state as completed, so you can have this entire sub-tree accessible and run them as a singular state

15:24I personally don't love doing this, uh, because of the next thing that we can do

15:30Instead of doing a sub-tree, is we can use a linked asset

15:35This effectively works the same way, but instead of making a sub-tree within this state tree view, you can just link an entirely like separate asset that it will run until it is marked as being completed, and that will then mark the completion of that state

15:45The upside of that is that you can make many more modular small pieces

15:54Like if you have a character that needs to have a patrol routine, right? It starts at a location, then it finds something to walk to, then it walks through there, waits for a couple of seconds, finds a new location, walks to there, waits for a couple of seconds, something fairly simple

16:04Of course, it can be more complex than that, but a lot of your characters are probably going to need to use that

16:10So, you can make a state tree specifically for that and then just use this as like a linked asset

16:17So anytime a character needs to patrol, you can just link it to that other state tree, and that is effectively a substate

16:27tree

16:38That makes the code a lot more modular, a lot more reusable, uh, than using these linked subtrees, which is also a possibility and sometimes might be nicer to do, uh, but I personally think that using linked assets is a little bit smoother to work with

16:43So those are all the types of states that we can have

16:49Now, none of this does anything yet because we need to actually, like, start programming some tasks for this

16:54So let's just remove all of these, and we're going to change this back to being a state

17:00The root usually, uh, can actually be a group instead if you want to, but we're going to just change it back to

17:07Being a state, everything back to default, and we'll make a character that has this state tree on it real quick

17:14So, I already made this state tree, uh, character, uh, character class, and here we simply just add a state tree component

17:19Again, if you're making a state tree AI schema, you're going to need to add the state tree AI component, and you need to add that on the AI controller, not on the character itself

17:30We're going to stick with state tree, uh, normal here

17:35Apparently, I already added one of those

17:39So, in there, you have this, uh, state tree AI thing, and you can see we can pick our schemas here

17:42We only Have one schema, and I already picked it

17:46And here we can even change the walk distance parameter

17:49Remember the parameter that we made, the walk distance that I said you can't write to? You can very much just say, "Hey, I want to set a custom value here, like I want to make this 1500 for this type of character." And then whenever we use this walk distance in any of our tasks, it's going to uh use whatever value we gave in there because it's just a variable

18:02We can say whether or not it should start eloic automatically, uh, and all that kind of good stuff

18:08So, let's add in a uh child state real quick, and we're going to just add

18:16In a task, uh, debug text task, and the text will just be "hello" just so that we can see that it's actually running

18:29We'll talk more about tasks in the future

18:43I already put it in the world as well, so now when we run this, we should be able to see, right there, it says "hello." Uh, this actually seems a little bit broken because it's supposed to use the actor as the location, and this should be the offset, but apparently it's doing this as world location, but we can see that the debug task that we apply it to, uh, the "hello" is getting added to the world pair as a debug thing, so our state tree is running, congratulations, and You have technically added your first task

18:56It doesn't really do anything yet, uh, but I think there's quite enough for the first part here

19:03So, we've run through all this so that you have a basic understanding of where everything is and what kind of things they do

19:09If you aren't really following along in a lot of detail yet, uh, don't worry

19:17As we start going through and actually making stuff, all of this information will start to click into place and you'll start to understand what is actually going on

19:23But now that you have all of this basic knowledge of like what all of these little, uh, different things Are, we actually can start to use them

19:29Now that we understand the basics of what a state tree is and how all of these things work, uh, we're going to go through and actually talk about how to make them useful

19:41Because in the last video, uh, all that we managed to, uh, end up with is saying hello at the 0000 position of the world, and well, while that is fun, it's not actually that useful

19:50So let's talk about making some tasks

19:58Now, if we open up our state tree that we made, uh, we already added a task, the debug text task, which seems to be a little iffy with the way it works because this offset is supposed to be an offset

20:06From the character, uh, that it's running on, uh, but that doesn't seem to be working because it's just the world position for some reason, but that doesn't really matter for what we're doing right now because we can just, uh, remove this because we're going to be making our own tasks

20:23Now, I should point out that if you're using a State Tree AI schema, uh, you have one more default task, uh, available to you because we have AI actions, move to

20:29This requires an AI controller to work, of course, because it just uses the move to function, uh, from the AI controller wrapped up in a nice little task

20:36We can replicate that

20:42Effectively, so that we can use it on a, uh, non-AI version of the schema instead

20:49And the reason that we would do that is because we want to put the state trees on the character classes themselves instead of on the AI controllers, because we want to be able to set things on a more, like, individual basis, or it just makes a lot more sense, personally, to me to be able to do that

21:02So let's get started with a handful of things

21:09We need a move-to task, and then we need something that will figure out what location will move to, and we're going to make those two separate tasks

21:15Uh, you might want to make that one singular task in

21:22Practice, but I want to show you a couple of things of sharing data between different tasks as well

21:26So, we're going to make that into two separate tasks, uh, for mostly educational purposes

21:31So, let's get started by making our AI move to task

21:35You can just do that by going to your blueprint, typing in task under all classes, and finding the state tree task blueprint base

21:41I personally marked it with ST for state tree task, move to non AI

21:51In here, we have a couple of things that we can override: the enter state, so this runs whenever the state that this task is on is entered; the exit state, this runs

21:58Whenever we exit the state that we were on, state completed, which does a similar thing, it runs whenever the state we're on is completed

22:09Uh, this has a little bit more intelligent logic, uh, to it, where it does it in the proper hierarchy

22:16Exit state is, I believe, not so consistent in the order that it does things, because state completed is called right after the state has been completed, as it says here as well

22:26But for most use cases, uh, these two are effectively interchangeable, and then we have tick, which will just run every frame as long as the state that this task is on, uh, is active

22:38So for this, what we're Going to do is we're going to enter state

22:43So whenever we enter the state, we want to move to a location

22:48So for that, we'll first need a location to move to

22:53So move to location, which will be a vector, and we'll expose that

22:58Now, we also want to get the actor that we're running this on, because we don't have like default access to that

23:04So we'll make a variable called actor, which will be of type actor, and we'll expose that as well

23:11We're going to make this more intelligent and a little bit automated in a moment, but I want to show you the basic setup first

23:16So, we'll get the actor, and we'll actually uh get the AI

23:22Controller off of it to check whether or not it has an AI controller, because even though we're running this on a non-AI controller tree, uh, we're going to be using an AI controller function, so it needs to have an AI controller to work

23:34So, we're going to get AI controller, and we're going to check if that is valid, because if this AI controller is not valid, we want to just immediately, uh, finish the task and mark it as unsuccessful

23:45We'll talk a little bit more about finish task in a moment, because this is poorly named

23:48This should be finish state

23:52If you have multiple tasks on something, it's not going to do

23:58Those tasks one after the other, necessarily

24:03It's going to run them pretty much all at the same time, and whenever any one of them gets to a finished task, it finishes the entire state

24:09Anyway, if the AI controller is found, we can do move to location or actor

24:15The reason that we're doing this one is because this one is latent, uh, so it has these pins for on request failed or on move finished, which is, uh, quite important

24:22If we just use the normal move to location, uh, this will just start the move, but it won't give us any feedback as to when the move is finished, and that's going to be important for what we want to do

24:29Here, so we can give in either a goal, uh, actor or a goal destination

24:36We're just going to go for a goal destination at the moment

24:40Uh, you can make this also take in an actor

24:45I believe the actor, uh, input takes priority over the location, so if you put in both, it's going to go for the actor

24:50Uh, but that's not really, like, too relevant right now

24:56We just want to have the move to location, and then when either the request, uh, fails or when the move is finished, uh, we'll again finish task

25:02On request failed, we'll see, uh, this as being not successful, and when the move is finished, we'll say that this is successful

25:11This

25:19Can influence the different types of transitions that we go into based on, hey, did we reach our goal or not? We might want to go into a different state entirely, but this effectively is our first task

25:27So, we more or less just recreated the AI move to task, uh, on something that now can exist on the actor itself instead of having to be run specifically on the AI controller, which is just kind of nice if you ask me

25:34So, going back into the state tree, we can see, uh, we have this thing over here

25:41Let's add, let's call this, uh, patrol, and we add the task there

25:48The task that we'll add is our ST move to non-AI, and here we can see

25:53We have a field for the actor

25:57That's going to be the actor that we'll be doing the move in, and then we have the move to location

26:02Both of these we're going to need to populate in some way or another

26:07The actor field is actually very easy to populate because state trees has a built-in way to supply this context variable into any task that we're running on it

26:15That's simply going into our blueprint here for the task and going into the category and typing the word "context." It's not case sensitive

26:20It can be lowercase, uh, if you wanted to, uh, but do make sure that there's no typos, and then when we compile this and go Back, you'll see that, hey, it's now immediately populated with a binding to this context variable, and it even does that when you have like a different name

26:37I just changed it to like FD SFS, just some gibberish

26:43It just does it based on the type

26:48So if you have multiple things that are actor references, only one of them should be the context, because otherwise they're all going to be filled in with the actor context here, but we'll just call this actor because it's descriptive

26:53Now we have this move to location, and we can just manually say, hey, I want you to move to like 100, 500, 200 or something like that

27:00And that will manually make it move that direction, uh, to that location

27:07Of course, uh, that's not what we want to do

27:12We want to be able to, like, do this dynamically

27:16It should pick a location to move to, and then move to that location

27:25So you can just do that in, uh, in here

27:34Of course, you can just calculate where you want to move to, do based on the current location, and then, like, find a different location, and that is a fine way to do it, and that's probably the way to do it, but I want to show you how to set up a different task and access information from that task to populate the move to location variable

27:38So let's make a find

27:42location task

27:46So, we'll make a new blueprint task and we'll call this ST bind location

27:50And here we'll just make a variable, uh, which we'll call location, and we'll set this up as a vector, and we'll make a variable that we'll call radius, and we'll set that up as a float

27:59Then on state enter, we also actually need the actor again

28:09So, let's make an actor reference, and just like we did before, we can set this to being, uh, context

28:18And the wonderful thing actually is that if you set this up to be a context, you don't even need to like expose it

28:22Technically, it'll just do that for you, but let's just expose it

28:25Everything anyway

28:28So, we get that location and we get a random reachable point in radius

28:32So the origin position will be the actor's location, the radius will be the radius, and then the location that we get out of that will be the value of our location variable here, and that's kind of everything there is to it

28:48So we can now add that as a task here as well, so we can add that ST location

28:54I want to pull this up to above there, and now we can start populating these things

28:59So this radius we made a parameter for, so we can bind that to that parameter with this icon over here

29:07If you press that, you can get any value

29:14That exists on the actor that we have, and the nice thing about that is, because we have this drop down here for the context actor class, we can actually set that to our uh, stage three character that we have made

29:18And if we have any variables on there, we can actually sample from that as well

29:23So let's make one just as an example

29:28Let's make a uh, like test var float or something like that

29:33We'll make that a float so that it's actually like the right type

29:39And if we now go to radius, we can on our actor find the test var float because we have set this up to use the context actor class of our state tree character

29:45If we Just go back to being a normal actor, we'll see that that actually is no longer available because it doesn't know what type of actor

29:51So, it's kind of like a built-in uh casting method for our users

29:57Of course, we don't really need that variable to be accessible, so keeping this as generic as possible is a good thing so that we can reuse this on other characters as well

30:03We instead just want to bind to the parameter for walking distance

30:09Now, this location we don't need to bind anything to because this is going to be a thing that we set

30:15Uh, instead what we want to do is we want to get our move to location on our

30:21Move to non-AI, and we can then bind that to a value on a different task on this state or any of its parent states

30:27So if we put the location finding thing on the root here, I can actually show you that find location, we will be able to see that in the move to non-AI if we want to bind something, we can get either one of these

30:41At this point, I'm not sure which one is which, though, so I'm going to delete this one again, because we're going to just do it on the same state

30:53Or you can individually, like, bind the X, Y, and Z to floats and all that kind of stuff, as you can pretty much anywhere with any vector

30:58So let's bind

31:02This

31:07And now this is going to, when we move to location, going to look at whatever value exists on this task, which ideally, uh, will have run before and have picked a location

31:12But this is a little messy still, because we still have these fields that we can manually fill in, and it's kind of weird

31:24And what if we forget to put in the radius? Well, context isn't the only category that we can use, uh, to make our lives a little bit easier

31:31If we go back into, uh, any of our tasks, we can set this location, which we are setting to be an output value

31:37That will get rid of all of the input fields, so it's only a value that was setting

31:43Through code, and we can then bind to

31:50So we simply do that by going into the category and typing "output." Again, make sure that you don't have any typos in it, and if we do that, we can see our location is now set as an output property

31:57We will set that value, and then other things can bind to that value, which is quite nice, and that should even work dynamically

32:10So if we're setting, uh, this in event tick, uh, based on like a bunch of calculation, a bunch of other data, or whatever, once we update this, anything bound to it will also then reflect that with its like new updated value, because that is what a binding does

32:22It's Constantly checking that value

32:29As for the radius here, uh, we can set that up to be an input, and all that an input is, is that will, in the category of course, that will just force you to bind it to something

32:40It gets rid of the input field, so you can't manually put in a value anymore, but you have to bind it to something

32:47If I remove this binding and I try to compile this now, it's going to scream at me that this input doesn't have a binding, so this prevents you from accidentally making something that will break your entire state tree

32:56So this move to location on the ST move to non-AI, which is this one probably also

33:03should be set to being an input value, because we always need to have something to walk to

33:09And with this setup, we should now have something that pretty much just picks a location and moves to that location

33:15So let's test that out

33:21If we run this, uh, we don't have a nav mesh yet, so it's not going to do anything

33:25So, let's do a nav mesh bounce volume

33:30I will make that as big as it needs to be

33:33Press P to check the nav mesh has been generated

33:35That's pretty good

33:38And now we will see that he is just moving all over the place because he's not waiting

33:41He's not resting

33:44He's, he's not doing anything

33:47He's just moving to a place, picking a new position, moving to that place, picking a new position, and just keeping that up

33:51He also doesn't seem to be playing animations, but that's not the biggest issue right now

33:55But our, uh, two tasks that we made are working together

34:00This one is sampling from this one, and then when it finishes, it marks this state as completed, which, uh, by default then goes into the transition that we have set up for it, which is no transitions that we have set up yet because that's going to be a video in and of itself

34:18Uh, so default transition is just going back to root, which means that it's doing, uh, just this as A loop right now

34:26Now, I will say, you might think, okay, so then I can put a delay in here for like 1 second or like even like 5 seconds

34:33Let's make it 10 seconds, uh, and then after it reaches this point, it's going to do this delay task and wait for 10 seconds, right? That's how that works, right? Well, no, because as I said, when any of the tasks on a state finish, that counts as the state being finished

34:46So when it moves to a location and it reaches that location, it marks the state as being finished and then does the transition

34:57So what happens here is it either finishes on move or after 10 seconds, whichever one of These tasks, marks itself as being finished, first will just trigger the entire state to be finished

35:13So if I set this to 0.1, you will see that he gets, uh, very, uh, weird because he's finishing the state every 0.1 seconds and getting a new position to move to every 0.1 seconds

35:20And even if we delete this and I give this thing a, um, child state, which we can now start playing around with, and we call this weight, and I put in a task for it to delay and say that's 0.1, it will do the same thing

35:39So because this state is active, its parent state is also active

35:45So it's still going to be doing the moving thing, but whenever this State finishes, it's going to go back to root and restart the entire thing

35:51So this will still behave the exact same way, even though we're technically like in the weight task

35:57The weight task is part of the state that does the movement, so it's still going to be doing the movement as well

36:02And if I set this again to 10 seconds, uh, it's not going to wait for like this to be finished because this is going to finish sooner and that's going to get you back to here as well

36:13I think, as you can see, whenever it finishes moving, it doesn't wait a full 10 seconds, it just does the thing

36:21Now, that's a little bit confusing

36:29Because it doesn't actually show the transition here anymore, uh, but it still does that

36:37When something doesn't have a transition, it just, it goes back to root upon finishing of any of the tasks in the state, which is also why this find location task that we made doesn't finish anything, because it doesn't need to

36:42It shouldn't

36:47As a matter of fact, this just needs to set the thing and then be ready for anything else to grab that value

36:51It doesn't need to tell anything that it's finished, because if it did that, we would never be moving

36:56I can actually just show you that by adding here the finished task

37:02And now it, uh, it finishes every frame, which, uh, it's a little wacky, isn't it? The whole finish task thing again is a little counterintuitive, but this is how, like, hierarchically that works

37:15And that's the basic rundown of tasks, inputs, outputs, context variables, and all that kind of good stuff

37:21So, combining this with what we're going to be talking about next, which will be transitions and enter conditions, then we can start making some really, really interesting stuff

37:32So, we have this AI that is just kind of running around, minding its own business, but it's not standing still at any point

37:38It's not doing anything, uh, else at any point

37:44It's just kind of, uh, running about aimlessly, which is maybe less than ideal

37:49So let's give it a state where it can rest every once in a while, right? So we have this state that we have set up so far where we do, uh, patrolling, and then, uh, we had this weight task, and we tried to do that as a child, but hey, that didn't work because that's not how these things are, like, structured

37:57That's just not how they work

38:05Instead, this weight task needs to be its own state

38:13It needs to go from patrol, which, uh, will change, uh, from being named patrol to being named, like, move to instead to

38:19Be more descriptive to going into the weight task, so these are going to be siblings instead of a parent and a child

38:25So when we enter route, it's going to move to, and then it's going to wait, and then it's going to go through root again, move to wait, and so on and so forth

38:36From there, we can build up some other stuff, so let's set this delay task to being a little bit less than 10 seconds

38:42Let's make it 5 seconds instead, and we can give it a little bit of random deviation, uh, of like 1 second, so it's between four and six seconds instead

38:47Uh, we could even set this to run forever, so it's going to be waiting until it is

38:51forcefully transitioned into another state, but timing is actually exactly, uh, what we want to do

38:55And again, you can bind these to outputs from other tasks or to parameters or whatever we want, really

39:00So, setting this up is actually remarkably easy, because in the move to, we can just add in a transition, and here we have a couple of different things that we can do

39:13We can trigger this when the state is completed, so, uh, whenever it is either failed or succeeded, we do this

39:20We can say when the state succeeds, we move to, uh, whatever we're going to be transitioning to, or when the state fails

39:28And if you remember, Correctly, we set up the, um, move to task right here to be able to say, "Hey, this task is finished either successfully or unsuccessfully in a number of different scenarios, whether that is not having an AI controller or not being able to reach, uh, your destination." So we can say if the state succeeded, we can go into waiting, but if it has failed, uh, we can do something else, like deleting this actor because it's clearly in a position where, uh, it just cannot move, or maybe reset it back to its original position, or we can do a variety of different things, uh, depending on what you need

39:41But this is a way that you can

39:53Easily make it go into different paths depending on what's happened

40:06We can also just do on tick, every tick, every frame, check a certain condition, and we'll get into conditions in a moment to see if we should uh transition

40:19So if you, for instance, wanted to uh attack the player when it gets close enough to the player, uh you would check every tick if you are close enough to the player, it has built-in stuff for that, so that's kind of cool, and then move into the attacking state uh when the condition is met

40:28We can also do this on event, uh and this is kind of neat

40:36We can externally from our other code, whatever might be happening there

40:45Uh, we can send an event with a certain gameplay tag to this state tree, and if that happens to be sent while we're in this state, that will trigger this uh transition, that's actually kind of really uh cool

40:56So for instance, if you're in a attacking state and you get damaged, you can send a event tag to make it go into a like damaged state, make it go stunned, or something like that

41:09For now though, uh what we're going to do is just on state completed, doesn't matter if we failed or succeeded or whatever

41:15Uh, we're going to go transition to a new state, and we can transition either to uh none, which makes it just get stuck in this state, so it's probably not the best thing to do

41:28Uh, the next state, so that's going to just go through and see whatever is beneath me, like what, what is under me, I'm going to move into that one

41:33Just to be clear though, uh, this only counts for sibling states

41:39So if I, uh, add a sibling state to the root here and put this one like down here, it might seem like this is pointing to next, uh, but since this is a state that is entirely unrelated to whatever this state is, it's like it's uncle, right? If these are siblings, this is the parents

41:53This is an uncle state, it, it can't transition to

41:58Its uncles or cousins or whatever, stuff like that

42:02It can only transition to siblings, which is exactly what we need for what we're doing right here

42:06But let's just run down the list, uh, for the sake of, uh, showing everything

42:12We can do the next selectable state, so this just next state will try to just move into explicitly what is under it

42:18But if this has an entry condition, which we'll talk about in a moment, that makes it unable to be entered, this is just going to, uh, short out and effectively go back to root is usually what happens

42:25If you try to enter something that can't be entered, it effectively just

42:31Resets the whole state tree

42:38However, if you do next selectable state, it's going to effectively just kind of work as trying to select its children in order, but what it will do instead, it's going to try to select its siblings in order

42:44So if it can't enter this waiting node for whatever reason, it's going to try to do whatever is under it, and if that's not possible, it's going to try to do whatever under it until it runs out of siblings, or we can just mark this as the entire tree having succeeded or failed, which, as you remember, uh, is useful if you're using sub trees or linked subree assets, uh, because those

43:12Will be able to communicate that way, that hey, the tree as a whole is now finished, and whatever tree has me running as a singular state can now move on, uh, because that will trigger the on-state completed for whatever state that is in

43:26I think I want to make a video specifically just diving into subtrees and just setting up some subtrees to actually show you how these work instead of just loosely explaining it, because I feel like that's going to make you understand it a lot better

43:39But within the context of transitions, uh, that is all you need to know, uh, for right now

43:44So with all that, we now just have made a loop

43:52Uh, with a delay in it, effectively

43:59So if we make sure that everything is compiled and saved, and we run this now, we see he runs, he waits, and then after a couple of seconds, he runs again, he waits, and that will repeat, uh, pretty much infinitely because we're just looping, uh, through over and over and over again

44:06So let's make something that is a little bit more interesting than this

44:12When we're waiting on state completed, I want to check, for instance, the distance, uh, to our player, and if it is within a certain range of our player, I want it to do one thing, and if it is not within that range, I will want it to do something

44:27Else, at the end of our waiting task, let's add a transition, and here we can start adding conditions

44:30We can make our own conditional checks in a moment as well

44:34That's actually really interesting to do, uh, but there's a lot of them that are just provided

44:38We can just compare a bool variable, we can do a distance compare, enum compares, float compares, integer compares, or we can just give them a random chance

44:44And this is the wonderful thing about State Trees

44:51It just has a built-in random chance, so we can say, hey, we want to give this like a 30% chance, so 0.3, uh, to go into any like given state that we, uh, provided in with, which is kind of cool, and if you add multiple conditions at, uh, the same time, so we can do this and a distance compare, you can see that this, uh, has a little "and" on it

45:10We can also change that to an "or", so we can do, hey, if this randomness is true, or the distance compare is true, this transition is now valid, or they need to both be valid

45:22So need to be within a certain distance and have that random chance, uh, just rule in our favor, and we can add like a bunch more of these

45:34Of course, we can then do, um, this and this, or this, like these binary operators work the same way that they would for like branch now

45:40Like just normal boolean and stuff, right? Uh, so you can set this up however you want

45:46For now though, uh, we're just going to do this as a distance compare, and there we can get, hey, the operator we want to get, equal, less than equal, greater or equal is true

45:52It's kind of a weird one

45:59Uh, so we want to check whether or not there's less than equal distance between two things

46:06So the source is an input, and we should just be able to get the actual location, but it seems like, uh, since I'm using 5.4, this might be an older version which doesn't have that implemented yet

46:11In newer versions, you have a built-in get actor

46:16location um function here that you can uh use, and then you can give an actor to get the location from

46:21That does not seem uh to currently be working, which is actually the perfect chance for us to, instead of using a pre-made transition condition, to make one of our own

46:33So, let's make one that just literally checks the proximity to the player character

46:38So we can just get blueprint class um and then type in condition, find the stage three condition blueprint base, and we'll call this uh STC for stage three condition distance to player, and here we only have one overridable function, and that is receive test

46:47condition

46:56In newer versions, you also have a function where you can override, uh, the text that it displays as a little, uh, explanation

47:05Again, state trees are new enough to the point where it's actively, uh, being worked on

47:10Some things are a little buggy sometimes, like writing to parameters, as of right now, and it's constantly getting new features as well

47:17I'm just using Unreal 5.4 for this series

47:24Uh, my experience using it has been at 5.5, and I can already tell, like there's differences, uh, in things that are missing in 5.4

47:35Anyway, this, uh, receive test condition, uh, just gets us a bool, uh, that will either Let us go through, or not let us go through

47:39So, we need a couple of variables here

47:43This will be the actor variable that we um have in our context

47:47So, this will just be an actor reference, and we'll set that as category context

47:52We'll use that, and then we'll also just get player character

47:58You can also make this like a target uh input or something, and then like this and make that an input and use that instead, but then you would need to supply that in uh, which actually, let's do that because that's a little bit more fun uh to do it that way

48:06So we have our actor and our target, and we'll get the actor location from both

48:15Of those, and we'll get the distance between those two vectors

48:23Now I want to do a select here, and we're going to be selecting, uh, based on a, uh, compare, and that will be of type E comparison methods

48:38So we do that, and then we get the equal to, not equal to, greater than or equal to, less than or equal to, greater than, or less than, and we will return values based on all that

48:51So we'll check the distance between the two, is that equal to a inputs that we want to have? So that will be, uh, the distance be a float

48:57We can give that a default value of like 500 or something

49:02So we'll check, uh, is it equal to, then we'll check is it not

49:05equal to, and so on and so forth

49:08We'll just do this for every single one of these

49:11So, uh, then we get greater than or equal to

49:15So that's greater than or equal

49:19I think, uh, you kind of get the point

49:23So then we have the less than or equal, simply just greater than, and simply just less than

49:27And if we hook all that up, now we have, uh, a condition check that we can reuse for, like, every single one of the, uh, comparison methods between the actor that is running this state tree and whatever its, uh, target that it is comparing against this

49:35Also, do make sure to hook everything up

49:43So now, in conditions, we suddenly have our Custom distance to player

49:49Well, that should probably be called distance to target, to be fair

49:54And there we get the context actor in, and the target actor we can supply in through a variable

49:59So now what we're going to do is, instead of just keeping this as context class for the normal actor, we'll actually change this finally to our state tree character, because we're going to make a variable on the state tree character for our target that we're going to be comparing to

50:16So let's make this an actor reference, and with that, we can now say, hey, the target that we want to get is the context actor

50:22Target, and then it's going to bind to that variable in the state reactor

50:30For now, though, uh, we can expose this to maybe, um, make this editable on a per instance basis, but for the time being, I think what we're going to do is we're just going to, uh, set this to get player character after all

50:44But this does make it more flexible, more reusable in different kind of scenarios to just make the task or make the condition check in this case

50:49Uh, taking a variable, and then we'll check whether or not this is less than or equal to, I think, 500 is a pretty good one

51:03So if that is the case, what we're going to be doing is let's make a New state, so we can make the, uh, let's say jump

51:09I'm just, I don't know what I'm doing, but it will jump

51:13And after jumping, it goes back to root

51:17Within that range, what we'll do is we will, uh, transition to the jumping state, and otherwise, we just go, uh, back to root

51:21So we'll try to do these transitions in order, so we don't need to set up an entire, like, inverse condition for this one or anything

51:31Uh, just for demonstration purposes, I guess, uh, let's make a quick little jump task

51:40Uh, so we can make this task blueprint base statry task jump where we'll make an actor

51:44That's going to be a context thing, obviously

51:48Let's

51:52Actually, just make that a character right off the bat because we're going to need that for, uh, jumping to be able to work

51:56And when we enter this state, we get our actor, we jump, and then what we're going to do is we're going to just check inside of tick if our actor get movement all the way at the bottom is falling, and whenever it is no longer falling, that is when we will finish this task, and let's set this category to context

52:17So now that we have that, we can add this jump task and transition, uh, on complete with go back to root

52:23That's actually just the default, so we can just keep that there

52:29And now whenever you Are within 500 units, it will jump before restarting

52:35Uh, if we just let you walk around, uh, a bit, it doesn't jump at all, but if I am within 500 units of it, when it stops waiting, it should jump before doing anything else

52:43So we can just, there we go, and it runs away

52:51So we effectively have it making a decision here, uh, based on some inputs that we give it, and we do this on state complete now

52:55But what we can do instead is we can do this on state tick

53:00So as long as it's waiting, whenever we get into 500 units, it immediately will jump and start moving again after that

53:04So that can be like we kind of scared it and and it's

53:12Like, uh, and start moving

53:19Uh, so you can see it jumps and it starts moving again, and then it jumps and it starts moving again because it's picking, uh, locations within 500 units every single time

53:25Uh, but this makes it feel a little bit more reactive because it's checking this, uh, on every tick

53:31Now, ideally what you would do is instead of just moving back into move two, maybe what you do is you run a query, an environment, uh, query

53:38I have videos on that as well, uh, to get a location far away from you and make it move to that location instead and make like an entire, like, separate hierarchy, uh, for that, or like a separate, uh

53:49Couple of states, but those are transitions

53:56That said, now that we have this condition made, these entry conditions kind of just work on the same principles, but except for being evaluated at the start

54:06So when you try to enter a state, you can just put any condition that you want on here as well

54:13So if a certain object is of a certain class, or if you have certain gameplay tags on a container or whatever, it just checks, hey, is this check cleared before moving into the state? And if it is not, the state is considered unenterable and it will deal with it as specified

54:33So when trying to Select children order, when you cannot enter this state, it's going to try to enter this state instead

54:39So let's say for this one, uh, we can only make it move if the distance to player is greater than 500, and then the distance to player, we set that to player target

54:52So now, if we're within 500 units, it's never going to enter this, and all that is going to do is it's going to wait and jump again, and wait and jump again, and wait and jump again, which is a bit of a bad survival tactic to be fair, but I don't know

55:01Yeah

55:10So, it's uh, going to just keep jumping, uh, because we have this set to untick actually, so that's maybe not

55:21Ideal

55:31Let's set that back to being state completed, but it works as expected, right? So, it runs away, and then if we're within a certain radius, uh, it will jump in a moment, but then it won't actually start moving again because it filled the entry condition of the walking state, and it will just wait and jump again, and wait and jump again, uh, pretty much infinitely

55:42Now that we have this guy, uh, kind of wandering around and doing its thing and responding to us somewhat intelligently, like when we're close to him, he jumps, and then he just, uh, gets kind of stun locked until we run away again, at which point He will resume his running around

55:54It's not very, um, intelligent, but it is artificial

56:02So, it is artificial, almost intelligence, uh, that we have made

56:07Let's take a look at the state trees and a thing that I skipped over, uh, in the stars, and that is evaluators and global tasks, because these things are kind of the same thing

56:13They're two different names

56:19Uh, they are both code that runs over the entire tree

56:25So all these states, when we enter them, their tasks will run, their end task, and when we exit them, it will run the exit task, and then in the meantime, it can run a tick as long as a state is active

56:31A global task is Just something that does all that on the basis of an entire tree

56:39So usually that is mostly, uh, something to do with updating information, uh, on tick

56:46For instance, we have this, uh, distance to player check, right? Which we specifically coded to check our distance to a certain actor, but maybe we're using that in a bunch of different things

56:58Maybe we're using that, uh, as a check

57:03Maybe we're using that to decide things in certain tasks

57:09That distance might just be a value that we want to be able to get easily in a bunch of different places, in which case, we can make a task for that and add that to our global

57:15Tasks, and global tasks are just the same as any other task

57:22So, uh, any task that you make can just be added in here as a global task, and every node, or every like state in your state tree, has easy access to global tasks

57:28So it's effectively just a task that is running on the root of your state tree, more or less, except that, of course, you can have multiple, like, roots, like I can add a sibling to the root, and um, if I wanted to replicate what a global task can do

57:47Now, both of these also then need to have, like, a parent

57:54So I need to add, like, another sibling, and then add both of these into there, and it becomes a little messy, real

58:00Quick, we can just do it with a global task and everything will just have easy access to that, so that's where global tasks come in

58:06Now, evaluators are effectively the same thing, but they are tasks specifically made to run on entire trees

58:13So if you have a task already that you're like, "Ah, but I actually kind of just want to run that globally," you can make them into a global task, and that's kind of like a good enough way to do it

58:23If there's any code that is specifically going to be designed to be run on a tree as a whole, that's where you just make an evaluator for it instead

58:31The reason that both exists is this is

58:39Kind of like just nice to be able to reuse some code that you might already have, and global tasks existed before evaluators, I believe

58:46So evaluators are just kind of like the new and improved version of global tasks

58:54So let's make a evaluator here that will keep track of our origin position, so the position where we started, so that we can make our patrol not move away too far from that

59:01We're going to make him patrol within a certain radius of its starting position instead of within a certain radius of its current position

59:07I think that will be good to do

59:13So to do that, we can simply go into our blueprint

59:20classes here, and we can type evaluator and get the state tree evaluator blueprint base, and we call this something like, uh, stage tree evaluator get start location, and this will be relatively straightforward, uh, to make, but we have three functions here: tree start, tree stop, and tick

59:38So when the tree starts, we can do something

59:43When the tree stops, we can do something, and we can, of course, do something on the tick as long as the tree is running

59:49For this, of course, we want to just get our position when the tree starts, so we add a variable for our context actor, so that'll be actor of type context in the

59:56Category, and then the actual type will be of type actor object reference, and we'll just get the actor location of that, and we'll promote that to a variable, and we'll call this, uh, location, and then in the category, we will mark this as an output, and that's kind of everything that this needs to do

01:00:24This just will, uh, get and save our starting location, so we can use that easily throughout our state tree

01:00:30So these things are kind of more how you, uh, get and set dynamic things

01:00:38These evaluators will themselves set values based on maybe other bindings that they have, and then other tasks can read from the

01:00:50Evaluators, so a lot of this might happen within like tick, and you can specifically optimize that to only tick when they get certain events, of course, so that they don't run constantly, uh, like I showed you in, I believe, the previous video

01:01:04So now that we have an evaluator, we can add it as the start location, and we can see that indeed it has a location out

01:01:10So now if we go into the move to, uh, we have this move to location, uh, instead of, uh, doing this and the find location, we'll actually change the find location, I think

01:01:23So instead of taking in the actor, uh, context here, because we don't need that anymore, what we want To do is open up our find location, and we just make an origin variable, uh, that we set to being a vector, and that will be an input because it's always going to be required for this to work

01:01:42And we can get rid of this context because we don't really need that anymore

01:01:48We just use this origin instead, and for this origin, we still can just use the actor's location if we wanted to

01:01:54Uh, again, I think that might not quite work in, uh, the current 5.4 version, but in 5.5 that does work

01:02:00So here in move 2, we have this, uh, origin, and we can bind that origin, uh, to anything on the character

01:02:06So yeah, there's also in 5.5 and beyond

01:02:12There's also just a, like, get actor location option whenever you want to bind an actor like this, so you would be able to do that

01:02:18Uh, doesn't seem to exist in 5.4, uh, but instead what we do is we get the starting location from the evaluator that we made, and now it's going to always try to find something within 750 units of the starting location

01:02:31So, it's never going to, uh, get outside of, like, a circle that is, I don't know, about this big, which we can test by just doing this

01:02:42So, uh, we, we can just stand here for a little while, and instead of walking even further away from its origin position, now it will just, uh, stay

01:02:52Within a certain radius, which is quite nice

01:03:02That is especially good if we start doing other, uh, like more complex stuff, right? Because we can do something where, uh, we can add a chart state to this and call this, uh, patrol, and we can get rid of this, uh, jumping because that was just for an example

01:03:12Let's get rid of the transition to that as well, and then when we complete this state, we're just going to go immediately back to move to

01:03:18We're not going to go back to root, and the reason that we do that is we're going to put these two within the patrol state instead, because we can add another sibling to the patrol

01:03:25So

01:03:32Another child to the roots, and this will be chase, for which, uh, we will change the move to non-AI as well

01:03:39And we'll also put in a goal actor here, so we'll just call that goal actor

01:03:45And we'll change move to location, uh, to not be an input, uh, anymore because it's no longer necessarily required, because we can do either this or this, and inputs always need to be filled in

01:03:56So we can provide an actor instead, and, uh, with that, it effectively becomes a possible chase, uh, task as well

01:04:02So within chase, we add a child state where we, uh, do it, we move to

01:04:09So that is move to non-AI, and we're going to be moving to the actor's target

01:04:16That we set up before, and it's just going to entirely ignore the move to location, uh, because the move to actor all location will prioritize moving to actors

01:04:24So when that is finished, what we want to do is we want to move on to the next state

01:04:33And the next state, let's actually call this run to target, and when it is finished doing that, it will add a sibling state

01:04:40We'll call this jump again, and it'll just do the jumping

01:04:48Of course, this would be attacking in any reasonable, uh, video game, but we don't have any like combat setup for this, uh, example, of course

01:04:56So, we just add a task for jumping, which will then Get us back to route, which will get us back to patrol

01:05:02And then patrol is going to have a transition on it for on tick

01:05:07It's going to check this every frame as long as it's within patrol

01:05:12It's going to try uh to move to chase under the condition that we have a distance to the player that is less than 500 units, but that's a one-way street, right? So, if it is less than 500 units and I manage to get away from it for more than 500 units, it's still going to stay in the chase state until it is specifically told not to be in the chase state, unless it gets to me or I set up something in the chase states to go back to

01:05:23Patrolling

01:05:33So, let's set something up in the chase state to go back to patrolling

01:05:44Uh, if the uh state is uh on tick, we transition back to patrol

01:05:48Uh, this interface also looks better in 5.5

01:05:52It actually just shows you a miniature version of this hierarchy instead of just a dumb list like this

01:05:56So, again, the system is being improved constantly

01:06:04Uh, but the condition, let's check the distance to player, if it is greater than a thousand, we'll consider that having uh escaped, and we'll compare that to the target actor for both of those as well

01:06:19So now what this will do is we will uh be in the patrol state, which Will just move to wait, move to wait, move to wait until the player or its target gets within a certain radius, at which point it will go into chasing

01:06:31It will run after us

01:06:37And the whole reason that I'm setting this entire thing up is because when it goes back to patrol, it will go back to patrolling around its original location

01:06:43So, I can lure it away very far, and then when it loses interest in me, it's going to go back to its original position

01:06:50It's not going to keep patrolling around the place that I lured it away to, which in a lot of cases, in a lot of games, uh, would break AI and would do weird stuff

01:06:56Most games

01:07:04Have a concept of going back to an origin position for an AI when their task, uh, like resets to just patrolling

01:07:10So, we can see he's just patrolling, but when I get within a certain radius, he starts to, uh, run after me, but then when he gets to me, uh, well, he will actually always, uh, be trying to get me now, uh, because I'm still within 500 units

01:07:24So I think it is a good thing to add in a sibling set here as well, uh, to wait again

01:07:35So instead of going back to root, I want this to transition to the next state on completion

01:07:41So let's go next state, and then I will add in a delay for this one of like 4 seconds with a random deviation

01:07:49Which can then go back to root, uh, to do its entire thing

01:07:54So, uh, let's make it, uh, chase us, which is kind of annoying to get it away from its origin position now that it is, uh, going to wait every single time, but I'm just trying to lure it away from its origin position so that you can see that when, um, it resets and goes back to patrolling, it will go back to patrolling with, uh, within its like original range, not going to just start patrolling around, uh, its new position

01:08:20So, as you can see, it runs back to roughly where it started within about 750 units

01:08:25So, that's where things like these evaluators can Come in, uh, really handy

01:08:32And again, we can also fairly easily just make an evaluator to, like, state tree evaluator, get distance to target

01:08:39This might be useful information for a bunch of different things, right? So we can pretty much just copy a bunch of the stuff, like from distance to player, like effectively this entire setup

01:08:52We can just do that on tick, and we promote this to a variable, call it distance, make it an output, and that's kind of everything there is to it

01:09:00We do need to also make these two, uh, into, uh, variables

01:09:09The actor, of course, will be then of type context, the target will be of type input because

01:09:14We're going to want to have, uh, that always filled in

01:09:18Uh, but just like that, we now have an evaluator that will always have an up-to-date value for our distance

01:09:23So, we can go back into the state tree, add that in as an evaluator, uh, get distance to target

01:09:30We can set up the target to be the actor target variable, and then we have this as a usable, uh, referenceable instead of wood

01:09:36It is now a value that we can use anywhere in the state tree

01:09:43So, making these evaluators is kind of a workaround

01:09:49Uh, instead of using parameters dynamically, you can just make these as little calculations that take in stuff like the

01:09:58These are taking in values, and these can even, like, take in parameters or take in, uh, things from other evaluators if need be, and then expose the value out for you to use in a bunch of other stuff

01:10:10So now, instead of, uh, using this condition for get distance to player, I can just change this fairly easily to a float compare, and I can just compare the get distance to target distance to a number, and I can check whether or not that is less than or equal to, and now I can reference that number from a bunch of different places

01:10:24Everything we did here also technically is possible to do within a global task, but since these

01:10:37Are things, uh, that are very much just only useful to do within, like, the context of an entire tree

01:10:50There's no real use making them into a task, and making them into evaluator is just a little bit smoother, a little bit better

01:10:56So I think in the next video what we'll do is we'll make an evaluator that, uh, creates a cooldown, because one of the things that state trees, at the time of recording this anyway, uh, is missing that behavior trees do have, is the ability to add cooldowns to certain states, which I think is a bit of an oversight that might get added in the future

01:11:05So that video might become irrelevant at some

01:11:13So we have some fairly simple, uh, state tree behavior for our character

01:11:22Now, uh, we are using a bunch of different states with tasks and evaluators and values and a lot of different stuff, but there's one thing that is a little bit lacking with state trees, uh, compared to behavior trees, and that is that there's no real way to, uh, put an entry condition with a cool down on it

01:11:44You can't say, "Hey, keep this, uh, entry condition, uh, locked for x amount of time after it has been initially, uh, entered." And I kind of just want to set up, uh, a fairly basic way, uh, around that

01:11:56Honestly, this will require you, uh, to have a Specific context actor class, um, that has some variable set up to work with this, uh, just due to the sheer fact that we need to access a variable that we're going to be making on this class, and that's a variable that we can't send through, uh, as a reference

01:12:16We need to access it directly, so let's make that

01:12:23And what we're going to be doing is we're going to be making a new variable, and I'll call this, uh, cooldowns, and I'm going to make that of type, uh, name or string

01:12:27Let's just do string for now

01:12:31I think name technically performs a little bit better, but it's not that important, and we're going to make it a map and

01:12:35It will have values of float, so it's going to be a string and float map

01:12:41Then we're going to make a condition to use that, so what we'll do is we'll make a state tree condition, and we'll call this, uh, STC cooldown

01:12:55And the annoying thing about state conditions is that they are read-only blueprints

01:13:02You can't set variables within this, but maps are actually kind of a special thing because you can edit them from a read-only blueprint

01:13:15So we can do our, uh, test receive, uh, condition, and we'll make a variable for our act, and we're going to make that specifically of our type tree character because of the map that we

01:13:22Made on that

01:13:29It's going to be the context variable because we just want to automatically uh provide that in

01:13:37And with that, we can now get our cooldowns, and we can check if we can find a certain cooldown, and this is going to be a variable as well

01:13:48So, cooldown name, we'll just make that an editable field

01:13:54If we can't find any cooldown, that means that we have no cooldown on that name, like we haven't entered that cooldown yet

01:14:01So that's what this bottom pin is, is telling us whether or not it could find that

01:14:07If it could not find that, we just add it uh as a new one

01:14:14So, we add to it our cooldown name, and we're going to be Adding that with the current game time in seconds plus an amount of cooldown time

01:14:20So this is a cooldown that starts from the moment you enter this state

01:14:25From the moment you first check it, if you pass the cool down, it's going to immediately start ticking down

01:14:30It's not a cool down that necessarily will start ticking down from when you exit the state and you have finished a task

01:14:36We can make a task to do that though in a moment, which we will do, but by default, if you're just using this condition, uh, it will only work from entry of the state, or I suppose it will work on exit if you use this condition as an exit

01:14:44Condition for a transition, but that would be kind of weird

01:14:52Anyway, we're going to promote this to a variable, and this will be, uh, the cool down time, which also will be exposed

01:15:01So, if we don't already have it, uh, we add it in, and then we return true

01:15:07If we do already have it, we just want to check, hey, is this less than our game type? And we just add in a branch for that as well, uh, because if it is, that means that the cool down, uh, has been there long enough, and we are allowed to enter this again now

01:15:16So if it is, we just add it again

01:15:25If you add a thing into a map that already exists with that, like key, in this case, the name

01:15:34It will just override it, so we can just use the adding node here, uh, in both scenarios, and that will just update, uh, the time for it

01:15:41Uh, but if this has not, in fact, uh, returned true, so if our cooldown is not less than our game time in seconds, uh, we return false, so we just untick this and we return false

01:15:58So now we have a condition that effectively checks whether or not a certain actor has a certain cooldown, almost in a tag-like system

01:16:05So we can say, instead of doing a waiting task here for chase, we can do it as an entry condition now, and we can say, hey, cool down, we can say the cooldown name is chase and the cool down time

01:16:18Is, I was going to do 15 seconds, but then I mistyped and now it's 14 seconds, so short, which also means that the jump now doesn't have anywhere to go, actually, so maybe that wasn't a great way to do it

01:16:29We can just make the jump go back to a route, that's fine, so we just default transition

01:16:35So now what, what this will do is when it starts chasing me, it adds that value to, uh, that map, and when it tries to chase me again, it will check whether or not the current game time has exceeded that, uh, like threshold time, and if it doesn't, it's just going to troll

01:16:54So now you'll be able to see that he, uh, does his thing, but when I get within A certain range, he uh comes close to me, and then he jumps, and then he waits for a moment, and he'll start doing all this again

01:17:04But he won't start chasing me again until his cooldown of, I think, 15 seconds

01:17:09I changed it anyway

01:17:13Uh, is all up, at which point he will start chasing me again

01:17:18So he now has a cool down on his chasing behavior

01:17:24But what if we want to also make a task where we can say, hey, extend that cool down now, because right now we can only extend the cool down if the cooldown has been passed

01:17:30But maybe we want to be able to have a task that also uh extends the cool down

01:17:34So for instance, on finishing a certain State, we want to extend that cool down

01:17:39Well, that's super easy to do as well

01:17:42So let's do that

01:17:45We can make a task blueprint, uh, task for stage three street base and call that ST set cool down

01:17:49And here, we're just going to copy over a couple of things actually

01:17:53We're going to copy over, uh, the act

01:17:58We're going to copy over the cool down name

01:18:02We're going to copy over the, uh, cool down time that we're going to be adding to it

01:18:06So, we can set this up in a handful of different ways

01:18:09We can set it up to say, hey, reset the cool down, so the cool down will be X amount of seconds from now, or we can set it up to add to the existing

01:18:15Cooldown instead

01:18:23Uh, I think we're just going to make a tick box that will let us decide what we do

01:18:29So, uh, resets cool down with time or something like that

01:18:35So by default, it's going to be adding to it, but if we take this to be true, it will instead uh set the cool down to be whatever we put in here, so that can also make it shorter as a result, so that can be quite interesting

01:18:44Uh, you can set this up to be either on uh exit or on enter

01:18:52I'm going to do this personally on exit because I think that makes the most sense for setting a cool down, but you can do this on enter as well if you wanted to

01:19:00So here, we first and foremost Check, uh, if the cooldown timer, uh, should be reset, or if it should be added

01:19:04And let's give these things a couple of categories

01:19:09So we, uh, give this the category for context for the actor itself, of course

01:19:14And then these two, uh, don't need any categories

01:19:18And with that, we can kind of just copy some stuff over here

01:19:22So, let's just copy over everything, and then we'll delete everything that we don't need

01:19:25How about that? Because we need most of this

01:19:28We still need the actor, uh, cooldowns

01:19:31We need to check whether or not we can find it, because if we cannot find it, no matter what happens, we need to just add it anew

01:19:37So

01:19:44That's actually the first thing, uh, that we do before we even check whether or not we want to reset it, because, um, there's nothing to reset or to add if it doesn't exist yet

01:19:48So if it doesn't exist yet, uh, we add it

01:19:53If it does exist, we check if we want to reset it or if we want to add to it

01:19:58So if you want to reset it, what we do is we also just hook back up to this node

01:20:03We don't really need this one, uh, or this one, because resetting effectively just means getting the current game time and adding to it our current cooldown time and adding to it, uh, the amount of cool down time that we want to do

01:20:11So that's effectively the

01:20:19Same thing as just setting up an entirely new uh value, but what we can do as well, we can use this adding node, hook everything up properly, like the cool down name, and then we want to add a new amount of time to it

01:20:27So from that, we are going to take the binding note that we have here and add to it the cool down time instead

01:20:34So if we're not resetting, that means that surely we must be adding

01:20:41So we go to this one

01:20:45That's everything there is to it

01:20:50We don't need to uh finish task because this is running on uh exit anyway

01:20:58And if you want to be able to like make that variable as well, uh we can call this like run on exit

01:21:06Ideally, maybe make this like an enum instead to make it a little bit more clear, but for now, we'll just make this like run on exit, and then we do enter state as well

01:21:14And we can just hook both of these up to like a, uh, branch like this and check run on exit

01:21:19And if run on exit is true with exit, or is false with enter, we do that, so now it can run on either enter or exit, depending on the value that this variable has

01:21:32I'm going to set the default value for it to true though, and the same thing with reset cool down time

01:21:36I think I'm going to set the default value for that to true, cool down time

01:21:40Uh, don't need a default

01:21:45value

01:21:51So now we have a task that we can add into any state on our behavior tree, uh, that can run on enter or on exit, that will either add to or reset the target time for our cool down as well

01:21:56And that can actually work fairly interestingly because we can say anytime that we enter the uh patrol state or the move to state, because we never actually re-enter the patrol state seemingly

01:22:03So every time we enter the move to state, we can add this task here, which is set cool down

01:22:10Our cooldown name was chase

01:22:17This is case sensitive, so it might be a good idea, uh, to make this into a parameter if you're going to be

01:22:23Referencing it in multiple places, or just copy-paste it, but just making it a parameter is probably easier

01:22:29Now it's the other one to chase

01:22:35Yes, I did actually use the uppercase there, still just copy it over just to be sure, and we can say the cooldown time is actually going to be minus two, and we don't want to reset it, and we don't want to run on exit

01:22:39We want to run on entry

01:22:43So that means anytime it enters the move to state, now it's going to reduce our cooldown time by two seconds

01:22:46Didn't see that coming, did you? But that is entirely possible

01:22:52So this is now a task and a condition that can really work together fairly

01:22:58Well, and they all just work based on these strings, or again, you can use name variables if you prefer

01:23:03The only downside is that it is limited to using this actor context class because we need to directly interface with that map

01:23:16You might be saying, "But you can make like an interface to get that map." Sadly, you cannot

01:23:28If you're using C++, you might be able to, because you can actually get a pointer to that specific map, but if you use an interface function call in Blueprint, it's going to pass it through by value, meaning that it's going to give you a copy of the map, so you can't actually edit the

01:23:38original map through an interface call

01:23:48You need to actually do it, uh, through getting the actual actor and getting the actual cooldown map from that actor, meaning that you do need to, like, effectively do that cast, right? So, you're going to be stuck with having to use, like, this base class, uh, that has that variable on it

01:23:57That's the only real downside to it

01:24:04Just during editing, uh, listening back to this, I wanted to cut in real quick to explain that you still can set this up to use an interface

01:24:10What you would need to do is you would need to move pretty much all the code that we just took from the condition and Or the task and put it in the implementation of the interface on your various different classes that might need to work with these cooldowns and have their own maps

01:24:28And then for the interface function, uh, that is going to be used for the condition, it just will return a boolean variable, whether it's true or false, whether you can succeed or not

01:24:34That way you can still use this on a bunch of different, uh, classes, and you can still make this fairly generic, uh, without them having to share a parent class, which might be an issue for a variety of reasons

01:24:47It would be ideal if you could just have a cooldown

01:24:52Functionality on these things provided by Epic itself, that is a little bit more like flexible, but just about every other method of checking this, uh, doesn't quite work, because if you just, uh, make it check that within the same condition, there's the issue that these conditions are objects in and of themselves, and when, uh, the state is no longer active, those get discarded, and when you reenter the states, it creates new ones

01:25:19Ideally, you would be able to use parameters instead, but setting parameters is a bit of an issue through C++

01:25:24I think it is possible through blueprint

01:25:28It's a little bit iffy because it

01:25:33Seems to work in editor, uh, if you want to set a parameter, uh, but then when you package the game, it causes crashes, so don't do that

01:25:38And we have a similar issue if you wanted to use an evaluator for this, because, uh, if you bind to these in a task that is trying to set stuff in them, it's going to pass them by value, not by reference, so you can't actually edit the original values on these evaluators

01:25:56These are only for getting, you can't set these externally

01:26:01This is one of those things where if you were using C++, it would be trivial to get a pointer reference to these to actually be able to edit them

01:26:05Blueprints makes it a little bit more difficult

01:26:09So, this is the way that I have found that works to set up cooldowns for state trees

01:26:13So, the project has been updated to Unreal 5.5 because I want to show you some things that have been very recently added as of me recording this

01:26:25And the first and foremost important thing is the new selection method that we have

01:26:31So, if we go into a state tree, you might remember me going through the selection behavior of these nodes

01:26:37So they choose what child state to run based on some selection behavior

01:26:42There's a new one, and this one can let you select it based on

01:26:49A utility score, or at random weighted by the utility scores

01:26:54So let's talk about these selection utility scores, because they are added newly in 5.5, and they can really be used to make your state trees a lot more intelligent, a lot more easily

01:27:01Of course, the state tree that we have here is relatively, uh, simple, so there isn't a lot of choosing to do, so most of this is going to be theoretical

01:27:14So how do these selection utilities work? They all have a weight and a couple of different selection methods, or a couple of different tests, is the way you can think of it

01:27:20So, uh, just adjusting the weight doesn't really do

01:27:25anything, because the weight is a multiplier for the score that they have

01:27:34So, by default, they don't have any score

01:27:43So, uh, if I set this to try select by highest utility, and I just set this, uh, to a value of two, for instance, uh, it's not going to do anything, because it's effectively just multiplying zero by two, which is still zero

01:27:49Uh, and if it's a tie between them, it just does them in order

01:27:54It does them in sequence, just like normal, uh, select children in order

01:28:00So, what we need to do is we need to add a constant for now

01:28:06So, if we set this just back to one for the time being, and we set this to one as well, this will now have a Constant value, which is just a literal float value

01:28:13Uh, you can bind this to anything you want, of course, anything that is float or number adjacent

01:28:20Uh, but for now, we just set this to a constant value of one, which means that the waiting node, uh, now has a value of one with a weight of one

01:28:28Uh, the move two node doesn't have anything, so it's going to go into waiting

01:28:36I've set the waiting node up to transition back to root, so it's always going to be skipping over the move two now, and we can see that because it has indeed stopped moving

01:28:43Uh, but it will still chase me, uh, but it doesn't patrol anymore because it's

01:28:50Immediately going from root to waiting, to root to waiting, to root to waiting over and over again, but we can see if we put another constant in here and we also give that a value of one

01:28:56Now they're tight again, which means that it will operate in order and it will have the patrolling functionality again, but if I then go back in and instead of changing this, which is just a zero to one value, we change the weight of this to be two

01:29:14You will see that it goes back to immediately going into weight again because they both have a score of one, but this is getting multiplied by the weight of two, so no longer does it walk all

01:29:20Over the place again

01:29:26Now, that doesn't really do much, um, if it is a static value, because obviously you can just set up your transitions that way

01:29:31This is good when working with dynamic values

01:29:39So, uh, we can do like binding this to a HP percentage, for instance, so that it's less likely to chase us when it's low on HP

01:29:46So, we would, uh, make this root instead of select, uh, try to select children in order, we would make this try to select children in highest, uh, utility, and we would put a utility thing on here that would represent our, uh, enemy's HP on a zero to one scale

01:30:05Now, we can even, uh, use a utility, uh, selection for the distance to our target

01:30:16So in this chase, what we can do, we can maybe make two different types of chases

01:30:28We can make one that runs toward the player and one that runs away from the player with like an environment query, right? So what we would do is we would just add a child state to this and put all of these inside of that child state and call this, um, run to player, or run to target more accurately

01:30:40And then we could add a sibling state to this, and this would be run away, and this could do the running away

01:30:48So when we chase, uh, the player, it doesn't really matter because chasing the player is more like sensing the

01:30:51player

01:30:54The player is nearby

01:30:57Do we run after the player, or do we run away from the player? So we can do that based on selection utility

01:31:00If we have an evaluator here that would have a float value of our HP percentage, so on a 0 to 1 scale, do we have 50% HP? That was 0.5

01:31:08Do we have 10% HP? That would be 0.1, and so on and so forth

01:31:13Well, that is just with uh constant values

01:31:19We can actually interpret values as a float input instead and be a little bit more flexible with them

01:31:25So what we can do is we can use a response curve that takes an input range and that normalizes to 0 to 1

01:31:31So this might be good for a thing like uh Doing things based on distance, because your distance value is going to be in the hundreds or in the thousands of units, uh, but to make them easier to work with, you can say, okay, we're going to, uh, normalize this from, uh, 0 to 3,000, and that's then going to normalize down to a 0 to 1 scale, uh, that you can more easily use in this curve

01:32:00So we can say at zero units, we actually have a value of one, so it is going to be weighted fairly highly

01:32:07It's going to score fairly highly because it is really close to you, which means that it needs to attack or it needs to do something, uh, but add a value of one, which we can do by just

01:32:14Adding another key, curve times one, and then the value will be zero

01:32:20Of course, this is just a linear line

01:32:26You can add in, uh, however many, like, more points you want to make the shapes the way you want, or you can even use a curve asset, like any curve asset that you have made

01:32:33Uh, you can just put in here and it will show up as that curve, which allows you to have a little bit more control over, like, the fall of and the, um, tangents of your points

01:32:44And theoretically, uh, you should be able to even output a value of bigger than one on this

01:32:51I don't think in most situations you really want to do that, uh, but I don't see any reason

01:32:55That you couldn't

01:32:58If you make a curve that goes up to a value of two or three or five, uh, you would just have a bigger value being outputted by this specific test

01:33:02So here, what we could do is we could have like that inverse, uh, linear curve that we had a moment ago

01:33:09So at time, uh, zero, we have the value of one, and then at time one, we have the value of zero

01:33:17It's not quite a linear curve anymore at this point because it has like extensions working for it, but that means that if we have full HP, this is going to return a value of zero, so it's not going to be weighted very highly at all, but if we have almost no HP at all, it's Going to be a lot more, it's going to be valued a lot higher

01:33:42So if we put that test on here, it will run to the player when it's on high HP

01:33:47And if we put an inverse of that on the runaway state, what it will do is it will score higher as your HP lowers, which at some point is going to intersect and is going to make it so that it doesn't run toward the player anymore, but it runs away from the player based on those dynamic inputs

01:34:06Now, of course, to make it a little less predictable and a little less, uh, mechanical, what you can do is instead of doing just by the highest utility, you can select them at random, based on a

01:34:14Weighted utility

01:34:23So that will just turn the utilities instead of a pure selection method of saying this has two and this has one as its score, so we're going to always go with this one

01:34:32What it does is it normalizes those values, and it says, well, this one has twice the value of this one

01:34:40So out of a 100 times that we're running this, this one is going to show up twice as often as this one

01:34:45So that would be a two to one ratio

01:34:50So out of three times that we run this, it's going to do this two times on average

01:34:55Of course, it can very much do it 10 times in a row because that's just how statistics work, and it's going to do

01:35:02This one times out of three on average, and then the last one that we have is an enum input, and this one is actually very, very interesting because we can choose what type of enum we're using

01:35:09The default will be the state tree, uh, any enum, which doesn't really do anything, uh, but we can take any variable, uh, that is an enum on our, uh, available bindings

01:35:23In this case, let's say, uh, we have the autopossess player enum, and we can say, well, when it's autopossessing player zero, we give it a value of one, but when this thing is set to auto possess player one, uh, we give it a value of six or something like that, right, uh, for the

01:35:42Auto-possess, that doesn't make a lot of sense, admittedly, so realistically, you would have your own enum

01:35:49Uh, so we can do something, uh, like just making a quick enum here for that, and let's call this aggression state, just to keep with the example of attacking or running away from the player

01:36:03And we can add an enumerator to this, and we can say, uh, this guy is angry, or this guy is neutral, or this guy is scared, or anything in between

01:36:15You can add as many states to this as you really would like, because again, that's just how enums work

01:36:21Then we can add that to our state tree, uh, character here

01:36:24So we add our, uh, emotional

01:36:28State or something like that

01:36:31We'll call, we'll call it emotion, uh, and we'll call that the aggression state

01:36:35So now that we've added that, we can use that, uh, on here

01:36:38So we have the, um, emotion variable and we can say, well, you're angry, uh, you're going to not run away

01:36:46So if you're angry, you're going to score zero on this because you're going to be confrontational

01:36:54If you are neutral, uh, let's say that we just score this at 0.5, but if you are scared, we're going to score this at, for instance, one

01:37:02And then, of course, run to player would have potentially the exact opposite

01:37:05So we can use a enum input here

01:37:08Look at the

01:37:11Emotion and add three options to that

01:37:14When you're angry, definitely we want to run towards you

01:37:17When we're neutral, uh, we want it to weigh a little bit toward running, uh, to the player

01:37:21So, you can, uh, either just put this at 0.5, so it's a tie, or maybe at .6, so that it outweighs it a little bit

01:37:32If you're doing this just based on how you score, this is a good way to make sure that this is picked before this when you're at neutral, but in this case, putting them both at 0.5 would do that as well because when you, uh, pick them based on a score

01:37:43Again, if scores are tied, what it does is it just executes them in order

01:37:48Or it picks them in order, rather

01:37:53Uh, and yeah, when we're scared, we will set this, uh, to zero

01:37:58Just keep it at where it is, so that would now, when we have some code that runs, uh, this emotion and sets it to its proper value, which, uh, we could just do as an evaluator or a global task on the state tree itself as well, it will now make different decisions based on that, because we can use this selection utility for all that

01:38:15As a little side note, uh, because we're in 5.5 anyway, now we can also now more easily map, uh, vector variables on here

01:38:27So we have this, um, move to state that I made, and this has the move to, uh, non AI, which takes In a move to location, um, in 5.4, which most of the series has been made in, uh, this wasn't available yet, but now when we have a bindable vector parameter anywhere, uh, we can use the get actor location, uh, function for that, which allows us to put in an actor or like bind any actor

01:38:52So we can just move to, for instance, uh, the target location or whatever

01:38:58Of course, we didn't program this task to work with that, so it's like find the way it works

01:39:06Uh, but for things like distance comparing, that can actually be really quite useful because you can now, uh, set up a transition, uh, with a condition for a distance compare

01:39:14You can Just set both of these to get an actor location, and this can just get the actor itself

01:39:23And then this can get the actor target that we created and check if it is within a certain distance

01:39:31So what we made an entire uh condition check for in the previous part, or the part before that, uh now is much easier to do with just the default uh handed tools

01:39:42So that's a nice little update in Unreal 5.5 for state trees uh that you're really going to want to have

01:39:48Most of the project files for this series are still going to be 5.4 before, so it's going to be a little confusing uh for anybody following along project by project

01:39:55Because suddenly you'll have to use Unreal 5.5 for this one

01:40:01I'm sorry about that, but again, this is actively being improved and developed still by Epic, so features are still being added

01:40:07So, while we have an AI that can wander around, and even when we get close enough, uh, chase us, and we've even discussed things to make him more responsive and dynamically responsive with things like utility scoring, uh, we are going to run into an issue at some point, which we haven't really run into yet, but this is going to start to spiral out of the control in size and become quite annoying to manage as this tree

01:40:34keeps growing and growing, and growing, and that as well is, we have pretty generic behavior in this tree so far, don't we? We have a simple patrol functionality that likely a lot of different state trees across a game would be able to use, so are we really going to, like, copy paste this into everywhere, and then when we want to change something, we need to go into every single one of those state trees to update that code? That seems like not a great way to do it

01:40:53The same thing with chasing the player

01:41:12Uh, we can take away a couple of things we did in the last video, but that also seems like maybe we should make that a

01:41:20A little bit more reusable

01:41:27Effectively, what we want is, we want this entire state tree to just be the patrol state and the chase state, which both reuse modularly placeable code

01:41:35So, that's exactly what we're going to do, because I finally want to talk about linked assets

01:41:43I talked about them a little bit in the first video, uh, talked about the, uh, difference between subtrees and linked assets, and how linked assets are effectively just a more organized way to deal with, um, subtrees

01:41:51So, we're going to effectively never use the actual subtree type, just use linked assets

01:41:57So, let's make a couple of assets, uh

01:42:04To link, shall we? Uh, I'm just going to keep the state tree here as the main one, and I'm going to copy it over, and I'm going to call this, uh, patrol, and I'm going to copy it over again, and we're going to call this chase target

01:42:11So if I now open up the patrol state tree, it's going to be the exact same thing

01:42:17We can throw out everything to do with chasing because this is only going to do the patrol routine

01:42:21We don't need this root state anymore either

01:42:26So, we can take this patrol and put it up at the top and get rid of the original route

01:42:31This is only going to be, hey, we're going to patrol, going to move to, we're Going to wait, and this in and of itself loops, which is potentially okay to do because in our state tree itself, we have transitions that can cancel out of the patrol state

01:42:46For the sake of making this video and teaching you something, we're going to change that as well

01:42:54So, first and foremost, we're trying to transition from patrol to chase anymore, which doesn't exist anymore, so we can delete this transition because that transition is going to be handled within the state tree itself

01:43:12And here we just try to select children at order, and we can get rid of all of the selection

01:43:20Utilities that we made in the last video on both of these, and now wait tries to go back to root, which obviously, um, doesn't exist anymore

01:43:26So what we can do is we can either make this go back to the patrol state, and as you can see, by the way, I'm now in 5.5, and this little dropdown menu is a lot more readable

01:43:32It's actually so much improved

01:43:38Uh, but we can go back to patrol, which will make this loop

01:43:44So when we enter the state, uh, in our actual state tree, it will loop until this transition happens, and we go to a different state

01:43:50That is realistically probably what we want to do, uh, but alternatively, what we can do is we Can finish the state tree

01:43:57That's a concept that we haven't really discussed yet this far

01:44:04State trees have this concept of being finished, and if it's just the main state tree that you're running on anything at all, when you finish the state tree, it's just going to actually finish

01:44:17It's going to stop running and it will have done its thing, unlike a behavior tree which you can force to stop, uh, from externally, but they're not really meant, uh, to be ended

01:44:24They're meant to continuously just keep running

01:44:32State trees have built-in functionality to stop, and that mostly comes in useful with these

01:44:37Substate trees, because when a substate tree, or a linked asset as we call them, uh, marks itself as being completed, that is then seen as the completion of the state within the parent state tree

01:44:50So on patrol, after we, uh, finish waiting, instead of transitioning to the patrol base, uh, state again, what we're going to do is we're going to set this tree as having succeeded

01:45:02We can also set it to having failed, and that will then count as specifically the state having either succeeded or failed, which we can use for transition, uh, information as well

01:45:12In this case, we just care about it having completed at all, so it

01:45:16Doesn't really matter

01:45:19So, we're going to mark this as succeeded

01:45:23Now, let's go back into our main state tree, and I'm going to remove effectively everything

01:45:28So, we're going to remove this, and we're going to remove this, and this, so that we only have the patrol state and the chase state left

01:45:34This is all that this main state tree is going to be, and it's going to use the other assets for the actual behaviors, so that when this enemy starts becoming more and more complex, the main stat itself is still nice and readable

01:45:52Of course, the downside to doing this, I should point out, is that where before we had The possibility of going from any state within our patrol sequence to any other state in our entire state tree, that no longer is possible between different assets, of course

01:46:10But since these states only really need to change between patrol as a whole or chase as a whole, we don't need to move from, uh, move to immediately, explicitly, exactly into jumping, which would be attacking if I had an attacking animation

01:46:28So, it's not that big a deal, but there might be reasons that you don't want to section off certain things into their own separate assets because it does make going from specifically one state To specifically another state, sometimes a little bit more difficult to deal with, but it also makes everything a little more reusable, which is usually a good thing

01:46:47So let's change this from just a normal state to being a linked asset, and then the linked asset that we're going to link to this will be the patrol asset

01:46:54You can see that it has the parameters that we set up on this thing because we just copied it over

01:47:00We actually just want to bind this to the parameter for walk distance that we have on the main tree so that it forwards it to still work properly, and that's pretty much everything there is to

01:47:15So let's also uh set up the chase target, which again, we don't need anything to do with the patrol

01:47:21Uh, we can just move chase to be the new route, get rid of the original route, and then after we finish up waiting, we can add a transition to mark this as the tree having succeeded

01:47:33Now, if you remember correctly, this run to target uh uses a move to non-AI

01:47:39If we open it up in the editor, we can see that we have a couple of different situations where the finish task actually finishes as a non-success

01:47:46So in this case, what we could do is if this fails at all, uh, we can set up a transition on state field

01:47:53We set that up as The first thing, we can say that the tree has a whole field so that it doesn't jump, and it doesn't do the waiting, just when it fails, running is going to stop this tree altogether, and it's going to mark that as having failed, just in case whatever is running this tree cares about it having succeeded or failed

01:48:18And of course, in the chase state itself, we have this transition to patrol, which no longer is needed in the sub asset

01:48:25So with that, we can change this all around, and this should work

01:48:32Now we can go into the state tree itself that we're working with on the character, and chase will now, will now also

01:48:36Become a linked asset

01:48:41Of course, that'll be the chase target assets

01:48:45This one doesn't need a walk distance though, so we can actually go back in here real quick and, uh, just remove this as a thing

01:48:49Uh, this thing also doesn't need to get starting location, so we don't need to, uh, like double check that

01:48:53And I don't know if this thing at any point uses the distance to target

01:48:58I think it might, but it probably doesn't

01:49:04Either way, it's probably better to forward tap as a parameter, so we might as well, uh, delete that, too

01:49:09Now, in the patrol state, uh, now that I think about it, actually, uh, we probably don't want to

01:49:15generate, get start location on this, because this will generate a get start location every single time this sub tree runs, meaning that it's going to get its origin position at the position that it is whenever we enter this state

01:49:26We want that origin position to be provided from the start of when the parent tree, this one, the actual state tree that we're running, uh, starts

01:49:36So this will use the get start location

01:49:46This one doesn't need that at all either, and I don't think, like, we're using the distance, uh, to target thing anywhere at all, so we can just get rid of that, but we can add a new parameter, which will be a Uh, vector to the patrolling state, and the name for that will be origin location, something like that

01:49:56And then in the find location task, we can set our origin, uh, to be our parameter origin location

01:50:08Going back into the state tree, now if we go back to patrol, we'll see that we also have this origin location as a parameter now, and we can bind that to our, uh, get start location from our evaluators on our main tree

01:50:19So we're forwarding this information, uh, from our main tree to only the subtrees that require it, and we also really don't need this enter condition for the cooldown anymore on the chase target

01:50:26Now that I think about it

01:50:33So let's remove that as well, because that cool down also, uh, still exists on the state tree, uh, itself, the parent one

01:50:40So you don't need to, uh, double up on that, because that will actually, uh, mess things up, because when it enters this, it's going to set the new cool down, and then when it would enter this, it would check the cool down again and not run and get stuck

01:50:53So, uh, yeah, do make sure that if you're like copying stuff over like this, uh, you remove unneeded transitions, because they can actually like double up and, uh, conflict with each other

01:51:06But now that we have all that, uh, we

01:51:11Effectively, have the exact same thing happening here, uh, that we did before, except that it doesn't wait anymore, because I guess technically when it jumps, it also aborts this movement, so it teases as having failed

01:51:19So I think we just want to get rid of, uh, this

01:51:28But aside from that, like little, uh, quirky difference, we have exactly the same AI now that we did before, and we did a bunch of work to get back to the same point and added nothing new

01:51:36But the upside of all of this is number one, a little bit more readability, as I said before, because the actual state tree on the character now only has two states

01:51:50And If you want to go into those states, those states themselves also only have two or three uh states themselves

01:51:56Matter of fact, um, this can just kind of get rid of the top one as well to make them even easier to deal with

01:52:02And now, if we make a different state tree that has like more other stuff aside from this, or maybe only uses the patrol, uh, and then has some entirely different behavior instead of chase or the other way around, maybe something that only chases and doesn't really need to do a, uh, like idle patrolling or whatever, we can reuse this stuff

01:52:24And then, if we decide that actually we want to make this a A little bit more intelligent, instead of just move to wait, move to wait, we only have to do it in this one place, and then everything that uses this linked asset will instantly reflect that with updated behavior

01:52:33There's one more concept that I really want to talk about about the state trees, and that is the event

01:52:41So you can see in 5.5, uh, there's been a change here as well

01:52:50The entry conditions can require an event to enter

01:52:54We're not going to really look at that too much

01:52:59As a matter of fact, I'm actually going to get rid of this distance to player entry event, or entry condition rather

01:53:03Uh, we're going to just do

01:53:07This is based on normal transitions

01:53:12Just know that these entry conditions can also use events, meaning that when you're trying to enter this, a certain event needs to be happening, but the use case for that is a lot more niche

01:53:16So what are events? Well, events are just messages that you can send to your state tree from other places of your code to tell it to do certain things, or more specifically, to tell it something has happened, and the state tree can then interpret that based on tags to decide whether or not certain states care about it, and if that is even like an active state or whatever, and deal with it

01:53:44As you set it up to

01:53:55So, what we're going to do is, I'm going to go into the state tree, uh, proper

01:54:06So, the thing that has both the patrol and the chase state, and we're going to change this from, instead of just using on tick, transitioning to chase if the distance, uh, to the target is less than a certain amount, which is just a little goofy, because if you sneak up behind them, um, they won't see me, but they will still start chasing me

01:54:12So, what we'll do is, we'll get rid of this

01:54:18And what we'll do, and instead, we're going to do this on event

01:54:23We don't need to really, uh, use this condition anymore, and we can set this to have a

01:54:30required event, so we can make a tag specifically for this

01:54:36This uses the gameplay tag system, and we're going to add a tag named event.scene, because we're going to be using Unreal's built-in perception system for this

01:54:42We can set this just to the gameplay, uh, tags default.ini, add a new tag, and now we have event.scene

01:54:50So whenever this state is active and this state tree gets a event scene event sent to it, this transition will now happen

01:55:02Uh, we can set up a certain payload, uh, to also send through certain information, and it has a bunch of different ones

01:55:08So if I select a rotator, it sends through the XYZ

01:55:13rotation

01:55:18So you can see that you can send through like fairly arbitrary data

01:55:22I don't think, uh, you can easily send through custom structs with this, as far as I have tested, so that's not exactly ideal

01:55:27I'm sure that that's possible to set up within C++ though, but there's, there's a bunch of stuff that you can send through

01:55:33So if you need to send through some information with your events, uh, that is likely possible, uh, but for the most part, I just use these to update that an event has happened, and usually that doesn't really require sending through information necessarily, at which point we can just

01:55:41Transition to something

01:55:50We can set up a priority because you can send multiple events to a component like this

01:55:58If multiple of these transitions were to trigger at the same time, these priorities will say, "Hey, if you're a higher priority than something else that's being triggered in the same instance, go with the thing with your higher priority." We can even delay the transition

01:56:08So, if we, for instance, see the player, uh, we can say, well, wait about a second until you actually start going into the chase, just to give the player a little bit of a head start

01:56:14That kind of stuff

01:56:20We're not going to do

01:56:30That, but you could do that

01:56:40So then on the chase, what we'll do is instead of, uh, checking again the distance to player being bigger than a certain amount, I will just say, "Hey, if you cannot see the player anymore, I'll go back to your patrol." So it'll also be a little bit easier to get rid of a chasing enemy because if I run around a wall, for instance, it'll, uh, just stop seeing me

01:56:50Now, in an ideal world, what you would do is you would still make it move to your last known location, and if it can't pick up seeing you within that little last portion of the chase, then it would go back to patrolling, uh, but for Now, I just want to show you how these events work and not exactly how to, like, set up a more advanced, like more intelligent chase routine

01:57:09So, we're going to ignore that part of it for now

01:57:15We just want to focus on the transition events

01:57:22So, let's set up that event, and we can make a new tag in here, uh, and call that event "unseen." You could technically just use the same tag for this

01:57:29I like sending through a different tag to prevent any confusion, any possible mistakes happening, and having, like, one more tag in your project doesn't really hurt

01:57:35Like, tags are pretty cheap

01:57:42So, and then we just make sure that we Mark this with the proper tag, which, uh, after making the tag, sometimes I forget to actually mark it with that tag, so don't forget to do that

01:57:46And now, when we get an event with unseen, I will go back to patrol

01:57:51So let's send it these events, shall we, because that's quite important

01:57:55And the way we will do that is by making an AI controller class, because I don't think we have one of those yet

01:58:02So let's make an AI controller

01:58:09And admittedly, if we were using an AI, uh, controller state tree, this would be a little bit easier to accomplish, but let's make it so that we can send this through with the character instead

01:58:16Because I still really like the idea of having the state trees predominantly be on the characters themselves, so we make an AI controller, and we'll call this AIC, I'll just call it AICB, AI controller blueprint, on which I'm going to put a perception component on that

01:58:38I'm going to set up the sense of sight, AI site config, and we'll just kind of keep with the default settings, I think

01:58:45So, it has a 90° view cone, lose side radius is 3,500 units, side radius is 3,000 units

01:58:51We can detect enemies, neutrals, and friendlies in this case because we don't really have like an alliance system set up

01:58:58That's another sense that we can set up if we want to, uh, but that's not what this series is about

01:59:05So, we're just going to make it sense everything, and that's pretty much it

01:59:12So, let's go into the event graph

01:59:19With the AI perception selected, we can say on perception updated, which gets you an array of every actor that its perception has been updated with

01:59:25Alternatively, what you can do is just on target perception updated, which will get you a singular actor, which is just a little bit easier to work with because all we need to do is we're going to need to check if that actor is equal to our, uh, get pawn

01:59:43So, That function is called get control pawn, uh, which we'll need to cast to our state tree character, because that has on it a target variable that we made a while ago

01:59:56So we want to check, hey, did the thing that just updated our perception match the thing that was supposed to be looking out for before anybody complains about casting

02:00:02Uh, since this is always going to be running on a state character anyway, this doesn't cost anything, 'cause everything's loaded into memory regardless

02:00:13So, if the thing that just updated our perception is in fact the target that we're supposed to be looking out for, we're going to, uh, Break the stimulus so that we can see the stimulus location

02:00:18This is what you would use if you wanted to set the last known location of your character and make it move to there and like do some more fancy stuff

02:00:31All that we care about at the moment is just whether or not it was successfully sensed, so we add in a branch, and if it was successfully sensed, what we do is we get the state tree component, and we send an event

02:00:45We can split into its tag, its payload, in case you want to send through some information

02:00:52The way you would do that is you can make an instance struct which has a wild card, so you could like set up the

02:00:57Stimulus location and make it send that through in this way

02:01:01Again, I don't really care for that right now, but that's a thing that you could do

02:01:06Uh, if it is successfully sensed, meaning that we're now within its field of view, we're going to send through event scene, and if it was a false, that means that our new updated perception of that actor is that we can no longer see them

02:01:24So that means that we're going to send through an event do unseen instead on the perception being false, which again, you can send through that payload if you want, but I don't care

02:01:30Now we do need to go into our character real quick

02:01:37Because, uh, the AI perception component can only see things that are set up to interact with it

02:01:44So we need a perception stimuli source, and here we need to say we register this as a sense on the site, and I think you want to set auto register as source, uh, to being true, otherwise you need to, I believe, explicitly like turn on the senses

02:01:56So you'll be able to see that it starts chasing me now

02:02:04Uh, but as soon as I go around like a corner where it cannot see me anymore, it's going to start losing interest and stop chasing me, and then it just goes back, uh, to trolling, in much the same way, as long as I like stay behind it

02:02:16There's going to be no chasing happening either because it's actually relying on Unreal's sensing system, which has like a system for field of view and all that kind of stuff

02:02:30So it's a lot more intelligent now, uh, working with this stuff, uh, for perception, and we can use the transition events to make use of that

02:02:37So these transition events can be really, really powerful in all of the ways, and the AI is kind of freaking out because it could see me but had no idea how to reach me

02:02:43So that's kind of funny

02:02:49So that's a quick little addition, uh, to round out everything about state trees

02:02:52There's always more to learn

02:02:54There's always more to do

02:02:57These things can be used for so much more than just AI as well

02:03:00You could use them for dialogue trees

02:03:02You could use them for quest progression system, which I have an entire, like, custom quest system already up on this channel

02:03:08I might redo a quest system and actually also a dialogue system

02:03:13I might redo both of those in the future using strikes because they are such a powerful and flexible tool to use for so many different things

02:03:24They're a little bit less flexible than making your entire custom system from the ground up in all the ways, but they're also a lot more user

02:03:29Friendly and have a lower barrier to entry once you actually start understanding state trees as a whole, and then you can start applying them in every little bit of your game, which is going to make your life a lot easier

02:03:41So, this is going to be it for now for state trees, but don't be surprised when you see more state tree related content popping up on this channel in the future

02:03:48And a very big thank you to all my Patreons

02:03:54You can see them on screen right now

02:04:01If you want to help support the channel or get any of the project files in any of my tutorials, there's a link down below to the Patreon page to support me, or Alternatively, as a YouTube member

02:04:07And of course, an extra massive thank you to my cave digger tier supporters, Sergey Thomas, and my cave student tier supporters, Ou and Earl Montville, Uno.