I recently completed the development phase of the current game project, and I had to fix a lot of small flaws in the data and animation code. These types of problems have often met me in past projects. A little upset, I began to write down the simplest tips and tricks I used before. They can be useful to other developers who are starting to work with game animation.

Response to joystick signals only after their stabilization

Modern gamepads usually have not only numeric buttons, but also analog triggers with joysticks; each of them can output a virtually infinite number of values. Joysticks can transmit any angle from 0 to 360 degrees and a radius of deviation from 0 to 1. Triggers, although similar to binary buttons, can produce any normalized value from 0 to 1 - they are pressure sensitive.

It is important to take into account this difference, tying the analog control to the key points of the actions and animations of the character. Users need a certain time to change the value of any analog control from 0 to 1. If there are several segments in this range that are used to activate various types of actions, some intermediate states of analog control can cause unexpected actions for the user in the game.
')
For example, players can usually rotate 180 degrees with a joystick in two different ways (see picture below).


Different ways to change the joystick deflection 180 degrees

In both cases, a problem may arise. In the case of the left, this is due to the passage of the joystick through the initial position. Sometimes games mistakenly interpret this as a signal to enable character stop animation, because the position of the joystick has a zero radius. In our current project, we do not allow the stop animation to be interrupted until a part of the slowdown animation is complete, so the user cannot immediately start moving again if he was going to move the joystick in a different direction. In the case on the right, the game may attempt to rotate 90 degrees, if the only criterion for the joystick is to be in a certain segment of the circle.

Of course, if the action or animation that was triggered can be immediately stopped, it will be replaced after the player rotates the analog joystick to the end, and to some extent this problem can be ignored. In case the triggered action is not interrupted, the player will have to wait for the completion of the previous action to get the expected response. This can even lead to complete disregard for the keystrokes he entered.

To prevent such cases, you can enter a stabilization criterion for a joystick or any other element of the analog input. We can take the average of the last few frames of analog input and compare it with the current value. Thus, we will determine numerically whether the analog input is stabilized and whether it needs to be taken into account. Or it continues to change rapidly and the response to it needs to be postponed. This approach significantly reduces the number of false-positive reactions that generate triggered actions using analog input. The main disadvantage here is the latency of control over several frames. However, when using this principle in many movements of a character in my current project, when properly configured, none of the users could notice the difference.

A sufficient number of animation frames overlapping mixing

Many characters in video games are real athletes. They can run at high speed, jump, run again, maneuver on the run, keeping great inertia. Therefore, in video games, when transitioning from one action to another, it is extremely important to maintain smooth and believable transitions and movements of the character. One way to ensure smoothness is to add extra mixing time between movements. This will keep the transition from one animation to another smooth. However, in order for this to work well, in the process of mixing it is necessary to continue updating the completed or dependent animation and move accordingly the inertia of the character.

If the motion remaining for the completed animation is shorter than the duration of the blending between this animation and the next one, then the blending algorithm will use a static pose without a certain speed as the downstream animation. Often this is interpreted by the game as zero speed. Depending on the weight of the mix left for the dependent animation, such a sharp transition of the dependent animation to zero speed can create a discontinuity of the character’s mixed speed during the transition.


Changing character speeds when moving between animations A and B

In the lower case, the mixed speed contains discontinuities caused by a sharp drop to zero of the speed of the dependent animation. In the upper example, the character's speed in the mixing process remains exactly as we expect due to the large number of frames remaining from the transition point in the dependent animation.

Try not to lose significant actions when mixing with assets.

Most of the actions performed by a character consist of preparation, the action itself and its completion. If you remove at least one of these segments, the character will look unnatural. For example, imagine a baseball player trying to strike without a backswing and complete the strike. Unfortunately, such unnatural transitions in video games is too easy to create.

This effect is very noticeable in basketball games, where the player with the ball constantly dribbles the ball, hitting them on the floor and catching it on the rebound. In other words, he almost always either swings to hit the ball on the floor, or ends the movement, catching him in the air. For completeness, each of the segments of hitting the ball and its subsequent capture must be played completely, otherwise dribbling will look unnatural. It is necessary to be very attentive to the transitions during each of the segments, so that they can be replaced by something that smoothly continues the process of preparation, action and completion. Often there is a problem when moving to a new asset that contains the waiting segment right at the beginning of the animation. If the transition blending process is too long, players will not see preparation for action in the animation, because the previous animation will continue. The resulting movement in the game will not look very realistic.

There are ways to remedy the situation by dynamically changing the type or length of the blending transition. However, the best thing to do in this case is to avoid these problems altogether, creating assets in such a way that the animation does not have any required poses until the current animation has reached sufficient weight in mixing. Thanks to this preparation, action and completion will be clearly visible on the screen. Example: if you mix the animation of a baseball player ready to strike a bat, and you have a long mix with animation, then do not force the baseball player to start the bat swing movement in animation assets too early.

Scaling source motion rather than adding or subtracting

Often we need to add movement to the animation so that the character reaches a certain point for interaction. For example, a character's step forward to get closer to the door handle. Games often have to transform the motion of an animation during execution so that inverse kinematics brings the character's hand close enough to the handle. In this case, you do not need to add movement, which should occur at a constant speed throughout the entire animation. Instead, it is worth noting when the animation is moving, and convert the speed of movement, taking into account the required amount of additional movement. In other words, if a character is immobile in some segments of the animation, then you should not add movement to these segments. Otherwise, this situation may arise: the character must stand, but instead he moves, and his legs slide along the floor.


The speed of the character with the added 20% movement. Both dashed lines cover the same distance.

In the picture above, we take a graph of the speed of animation, starting at a certain speed and slowing down to a state of rest. For the game, we need to add another 20% of the character's movement during the animation. In one of the cases, we decided to add additional motion to the number of animation frames, and evenly distribute it over each map. As a result, the character continues to maintain a non-zero speed even near completion when it is in a standby state. In the second case, we added 20% of the motion, simply by scaling the entire velocity graph by 20%. Now the character moves faster in parts of the animation with movement and remains motionless at the zero speed specified in the animation.

In one of the old systems with which I worked, we forced the character to jump upwards to a certain height as follows: in animations, the time of separation from the ground and landing was noted, and then the algorithm calculated the additional amount of displacement needed by the character to reach a certain height. Then he evenly distributed this additional movement between the moments of separation from the ground and landing. In none of the cases did we manage to make this movement natural, because we ignored too much of the basic movement. The following year we rewrote the system and it began to scale the character’s vertical speed to match the jump correctly. The results looked much more natural. This happened because the parts of the jump, in which the character had not yet moved up, remained approximately the same, and we picked up speed only when the character was already moving fast. Taking as a basis data on this action and making changes to meet certain marks, we achieved much better visual results.

Quality management of a large number of animations

Over the past few years I have had the opportunity to work on many sports video games. In games of this type there is an interesting complexity: they try to reproduce the exact movements of specific athletes from the real world. In most other games, there is only one animation for one type of game action. We sometimes had to create dozens of different variations in order for game athletes to more closely match their real prototypes. So there is a large amount of game animations, and any operation that needs to be performed for each animation manually takes a lot of development time. Just imagine that for a new function, you suddenly need to manually add a new tag to hundreds of different assets: it takes a lot of time!

In such situations, it is useful to have a framework that allows you to perform data verification and create corrective scripts for several or all animation assets. Such scripts can perform verification on a specific set of rules, creating a list of assets that require manual checking, automatically fix problems, or even add metadata at certain points in the required assets.

It is usually better to fix such data problems in advance. Otherwise, the elimination of errors in the process of their appearance can take a very long time. In addition, you will have to interrupt ongoing work to correct such data errors. As a rule, when I spend energy on data verification scripts, I save much more time compared to solving problems as they appear. In addition, gaining experience in the implementation of such scripts, you can better and quickly create new ones. If you have scripts, you can quickly recheck all assets for new animations with problems. This is quite useful when developing, when new animations are constantly added to the game.

Share your opinion with me

I hope my tips will help you save a few hours of work during the development process. At least some of these tips can help create an environment in which it will be easier to scale the number of animations and transitions of animations in your project. If you have something to say about these tips, or you have your own useful recommendations for working with game animation, then write me at jcdelannoy@gmail.com. Thank!