Devlog #3: Wrapping Things Up

Introduction

We are now in the final stretch. This devlog covers my progress throughout weeks 9-12. This was a bit of a hectic period, where I thought I was getting close to finishing, but then would realise I had completely forgotten to implement something. Something I could definitely work on for the next term. 

Progress Update

With our game level finished, I could start working on the environment query system for the AI. It worked well, the enemy would also strafe, rather than just mindlessly attacking over and over. 

With the EQS done, I started working on the other enemy types. This process was quite a hassle. I had to set up the attack montages, blend spaces, and animation blueprints for each enemy type. I then had to create new tasks for them for the attack and also make their own EQS tasks. This was by no means difficult, just time-consuming and tedious. 

I then started working on the death sequence for the AI. What I did was once the health was at 0, it would switch state to ‘pacified’ since our enemies aren’t supposed to die, when we shoot them with the bow we are ‘saving’ them.

In the image above that is the function for switching the state to ‘pacified.’ Once in the pacified state, the text renderer for health is destroyed, as well as the Niagara particle effect that the enemies have to represent the ‘corruption.’ 

Next up, I added a health bar and arrow count to the HUD.

I then made it so that the enemy AI could damage the player, as well as the death montage for the player character and the death screen. 

This is the simple, handy-dandy node for damaging the player after the attack montage is played.

In the player blueprint, I added this function that subtracts the damaged amount from the current health and sets it as the new current health, and an ‘if’ statement after that to determine whether the player is dead, if so, the death montage plays and the death screen pops up. 

Finally, I did the enemy boss AI. A dragon. I used the base enemy behavior tree but added some more branches just to make it a little more interesting and challenging.

The image above is just to show the sheer size of the dragon behavior tree. But I’m sure behavior trees get a lot bigger. This just so happens to be the most complex one I’ve ever made. It’s not even that complex. I gave the dragon a flying state in the animation blueprint and also a custom ‘hover’ task so it would do a little flying now and then in combat.

Challenges

This period was challenging, as I finally started doing things that I hadn’t previously done. For example, my game in the previous term did not require the AI to have an environment query system. Figuring that out was initially tricky, but I eventually got it. 

The dragon AI, however, takes the cake. Firstly, this was my first time adding different states to the state machine within the animation blueprint, as I needed a flying and walking state. Figuring out how to transition between the states was difficult at first. My next problem was that wanted it to switch between flying and walking throughout combat, but this was my first time working with any flying AI and I struggled. I tried a few different approaches, like giving it projectile movement. But this just made it to be in a constant state of flying. But whatever approach I went with, it all ended at the same conclusion, the nav mesh bounds and my patrol and attack tasks in the behavior tree would not allow movement in three dimensions. After a little research, I discovered that using a nav modifier volume could be the answer to my problems. But at this point, we were a day or two away from the date we had agreed to finish up the game and start testing. Alas, I had to take a much more simple approach. I used a ‘launch character’ node and just changed the launch velocity in the Z access, in the dragon blueprint and called it in the behavior tree. Every 20 seconds, the dragon will just shoot up vertically and hover for 15 seconds or so.

Upcoming Goals

• Submit