DeckWeaver: Hand animation implementation

For implementation of the hand animations, I actually commissioned from our animator some animations based on our particular needs.

To start, we had a suite of animations for the hands. I implemented those, but something was off; our game involved a lot of moment, and performing actions while moving. It looked more than a little incongruous that the animations for attacking and moving where so separated from each other; blending helped a little, but it still just looked off. Unfortunately, I don’t have footage of how this old system looked; it DID inspire me to make this though:

The animator needed direction on the next animations to make, and the above graphic was a guide to that; the plan was to separate the hands model into hand models, with their animations attached. This would allow me to have one hand focused on showing player movement, and the other player actions.

As such, each hand has a unique state machine and logic system that it uses to determine what it’s final pose will be. The general idea for each hand is shown at the top of the above graphic.

---

Later, it was decided that the current attack animation was a little too repetitive. Thus, I made another guideline graphic for the animator to use – though this one was a little less elaborate:

This one is a lot less pleasant to read – it was made in some of the final moments before release, so let me explain: the general idea was to have a series of attack animations that are made to flow one into the other. As a piece of reference, I also provided Zenyatta, from Overwatch:

Early on in development, it was decided that none of the player’s attacks would use any anticipation in their animations; a decision that even if I disagreed with, I needed to find a solution for. Our attack animation at the time looked like this:

Which was solid and snappy, but a solid half second mismatched with when a projectile would spawn. Which is where Zenyatta’s attack animations come in; each attack is INSTANT, but then afterwards holds its follow through for about a second after, waiting for the next attack command.

There could be no anticipation for the first attack, but this solution allows me to have anticipation for every attack afterwards!

We ended up only doing two attack poses that the attack state machine toggles between – but I am super pleased with the end result. Below are some capture images from while I was implementing and testing this system – thanks for reading!