There are multiple actions that the boss can take, which I had declared them as different action states. These states are: Walk Slam Charge/Rush Left Sweep Right Sweep Idle All these states were declared as values for the BossActionState enumeration type and the current state would be stored in a derived variable in the Boss Blueprint. For the walking I had decided to rely on UE4’s built in navigation system, so all I had to do was to lay down the Navigation Volume on the level and call the appropriate function in the AI controller. The five offensive actions are the Slam, Charge, Left Sweep, and Right Sweep. The offensive actions mainly consists 3 different parts, which are the wind-up, execution, and recovery. To allow myself to control the timing of all 3 parts, I used Animation Montages in the Animation Blueprint for all the animations related to said actions. The first action I worked on was the Slam action, where the Boss would lift its arm, lands it on the area in front of it while causing damage and the retracts it. To create the hitbox to deal damage to the player, I used the BoxTrace function, where I could create a collision box during that frame at a location I specified with the desired size. This function would allow me to adjust the range of the attack and the offset pretty easily. This came handy when the designers wanted to change the Slam from a short range attack to one that could hit the player far away. I used the Animation Notify function in the Animation blueprint, which allows me to call the function to create the hitbox at a specific frame in the animation. The next action I worked on was the Charge, where the Boss would bend down, leap forwards and return to its standing position. The idea of this was to just move the Boss forwards during the period when its leaping using Linear Interpolation, or Lerp. Initially I misunderstood how does the Lerp node work and gave myself some trouble when adjusting the speed and distance of the Charge. I later on learnt to pair Lerp with the Timeline node, which allows me to properly adjust the speed and range of the Charge, and automatically adjust the speed of the leaping animation to match the total time needed for the Charge to complete. I relied on the sweep function that comes Set Actor Location node, but later on due to some problems with collision between the Boss actor and player actor, I ended up reusing the function I made for the Slam to create the hitbox when the Boss is leaping. The next action I worked on was the Sweep action, this action is expected to be a follow up action after the Slam’s execution, and should be capable to sweeping to either the left side or the right side. My first attempt in this was to create a Notify State which would create the hitboxes every frame with a slight variation in angular orientation. I had some problems doing this as the Player character has a high chance of getting hit by multiple hitboxes, there is also an issue where I could not get the math right to create the hitboxes in a steady arc. Later, I learnt that I could attach a collision box to a Scene Component and use that rotate to make a rotating hitbox. When used together with the Timeline node, I managed to create a rotating hitbox that can go both directions at a specified angle. This rotation function would be called during the specific frame of the execution animation using Animation Notifies. To allow the AI controller to use all these actions, I made a function called ChangeActionState in the Boss Blueprint which handles inputs to change the Boss’ current action state. This function would accept an argument of the BossActionState enumeration type, if the parameter’s value is Idle, the Boss’ current action state would then be forced into Idle. If it was other values, the function would then check if the Boss is currently Idle, then check if the action is on cooldown before changing the current boss state to the value of the argument and return true as the output. The function would exit and return false if both the Boss’ current action state and the value of the argument are not Idle.

In this game, the players could not deal damage to the Boss except by hitting the weak spots, which would be revealed in different location based on the different attacks used by the Boss. The weak spots are basically the “core” of the boss, which is its source of life, and is hidden until the boss tries to attack. The "appearing and hiding" of the weak spots needs to look as if the weak points are rotating out of the Boss' body when it attack, and then rotate back into the body after the attack is done. To achieve the rotating effect, I tried to use Lerp together with the Timeline node to change the weak points’ relative rotation over time. However, the end result of the rotation is always not I had desired. I was initially baffled because no matter how I looked at it, it could not have gone wrong, but then I later observed that when I set the pitch, yaw, or roll of the object using the Set Relative Rotation node, the end result of the 3 vectors are different from what it would be when I edited it in the details panel of the editor. After some trial and error I found out that the Set Relative Rotation node does not set the rotation object based on its own axis, but is dependant of its parent object’s axis. With this in mind, I attached the weak point meshes to separate scene components, which are then attached to the bone socket. By adjusting the orientation of the scene components to match my desired rotation and location, I could then rotate the weak point meshes itself which yield the desired result.

The basic AI behaviour of the Boss would be carrying out actions based on the range between the Boss actor and the player actor. So it would be a simple “traffic light” AI where it decides to perform an action when a set condition is met. To accomplish this “traffic light” AI behaviour, I used to Behaviour Tree and Blackboard components to build the AI together with the AI Controller. The Behaviour Tree manages the tasks of the AI, making sure that it flows into one another properly. These tasks would attempt to make the Boss actor perform the actions, if the Boss actor is performing attacking or when the actions were on cooldown, the task would fail and the AI would either attempt the next task or start from the root again.

The AI for this game needs to be capable of identifying the movement patterns of the player when they dodged the Slam action. When it does, the AI would then then try to catch the player using the Sweep as a follow up attack after missing the Slam multiple times. The first thing I had to do is to make sure that the AI knows that the Slam action is successfully carried out. To do so, I declared an event dispatcher in the Boss Blueprint which would be called when the Boss successfullty changes its' action state and bound a function in the AI Controller blueprint to it. When this event is called, the AI Controller would then run a series of function to check for the following: Was the previous action state a Slam attack? If it was, proceed to the next step. Is there a decrease in the player's health? If there is non, it means that the player dodged the Slam attack, proceed to the next step. Identify if the player was on the left or right side of the boss, this tells the AI which direction did the player dodge towards during the previous attack. The goal of this AI was to tell the player that the AI learns from their patterns, but also leaves itself open for the player to outsmart it. I used a reinforcement-based algorithm, but only does negative reinforcement. This allows the AI to catch the player off guard during the first few playthrough, but the player would be able to outsmart it after a while. This algorithm relies on two integer values, the AlternateScore, representing the times the player dodged successfully by alternating their dodge direction and RepeatScore where the player dodged successfully by repeating their dodge direction. After identifying the side the player dodged towards, the AI then compares it with the previous side the player dodged towards, and increases the respective scores by one should they be true. In the Behaviour Tree, when the player actor is in range for the Slam attack, the AI would compare the two integer variables. Should the AlternateScore be higher than the RepeatScore, the AI would opt to Sweep towards the direction opposite of where the player dodged towards previously and vice versa. Should both score be equal, the AI would Sweep based on the the previous direction the player dodged towards. To outsmart the AI, the player would just have to repeat the pattern of dodging the one direction once and the other twice.

When the team went to a local game development hangout with the game, we had some feedback on how we could improve on how the Boss character looks. I was given a suggestion to use the Material Editor to apply shader effects for the Boss mesh. First, I gave the weak point, represented by a red crystal-like object a pulsing glow. To achieve this, I multiplied the colour values of the with the texture of the “core” with a 2 values going back and forth using a sine wave. The resulting value then makes up the emissive color of the material, causing it to go back and forth between bright and dim. Although the “core” does stand out among the textures of the Boss character itself, it’s still round and somewhat looks like a marble instead. To work around this I wanted to make the core a little spiky instead. To do that, I took the Red color channel of the texture and multiplied it with the vertex normal and a value, then assigned it to the world offset position of the material. This creates sharp spikes along across the material, which results in the material looking spiky. The Boss character was supposed to be a paper mache creature, but without any shader effects it looks too flat to be one. To rough up the surface, I multiplied the Red and Green from the normal texture for the Boss mesh with a value before assigning it as the normal of the material, this makes the Boss mesh look bumpy on the surface. As the level is a rainy environment, the artist wishes that the boss could look soaked, I played around with the roughness and specular of the material to achieve a slightly glossy and wet look. Before Material Editing After Material Editing