The way Jason is using it here makes absolute sense: set variables of the animator and handle all the logic in the MonoBehaviour (MB). Using StateMachineBehaviours (SMB) can easily lead to awkwardly distributed code where part of the logic is at some SMBs and part is on MBs. Especially when the interface between SMBs and code+state outside the Animator becomes unclear. Just make sure you make your design decision very consciously here. If done right, SMBs can give you well encapsuled, reusable code. You can even change the behaviour of your entities in play mode as you can modify the state machine. But it can also give you lots of copy-pasta, redundant code, awkwardly distributed state, etc. and that can be hard to debug and maintain. You can also use Mecanim for logical state machines. However, you need to make sure to set all transitions to "no exit time" and 0 transition duration. Otherwise, state enter of your new state is called before OnStateExit of the previous. This is important to understand. With Mecanim multiple states can play simultaneously.
The multiple states playing at once because of transitions kind of makes this harder to use under some circumstances, which I honestly can't remember any right now I just know that I've run into it before. Doing 2d games and removing transitions makes them entirely useful but in 3d games with transitions and such I'm not sure exactly when one of these will trigger? As soon as a transition starts into a new state with that new state's event trigger? And if you had an exit condition on the one you were transitioning out of does it trigger when the transition starts or after you are completely out of the state?
state behaviours are super convinient but you have to be very carefull with them - from my experience it may cause the "animator hell" even worse. There is couple ways to make events - state behaviours, events on animation clips, events on FBX or in monobehaviour scripts... Pick one! Trust me. Don't mix those approuches - you will forget where you put this one bool-changing event and if you mix approuches it will be very frustrating to change anything in future
Something to help ease this a little bit is to always link them back to the relevant script from within the animation behaviour. For example if you wanted something to happen in your monobehaviour from an animation behaviour just put a guard at the beginning of your animation behaviour state that gets the component if it doesn't exist from your animator, then call a function on that, delegating the responsibility back to the monobehaviour. Example: override public void OnStateExit(Animator animator, AnimatorStateInfo stateInfo, int layerIndex) { if (!meleeSystem) meleeSystem = animator.GetComponentInParent(); meleeSystem.MeleeAttackEnd(); } Likewise with events in the animation clips you can do a similar thing, particularly if you have a model that isn't your base player object you can create an AnimationStateListener class that lives on the model with the animator and relays those calls back up to your monobehaviour in the player class. An example of this: public class AnimationStateListener : MonoBehaviour { MeleeSystem meleeAttack; private void Start() { if (!meleeAttack) meleeAttack = GetComponentInParent(); } //This is an animation event called from an animation, which then relays the command up to the proper script public void AttackDealDamage() { meleeAttack.AttackDealDamage(); } }
I used this a while ago, but it tends to become a hell of a mess and a dependency problem with so much code being separated for just a single state. ITOH, I was told that old school platformers did split characters in half (top/down) or even 4 different parts/limbs, because it eases the management of states and stances. For example, you can have the lower part of your player be jumping while its upper torso is currently shooting. This complex state usually would require additional code and animations for the whole body. All expert developers will tell you to write a FSM, but it would be also nice to have a middle solution that works for everybody and it's easy to learn.
I really like this kind of Short videos with Unity Pro Tips that we tend to learn with the Power of Experience 💪🏼😁 Already took notes 🎮 To use a FSM Pattern coupled with the Animations in the Animator seem to be a nice idea, btw. Thank You!
Thanks very much for the video! This is great! I was beginning to thing I was the only one using StateMachineBehaviours. At some point I learned how to make NPC FSMs using it, and with me it stuck and I kept using it. Since then the course that taught me it re-did the lectures and started using enums and switch cases instead. I always felt that StateMachineBehaviours was a much better way of doing it. Great for FSMs of course, I'm yet to make an NPC complex enough to warrant using behaviour trees or goap or anything
I don’t know know if you’ve done this before but if possible, can you make a tutorial or guide on the “Sub-State Machine” state in the animator to help keep the animator clean when there are a lot of animation states in your animator? Even though I’ve been using the animator for a long time, I found out about this some months ago. And I think not many indies, especially the new ones, know about it and they end up with a mess of an animator window.
Wish that you would have done early but better be late than never.... Extremely useful jason.. only one thing can you plzz do some tutorial thing on this topic it will be very useful for ton of people
A very important warning: Those Behaviour instances are SHARED. If you add persistent fields, things will work right for one character, but as soon as a second shares the same behaviour…Armageddon! The way Jason utilized it is perfect-absolute minimum code, no persistent fields/properties, with core logic remaining in the MonoBehaviour. I just wish he’d made more of a point of why he did it that way.
Actually, Unity's documentation lists that by default the Animator does instantiate a new instance of each behaviour define in the controller. The class attribute [SharedBetweenAnimators] controls how behaviours are instantiated. So they'll only be shared if you use that.
I feel like your second example is a very good use case for animation behaviours but the first one does not seem like a good practive as it creates a coupling of logic state and animation state. This can be difficult to debug if you are not familiar with the implementation as you would not expect the logic to be modified inside an animation and can create issues if an animator decides to replace this animator controller for some reason.
I knew about state behaviors, but I never realized they could be applied to whole layers. This is why I watch your channel, thank you!
Yorai is the Yoraiz0r, developer of Terraria. Wow
The way Jason is using it here makes absolute sense: set variables of the animator and handle all the logic in the MonoBehaviour (MB).
Using StateMachineBehaviours (SMB) can easily lead to awkwardly distributed code where part of the logic is at some SMBs and part is on MBs. Especially when the interface between SMBs and code+state outside the Animator becomes unclear. Just make sure you make your design decision very consciously here.
If done right, SMBs can give you well encapsuled, reusable code. You can even change the behaviour of your entities in play mode as you can modify the state machine. But it can also give you lots of copy-pasta, redundant code, awkwardly distributed state, etc. and that can be hard to debug and maintain.
You can also use Mecanim for logical state machines. However, you need to make sure to set all transitions to "no exit time" and 0 transition duration. Otherwise, state enter of your new state is called before OnStateExit of the previous. This is important to understand. With Mecanim multiple states can play simultaneously.
The multiple states playing at once because of transitions kind of makes this harder to use under some circumstances, which I honestly can't remember any right now I just know that I've run into it before. Doing 2d games and removing transitions makes them entirely useful but in 3d games with transitions and such I'm not sure exactly when one of these will trigger? As soon as a transition starts into a new state with that new state's event trigger? And if you had an exit condition on the one you were transitioning out of does it trigger when the transition starts or after you are completely out of the state?
Quite funny, I have seen that "Add Behavoior" for many years, but never tried to click on that... :) Great video!
state behaviours are super convinient but you have to be very carefull with them - from my experience it may cause the "animator hell" even worse. There is couple ways to make events - state behaviours, events on animation clips, events on FBX or in monobehaviour scripts... Pick one! Trust me. Don't mix those approuches - you will forget where you put this one bool-changing event and if you mix approuches it will be very frustrating to change anything in future
Something to help ease this a little bit is to always link them back to the relevant script from within the animation behaviour. For example if you wanted something to happen in your monobehaviour from an animation behaviour just put a guard at the beginning of your animation behaviour state that gets the component if it doesn't exist from your animator, then call a function on that, delegating the responsibility back to the monobehaviour.
Example:
override public void OnStateExit(Animator animator, AnimatorStateInfo stateInfo, int layerIndex) {
if (!meleeSystem) meleeSystem = animator.GetComponentInParent();
meleeSystem.MeleeAttackEnd();
}
Likewise with events in the animation clips you can do a similar thing, particularly if you have a model that isn't your base player object you can create an AnimationStateListener class that lives on the model with the animator and relays those calls back up to your monobehaviour in the player class.
An example of this:
public class AnimationStateListener : MonoBehaviour {
MeleeSystem meleeAttack;
private void Start() {
if (!meleeAttack) meleeAttack = GetComponentInParent();
}
//This is an animation event called from an animation, which then relays the command up to the proper script
public void AttackDealDamage() {
meleeAttack.AttackDealDamage();
}
}
I used this a while ago, but it tends to become a hell of a mess and a dependency problem with so much code being separated for just a single state.
ITOH, I was told that old school platformers did split characters in half (top/down) or even 4 different parts/limbs, because it eases the management of states and stances. For example, you can have the lower part of your player be jumping while its upper torso is currently shooting. This complex state usually would require additional code and animations for the whole body. All expert developers will tell you to write a FSM, but it would be also nice to have a middle solution that works for everybody and it's easy to learn.
what does ITOH stands for ?
@@captainnoyaux In the other hand... , by the way..., additionally...
@@carloslecina9029 thanks didn't know this acronym :)
I really like this kind of Short videos with Unity Pro Tips that we tend to learn with the Power of Experience 💪🏼😁
Already took notes 🎮
To use a FSM Pattern coupled with the Animations in the Animator seem to be a nice idea, btw.
Thank You!
I’ve never seen so many ducks without a single goose!
Be honest I'm mad I didn't see this video a week ago when I trying figure how to do all this. So much easier thank you
Thanks very much for the video! This is great! I was beginning to thing I was the only one using StateMachineBehaviours. At some point I learned how to make NPC FSMs using it, and with me it stuck and I kept using it. Since then the course that taught me it re-did the lectures and started using enums and switch cases instead. I always felt that StateMachineBehaviours was a much better way of doing it. Great for FSMs of course, I'm yet to make an NPC complex enough to warrant using behaviour trees or goap or anything
I don’t know know if you’ve done this before but if possible, can you make a tutorial or guide on the “Sub-State Machine” state in the animator to help keep the animator clean when there are a lot of animation states in your animator? Even though I’ve been using the animator for a long time, I found out about this some months ago. And I think not many indies, especially the new ones, know about it and they end up with a mess of an animator window.
That is some great information right here! Super resourceful video, well done!
you are a life saver Jason! 🥰
I learnt something new today!
Great one Jason
learned something new thank you
Brilliant! This is very helful information.
Wish that you would have done early but better be late than never.... Extremely useful jason.. only one thing can you plzz do some tutorial thing on this topic it will be very useful for ton of people
And also if possible can you also tell's the pros and cons of state machine in the tutorial (if you made up your mind about making the tutorial)
WOW. veryyyyyyyyy useful . thanks Jason. I'm Excited of watching this video🤩🤩🤩🤩💯💯💯💯💯💯💯💯💯
Yorai you s a fount of useful knowledge
A very important warning: Those Behaviour instances are SHARED. If you add persistent fields, things will work right for one character, but as soon as a second shares the same behaviour…Armageddon! The way Jason utilized it is perfect-absolute minimum code, no persistent fields/properties, with core logic remaining in the MonoBehaviour. I just wish he’d made more of a point of why he did it that way.
Actually, Unity's documentation lists that by default the Animator does instantiate a new instance of each behaviour define in the controller. The class attribute [SharedBetweenAnimators] controls how behaviours are instantiated. So they'll only be shared if you use that.
I found my behaviours don't work on synced layers, just fyi
I feel like your second example is a very good use case for animation behaviours but the first one does not seem like a good practive as it creates a coupling of logic state and animation state. This can be difficult to debug if you are not familiar with the implementation as you would not expect the logic to be modified inside an animation and can create issues if an animator decides to replace this animator controller for some reason.
Super helpful ❤❤❤
i did not know about that, thank you...
thank you
WHY ARE YOU YELLING AT US?
I don't think you want animator to control logic of your game
I used to agree, but yorai made a great argument for using it in specific scenarios and now I'm convinced :)