The Spline Controlled AI
I set out to create this scenario as a testing ground for trying out ideas using a Behaviour Tree controlled AI. The purpose, besides furthering my knowledge of Unreal Engines Behaviour system, is to try out different systems using Spline based movement generating splines in runtime to create a more unpredictable moment pattern.
Setting the focus on the AI system I do not intend to go beyond basic white-box in terms of graphics and design.
The work was conducted as part of my teaching position at The Game Assembly intended to try out scripting concepts for later use in teaching.
Single player Boss fight with flying AI-spawning Boss
Created in 8 weeks
Created in Unreal 4.21
Mostly basic Epic Assets with some concept assets created in Maya
Done as part of my assigned work I had some restrictions mostly related to scope. But as a concept I was free to explore and design the AI myself.
I had been tasked to do do the prototype of the final boss battle of longer free-standing series. Since I wanted to try out some new ideas I decided to prototype a flying boss that had the ability to spawn independent mobs.
Planning the work
A flying AI came with some inherent difficulties mostly attributed to movement. After some testing of ideas I concluded to go with a script generated spline based movement. The boss was to go though three separate phases. I set up the layout of the area to take place on a rooftop of a ruined skyscraper.
Setting up a experimental prototype I did not put much focus on art since most of the focus would be on Behaviour and scripting. But to make it more fun I set up a area and created a quick model in Maya to fit my needs.
Planning the Behaviours
I wanted the main alternating behaviours of the Boss AI to be composed of the following:
Movement that follow generated paths that intersected the player area
While over the area conducting drops of minions or strafing runs
Using the headlight to search for the player and if discovered go to a more aggressive behaviour
If damaged moving to a more active search behaviour
If left alone the boss would eventually destroy it’s objective
I set up two alternating runs, Drop Pods and Machine Gun Strafing with conditions based on a basic state machine. Here I could also keep track on when it was time for the AI to switch over to Reload pod- or Objective attack runs.
Main Blueprint Scripting
In order to get all the activities to work I had to script both the functions of the Boss AI as well as the different Tasks, Decorators and Services that made up the behaviour tree. While some of the scripting mostly entailed getting the AI to create and hook onto the correct spline or to get the math right some, like to drop pod management, was a bit more complex since it meant keeping track on the state of 10 individual pods that could both be destroyed by the player and Launched by the AI.
After looking into a movement system for the boss based on a combination of splines and Navmesh with alternating flight altitude I eventually scrapped it and instead decided to go only with splines. Since I could generate the splines in runtime dependant on the player position I could get a more precise movement when needed and still get it to look like the boss was connected to a rail.
The standard run sequences was, together with the engines linked to the Boss model. By moving parts of the model with blueprints I could implement effects, like rotating the missile hatches exposing the vulnerable underside or make the model easier to read by connecting the engine rotations to the travel speed.
The Drops and Mob spawning
The drop sequence was quite complex but in my opinion a important factor of the scenario. As game element the pods served several purposes:
Adding more elements of gameplay
Adding ground level threats for the player
Giving choices for the player (Attack pods, mobs or boss)
Forcing the player to be mobile and preventing camping
Adding a way to hurt the Boss and non-direct reason to expose weakspot
Scripting-wise the pods meant altering and reusing other scripts and ,in the case of the spawned mobs, entire AIs that I set up before. I go over them more specific in this page: https://www.fredriksjo.com/ai-mobs
The Pods, unlike most of the boss can be destroyed, before, during and after launch. If destroyed prior to Launch it hurts the Boss, initiating a new behaviour. Once detached the they turn into a player choice. Try to shoot them in flight OR leave them and deal with the spawns.
Since every drop run initiates a random drop both in number of pods and what specific pods to be dropped it was imperative to me to keep track on what pods that had been dropped, destroyed and which ones that remained. To solve this I setup a array that always could be called to get the remaining Pods
Once the Pod rack is empty the boss has a special Reload behaviour. Once initiated it flies out of view and a new batch of Pods are generated.
Phases and General management
I set up the behavior with a main tree that essentially switches between the three phases. Each Boss Phase has it’s own sub-tree. The re-usability between the individual tasks in the sub-trees can be re-used but in most cases variables and other adjustment change the outcome of the tree.
The Change between the phases are set by a enum change in the Blackboard keys. After the introduction sequence is done the Task changes the Phase-enum to Phase one. Should the boss go below a certain amount of hit points the Controller would initiate a change to phase two.
The majority of the features in this scenario relied on various kinds of spline movement. In many cases I relied on manipulating existing spline points to create a path that the object could follow (for ex the Missiles, and the Pods) In some I used a combination of adjusting existing splines and creating new splines to “hook up” between the entry and exit points (used in boss runs). For some features I relied only on generated splines (Boss search movement)
In order to get the movement to look smooth and not to create any obscure looking splines I had to work with the entry and exit tangents of the spline points making up the spline. Using the “Get number of spline points” I could keep the date intact even when adding additional points to compensate for the curvature created in the Bézier curves.
Conclusion and Lessons Learned
The project was interesting and provided a much needed insight in the difficulties creating full prototypes using only blueprints. I exposed many of the strengths and weaknesses of splines but also came up with interesting ways to use splines generated in run-time to create smooth movement for a flying AI. Things can always be improved and for this project I would like to experiment on how costly it would be to check the spline path once generated and if it failed make adjustment accordingly. More things could of course also be added, like scripting the boss to float more realistically in the are and bank the curves.