We thought it might be insightful for you guys to be able to read a bit more about the challenges we’ve faced in completely overhauling our animation system since the success of our Kickstarter. As we mentioned in that pitch, animation is one of the key challenges for the game, and we feel we need high quality character animation to really make the experience work. So that’s what we’ve been doing. However, it was not without complications.
During the time where we were working on the initial prototypes for Sir, we were lucky enough to get Frogames‘ Christophe Canon to produce some great character art and an early model for the main enemy NPC, the Hunter. At this point we didn’t have the resources or time to commission a full animation set for this character so we looked around for alternative quick solutions – something that Unity has in abundance.
IK And Smart Locomotion
Rune Johansen’s dynamic locomotion system for Unity was an obvious choice, because it does so much without us having to code very much into the game.
Rune developed it for his Masters thesis and it’s a really smart piece of coding. It’s essentially a procedural animation blending system with foot inverse kinematics, or “IK”. This means that characters to which it is applied will walk realistically, placing their feet sensible on the terrain they traverse. We implemented it with a series of animations from Mixamo.com (an autorigging service that applies generic animations to any humanoid model).
Once we had our initial Hunter model and a set of animations we could use Rune’s system to blend them together. Rune explains how this works better than we can:
“The system uses a set of example motions primarily in the form of keyframed or motion-captured walk and run cycles. The system automatically analyzes each motion at design-time and extracts parameters such as impact and lift-off times for each foot as well as overall velocity. At runtime the system first blends the motions according to the current velocity and rotational velocity of the character, it then adjusts the movements of the bones in the legs by means of inverse kinematics to ensure that the feet step correctly on the ground.”
So for an attacking stance you might have the following animations (walk forwards, run forwards, strafe left, strafe right, walk backwards etc.) Rune’s code examines each of these animations and then can pace and crossfade the animations dynamically to match the characters movement. The system is also capable of aligning the characters feet to the surface between them and then cascading the bone changes up the transform chain (IK).
All of these features require some setting up and tweaking but can result in a genuinely dynamic and adaptable animation system. The net result is a character whose feet and legs remain solidly and realistically rooted the ground, bending and blending procedurally to create really believable connection to the floor, regardless of changes in movement vector. Of course the underlying movement is not Root-motion based (where the distance travelled in each animation loop is dictated by the animation loop itself), but constantly variable. The only disadvantage to this system is that it is (understandably) very complex and can be a significant performance hit if you intend to run multiple characters – which for Sir was a big problem…
Mecanim
When Unity4 introduced their Mecanim animation solution we were excited to try out the new system, hoping it would provide us with a similar system to what we had enjoyed with Rune’s work, but with less overhead. However it took quite a while to readjust our models, animations, and code to get a satisfying result.
Mecanim provides a “blend tree” system where animations can be crossfaded in realtime based on script-sent input values. For instance this could involve defining a series of blend states to mix between a walk and a run animation based on an passed speed value. This area of functionality is similar to the original blending functionality of the locomotion system we used before – in fact it offers far greater control of the process – but it involves more manual setup via the Mecanim ‘Animator’ tool. The Animator essentially allows you to minutely build and fine tune blend trees for your character’s animation. Where before Rune’s loco system did this on the fly, it was now down to us to rebuild the rules governing what anims to play with what blends at what time. No small task!
To Root or not to Root
Most Mecanim demonstrations use root motion based movement because blending animations generally works best when the animations are mixed at specific loop points (i.e. moving from a walk to a run works best when the ending of the first animation has the character’s feet in the same position as the start of the run). Root motion approaches often imply that once a character has begun a specific animation they can’t react until it has reached a convenient loop point (an example is in many games where an enemy will continue reloading even if staying in that pose exposes them to a rain of bullets). Our NPCs operate in a procedurally generated world and function much better if they can stop and alter their motion and behaviour mid cycle where necessary. So instead of converting all our code to work with root motion we decided to try and implement a mix of Rune’s procedural system and the new Mecanim blend trees.
As a result, each character in Sir has a script that tracks the velocity, turn speed, strafe speed, heading and other motion values. These values are then sent to whatever current Mecanim layer we have activated on the NPC (we have a layer for each behaviour; attacking, fleeing, hunting, searching, roaming etc.). The blend trees in that layer then resolve the final animation mix that is appropriate for the characters current behaviour. This can result in a few rare hiccups where an animation crossfade happens at a non-ideal cycle point, but with careful setup of the blend trees and clever animation design such instances can be minimised.
This approach also gets tricky when a character has the potential to execute a wide range of movements. It’s convenient to branch animation blend trees first by velocity, then by turn speed for example, however if a character can strafe, turn and walk/reverse the tree can quickly get complex (Of course this would also be true for a root motion based animator too). Finally, we can also control the overall animation speed of any layer (attack, flee etc) from the AI state itself, so we can easily speed up a particular behaviour and adjust the animation speed in the same script.
Compromises
The loss of the original IK system is a compromise we had to make. It felt like a big loss, but the advantages of another system were clear. The Mecanim solution is a lot more efficient and allows us to have more active NPCs in view at once, which is clearly more important to the game than exceptional foot placement. The majority of AAA games do without foot IK on models and however nice the original IK looked our NPC hunters are often knee deep in grass or peering over walls to shoot you, making believable leg movement pointless. You generally don’t have time to admire the enemy footwork while running for your life through the bracken, either.
Ultimately we think our experience with these two different approaches to implementing animation show the complexity of the choices faced by developers working in the kind of environments we are using to build Sir. It’s rare that one piece of tech or middleware will do exactly what you want, and that’s the reason why so many larger teams choose to write bespoke engines and code for their games. When you are a small team like us, it’s wiser to appraise the solutions available and then weigh the advantages: the system that is most efficient, and easiest for the designers to tweak, is almost always the winner.
