So I have only just begun to implement my animation state machine. Right now it just covers motion, falling, jumping, dodging, etc… and it already looks like this:
It’s a chaotic mess, and I am wondering if there is a way to clean it up? I understand this is the nature of state machines, but it’s only about a third of the way done and with so much more to go, I worry.
Thanks.
Well as an opinion Unreal 4 is a mix of old school ways and means mixed in with that would be considered nextGen tech so in most cases the way to go is usually set as the road most travel. The reason why UE4 even has state machines, and as you have discovered is they are evil and do not scale very well as to the needs of what would be considered an advanced character animation system, is just one of those things that has worked going back as far as Pong. A case of going with what you know.
NextGen wise UE4 does have the ways and means via blend spaces in combination of Blend By where a much more easier and scalable design could be implemented that has yet to be documented or has a proven track record as to yet another reason why most will still favor the use of a state machine as compared to the risk that a new approach represents of something that may or may not work as to expiations.
In all though the next step in what would be considered as being an advanced design is the consideration that such a design needs to be compatible as a data drive channel where the kind of input is not restricted by nested arguments required to move into and out of a given state and could be anything from a keyboard input to a set of VR glasses.
I do 90% of my “state machines” in blueprints…so some of the work can be offloaded there if you run into too much trouble…
So, you’re saying it’s possible to implement a “state machine” in the Anim Graph using nothing but switch statements and the like? Would it be performance friendly? Can I still have nice smooth transitions between states?
You can certainly do a lot of work elsewhere IF YOU WANT…but that’s the real question is how would you like to do it…it’s nice you always have options with the engine…so I do it mostly in Blueprints and use plenty of bools…performance is going to be how many instructions you force your anim blueprint to run every update…so Bools can be nice since they’re easy…1 million of them wouldn’t be but a dozen wouldn’t likely be so bad…
as for smooth transitions I use the blend times - 
lots of ways to do this though…so this is just how I go about it…plenty more people on the forum likely have a different way…
Certainly one could build an entire character control sub-system with out using a single state machine and is even possible to do with out using a single event graph argument. Epic for the most part provides the very basics as to the need of making something work as to expatiations but just like Lego blocks one can build much more complex and in turn efficient movement controls based on the demands of the game design.
A true top down design that is 100% data friendly is way more efficient by default as to performance as it bypasses the requirements of bottom up requirements. A bottom up requirement is the need to cast to whatever is being used as the movement component and ask 20 questions as to what event “might” have occurred. Top down the movement component could “tell” the animgraph, based on it’s own logic tree (?), what needs to be triggered starting with as little as 3 basic requirements necessary to make something move.
Based on just the 3 requirements the output could be character is running while casting a spell and is on fire.
You bet and in ways that can’t be done using the “limitations” of a State machine that requires “nested” arguments that are required to get into and out of a given state. As an animator it’s crazy talk to have to tell a State to exit if the player has stop running but only if there is 5% left in the current run cycle. By including anything that forces the state to wait your actually adding a performance hindrance that compounds with the more you add and the result is a movement latency that feels sluggish.
The flip side is a Blend Space handles the interpolation for you moving from one index to another and does not require a wait state hooked to a blend by <insert var> as the blend weighting is handled by the blend by which once again can be a var coming in by any kind of input you wish.
Once again these are just game design theories that have yet to be proven or even properly demonstrated as it requires throwing out what’s considered best practice out the window and start from scratch which is very scary if the purpose of the design is to make and “sell” a game.
Sounds confusing right? 
Trying not to write a book it’s all a frame of mind and which direction your designing from.
Yes. You can try using conduits to reduce number of transitions. Instead of providing transition for every possible scenario, add conduit that can be only entered when some condition is true (“ground == false”, for example), and then drag transitions from there.
Generally speaking there’s not much reason try to stuff everything into statemachine, you can blend several animations together, and you can use animation montages (which can provide better degree of control than statemachines)
