I have certain animation states that I want to tranistion to regardless of the current state the skeletal mesh is in. A basic example for this would be a falling animation that could be triggered when the character is not grounded any more, regardless of which state he was previously in.
Right now the only way as I see would be to add a transition to the falling state from any other state which would turn my anim BP into spaghetti. Is there a more elegant way to do this. I remember Unity’s Mecanim had something called an Any state – so I wonder if there might be something similar that I have not discovered yet.
I struggled with this for a while till I found my solution. In your animation state machine, your very first entry node should just be a buffer zone. Each animation state should be controlled by an integer state machine coming from the character bp. essentially all of your state transition rules will either be “state==1 -> go to state 1 animation” and “state =!1 -> go back to buffer”. Every time the integer signifying the current state changes, it will switch back to the buffer state then trigger into the next state transition. This way, you can handle hundreds of animations without ever having to connect state chains because all states go through the central buffer with proper blend times.
Well to put things into context Unreal 4 consists of feature sets based on how things use to work that also combines feature sets that is in place to contend with what could be done via research and discovery as to the need for much more complex movement systems.
What seems to be the case is the need for the straight ahead bottom up design pathway where the mind map says it needs to work today instead of building up a frame work which is the need between code and content of just doing enough to make it work versus the required R&D which is usually considered a time consuming process as to proof of concept and time spent with real time development usually = $$$$$
That being said state machines are very easy to understand as to animation migration as to a solution that has been proven to work and every game since the beginning of game development history has used some kind of state machine that requires a nested argument built into the pathway based on the need to change a animation state within a parallel animation migration pathway.
In most cases state machines are still used today as they are off the shelf solutions that works well in combination with the movement component as to the need for ready made replication requirements.
The back end is the tendency for a state machine to become very sloppy that adds input latency from the input device giving it that kind of sluggish feeling as the design scales up as to the need of state changes.
The direction with animation needs in Unreal 4 though seems to be more towards data driven top down migration pathways that excludes the need for argument based state machines starting with the locomotion state and layering animation state changes with out the use of a state machine.
To avoid the 10 page design documentation I noticed like many that over time state machines became more and more difficult to understand to even be able to get out of fixed state and over time my conclusion is the only practical reason to included a state machine is when you don’t want the player to leave the state as to cause and effect.
So to answer the question with a question.
Do you even need to use a state machine at all?
In my case the answer is no but requires a development pathway that makes assumptions as to what might be needed down the road instead of what works today in exchange for top down design ideology in an effort to build the framework which is what the state machine is as an off the shelf ready to use solution.
With that in mind watch Epic’s twitch casts of the animation tech used in Paragon and the ah ha moment is that the animation migration is 100% data driven and the question is where is the data coming from?
Another thing I’d note here is that there’s no rule that says you have to contain all your logic in one state machine, and breaking yourself of that mindset can be helpful. For instance, if you have a very complex set of rules that govern the player’s animation when he’s on the ground (idling, walking, sliding, turning, climbing up hills, etc etc) and a very complex set that govern him while he’s “in the air” (rising, falling, rotating, swinging from poles, on ladders, whatever), you CAN try to create a series of state rules for transitioning from each one to another… and a conduit would be helpful in that case, sure.
But you could also just have a “ground locomotion” state machine, and an “air locomotion” state machine, and blend between those two state machine outputs in the master animgraph using a simple Blend Poses By Bool off of your IsFalling var.
Using state machines blended with other state machines, or state machines cached and called at various places INSIDE other state machines, is an extremely helpful practice. I have a locomotion state machine which I cache, and then a second “weapon usage” state machine where every possible weapon state has a call to that cached pose inside of its own state, so that the way each weapon blends with the base locomotion can be specified (based on how each weapon is held, etc). In your case, florian, you might consider having those “master state-override” animations simply exist outside of the state machine. Let them be blended in over the state machine’s final output, that way you don’t actually have to care what the state machine itself is doing when you stop playing its animation output back.
EDIT: Picture worth a thousand words. This is a pseudograph example but you can see how it would work; you have each set of mutually-independent states in its own machine, and then utilize high-level logic for “full machine blends” and “full machine transitions” so you don’t have to think about how each state interacts with each other state.
