Large Storm Elemental Integrate

By: Matthew Steinhardt

Implementing the Storm Elemental (Problems)

Once we found a model for the large storm elemental, we had to decide how we were going to implement the following abilities and effects: The elemental has two attacks that it randomly cycles through. The first is a charge-up attack that fires off a beam at the player's location. This attack and be fired from its left or right hand. The second is a lightning cloud effect that shoots lightning bolts down around the player. If the player is hit by any of these lightning effects, they are stunned and take damage.

What started out sounding relatively straight-forward turned into a convoluted nightmare very quickly. I knew I had to make some kind of rudimentary state system to keep track of what the large elemental should be doing at any point. This would need to keep track of whether it is attacking, whether the player is nearby to attack, what attack they want to use, etc. In addition, the model we have does not contain perfect animations for each of the attacks we want to implement. Therefore, I would have to come up with some way to retrofit the available animations into something usable. As I have never worked with animations inside Unreal Engine before, this proved to be a daunting challenge.

Implementing the Storm Elemental (Solutions)

The most straight forward part was coming up with a viable state machine/notification system to handle AI logic. The Large Storm Elemental wasn't complex enough to warrant making a complete state machine via the blackboard system or otherwise. I elected to use simple Enums and Booleans to keep track of state and run logic via animation notifications. How this turned out in practice was an Enum to determine which attack the elemental should perform: Charged Attack or Lightning Storm or None. When the player triggers the attack range collision sphere, The elemental decides which attack to start (if and only if the current attack is not None). Once an attack is decided upon, the proper animation is played via an animation blueprint. If the Charge Attack is chosen, another Enum is set to determine if the attack plays from the left hand or the right hand. The animations contain a notify system that tells the elemental to run the attack function. Based on the set Enums, it carries out the logic of the given attack. In the Charged Attack's case, this creates a Niagara particle beam effect from the selected hand to the target location. A Sphere sweep is performed to see if it collides with the player and to stun/damage accordingly. The Lightning Storm ability spawns a lightning effect with colliders on each strike and does the same checks as the other attack. At the end of every attack, a cooldown period starts a timer that triggers a function which essentially starts the whole attack process over again if the player is still nearby (whenever the player leaves the collider, the player's reference is cleared, thus making it easy to tell if the player is nearby after the attack cooldown is done). 

The animations continue to be troublesome, however. For the Charge Attack I thought to split up one of the animations into two. The first part was severely slowed down to mimic a long wind-up time which would then play the second part of the animation at full speed. Unfortunately, for some reason Unreal insists on making the last keyframe return the model to the position of the first keyframe. This made my implementation extremely janky. In addition, the blending within the animation blueprint that I created was causing issues because of the irregular way in which the model's bones are set up. I ended up forgoing blending the walk/run animation with the attack animation for now to make it at least passable. I still need to work on cleanly cutting up the Charged Attack so that it doesn't abruptly lerp between the two. In addition, the Niagara beam effect I made has a fixed start and end position. This looks okay when the model isn't moving, however it can sometimes look disjointed. This will require further tuning later.