# When an animation involves movement, where is the movement better to implement?

For context, I am using Blender and Unity. Regarding the question, as an example, in some games, when you get hit, your character tucks a bit and gets knocked back a few distance. The tucking animation I want to implement in Blender but how about the knockback distance? Do you move your model in Blender (tuck and knockback), or do you do the tuck animation only (tuck in place) and then handle the knockback in Unity (basically triggering the tuck animation and then moving the model backwards a bit).

My question basically is, what's commonly done and if there's any specific reason, why?

Both options have pros and cons; in practice I'd advocate for using a mix of techniques, as appropriate for the situation.

When the animation drives the object's world position, the animator has significantly increased control over the artistic look and feel of the animation and how realistic (or stylistic) they'd like it to be. But the game has significantly less control over the object, leading to more work and/or potentially very ugly looking stopgap techniques to (for example) prevent objects from being forced inside other objects due to the animation (if collision is off). Or if collision is on, preventing the animation-driven displacement from being countered by collision, destroying all the animator's hard work as the object "slides" against some surface while animating. IME it's better to let the animation drive the object for complex interactions like clambering over obstacles.

When the game drives the object's world position, the game logic has much more precise control over the object; since it's usually game logic that translates player input into displacement of player-controlled objects, this can result in much tighter-feeling control. But it can also result in less than ideal visuals because the animators typically cannot know for sure when the game will blend between two animations, and some blending techniques can result in obviously-video-gamey transitions in scenarios where, for example, you stop a character short in their walk cycle. IME it's better to let the game drive the position for locomotion related actions in particular, and also as a default choice.

There's a variety of ways to combine animation techniques in a mix-and-match approach that let you hide or minimize some of the cons of either approach (motion matching, for example, is a Relatively Hot New Thing recently).

What I recommend you specifically do is look at what is most efficient for you: is it easier for you to work in Blender and have all your displacements authored there? Or is it easier for you to do displacements programmatically (for the majority of cases). Either way you'll likely need to put work in to smooth over artifacts, so you'll be paying that cost. So look at which option will let you personally pay the cheapest cost for your project's needs.

In my opinion this is best handled inside the game and NOT inside the animation. In your case that would be inside Unity and not Blender.

So the idea is the animation is only showing what your character looks like when they get hit, and through Unity you can configure how long away you want the character to move.

Here are the benefits:

• You can use the same animation for multiple characters and multiple occasions. Characters that are small (so thrown further away) or big (not really moving), or creating a big explosion or just a small bullet.
• Usually from within the game, all objects are in the "center" of themselves. So if you place a box at coordinates (0, 0, 0), you assume that it will be in the center of the world. If you animate a character, and at the end of the animation they now have an offset, that might make it awkward to place it correctly in the world and make it look smooth.
• You can combine multiple animations easier, as its animation can assume the character is at the center, and not offset because of the previous animation.