AI programmer
Table of contents
- 7 weeks
- 1
Introduction
In this project I wanted to create a simple AI that resembles the AI found on "Hell knights" in Doom 2016 and Doom Eternal.
This AI is really simple, just running towards you when available and trying to hit you with melee attacks. All the AI in Doom also use a "token system" that allows them to mark their intent on attacking the player and allowing the "token manager" to keep track of how many enemies are allowed to attack the player at once, leaving all other enemies to find other tasks rather than attacking the player.
I wanted to recreate this system as best I could through C++ only. Using Unreals already established system but not doing anything with the behaviour tree in editor. This was more of a self imposed limit to force myself to learn how Unreals behaviour tree system works in the codebase. Link to the project files on GitHub can be found here. This report is assumes that you have previous knowledge on how a behaviour tree works & the concepts inside of one. If not I would recommend reading this link.
Top down result
AI behaviour tree
The behaviour tree of the AI is the foundation of this project. The behaviour tree requires a character class to handle movement and an AI-controller class to manage behaviour & decision making.
Creating the behaviour tree & blackboard entirely C++ is challenging and will be divided into two parts, one for creating the Behaviour tree and one for creating the Blackboard.
Creating the Blackboard
Creating the blackboard is the simplest part, where all you have to do is create a blackboard component class in the controller class and create blackboard keys with a given name and what type of data the keys can store. These keys then need to be added to the blackboard component which they then have to be assigned to a behaviour tree class.
Creating the behaviour tree
Creating the behaviour tree includes a lot more steps than the blackboard so this part will be split up into several smaller chapters:
- Tasks
Each task is its seperate class inheriting from "UBTTaskNode" and overrides the "ExecuteTask" function. Its inside of this function that all the logic for each task is contained.
- Decorators
Decorators are similiar to Tasks in how they are made. They all inherit from "UBTDecorator" and override the "CalculateRawConditionValue" function. Its inside this function where all the logic for the decorator is contained. Based on the result from this function the tasks under it either can run or can't.
- Tree structure
The tree can only traverse through "FBTCompositeChild" nodes. These nodes functions as data-assets that can hold either a composite node (controlling the flow and execution of its children) or a task node (simply runs the assigned task).
These "FBTCompositeChilds" are used as nodes in the tree, containing all necessary information for the nodes contained within to be ran. The tree will always run from the first child of the root node & continue until it reaches a leaf node.
- Running the tree
After having connected all the "FBTCompositeChilds" together I then need to assign the behaviour tree to the controller using the function "RunBehaviourTree".
(Picture only for visual reference, no actual BT asset)
Example task behaviour
Example decorator behaviour
Example task creation
Example decorator creation
Example composite creation & assembling
Director
The director is my enemy manager & token system merged into one entity. I first planned to develop these systems individually and keep them inside the game instance, I quickly realized that for these systems to effectively interact with the enemies in the world, this approach would require complex workarounds and thus decided against it and instead merged them into a seperate character "The Director". As such the director has 2 main systems as of right now:
- The enemy manager
The director holds a reference to each enemy currently spawn and toggles their "aggressive" variable depending on how many enemies there are & how close they are to the player. The closest enemies get priority. As of right now the function to find all the enemies is expensive so the function is only runs on "BeginPlay".
- The token system
The Director also holds tokens. These tokens are used by the AI to launch attacks. If all conditions are met for an AI to be able to attack they will be marked as a token holder and will hold their token until their attack is launched. If there are no more tokens available the other aggressive AI will wait for their turn by keeping distance from you but maintain inside your vision.
Result & Conclusion
Result
The director manages all enemies states and token availability. Whilst the enemies hover in between 3 different "states" those being:
- Not aggressive
Will wander around random points in a set proximity to itself.
- Aggressive & holding token
Will move towards player and attack it when it has reached the player
- Aggressive & not holding token
Will wait a set distance away from player, keeping itself within sight of player but 1000 units away from it.
Conclusion
Working with Unreal’s behavior tree system purely in C++ has been a challenging and often frustrating experience. The main issues have been the difficulty of debugging and the lack of proper documentation for a C++-only workflow. Debugging a single task or node could take hours without clear indicators of what was wrong. At this point, further improving the project would likely require refactoring to allow integration with the editor, both to speed up debugging and to take advantage of existing documentation.
That said, this project has been a valuable learning experience. Adapting to a node-based workflow deepened my understanding of Unreal’s behavior tree system and how I could replicate my own. While the final product didn’t fully meet my initial expectations, I’m proud of what I accomplished despite the limited documentation. However, I wouldn’t recommend this approach. Behavior trees are meant to be easy to assemble, with programmers focusing on decorators and tasks rather than the full structure. Managing everything in C++ made the system more rigid, harder to tweak, and prone to cryptic errors with little debugging support—leading to unnecessary time sinks.