For example, in my previous method, if the enemy was performing an action but the game conditions change, I had to add exit conditions to all the nodes of that action to make sure the AI would react accordingly. Right off the bat, this makes things more manageable, since the behavior tree is the one in charge of deciding which action to perform, and I don't need to really worry about "exit conditions" or "overlapping conditions" for the different actions. For example, the "attack" node calls for the "ATTACK" event in the "actions" FSM. If you don't do this, the behavior tree stops at the last node. To make things easier to manage, you can add the same "Send Event" action to every end node, with different waiting times.Įvery node at the end of the tree has a different action to be called (these actions are found in the "actions" FSM). To make sure the behavior tree is constantly running from the start, I add a "Send Event" action with "RESTART" as the event to be sent. This is a pretty basic state machine that runs every 0.1 seconds (for the most part) and checks if the player is seen or not. The first state machine is the behavior tree. Another thing I need to mention is that, while this AI I am making right now is pretty simple, you should be able to use this basic principle to make more complex AI. In the past I've also written about using PlayMaker to make NPCs (look for my "How to create NPCs with Navigation Meshes and PlayMaker" series), but, after using UE4's AI tools I realized using behavior trees is a lot easier and more organized than using the method I used before, where I had a big state machine that became too hard to maintain.
As you can see below, I have a base behavior tree state machine, an actions state machine and a sight state machine. The first thing I did was go ahead and create a few different state machines for my enemy.