MCV/DEVELOP News, events, research and jobs from the games industry
A common challenge in character animation is getting characters to appear and move correctly early on in a project’s development cycle. In this phase, it’s important that your development environment be iterative and flexible.
Typically character animation is achieved with data driven tools that often rely on a C++ back-end to drive character behavior. While computationally efficient, this method can be less than ideal because of the edit-compile-launch cycle associated with C++.
Character teams can spend months building locomotion models, attack sequences and environmental interactions to piece their characters together and place them in the game world convincingly.
High Quality Character Locomotion
When implementing character locomotion, it’s difficult to make a character highly responsive and still maintain high quality animation. Let’s attempt to improve the fidelity of the initial movement as a character starts to run. In this example, we are integrating realistic transition animations that maintain proper anticipation and momentum. These transitions are driven by a simple interactive script that reacts quickly to input changes and is consistent with the character’s orientation in the world.
First, we create a set of transition animations that begin with the character facing forward and end with the character facing in one of eight different directions (see Figure 1.1 below).
When executing a transition, we need to pick the animation closest to the direction requested by the user (on the input stick) and then rotate the character to correct any error.
Next we focus on responsiveness. Character animations are typically authored with consistent striding for example; all animations will start with the left foot down. A responsive character will sometimes stop in a gait where it is natural for them to lead with their right foot. In these situations leading with the left foot would cause ‘foot-skate’, delaying stopping leads to an unresponsive character.
In Havok Behavior we address this with a simple script, executed at the start of the transition that evaluates the feet positions and selects the normal version or the procedurally mirrored version, which leads with the right foot animation. The mirroring is then handled automatically by Havok Behavior based on the results.
Interacting with the Game Environment
Players expect enemies to interact realistically with their environments, taking cover under fire, hurdling moving cars and clambering over buildings. Executing these features typically involves a three-step process:
• Querying Your Game World for Annotation Information
For prototyping purposes you can expose finding interesting interaction points such as cover points, moving obstacles or climbable ledges directly through scripting. This allows you to test character interactions quickly within a tool environment. The game-runtime will naturally use more optimised versions of these queries, which gives you the best of both worlds; designers can work in a highly iterative and flexible environment, while your game runs with optimized C++ code tailored for your engine.
• Choosing Context Sensitive Animations
Once you have developed a behavior for a specific action, like taking cover, you can then use an Animation Selector, driven by Havok Script, to refine this for more specialised situations – for example taking cover behind a wall versus taking cover behind a car. This allows the art team to quickly build more context sensitive versions of existing animations adding richness to the characters interaction with the environment.
• Registering the Character Correctly with the Environment
Since the user can start specialised actions from almost any location, you will need some mechanism for ‘fixing up’ animation at runtime to ensure they end up in the right location. In Havok Behavior a Docking Generator allows a single animation, for example a jump and grab animation, to be adapted at runtime. This single animation can be used for jumping and grabbing ledges at a range of different heights. The Docking Generator also supports docking bones other than the root. For example, when vaulting you might require a character’s hand be placed on the hood of a moving car at the apex of the jump.
This is just a sample of the types of animation techniques and experiments that can be rapidly prototyped inside the Havok Behavior Tool. For more information on Havok Behavior, visit:
