#How should a player controlled by a finite state machine handle animations?

1 messages · Page 1 of 1 (latest)

obtuse aurora
#

I'm converting my player movement from a very simple enum approach to a proper state machine. Previously, I had a script that handled the animation by just checking the player state enum (walking, running, idle, etc) and sending the appropriate animation to my animator script (I use animancer). However, because I've fully rebuilt the movement from the ground up to utilize a much cleaner FSM approach, I'm wondering if there's a better way to handle animations. Something more industry standard, if that makes sense.

I've seen the suggestion that I should just have references to all of the animation clips in the state machine script, but that seems like a terrible mess that would quickly become unmanageable if I were to add more than a couple states. I'd like to keep it as a separate script, if possible. I'm confident I could slap something together, but I want to know if there's a cleaner solution.

deft ether
#

Well, you shouldn't be referencing clips but you should have identical states within your animation controller to toggle or trigger. If you have like some multi-staged animations, the animation controller does handled a lot of that workload as it can sequence a lot of that out with little communication from your controller.

#

So the idea is you do want to generalize a lot of these animations to only a few animation states if possible.

#

Some examples here would be something like strafing. You wouldn't be calling the clips of the 8 or so strafing animations you might have, but instead use something like a 2D blendtree that blends together those animations which you'd have to pass some normalized velocity to that tree.

#

Same velocity parameter can be used by all other types of strafing animations (crouch, swimming)

#

If you're curious how the industry does it, I'd probably look more into unreal to get an idea. I'm pretty sure the whole node idea extends to the backend. Not a bad idea honestly since behaviour trees work pretty well with them.

obtuse aurora
obtuse aurora
#

My best idea rn is using this:

System.Type currentState = _stateMachine.CurrentStateType;
if (currentState == typeof(PlayerGroundedState) {
// do things here
}```
#

using TypeOf seems cleaner than just reading boolean values (and also means I don't have to constantly set/unset booleans). Is that a reasonable approach?

#

Honestly I could just use an enum value again JUST to provide context to the animator

#

TypeOf is less efficient and kind of relies on class names never changing which seems like bad practice

obtuse aurora
#

basically I just need to know if I'm shooting myself in the foot here

#

I'm not a programmer by trade