GameStates managed through animator's state machine?

Hi,
So is it a good idea to use the Unity's animator state machines to manage all your game states?
What would be the best option here otherwise?

Thanks

 

There isn't a right or best way, just how well executed it is. Using the animator for every game state would be a major decision towards standardizing workflow.

With a major decision comes benefits and consequences. Standardization makes production more predictable since inputs and outputs are dictated. In this case you can't really change how the animator works, your inputs are your setup of the animator states, your outputs are what happens upon entering those states.

Standardization has the drawback of being over-engineered for simple situations. A standard way of doing things needs to encompass most if not all situations. A situation containing 2 states remains just as complex to use and maintain as a situation containing 30 states.

The benefits of standardization only become apparent when the project gets big in team size, and the brutal truth is most games simply do not reach that level of complexity to exploit that benefit.

EDIT:
With all that said, I've seen the animator used in very interesting ways. I've yet to see the animator used for almost everything. Maybe this method is easier for the less scripting inclined.

 

Don't actually do this.

The animator is made for animation, which means that the concept of "being in a state" isn't very clear-cut. You can be in-between states when transitioning, which makes using it as a general purpose state machine lead to a bunch of issues. I've written a fully fledged ai state machine using the animator and state machine behaviours, and that ended up being a horrible idea; when I rewrote the same system as a pure in-code state machine, a ton of bugs went away.

 

Thats amazing. I never thought anyone actually tried it. It sounded like a relatively good idea on paper. Would you be willing to share some of the bugs you experienced? Quite curious to know what issue arose from it.

 

It's a long while back. I did it for World to the West, which shipped ealy 2017, and we changed it quite a bit before launch, so I'm guessing that it happened in mid-2016. So my memory is a bit blurry.

But, issues were:
- You always had to remember to set all transitions to instant, which isn't the default. Otherwise two states were running at the same time.
- It's near-impossible to debug why the animator has done a transition. You can't put a breakpoint or a Debug.Log where it transitions to see what's going on
- It's trying to do a bunch of animation stuff, so there's a ton of overhead.
- Figuring out which state you're in is a mess, so you have to keep track of that seperately from the animator controller anyway

The only good thing is that you have a high quality visualization of which state you're in, and which states can transition to which others. it's probably a lot less work to get hold of a node editor and do that for your own states than it is to use the Animator Controller for this.