The Spline Controlled AI

Summary

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 blockout 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.

Specifications

  • 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

The AI Boss making a drop run, releasing AI minions to keep the player occupied

Getting started

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.

Inspiration for the drop ship was taken form a futuristic movies such as Aliens

The main inspiration for the scenery was taken from dystopian sci-fi such as Bladerunner 2049

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.

Overview of the game area. Four objectives to defend and a fairly open space.

The Boss with important parts in red.

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.

Part of the Phase 1 BT showing the two most common sequences makes the AI create a spline based on the player position and conduct respectively a Pod-Drop or a Strafing run.

Part of the Phase 1 BT: Showing the services to initiate proper responses to searchlight detection and a response to player activity

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.


Isolated Hatch fire sequence. While it opens up the boss to fire it is potentially lethal to the player. A risk-reward sequence.

Isolated Task: The strafing run give the player some breathing room but don’t open up the boss for attacks from the player. But if caught by the spotlight this could quickly change.

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.

Isolated drop Sequence: A range of pods were released based on the Phase and available Pods. Each pod shoot cover fire and spawns a AI Minion

Basic logic behind the Pod management array.

The Blueprint for the Drop Pod. The drop was based on spline movement rather than physics adjusting the spline according to the target location and tangent.

The boss drops pods when traversing the generated spline. Once dropped the Pods provides some covering fire in sweeping bullet arcs towards the player

Spawned AI use operate by navmesh and their own Behaviour trees. In this case the Melee AI tree.

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 Spline Boss Main BT

Spline Movement

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.

A example of the combination spline. Transit spline is generated from Player position and tangents of Hook-up and Target points.

A example of fully generated spline. Player initiate Behavior at break away point. Making the Boss rotate towards the player while following the search spline.

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.