In this individual project, a mech bot was created using behaviour trees. I created a working behaviour tree, converted from a provided FSM solution for transitioning between primary leaf node states (Attack, Roam, Pursue, Flee). I also made a secondary behaviour tree for controlling the NPC weapon systems. This mech showcases realistic player-like behaviour.

The benefits of using a behaviour tree over a FSM is that a behaviour tree is more scalable than a FSM. Instead of having to re-write the FSM if a designer wants to add another state, it is simple enough to attach a leaf node to the behaviour tree to add another state. Furthermore, rather than thinking of the behaviours/actions as a circular machine, behaviours trees allow states to be thought of as branching actions that have specific requirements to be executed.

​

For the roaming behaviour, instead of simply travelling between random patrol points, additional logic was added to the method. When the Mech was within line of sight of the patrol point, they were walking towards, the Mech would check if the patrol point had a resource pack. If the pack was there, the Mech would continue to move towards the patrol point, otherwise, the Mech would choose another random patrol point. This adjusted behaviour means that the Mech is not wasting time going to a patrol point that does not have any resources and this behaviour is more player-like as, to a human, it does not make sense to go to an empty resource area. Furthermore, the Mech only checks if the patrol point has a resource pack if the point is in line of sight. This is more player-like as humans cannot see through walls.

​

For the attacking behaviour, to have the Mech behaviour more player-like, there was a 25% chance that the mech just runs away from combat. Using a random float between 0 and 1, if the float was like than 0.25, the mech’s state would change to flee. This was implemented because as a player, I personally may get scared during combat and just run away even if I am “fine” in terms of health and resources. I wanted to emulate that in this Mech. Furthermore, the Mech’s aim was made less accurate by adding a “wonky” variable to the mechAi movement. So, it would appear that the Mech is not just beelining towards their target, making their movement more player-like. 

​

The pursuing behaviour was left as in the base project, but the fleeing was adjusted. Instead of fleeing to a random patrol point, the Mech’s goal instead was to move out of line of sight as quickly as possible. In doing so, the Mech reduces the amount of time they are in the line of fire from an attacking target. This strategic retreat is done by finding the closest patrol point that is out of sight of the attack target. The method utilises an adjusted LineOfSight method call that determines if a game object is within the mech’s line of sight.

​

Finally, the StatusCheck() method was adjusted to better align with the kind of bot that I have constructed. Throughout this report it has been shown that this mech is cautious and strategic but because of this it may display fear-like behaviours such as running away sooner than necessary. I wanted this to be reflected in the status check as well. The following variables were added to the status check heuristic. If the attackTarget is further away, the mech is more likely to attack. This lends well to a sniper bot. If the attackTarget is below half health, the mech is also more likely to attack it. This means that the mech is more likely to gang up on a target if another bot is attacking it. I also increased the threshold for the bot to choose to attack, if there is an attackTarget to emulate a “fear factor”. Finally, if the mech has already died, they are less likely to attack and conserve resources. But if they
have a high score, they will be more likely to attack to keep on their winning streak.