Syncing Hit Collision with Animations

Written by Will Fox

2/16/2023

Hey everyone, Will here!

This week, my team and I worked on a lot for our game Slimegeon, and we're very satisfied with where we are.  Of course, though, we couldn't have gotten here without debugging and problem-solving. So, here is one of the more significant issues I came across.

I am primarily working on the enemy's AI, which means I create the logic behind an enemy's decision, but it also means that I need to take care of their animations. Because of this, I've had to do some research regarding animation notifications, composites, and animation blueprints.  For the most part, animations aren't too difficult to figure out. However, figuring out the timing between animations and turning a collision sphere on and off based on the state of the animation is a little more challenging than I initially thought.

Note: They are a little hard to see, but the collision spheres that this post talks about are the red circles around the Ghoul's hands

The issue began when I attached some collision spheres to the hands of our Ghoul enemy. The spheres are meant to detect when it hits the player character, but ONLY when the Ghoul is attacking. At first, this didn't seem too difficult. And to be frank, it wasn't. All I needed to do was set up a skeleton notification for when the attack animation began and ended. This almost behaved as intended. The "start attack" notification is always triggered. However, if the player runs away while the Ghoul is attacking, the enumerator that the Ghouls state machine runs off of changes and causes the enemy to exit the animation immediately. Thus, the "end attack" notification is never triggered, and the hand collision spheres will stay active. I decided that it might be better to simply make the Ghoul complete its entire attack animation before it continues to chase after the player, so I created a boolean that is set to true once the Ghoul starts attacking and it can only be changed to false once the "end attack" notification is triggered. I then used this boolean in a branch node that led into the Ghouls "chase player" logic. If the boolean was true - which meant that the Ghoul was attacking - the chase logic wouldn't trigger. But, once the attack ends, the Ghoul can chase the player again. But then, another issue emerged, which was a scope issue. The boolean that would decide if the Ghoul could chase the player wasn't accessible in that blueprint. Even with it marked as public and the instance editable, the branch node could not read the boolean. This would be an issue because if the sphere colliders never have the opportunity to become disabled, the Ghoul can one-shot the player. So, obviously this needed fixing.

In an attempt to fix this bug, I thought that maybe putting the boolean on the Ghoul BP itself would allow it to be flipped as necessary. But it still didn't work. This time, the boolean could be accessed, but for some reason, it wouldn't flip back to false. I double and triple-checked the animation event blueprint to make sure the boolean was being changed, and it was. But, for some reason, the event graph inside of the Ghoul itself refused to change. Keep in mind it's only this singular boolean. I honestly had no clue what was happening. 

Seeing that this was not working, I tried one last idea. The enumerator that changed the Ghoul animations was working just as intended, which meant that I could implement this in some way to check if the Ghoul was attacking. Luckily, there is a built-in comparator for enumerators to check what state the enumerator is in.

By checking the state of the enumerator, I could see if the Ghoul was attacking! If equality was true, that meant the Ghoul was in its attacking animation, and the sphere colliders should be turned on. If it was false, the sphere colliders should be off.

It's a little ugly to look at, but this is all the logic I needed. It was such a straightforward solution. 

I'm really happy that I was able to find a fix for this bug, though. Now, the player won't have to worry about their health getting drained by a Ghoul that approaches them - which also means that I upgrade the Ghoul's damage and not have to worry about it doing 20 damage per tick. Instead, it will only do 20 damage only when it is attacking.  Furthermore, to ensure that the player doesn't take multiple ticks of damage in one attack, we will add immunity frames for whenever the slime gets hit. This will ensure a fun combat system that allows the player plenty of opportunity to fight back against monsters and complete the dungeon.