As mentioned before, part of our team's new plan for the game's vertical slice included a final boss fight to cap things off. We had decided on a large ice-golem that would function as a guardian of the Ice Crystal. Since I had been responsible for the rest of the game's enemy AI, I was given the task of designing and programming this encounter.
Finding the core design for the fight
When I began work on the golem boss, I wasn't actually sure how I wanted the fight to go. What finally inspired the idea I went with, was when testing the scale of the golem in VR, I found that the player would mostly only be able to swing at its lower legs. This gave me the idea for a fight design where the player would attack each leg individually, until both had their health depleted. Then the golem would fall or move to the side, where the player has time to attack its head. After a while, the golem's legs would regain their health, and the player would switch back to attacking them.
When I had decided on this, I started work on implementing this general flow of the fight before any of the golem's actual attacks, since it was very different to anything I'd worked on for AI before.
Making the Health component system earlier on in development turned out to be extremely helpful here, since each leg would need its own health in addition to the golem's normal health. All I had to do was add three Health components in the actor, which could each be connected to their own Health-bar widget.
A detail I wanted to include was having the red damage flash on the golem be isolated to the area that was being hit. To do this I ended up having to export the model and create an additional material slot for each leg as well as the head. Each one needed their own timeline component to control the effect, which would be played depending on the collider that was hit.
I also had to mess about a lot with the Golem's animation blueprint, for a few different reasons. The first was getting a pose that worked for the Golem holding on to the side platforms of the arena. There weren't any existing animations with the asset pack that could be easily edited to create this kind of pose, with the closest being one where the Golem was crouching too low.
I ended up using a "layered blend node" to allow this animation to only affect the Golem's upper body, while letting his legs animate as normal. This way he could enter this pose and walk naturally over to the sides without just sliding across the ground.
In addition, I used another layered blend node to play a hit-reaction montage that would only affect the Golem's head.
With the animations and hit reactions set up properly, actually implementing the basic behaviour for the general flow of the fight wasn't too difficult. I ended up using the same 'Stagger' mechanic that was created for the Orcs, as the timer for the player to attack the Golem's head during.
One small adjustment I made to the stagger system, was to allow for the timer to be paused. The reason for this was that, since the Golem can be at any part of the arena when he begins moving to one of the sides, the time taken for him to reach his destination can vary. Because of this, at long distances, more of the stagger timer would have been depleted by the time the player can attack him. So to solve this, I have the Stagger timer remain paused until the Golem first reaches one of the sides.
I recorded a video showing off this main loop of the fight in action:
Designing the attacks
Close-range Attacks
The first attacks I came up with tended to revolve around forcing the player to move away from the boss' legs at times, or at least making them approach from a different angle. I decided on two close-range attacks for this, a frontal 'cleave' attack, and a circular area smash. To make the circle smash more interesting, I added advancing ice walls at cardinal directions, forcing the player to more carefully make their way back to the boss' legs.
At certain times the boss will also alternate the direction of the walls to inter-cardinal directions, allowing the attack to be used twice in succession to create a more difficult set of obstacles. This attack in particular ended up being quite intense when paired with other mechanics I would add later, so I tried to make sure that the boss wouldn't use it too frequently.
Just like with the Orc AI's attacks, I tried to make sure both of these attacks were very clear and well-telegraphed to the player. I used Anim Montages to slow down the wind-up sections of both animations, and in this case tried to give even more time to the player due to the scale of the boss.
Even with this, it was still often hard to notice that the boss was preparing an attack when up-close, as most of what was in view was just the Golem's legs. To better convey to the player when an attack was incoming, I would need to have more of a visual indicator at floor-level.
Inspired by one of my favourite games, Final Fantasy XIV, I decided to create a decal effect to visualize the affected area of the upcoming melee attack. I based the look of these markers off of the common 'Area Of Effect' markers in the game, since it was both a relatively simple effect and would also stand out against the blue colour-scheme of the Golem's arena.
Ice Rock & Pools
Since the player has the option of using magic to attack from a distance, I thought the boss needed some ranged attacks as well. I had some help here from Luke, who started work on one of the projectiles the boss would throw. He also helped with an expanding floor puddle, which we decided to have spawn from where the projectile landed. The idea here was that, since the arena was quite large, we thought it would be interesting for the player if their area for movement became more limited as the fight progressed.
Ice Shards
The second projectile would be more basic, a series of ice shards that would fire from above the boss' head towards the player's position. These basically just keep the player moving, but they also have the option of blocking them with the magic shield, or shooting them with their own fire magic.
Just like with the boss' melee attacks, it was often hard to notice the shards had been spawned when relatively close to the boss, as they were usually completely above the player's vision.
I ended up adding a beam-particle effect to each ice shard projectile, aiming from the front towards their target direction. I also had the beam increase its length based on the player's distance to each shard, which helped keep its visibility consistent. I think this has the effect of not only helping the player to notice the shards in the first place, but to more quickly understand that they are aiming towards their position.
Long Jump
Another thing I noticed during my own playtests, was that it would often take a relatively long time for the boss to reach the player from long distances. Because of this, the player could quite easily kite the boss around the arena, attacking with their magic and waiting for their mana to recharge to continue.
I wouldn't normally be against alternate strategies like this for fighting the boss, but in this case it made the fight significantly less engaging. So, to address this I developed a long-jump ability for the boss to quickly close large distances.
During testing for this mechanic, often the Golem would get stuck mid-jump by one of the arena's pillars. I originally considered just removing them, but having recently worked with Unreal's destructible mesh system for the game's breakable item crates, I realized I could have the Golem destroy them instead. Also it just generally makes the fight a lot cooler if it happens.
Falling Icicle
One last mechanic I ended up adding to the fight was a very situational attack that made use of knockback. While the player is intended it use the upper platforms to attack the Golem's head at certain parts of the fight, staying up there afterwards meant they could largely avoid the majority of the Golem's attacks.
I scripted in a behaviour for the Golem specifically for this situation, so he would default to repeatedly firing ice shards at the player if they remained out of reach like this. On its own though, this wasn't enough to full deter the player. I decided I would need an attack or hazard to properly force the player off the platform entirely.
The idea I settled on for this was a massive icicle the Golem would spawn above the platform, which after falling would create a large knockback force, pushing the player off of the platform if they were still on it. If the player was especially close, it would also deal a large amount of damage.
I didn't want the attack to trigger instantly if the player walked up onto one of the platforms, since the behaviour I wanted to deter was only staying on the platform for prolonged periods of time. I set up the Golem's behaviour tree to first attack with his regular ice shards at least twice, before spawning the icicle.
Since the icicle was spawning far above the player's head and vision, and potentially behind them, I decided to make use of the telegraph decals from the boss' melee attacks again. This time I did end up creating an additional effect, a ring that pulses outward from the attack marker itself. The intention of this was to convey the incoming knockback effect, suggesting that there would be a force beyond just the radius of the attack itself. I can't tell how effectively it gets the message across, but at the very least the knockback effect isn't too punishing if the player gets hit by it anyway.
Smaller changes / adjustments
Adding knockback to the melee attacks
One last element I added to the melee attacks was, depending on the player's proximity to them, a knockback effect. In the case of the frontal cleave attack, the player would only be pushed back if they collided with the attack hitbox itself. With the circular attack though, the player could avoid being damaged by the attack entirely and be affected by the knockback if they were within a certain radius.
The intention here was to both create more impact on the attack, but more importantly to push the player out into the boss' mid-ranged attack radius. This way, the ranged attacks are brought into the fight more frequently and more naturally.
Adding Jump Pads
As I playtested the fight, I found that it would take quite a long time for the player to walk up the stairs to attack the golem's head. Due to the nature of the mechanic, the longer the player takes to get to the top of this platform, the less time they would have to deal damage to the golem.
To some degree, I think having this timed aspect makes this part of the fight more engaging and gives room for improvement and mastery. However, the amount of time it took to climb the stairs was generally frustrating, and almost always lead to a significant loss in time no matter how fast the player was.
So to give players a quicker option, I had a set of jump pads around each platform spawn in only during this phase of the fight, and disappear afterwards.
Arena Layout Changes
The arena the fight takes place in was designed along with the rest of the temple by Luke, and for the most part I left it untouched. The only part I ended up making changes to was the staircase that would lead up to the Ice Crystal. Originally, the stairs simply faced towards the back wall of the room, but since I wanted the player to be facing the golem when picking up the crystal, I had to rework it.
Now two sets of stairs curve around from the front, leading to a pedestal that faces the centre of the room.
Phase Differences
By the time all of the main mechanics for the boss had been implemented, I started to feel that the intensity would be a bit too much to at once for players, especially when comparing the relatively low difficulty of the rest of the game up to this point. I thought that the fight should probably have more of a build-up in intensity, so within the Golem's blueprints I set up some variables to create a distinction for different 'phases' of the fight.
The first phase would last until the player completes one 'loop' of the fight, destroying the golem's legs and then traversing up the stairs to attack its head. During this phase, the golem only fires 3 ice shards compared to the usual 5, and has a longer delay before moving on to the next attack afterwards. He also has a longer delay between throwing ice rocks, and will only have a maximum of 3 concurrent flood circles in the arena at once. Generally, a lot of other attacks feature longer delays as well, to give the player more time to process them and learn.
Once the golem returns to the centre of the room and its legs regain their health, the fight enters the second phase. In this the Golem generally has less delays between attacks, and returns to using the original amount of ice shards, pools etc.
The Final Version
Without a doubt, this is the most complex AI I have worked on so far. In the process of developing it, I feel like I've become far more familiar with using systems like Unreal's behaviour tree, and I can already see ways I could improve or simplify previous AI I had made with it.
You can see all of the boss' mechanics shown off in this video:
I worked on the Golem over the course of about a week, and for what I was able to accomplish in that time I'm pretty happy. There's a lot I would've liked to have had a chance to polish and refine more if I wasn't under such pressure for time, but it is what it is.
I received a lot of feedback and advice from the rest of the team while the fight was in development, and it helped inspire many of the mechanics included. I'd have loved to have playtested the fight with people outside of the team itself too, to find more ways it could be improved.
Something I'm a bit torn on is the regular use of player knockback, as while I think it helps make the fight more interesting and dynamic, and also solves some issues mentioned previously (player staying out of reach on the raised platforms), I do worry that for some it might cause discomfort through motion-sickness.
I’ve tried my best to have almost all knockback effects be avoidable, but it does take some pre-existing knowledge of the fight to avoid all of it. Most players will be affected a few times at minimum by the knockback, which isn’t ideal for those prone to motion-sickness.
If the mechanic’s inclusion had been planned earlier in development, a better solution might’ve been to provide an option to toggle the effect on or off in the game’s settings. It likely would have meant coming up with alternate solutions to certain issues with the fight, but I think it would’ve been worth it to provide a better user experience.
Comments