I’d like to suggest a change to the usability of the Conduit node in animation state machines. The actual functionality is great, but I’d like to store my multiple states inside the Conduit node and have an arrow going into the node be the rule to reach the Conduit (like any other state would require).
My reason is clutter.
I have 8 stop animations that all belong to the transition state between Walking -> Idle. WalkFwdStop_LU, WalkFwdStop_RU, StrafeLeftStop_LU, etc.
And I have 8 stop animations that all belong to the Running -> Idle state. And Crouch Walking -> Idle.
And I have 8 start animations for the inverse of all of those states. That’s 48 state nodes, with tiny arrow lines connecting them all together in the most messy ways possible (what if you are stopping from a Run then start walking forward midway through your stop animation? Need a rule to handle that). It’s a hot mess - nearly impossible to manage even for me, who created the state machine.
If the conduits could somehow encapsulate those specific states it would clear up my state machines dramatically and make them less soul crushing to look at.
This is an older picture of my state machine, which only showcases 8 of my 48 “Start/Stop” state nodes. It’s freaking spaghetti now and I really can’t even determine which line goes to which state without hunting for 5+ minutes. That makes it really difficult to work when you need to adjust one “thing” that affects 16 states.
Wow… I’m just getting into the whole animation “realm”, learning about blend spaces, state machines and all that… then I saw that scary spaghetti monster from the answerhub post o_o.
That’s just frightening… I don’t even know if I want to mess with animations anymore lol
Anyway sorry for being slightly off-topic here, I just had no idea state machines can get that complicated just for “basic” movement.
I’m curious though, and forgive me if I sound like a noob (cause I am xD) but isn’t there a better way to handle all those one-off animations (like walkFwdStart, walkBwdStop etc.)? do you absolutely have to make a state for each one of those?
I mean if you were to make a fighting game for example, with 100+ different moves, you would need 100+ different states plus transition rules? :eek:
Not sure if this works for you, but you could setup all those transitions inside the “Blend Graph” of the “Transition Rule” itself. I think it would clean up you spaghetti stuff quite a bit
You can see they didn’t have the Blend Graph when they made the documentation * Edit: This might not be the case since they didn’t set the blend to custom, but I guess that’s not really the point I was trying to make.*
My follow-up question is, how do you apply logic in the blend graph? I’d like to have Idle -> Walk, with the transition rule handling all 4 of my WalkStart directional animations by determining the direction (a variable) the player is moving.
I would also like to see some improvement on the state machines. Its a very nice system, but it can get a little big when trying to get alot of different states, idle, crawling, crouching, walking, running, jumping, leaping, hovering, dying.
The state machine system can lead us to create spaghetti chaos like the one we see in the picture. However, that’s not the way everyone uses them. I would suggest, rather than improving them, give users more learning material on how to take the most of them.
A simple blend poses by Bool, using a “Crouch” Boolean would already half your graph, allowing you to reuse those states.
I’ll give you here example of a more expandable StateMachine which would allow you to have not only 2 states, but as many as you want, also could be shared amongst different characters.
Did you know there is a way to expose a pin of an animation or blend space node? I find it useful to connect different context sensitive animations. This way, you could have the same idle state playing your “Standing” and your “Crouching” animations. It’s a variable right? so just store those animation names via the eventgraph. Using something like this would already reduce your graph by half, and it would also make it scalable, in case one day you decide you need your character to swim.
As you can see here, it could be your standing walkrun and your crouching walkrun. Blendspaces accept a variable, like speed, this means you could have your land2idle, land2walk, and land2run animations in a BlendSpace rather than in 3 different states.
Let’s go back to the pins tho, BlendSpaces are explained somewhere on youtube, a google search could def help you with that. How do we get Animations in those slots?
What I did was create a few **structs ** so I could avoid hard coding any of those animation names. This also allows me to change not only character states, but also characters themselves. (This is a bit more complex so I won’t go into detail in this post)
These are the blueprint nodes we will need to store our animations.
The Structs are have in them Blendspace and animations variables, depending on what we want to use in the AnimGraph. I also add a “loop” boolean, you can add as many extras as you want, additive animations… anything you can imagine.
We then add it as a CLASS variable on our AnimBlueprint and we can get it’s defaults, all those animations!!
We then need a “current animations” struct so we can plug the animation names to that final slot we’ll use on our state machine. Here I’ve used a simple Boolean to change which ones to store, but you if you have more states you can use enums, structs, you can change anims based on speed, have a flying movementset if the character is in the air, or a swimming one if he/she is underwater.
As you can see here, the same blendspace allows me to play crouch and standing idles, halving all your different states, and if you then combine the lands to use a single state and a blendspace your spagetthi becomes a very tidy set of just:
lol
