TowerJam 005 Final entry and AI systems
2016/02/23 8:13:11 AM
TowerJam 2016 is complete.
At the time I decided to do the jam my schedule was a lot more free . Unfortunately life happened, my workload increased and I had a bout with the worst sickness I recall every having in my lifetime. I could have easily given up and not submitted to the jam but I decided instead to massively scope down to get something complete and submitted. I consider this a big victory for myself.
It’s submitted and available on GameJolt here http://gamejolt.com/dashboard/games/127031
The game is not particularly fun, in fact I would recommend watching a youtube video of the game being played rather than downloading and playing the game. In fact you can do that right here!
Here’s some screenshots of the final game.
One of the development goals for this jam was to really dig into the aspects of the Unreal engine I’m unfamiliar with. This includes but is not limited to :
I can now say I’m far more familiar with these systems. I’m so glad I dived into AI and character animation state machines because I previously feared working with them due to unfamiliarity with those types of systems but now that I understand them I feel I’m really able to use them effectively now. In fact I’m now wondering why I was so fearful of learning them in the first place.
In fact I think after this project, future projects in the Unreal engine will be more about making the game rather than spending most of my time learning how to do something in the engine itself. Unreal has a pretty steep learning curve if you want a holistic education but it’s well worth the time. I’ve used other engines in the past where getting something functional is quite easy but this comes at the cost of a project being tough to maintain when it starts to grow in size. In some cases the issues at scale are so bad that ultimately not using an engine would have actually been less time consuming. Unreal seems to handle this well and the dearth of large scale games that have already been released on the engine over the past decade is further proof it’s a capable engine.
The final bits of work I had to do to get my game complete was to implement an enemy. This means I had to learn how AI works in Unreal. Lucklily from a conceptual standpoint the methods Unreal uses to implement AI are very standard in both the game and AI world. I’d been exposed to the concept of blackboards in previous non-game related jobs I’ve had and behavior trees I’ve seen used in other engines I’ve worked with. That said I still had to learn how to use them in the context of Unreal.
Now I’m far from a professional AI programmer so take my opinion with a grain of salt but I think Unreal has done a very good job implementing tooling for AI via their blackboard and behavior tree editors.
A blackboard is essentially a set of key/value pairs where the value is a variant. In some implementations I’ve used the type of value is unknown so you have to remember what the type is and apply appropriate casts when getting and setting values from the blackboard.
Here’s what a blackboard looks like. As you can see it’s just a group of data that we wish to track. Unlike other blackboards I’ve used I can deduce the type of a value to some degree.
In Unreal implementing a blackboard was dead simple. I merely define the data that I’m interested in tracking and then periodically update the data in my enemy controller blueprint. From there I bind a blackboard to a behavior tree and use the data in the blackboard to make decisions in the behavior tree.
Here’s the relevant section of my controller where I update and set values in my blackboard. What I’m doing here is updating the “Target” value every update along the bottom line of execution.
The behavior tree editor was easy enough to use after I got past some roadblocks. I have to admit for a few hours I was quite stuck. This is partially due to some lacking documentation and partially due to my inexperience with the editor. My main issue was I wasn’t able to determine how to setup various conditional tests in a behavior tree node. It was only after looking around the unreal forums at screenshots of other peoples trees that I realized a tree node can be modified with decorators to execute the conditional logic to determine whether a node should be traversed or not. For instance I would have a node that tells the enemy to follow a target if they are within range of said target.
The other gotcha for the behavior tree is that task nodes such as an “approach target” task are only visible to be added to the tree if the appropriate type exists in the accompanying blackboard. So for the “approach target” node to show up I need an actor reference node in my blackboard. This makes sense but it was initially confusing to me as I was merely looking for the existence of the task when playing with the editor. Now that I know this restriction I’ll make sure next time I want to look for a pre-defined task that I have what I believe to be the necessary data already in my blackboard.
Here is what my enemy behavior tree looked at the end of the project. The decorator value for determining whether or not the enemy should approach is a blackboard value set from the controller blueprint. I suspect I could have gotten rid of that bool and replaced on a validity check to the target actor reference. I will definitely look into doing that in the future (the less state the better).
You can learn more about blackboard and behavior trees here :