Am I the only one using the Animator state machine for more than animations?

It's just so convenient. I'm using it to play a sound, disable colliders, movement, and remove from selection when the character dies, etc.

I'm thinking of using it a lot more than I currently am for game logic. Anyone else doing this already?

 

No, plenty of people do. Unity even suggests you use it.

I don't though... I don't like it.

 

Why don't you like it?

 

My issue is that it floats in between programmer and designer.

I'm an engineer, I like code, I like the freedom that code gives me. A designer like the one for Animator often turns into a roadblock that I'm constantly trying to work around, rather than a tool to ease my process.

But this isn't to say I don't like designer tools... I build them as well. But I don't build them for me... I build them for my designer. He can not code... or rather what little coding ability he has is scary enough that I won't let him near code except for extreme situations (such as basic art scripts like filters/simple animations, which I then also go back and proof if he's added it).

The tools I give him for building state machines require zero coding on his part. He can drag and drop modules that represent some action, and then it just works for him.

Animator has slowly gained more and more options to get it closer to this... or atleast allow me to create some modules that would allow almost no code for my designer. But we've been at this a while now since before said extensions of the Animator State Machine were added, and he's gotten used to the tools I've already written for him. They may be worth looking at as the grow and become better... but the learning curve required for my designer out weighs the usefulness of doing so. Basically... why fix what ain't broke, especially if the alternative isn't all the way there.

This isn't to say that they're bad. Far from... they're perfectly useful and good tools. And the fact it has a community of support behind it makes them easier to learn for people coming to the unity community. They're great tools... I just don't use them, nor like them, for my own personal usage. They impede an established development process for us.

 

The Animation State Machine has been designed to handle animations. I feel like using it for something else is not appropriate and seems a hacky way to achieve your goal.

Also, I'm not comfortable about how the transitions apply to game logics. If you implement your state machine in code, you know exactly in which state the fsm is in at any time. Whereas, with the Animation State Machine, that can be ambiguous since it can take some time to transition from one state to another.

 

The string-based communication to the Animator makes it seem like this "black box". You don't really know how it's doing what it does, but it works.
And the last I knew, there is no way to determine the progress of any particular state in the machine when the the speed of the state is not constant. This causes us to rely on animation events sent to us. Rather than just saying: "How far along are you?", instead you have to say: "Notify me when you're half-way done with what you're doing".

 

Well... I guess there are more people who don't like it that I expected.

Maybe OP is right that they're the only one. I could have sworn there were people that liked/used it.

 

Why do you feel that way?

What do you mean by implementing a state machine in code? Do you mean hard coded?

Can you give an example? Where is the Animator string based? For parameters? I can't say I've had this issue yet from my usage with it.


What I'd really like to see though is a more generic state machine: nothing to do with animations. Transitions would have TransitionBehaviours so if you wanted to keep the current behaviour, you would add a "AnimationExitTransitionBehaviour". States themselves would have no concept of motion or animation themselves. You would need to add an "AnimationStateBehaviour" or something like that to keep the current functionality.

 

For me same as with lordofduct. Programming means control and flexibility, i create my own statemachine,

 

Do you have a nice and pretty editor as well?

 

Yes visual studio

 

It's like using a knife as a screwdriver. It works and it seems that the knife can do more than a screwdriver, so why not just having a knife in your toolbox? Problem is you can easily damage both the knife and the screws, using the wrong tool for the job. I feel a bit the same way about using the Animation State Machine for implementing pure game logic. You have a nice interface to visualize and see your logic running. But there are those ambiguous situations due to transitions taking some time to go from one state to another. That works well for doing smooth animations. But there's no such thing as "smooth transiting game logic". That sounds more like source for race condition bugs.

Yes, I mean hard-coded, usually by using an enum to list the states and two switches: one to handle the transitions, and another to map the enum values to state functions. But I try to avoid FSM (hard-coded or not) as much as possible; they are a hell to maintain because of the explicit transitions that grow like cobwebs as your logic get more complex. I favor Behaviour Tree to implement game logic, it's a far more versatile, easier to use and more maintainable than FSM.

 

@Deleted_User Nothing beats reviving an old thread.

However, I have played with Unity's built in Animation State Machine a couple of years ago and was in two minds about whether it was a viable tool to use, after using Bolt and Node Canvas for the same purpose they both seemed like overkill, so now I am going back to Unity's internal FSM for other than just animations.

Worth adding that I am a developer and I hear what other developers are saying about how code is the most flexible option, blah, blah... but any tool that helps in abstracting complexity is welcome in my workflow.

 

As long as not abstracting to performance hell. It is curious that how much overhead animators cause when they are used as state machines with many states and behaviors.

 

Although nobody asked me, since we're talking FSMs, I feel compelled to save people a lot of unnecessary hassle:

This is my position on finite state machines (FSMs):

https://forum.unity.com/threads/state-machine-help.1080983/#post-6970016

I'm kind of more of a "get it working first" guy.

Ask yourself, "WHY would I use solution XYZ when I just need a variable and a switch statement?"

Your mileage may vary.

"I strongly suggest to make it as simple as possible. No classes, no interfaces, no needless OOP." - Zajoman on the Unity3D forums.