Best Practice for Coordinating Animation States and Character Behavior? e.g. Kneeling vs Standing

Unity Engine
1

I’m currently working on a 3D side-scroller where the main character needs to be able to switch between different behavioral states such as walking, aiming a weapon and kneeling. Different player controls and behaviors are naturally active depending on the active state, and animations are played to transition from one state to another.

The problem:
The system is mostly working as I have it, using some rough placeholder animations, but some relatively rare glitches are occurring which makes me wonder if I might have implemented it in a sloppy way that needs to be changed.
One example is when transitioning from a kneeling position to a standing position, it will work as expected unless I hold the key to move forward while the character stands up; now it will usually work the same way but occasionally the character will move forward slightly before resuming normal behavior resulting in a stuttering feel. Logically, this seems to be the result of some kind of off-by-one error where holding forward is resulting in the game thinking it should be moving forward for a single frame before checking the controls should be frozen until the standing animation is finished.
I assumed the nature of FixedUpdate being called more often than Update and potentially much more or less often depending on framerate may have had something to do with it and why it only happens now and then (it does seem more frequent during lag spikes) but examining those functions carefully didn’t provide a clear answer and it still looked to me as though there shouldn’t be a possible way FixedUpdate could decide to move the character AFTER Update had been called and seemingly the state was changed to one where the controls would be locked.
I’ve tried to pin down the exact cause, but after adding another ugly boolean that did seem to stop it from happening at least almost all of the time (it’s hard to check for sure) I decided I needed to reassess whether or not my entire behavior/animation state switching system makes sense or I’m setting myself up for more trouble down the line, not to mention it looking uglier than I feel it should as things are.

My current system:
The character can be in one of several movement states including WALK_MODE and KNEEL_MODE. The problem I’ve described occurs when transitioning from KNEEL_MODE (where the player is holding down a key to remain kneeling and releases to stand up again; left/right direction keys no longer work, but shooting is still possible etc.) to WALK_MODE (left/right movement is now possible again etc.).
A major issue is that animations take time to play, and during that time I obviously don’t want some controls to be usable but once I detect the player has decided to stop kneeling I instantly change the player’s movement mode to WALK_MODE but freeze the controls by checking if the “Unkneel” animation is still playing like so:

        if ( animator.GetCurrentAnimatorStateInfo( 0 ).IsName( "Unkneel" ) && animator.GetCurrentAnimatorStateInfo( 0 ).normalizedTime < 1.0f
        || animator.GetCurrentAnimatorStateInfo( 0 ).IsName( "Kneel" ) && animator.GetCurrentAnimatorStateInfo( 0 ).normalizedTime < 1.0f )
        {
            inKneelAnim = true;
        }

This sets a bool called “inKneelAnim” which is used to check if controls should be frozen. Clearly, the problem could lie in having a frame where WALK_MODE has been entered but for some reason the animation is occasionally not considered to be playing yet when checked; I notice I’m setting the booleans for the Animator using its Update function, perhaps FixedUpdate would be better? Presumably the Animator isn’t calling its Update function early enough to Unity seems to suggest putting them in Update, but either way I assume my system probably needs to be cleaned up as this seems very vulnerable to lag given the game’s actual logic depends on these things being done in the right order every time.

Is this a bad way to deal with animations or is there no real other majorly different way? Perhaps the addition of something like ANIM_MODE that I could switch to while animations were playing between states would at least prevent problems like the WALK_MODE behavior seemingly being active for a frame when it shouldn’t be…
Just testing now I can see that with one implementation the glitch seems not to happen until I scroll to encounter some enemies, at which point it happens almost all the time. Seems to be closely related to framerate so, and presumably the bool in the Animator indicating whether to kneel or not being set in Update too long after FixedUpdate.

Sorry if this wasn’t as clear as it could be, but TL;DR I basically just need some advice on how best to transition between different behavior states for a character using animations, making sure that the appropriate controls are active exactly when they’re supposed to be and there is no chance of undesired behavior due to animation states not being updated in time.

2

Ok, I’ve made some progress on this…

I decided to explicitly call my character’s Animator object’s Update() function at the end of the character’s own Update() function to see if updating all of the Animator’s parameters directly after the character may have taken actions that should alter them would make a difference.
Sure enough, it now appears to never happen. Hence, this means the problem must have been:

  1. Character’s Update() function is called and detects the player indicating to come up from a kneeling position,
  2. Character’s FixedUpdate() is called before Animator gets a chance to call its own Update() to alter the parameters, so when FixedUpdate() reads Animator’s parameters it still appears that the character should be moving, and FixedUpdate() moves the character this frame.
  3. Animator’s Update() is called at some point, correctly changing the values and meaning that further calls of the character’s FixedUpdate() will correctly not move for the rest of the kneeling cycle.

Now, I just have to ask if this seems like a bad idea and if there’s any obvious better way? One one hand I never saw it mentioned in the Unity examples so it seems like it’s not intended to be done this way at least in the general case, on the other hand it seems to ensure my problem no longer occurs by just inserting one neat function call and I can’t see why this would call problems in the future.
Maybe the particularities of my use case here just warrants doing what I described and many others wouldn’t? I still can’t quite see how called FixedUpdate() like that and taking actions inside it based on animation state (which, unless I’m greatly mistaken seems like it should be a common thing to do) wouldn’t be likely to cause conflicts when you only update the animation parameters in the much less frequently called Update().
I guess the key was ensuring that everything that should be changed once the player changes state and enters an animation is immediately set at the same time and not to rely on another function to update quickly enough, but I still don’t quite see how to decouple the logic from directly checking the state of the animations in some way…