I have never worked with Unreal Engine enemy behavior in depth, and was afraid to try it out as documentation is difficult to get through and I did not know anyone who had experience with AI. There is nothing more terrifying than a blank page…or blueprint that I have no idea what to do with. However, I decided to start with the basics. I’ve used the AI MoveTo tool before, and translating that into the Unreal system of Behavior Trees was not very difficult. Then, I had to make sure the enemy can see the player, so I researched and added a Pawn Sensing component to the enemy, which triggers an event every time a player is seen. When this event happens, the enemy goes from passive to aggressive, chasing after the player and trying to administer a hit.

Once that had been completed, I had to program all of these animations. Our amazing 3D modelers sent me the cutest animations ever, so all I had to do was program the logic that changed the animations when necessary. I created my own Enumeration state to easily track what state the AI is in, and started with Idle and Attack modes to check if the AI was passive or aggressive. This is a built-in Unreal data system that lets me track custom states, like how the basic player character can be Walking, Flying, Crouching, etc.

I felt that the AI moved well, how I intended, but it lacked a lot of style. It would hover and then move, then chase the player if it saw the player, but it had no other behavior. I decided to add a Scanning animation, so that when the enemy is idle it will still be moving, looking for the player, as well as a custom walking animation rather than just hovering and moving. The enemies are designed after office supplies that harm paper, so there is a thumbtack and a pair of scissors. The thumbtack hops along while the scissors open and close to move. 

The next issue was that when the enemies died, they just disappeared. It was very non-immersive, so I had the modelers give me death animations, where the enemy falls onto the ground. I had a lot of difficult implementing this, since I am still a beginning at behavior trees, and the enemies would not stay dead. They would fall to the ground and get up and keep looking for the player, which is not what I wanted. I eventually fixed this by refactoring the behavior tree to stay dead when the enemy is detected dead, rather than changing to other behaviors, as well as have a check before any behavior code runs to see if the enemy is still alive.

Our game is linear/open world, so there has to be several ways to complete puzzles. Therefore, we needed a highly modular objective system. This system essentially was for the level designers, so the goal was simplicity for them. I needed to create easy to use blueprints that required no coding, just a drag and drop system. Shockingly, creating blueprints that allow any amount of keys and doors to be connected to each other was really complicated to do, especially since the player can hold infinite keys for infinite doors. I had to make sure the doors wouldn’t unlock for the wrong keys.

I started by creating an actor component called BP_KeyandDoor that would track all of the keys and doors. I also made a manager blueprint that kept track of the specific keys and doors that each puzzle would require. In addition, all keys and all doors use the same parent class that has that component already added, with the pickup and open events already implemented.

The main issue I ran into was having several of these systems going at the same time. I had to make sure the incorrect keys wouldn’t count for the correct keys when trying to open the door, and I had to make sure the keys would all count no matter the order they were picked up in. I spent a lot of time writing an algorithm that basically checked all keys needed for each door, and subtracted that key from both the player and the door if there was a match. If there were still keys left in the door, that means the player doesn’t have all of the keys and thus the door does not open.

The last issue was making sure that the keys and doors would work for any way of picking up the keys and opening the doors. To do this, I created an event in the parent class that could be called at any time to run all the logic to pick up a key. The blueprint would then call that event whenever necessary, so a key could be picked up by just walking through it, or upon a button press. The same is true for the door blueprint, as sometimes the level designers wanted the door to open upon the last key being picked up, while sometimes they wanted the door to open when the player was near it.