New this week

This I implemented and created a lot of components for the first boss. This includes 5 new animations. A start of a state machine (before an essential detour). Implementing the enemy hitboxes and reworking the attack hitboxes (still in progress).

New animations

I decided to delete the IK controllers on the model’s hands. They were causing unbelievable pain and were barely functional. With this it simplified the keyframes for all animations.

The 5 new animations are a clap and its potential follow up, a drop kick, a spin and an intro summon. I’m still not happy with the intro summon and will rework it later.

I will most likely edit the drop kick animation to be more readable/impactful from the front view.

Below are the 5 animations

State Machines

I started creating the state machine. However, this had to go on pause briefly because the way it flows depends on whether or not a move has hit the player. This led down a small rabbit hole of re-implementing my attack hitbox system as requirements have changed.

The current state machine flow from intro to chasing then into 1 of 2 sub state machines containing attacks. The 3 state machines can be seen below.

As can be seen the close-range attacks don’t combo into their respective follow-ups. This is because the damage hitboxes are not yet implemented and building out the states for that would be untestable.

Hitboxes

I have implemented the hitboxes for the model themselves. These consist of a large box for the torso, capsules for each limb segment and a sphere for the head. The torso contains a separate capsule under the cloak because for some mysterious reason Unity’s built in cloth system doesn’t support box colliders.

Attack hitboxes also got a rework this week. I’ve reworked them to be more flexible and efficient by adding more methods. This way no information must be passed through an event. This also allows attacks to use multiple hitboxes have particle effects and just any custom code really. I have also moved damage and knockback values onto scriptable objects for ease of editing and balancing.

As this rework is still in progress, I need to consider how to handle multiple hitboxes. Whether you should be allowed to be hit by more than one hitbox or whether it should be on a move-by-move basis.

Root motion mystery

Last week I implemented swapping in and out of root motion. However, I failed to consider the mysterious and arcane nature of Unity. The code I implemented works as follows. If the animation state is not using root motion nothing should change. However, for a truly unknown reason adding the OnAnimationMove() method changes how the animation system handles root bones. Simply adding this method to a script causes a root bones rotation to apply to the entire model. This means I’ve had to move the root motion toggle script to a separate script adding more composition.

This is just mysterious because having the method present without any logic shouldn’t change anything, but it is what it is.

What’s next?

Next is to finish the hitbox rework, implement the remaining animations and then start making more animations and ranged attacks.