Best Practices for Game Animation

Question

I am creating a number of animations for a player character that will eventually be exported for use in a game engine (Unity, Unreal, Godot, etc., doesn't matter which). Unfortunately, the educational material I've been able to find is lacking in certain practical details.

(I understand that there are many different valid workflows that vary depending on studio, software, and even individuals, but for the purposes of this post, I'm looking for what's generally considered in the industry "best practice" in Blender or at least "equivalently valid.")

For example, there are obviously normal animations, but there are also "modifier" animations that are sometimes layered on top to create additional effects. (Being hit, varied torso motion while walking, etc.) For these "modifier" animations, obviously only the particular bones and channels (X-loc, Z-rot, etc.) that are being modified. I don't know how that relates to the "normal" animations, though--is every value supposed to have a keyframe? If so, where? If not, how do you make sure the animation plays the same every time? What about tweak bones when they're not being used, or scale channels in most things, or locked channels, or even -MCH or -DEF bones? Should this be stored in a default "blank" animation that just has a keyframe on every bone and channel, and every animation is built from this?

Additionally, what about FK/IK switchers? Some animations will use IK for, say, the arms, others FK, and others will switch mid-animation. Is it best practice to use a bone as a driver, or animate the switching on the fly per animation? Is this another thing that requires being keyframed for each animation regardless of whether it switches?

And what is best practice for storing each animation? Currently I just sort of have each Action named something like Character-ActionType-AdditionalInfo and stored as a fake user, but I've seen information relating to things needing to be pushed into the NLA editor for export. If that's true, is that a last-step thing?

TL;DR

1. What bones and channels are supposed to be keyframed in an animation? All of them for consistency, or only the ones that are specifically Doing Something in the specific animation?
2. Should I store IK-FK switching in a bone driver, and should this be keyframed in pretty much every animation?
3. What is the best practice for storing animations--datablocks or in the NLA?

Answer 1

Thanks for the TL;DR x)

1. What bones and channels are supposed to be keyframed in an animation? All of them for consistency, or only the ones that are specifically Doing Something in the specific animation?

Short version:
It kind of depends, but it's often mostly for your own sake to keep things simple and tidy.

When you have any kind of layered animation in mind, it usually works by either a mix of addition and multiplication of values, or complete override. Some game engines provide you a full control of these modes on a per-bone level, but more often than not it's only per animation layer. (If you ever use Blender's action system, that's a per-layer system).

But in either case, in terms of animation it doesn't really matter what you put keyframes on or not, it's a matter of what you actually animate and how. When you make an animation that's for example a "look-up" version of a run, you could go in your animation software and load the run cycle, make an additive layer, and make your look-up modifications on that layer, and export that. Then in the engine, when it will call this animation, it will have to layer it on the run cycle in additive.

Now some game engines might not want to have any keys on things you don't want to be affected at all by the new layer, and it's also a good practice to avoid creating unnecessary keys in any animation overall: it's easier to manage as an animator, it gives lighter files. Though some game engines might also require to key everything on every frame, and then compress everything with a crude axe.
Can't do much about it either way x) Work tidier for your own sake first!

2. Should I store IK-FK switching in a bone driver, and should this be keyframed in pretty much every animation?

Short version:
You are not supposed to (and should definitely not) export your complicated rig with intricate IK systems and driver systems. Complicated controls are all for the animators to have fun with. All that should come out of animation department are deform bones with stupid simple location/rotation/scale keyframes.

Rigs are always made of the deform bones in one side and "everything else" on the other. Deform bones have one job: deform the mesh. Some rigs have their deform bones without any hierarchy aside being under the root bone, some even are not oriented to the limbs and are instead aligned to the world axes.

All the functional features of a rig, being the F/FX systems and different controllers that the animators actually use, are often partially on a different part or the rig, if not entirely isolated. All these things are really only for the animator to see and use. When exporting, everything is baked into the deform bones, and the game engine will receive only that. The deform bones. Which are essencialy a bunch of points moving anr rotation around.

Reason: it's the simplest representation of bone animation. Simpler means, les data to carry around, no complicated feature that's incompatible with X software or interpreted differently in Y software, less likely to produce different results, less likely to fail, ...

In fact, in some other industries like movie VFX we don't even send bone animated meshes sometimes, but instead cached meshes like alembic. But that's another topic.

3. What is the best practice for storing animations--datablocks or in the NLA?

Whatever fits you, really.

You are kind of limited by what your target game engine can handle. And when you work in a studio, you often don't chose how things are done, because the studio will have their own set of tools that either have an in-house solution or will require you to use a specific option.

Using actions in the NLA has the advantage of making it easy to store and access animations from one file without requiring to switch files, but that's kind of not true anymore with the new asset browser and pose library.
Though it remains the only way to efficiently work on layered animations.

In practice, people rarely stick to one solution, they just do it the way their experience predicts is the best for the day.