Hello readers!

Welcome to this tiny section in the project I like to call - The Thinking Zone. Throughout the project, I'm going to come across areas and decisions that need some thought put into it, given its size or the procedure to implement it would disrupt a part of the system. If I state my opinions on the problem (maybe get some comments too!) and see it on paper rather than in my head, it could pave the way for a more effective and fun solution.

What’s this week's question? It's Behaviour trees! I understand that people from multiple backgrounds think of trees with attitude when you walk past them. However, this is not the case. Concepts will be explained so that everyone is on the same level.

The guards and their brains

Before we get into this, we need to take a little tour around AI in the game. AI, or Artificial Intelligence, is the concept of the computer making decisions that a typical character or real-life person would make in that situation. In the game, AI is used for the two guards who are standing and walking. They have several rules and constraints they have to follow to create the effect of the guards having some brain cells. For example, a guard's suspicion will only rise if the player is near or a treasure is stolen, which is done at different levels.

While I stated the rules and constraints, there needs to be some structure to house it all and to differ between states, like guarding and chasing. This is where Finite State Machines or FSM are introduced. FSMs are design patterns used to change how something works when certain conditions are met. In this instance, if the suspicion level is too high, then the current state that the guard is in will move to something more severe and start to catch the criminal.

Finite State Machine: this shows the states and conditions of switching between different guard modes.

Phew! I think that takes care of AI, the guards and FSM. Now, the trees at hand.

Trees with attitude

While FSMs have been used for a long time, a new structure has sprung up and created a unique perspective on how behaviours should be read. Welcome to the Behaviour tree. The structure of the tree describes how the AI will analyse conditions, make a judgement on when and how these will affect the guard, and the actions that will take place if successful or failed. While there is tons of stuff about trees, I'm going to simplify the situation. Behaviour trees have 4 tasks that can be interacted with: Conditions, Composites, Actions, and Decorators:

Conditions are just bool conditions; they'll return a true or false based on whatever rule you have for it. 

Composites are used to get an overall result from sub-tasks by going through them in various ways. They mainly come in two flavours: Selectors and Sequences. Selectors will go through the order of sub-tasks until it succeeds, causing the rest of the sub-tasks not to execute or fail when all tasks return failure. Consider it like an OR operation; once it knows one is true then there's no point in checking the rest. Sequences, on the other hand, will execute all sub-tasks in order unless one of them returns failure, causing the rest of the sub-tasks not to execute or succeed when all tasks return success. Imagine it as an AND operation; everything has to be true to pass.

Actions are the results of all these comparisons and checks. They interact outside of the behaviour tree to do the actions we want it to, like walking to the player or throwing something to stop them.

Decorators are very neat in a certain way. Decorators are design patterns used to wrap objects with behaviours without affecting the original object. If that was a mess of an explanation, consider this: You have a wall in your house. Its properties are to block air, not allow you to see through it and give you some privacy for once... but it's a dull colour. If we painted the wall, the original properties of the wall are still there and even the colour underneath it, but that coat of paint causes our eyes to see a beautiful wall. 

How the decorator's design would be used for a real-life wall

Now, let's snap back to behaviour trees. The easiest Decorator you can make is an inverse. Any output from a condition or composite will be flipped when it passes through this (true -> false, false -> true), and that's it. This opens a big field of what can be done to tasks and conditions to create unique designs.

When you apply all of these together, you'll create a behaviour tree! BIG PHEW! Both FSMs and behaviour trees allow multiple conditions and actions to create interesting and complex behaviours. But now we move on to the problem.

A behaviour tree graph showing the states and conditions of switching between different guard modes.

To put it simply: Should the current FSM solution be swapped with one using Behaviour trees? What grounds are there to stand on each type? Well, there's a couple and we'll discuss them.

Comparing each structure... to the best of my knowledge

Performance:

The performance between the two is similar; They won't execute additional checks or actions if something fails based on their rules. The size is also not worth mentioning as they can be massive or tiny based on what they're used for.

Ease of use (useability):

How easy it is to use, modify and potentially create new behaviours for new enemies? For FSM, this is a bit tricky. The furthest you can do for this is by controlling which states goes by specific conditions. However, the exact rules in the states are more entangled with each other. You could separate it, but it would be pretty tricky to make it flexible without writing the code yourself.

For behaviour trees, this is a different story. Of course, tasks and decorators would have to be coded for a specific enemy (A guard would be coded differently to a security camera as an example). But because the tasks themselves are modularised, it's very simple to add, remove and modify trees to create new behaviours without touching the code once. The only concern is that the tree must obviously know what it's talking about. If there is a task to cycle a specific list in the guard like waypoints, then the guard must understand that it’s talking about that. 

Coding the structure:

while the FSM system has already been coded, I can say that the process of making is simple enough. With an enum/pointer to state the... state, you can just code whatever actions and conditions you want while ensuring everything is connected correctly. It should be simple but don’t bet on me!

However, while behaviour trees are easy in the long run, setting it all up while ensuring its flexibility for each task is not relatively easy. Another thing to consider is a graph editor. In C++, IMGUI is very, very good to have. In Unity, there are paid solutions, but using an open-source approach like xNode is better for both worlds. You could create your own, but be prepared to have time and attack it with many human errors.

Other factors could make a dent in the debate, but these are typically the main reasons to choose either. But the thing is that both FSM and Behaviour trees are useful for their reasons. FSM are more state-like like a robot, while behaviour trees are used for complex lists or instructions of tasks to complete (like checking if everything is switched off when you leave the house).

Conclusion:

Okay, that took a long while, but I got sidetracked and interested in these haha! Hopefully, this post will explain FSMs and Behaviour trees and when to consider one or the other. My conclusion to this thought is that having behaviour trees would be better for human-like guards than FSM, but this is speculation.

I hope you enjoy your morning/day/night and see you in the next post, which is... at some point!

(As this is my first post, I hope it’s readable lol. I need to focus on explaining things and creating a flow of understanding from beginning to end, especially about AI. Any help or advice would be greatly appreciated! Thank you again for checking it out!)