I have an Attack state that gets triggered by C++ code and this state plays an animation contained in a variable (which is modified by C++). So I have one state for all attacks. This works very well for attacks that only need one animation, but not for attacks that need two or more animations.
One ranged attack, for instance, requires the player to aim before executing, so I have a sort of “charge” animation while the player is aiming and and when the player wishes to fire the attack another animation should be played. This would require a state machine only for that attack, and I can’t have a “state machine asset” that I can put in a variable and play whenever I want.
One option would be to create a state in the state machine for each animation of this attack (or even better, a sub state machine containing the animation states), but if I do this for 30 attacks, won’t the state machine get too polluted?
Opinion wise state machines is so 1999 and out of date as to more advanced options that prevents most of the problems traced back to the animation migration getting stuck inside the state machine. For one thing it usually takes an argument or condition to move out of one state into another and on top of that the argument usually has a statement that says something like “do not leave the state until there is 10% left in the take” so a lot of times the animation has to wait until it can move out of the state which just adds to the latency.
State Machines are OK for things like locomotion, as one can only be in one movement state at any give time, but best practice would be to keep the animation migration pathway in the tree and there are more than a few nod options, like blend on int, where you can get into and out of any given state as an absolute do it now event.
That said.
There is generally two blended state requirements based on a reactive event driven by the player, assuming in place, of locomotion and a action state that the player needs to preform while moving. As stated state machine is OK for this but for a much more complicated animation system your action states should be introduced into the migration path “after” the locomotion state and layered buy using blend per bone so you can add as many as you wish with out having to bloat the state machine and as you mentioned gets polluted over time.
The best option I’ve found is using Montages as you can create lists, determine the trigger on the controller end, and keep every thing data driven.
So the logic path would be something like the player is running, which can be easily be managed by the state machine, and while running reloads a weapon, which is layered using a slot and supplied animation Montage, that you can keep adding with out having the state machine collapse on you at some point as it becomes to heavy.
Hi @FrankieV, thanks for your response. I always thought state machines were kinda messy and there had to be another option, but I never found any. I tried learning montages a while ago but I didn’t understand them, after reading your post I gave them another try and I think I’m actually going to use them. They do provide a sort of state and can be easily controlled by C++. Plus, since they are assets, they can be stored in variables, allowing me to have a very flexible system.
Well with in context of wanting to do your “stuff” in C++ and use the animation BP’s animgraph then it makes total sense to avoid the use of a state machine whenever possible. As I’ve mentioned it takes arguments to get into and out of a given state.
The more logical approach is to keep everything data driven as to the need for a change of state than evaluating that there has been a change of state with in the event graph directly driven by whatever control input you are using.
As a concept you could add in two variables on the controller input end, since the player can only be in one state at any given time, of say an integer value of “locomotion” and “action” to account for the basic two needs for layered animation. In this configuration the animation BP needs to only cast for a change state as to just the two variables rather than playing twenty questions as to the total number of possible state changes available.
The only logical reason to use a state machine is if one has no coding skills where if someone does then then what the coder needs as a reactive state change can be assigned to a variable as to the give change. Lets say you just need the player to walk forward. For that action a state change request can be sent via the “locomotion” variable as a fixed integer value of say 10. If you don’t have C++ skills then to change the state one would have to cast to the movement component for speed and direction changes.
So sure your impression, as a coder, that state machines are messy is very much true as it violates the rules of a 100% data driven design and if anything is given far to much credit as the preferred way.
After all there is only one state machine where there are a boat load of nodes to use as a switch based on a single variable as to the needed state change.
