Author: Jonah McConnell

Okay so in the end, the "concrete sliding" is still present. The enemies still occasionally slide around rather than animate correctly, however, the improvement is there. The tricky part is to do so, I had to modify the animation blueprint that the player was using as well. While the fix was partial, it also in turn partially broke the player.

As you can see there are many animation states, even just for the running portion. This strays a bit from how I'm used to processing things, so I'll be the first to admit I get lost often when working with it. To fix the lack of animation for the enemies, I had to look into why they remained idle despite moving. The answer lay in that the way the enemies accelerate versus the player is very different. I had to remove any code reliant on accelerating or not accelerating and remove some unneeded transitions... At least the latter is what I'd like to say, however, these removed transitions are likely what has broken the player's own animations. When animating, both the player and the enemies will at times stop animating. The most sense I've been able to make of it is when the input is in certain directions, it seems to trigger the bug.

In the future, I will look into fixing this by checking how I calculate the direction the character is moving in, especially because I did some math to make it relative to the facing direction of the player. I feel it is likely related to the animation changing when facing near ordinal directions such as Northeast. 

While this was only a partial success, I did succeed in allowing our enemies to attack the player. By extending the enemy behavior tree, the enemies now attempt to attack in parallel with their chase sequence. 

Getting to this point allowed me to really feel as though I was getting a handle on the utility of behavior trees. While I understood their value in theory, seeing it and experiencing it for myself in practice was of course a different matter entirely. Being able to easily modify what the enemy should be doing at a given time visually proved to be a great asset. I was able to rapidly prototype by keeping the logic in one place, and the actions themselves elsewhere. While only a temporary implementation, I am casting to the enemy blueprint type to perform more sequential, branching logic there.

In the future I hope to better use nodes like the "Wait Blackboard Time" node, to help my behavior trees be more responsive to the environment. One of the things we plan to implement in our game is a combat director to help the hordes of enemies feel like more than mindless zombies. While our enemies may not be intelligent per se, they should be able to group up and time their actions to at the very least feel cohesive. To do this I will need to make a more generic implementation of some of the individual tasks like the attack, as well as plan to use dynamic wait times to have finer control over the course of the behavior tree.