We threw it out because it turned into a rat's nest of inadvertently nested coroutines that resulted in blended state behavior. The reasoning was that when a unit went idle there would be no coroutine. That means that the states has this signature:įWIW we did our initial FSM implementation using Coroutines to evaluate the state each frame. I ended up making the states themselved responsible for where to transition, forgoing the ability to re-use the same states between different enemies. a bunch of variables you need to take care of. The downside with that is that the machine now needs to have state. The upside to having the machine responsible is that, as you said, you can re-use different states for different machines. Either the states themselves are responsible for knowing where to transition, or there's a state machine that has states and transition rules be separate things. That being said, here's my experience with making AI state machines from our last game: My main advice is to create a few different enemies the way you're doing it now, and see what abstractions appear naturally. Making a Transition concept before you have quite a few different enemies will probably end up with a design that's hard to work with and maintain.
You want to wait with creating abstractions until you have enough examples to create good abstractions from.
