The Second Boss

By Will Fox

4/14/2023

Hey everyone! 

This week, I put a lot of time into working on the next boss of our game. Now, because I have already had experience with developing a boss already, I didn't run into too much trouble with development for this one. However, I did take a different approach so that I could improve upon the systems that I didn't like in the first boss. For starters, I didn't really like that there was a set order of attacks for the first boss. I think that having the same attacks happen in the same order every single time is a little boring so I wanted to mix them up a little. So, for this boss, I have a random number get selected and the boss will do an attack based on what it is. When and if I have time, I would like to add some weights to this randomly generated number so that the boss will have less of a chance of selecting the same attack he just did.

Now, the other thing about this boss is that it is melee based. If you haven't read my previous blog post, the first boss I made is called the Lich Boss. The Lich uses magical attacks and attacks from afar for the entire time for the most part. But, since boss two is melee, the attacking system needs to be a little different. For starters, I need to make the boss stop its movement whenever it comes into range with the player. If it is charging at them or something, I need to constantly be checking if the boss is within melee range to attack. If not, it should continue chasing after the player. On top of that, a melee boss would be pretty over-powered if it constantly tracked the player - like turning to face them at all times. Here is why. If the boss is attacking you with a melee attack and you dodge to the side to avoid it - well, if the boss is CONSTANTLY tracking you - the boss will simply turn during the attack and hit you anyways. So, to avoid this, I implemented a Boolean that would turn off the "follow player" logic until the end of the attack - or until I wanted it back on. By implementing this logic, it would allow the player to avoid the boss a little more easily.

Another system that I changed about this boss is its "hit" animation. Whenever any enemy gets hit, it should play an animation so that the player knows they hit the enemy. We've been doing this "hit" animation logic through a health manager class. However, this health manager isn't very clean and I think it's beginning to lose its effectiveness due to the amount of casting that needs to be done in the class. For example, we have around 5-6 enemies in our game now. If I hit, lets say, a ghoul. The ghoul will access the health manager class, go into the "find damage animation" function, go through 5-6 different branches to find the correct animation that corresponds to the ghoul, and finally play the animation. At first, this function made sense because all of the enemies took damage via this "health manager," so finding the damage animation here would make sense too. But, in hindsight, it makes no sense. Instead of testing a bunch of casts and checking what kind of enemy is being damaged, I could literally just play the animation inside the enemy itself since we already know who the enemy is. We know the ghoul is a ghoul, so I'll play the "ghoul hit animation" when the ghoul gets hit. So, I'm going to implement this for the boss.

One of the last things that I worked on for this boss is an attack called "rend." This attack starts off with the boss shooting out a projectile that will track down the player. If it hits, the player will not be able to move for 4 seconds while the boss charges up a slam attack. The biggest issue I ran into with this attack, though, was the tracking. At first, I used projectile movement and made the projectile move at 500 units on the x axis. Essentially what this would do is, if the projectile is rotated in a way so that the x axis is facing the player, it should move at 500 units towards the player. But, the issue with this is that the projectile would only move to where the player was when it initially spawned. This means that it doesn't actually home in on the player. My solution to this was rotating the projectile every tick so that it was always facing the player no matter what. In theory, this should have worked. But, due to some unknown functionality in Unreal, this didn't work. The projectile just spawned and moved to where the player was when it spawned initially. Even with the rotation of the projectile being updated every tick. Luckily though, after a little research, I found that there was a built it "homing" function in the projectile movement component. So, followed a tutorial on YouTube and had a homing projectile in no time.

So far, this is about all I've had time to work on. There are still a few more skills for this boss that I would like to implement. But, as of now, I'm pretty happy with how this boss is looking.