Hello everyone, hope this workflow is working well for you 😁. Following your amazing feedback on the topic, I put together a plugin for the Unity animator was does all the tricky logic behind the scenes. It only takes 10 seconds of setup and works straight out of the box. Might help y'all out a bit ua-cam.com/video/9tvDtS1vYuM/v-deo.html
Making the animationBrain abstract and having the default animation method abstract would force the child class to have the defaultAnimation method + having the Action variable would be unneccessary and the initialize parameter would not be neccessary.
I think this is great! But I take some minor architectural issues with how some of this logic was explained. Animation should be a layer on top of your game to give context as to what is happening, NOT something that manages direct control over how your game plays. More specifically that reload bit at the start, because what you said implies (A) reloading has a zero waiting period or hangover time where you aren't reloading anymore but animation lasts longer, and (B) possibly is purely aesthetic which serves no purpose than an extra button press that interrupts a game's core combat mechanic. In the first case, that means you have an issue where the animations are feeding players with misinformation on the state of what is happening in your game. In the second case, its self explanatory that its poor game design to have such a purely aesthetic feature be in the way of players utilizing your core mechanics without it being one itself. Reload times are supposed to be uninterruptible from shooting again by its game design to support more tension / periods of vulnerability, and should already be in your non-animation game logic meaning your animation shouldn't ever be in that position in the first place. Bah, I am just nitpicking your examples though. The video was great nonetheless, and tackles issues Unity's animator gets in the way of. Good work!
Yeah... fk knows how i found this video, but I will watch it tomorrow, also subbed and bell is turned on. I hope to find more advanved tutorials like this. Thanks king.
THANK YOU SO MUCH THIS IS TRULY AMAZING, Like back then I have to find freaking multiple animations online just for it to be slightly different, now this is so much better on so many levels!
At 14:49, I'm getting error CS0117 on line 54 for Animations.NONE, saying "'Animations' does not have a definition for 'NONE'. I'm using Unity 2022.3.8. Is there something I'm missing?
Hello, your tutorial is amazing. I did something similar but doing some improvements on it to dynamically add animations when they are played frist. So if you play "run forward" and it doesn't exist in the animations to add it and override the animation component. In my case, since my characters logic is all bound to Observable Properties, instead of having methods inside "PlayerMove", my "CharacterAnimationController" listens to the state changes "(like, state.IsGrounded.AddObserver(b => Play(b ? Animations.IDLE : Animations.JUMP, 1));" and it adapts itself to what it should do next. It makes it so I do not have to have the behaviours on falling, jumping, etc. but it looks at the y velocity and when it is -1 it just transitions itself to falling. Also, besides that, I am trying to figure out PlayableAPI to add certain animations to be played by one shot and then clear the animation but it is a little bit more difficult than what I thought. I just wanted to thank you, it gave me a couple of ideas on how to do my version of the system! Really, thank you!
Yo thanks! These are really great ideas. Adding listeners would really automate it, without the need of behaviours. If you would like, I put together a plugin called AnimatorCoder in a later video about a week ago. ua-cam.com/video/9tvDtS1vYuM/v-deo.html It has very little setup, it takes the ANIMATIONS enum and coverts its values into hashes so it basically skips a step. It also adds animator parameter logic and a few other things. I believe it might be the most optimised you can get with this technique.
The ability to lock a layer is not a native Unity feature. It is simply a bool[] in the animator brain script. When you set it to true (lock the layer), it changes what happens when you call AnimatorBrain.Play(). Now calling AnimatorBrain.Play() does nothing if the layer is locked. When the layer is locked, the AnimatorBrain won’t allow any new animations to play. This is required for animations that need to play all the way through and cannot be interrupted, such as a reload, hit, or death animation. When you come to play these animations, you set the layer to be locked, so no other animation can play. Then there is the option to bypass the lock. These are animations that should play regardless if the layer is locked, such as a death animation. Now if the player is reloading and gets hit, if the animation is set to bypass the lock in AnimatorBrain.Play(), it will play regardless if the layer is already locked. So nothing changes in the Unity Animator itself. It is simply additional logic in the AnimatorBrain script to keep track if it should call Animator.Crossfade() on the requested animation through AnimatorBrain.Play(). Does that kind of make sense?
1. Hold the CurrentAnimation: So you don't use Animator.Crossfade() on an already playing animation 2. Ability to lock/unlock layers: Some animations need to play all the way through without interuption 3. Play consequent animations: When an animation finishes, choose what animation to play next 4. Select animations through enums: Passing through an enum to play an animation is quick and easy In a nutshell, it adds a bunch additional checks to Animator.Crossfade() to ensure the requested animation is allowed to play.
This is all possible within the animator. Crossfading, Logic, Sequencing, Layering is all possible within the animation. If your animator state machine tree looks like the example images you showed, then you‘re not using it correctly. Animation state should never be managed by manually coding behavior. Animations should be derived from the state of the target object and not the other way around.
thanks! For the player controller, Brakeys has an excellent tutorial for it ua-cam.com/video/_QajrabyTJc/v-deo.html&pp=ygUgYnJha3lldHMgZmlyc3QgcGVyc29uIGNvbnRyb2xsZXI%3D
@@SmallHedgeHQ The site has closed. After many years of delivering game dev apparel we have decided to shut down Line of Code. It has been an absolute pleasure and we owe a big thanks to everyone who has bought and used our products. We wish all of you the best of luck in the future! Kind regards, The Brackeys Team
I never understood the problem with animator, I have a game with A LOT of animations and transitions between them. If you think about the animator like a behaviour tree, you can put all the 10 idle animations inside a "idle" sub-tree with its own logic and maybe even more sub-trees inside the sub-tree and all the 25 movement animations inside a "movement" sub-tree with a blend-tree or two. So you only have an idle node with its parameters to go for movement node in the main tree, and inside each you can have it similary clean. It all becomes incredibly well organised and easy to read... I really think the problem is people don't know how animator works, and they just drop all animations there and start linking them in the same "node"... 8:56 I mean, that animator looks more confusing than mine with more than 50 animations...
Yeah you can really optimise the Unity animator tab if you know how. I suppose it’s down to preference. Whether you prefer the animator tab or scripting.
Hello everyone, hope this workflow is working well for you 😁. Following your amazing feedback on the topic, I put together a plugin for the Unity animator was does all the tricky logic behind the scenes. It only takes 10 seconds of setup and works straight out of the box. Might help y'all out a bit ua-cam.com/video/9tvDtS1vYuM/v-deo.html
Making the animationBrain abstract and having the default animation method abstract would force the child class to have the defaultAnimation method + having the Action variable would be unneccessary and the initialize parameter would not be neccessary.
You are absolutely right. I completely overlooked the use of abstract methods and will make the change in the GitHub script.
That's awesome man! Will Definitely use it in my game
I think this is great! But I take some minor architectural issues with how some of this logic was explained. Animation should be a layer on top of your game to give context as to what is happening, NOT something that manages direct control over how your game plays. More specifically that reload bit at the start, because what you said implies (A) reloading has a zero waiting period or hangover time where you aren't reloading anymore but animation lasts longer, and (B) possibly is purely aesthetic which serves no purpose than an extra button press that interrupts a game's core combat mechanic. In the first case, that means you have an issue where the animations are feeding players with misinformation on the state of what is happening in your game. In the second case, its self explanatory that its poor game design to have such a purely aesthetic feature be in the way of players utilizing your core mechanics without it being one itself.
Reload times are supposed to be uninterruptible from shooting again by its game design to support more tension / periods of vulnerability, and should already be in your non-animation game logic meaning your animation shouldn't ever be in that position in the first place.
Bah, I am just nitpicking your examples though. The video was great nonetheless, and tackles issues Unity's animator gets in the way of. Good work!
My favorite part about this video is when he says "that's literally all we need" and then proceeds to type more code
never seen your vods before. 1:52 in i subbed. seems like high quality stuff
Great stuff, man! Just earned a new sub.
Hey!, how can I implement this with photon pun, since it works precesely with the animator parameters
Just use nested state machines like a normal person
holy crap that humming on the lamp is so annoying
Brother, I cannot believe the amount of work you just provided us. THANK YOU.
Liked and subscribed, is there anything you need?
man I cant Thank you enough😭😭
Yeah... fk knows how i found this video, but I will watch it tomorrow, also subbed and bell is turned on.
I hope to find more advanved tutorials like this.
Thanks king.
Could not get this working hit up hedge no reply :(
Stripped my game of it.
Sucks to hear. If you have a specific question, I can help you out with it :)
great thank you
I’m making souls like base systems for my masters project after Easter. You’re a lifesaver for this. Thank you!
Glad I could help! 😁
THANK YOU SO MUCH THIS IS TRULY AMAZING, Like back then I have to find freaking multiple animations online just for it to be slightly different, now this is so much better on so many levels!
does this method only works for 3d ?
For 2d and 3d! I actually showcase how to use these techniques in 2d in the next video of the series 😁ua-cam.com/video/9tvDtS1vYuM/v-deo.html
Yes, I always face animation hell, which looks like a spider web. Thanks
Super dope video! Huge thanx. Animatior can go autodelete itself, in a loop, no exit time.
At 14:49, I'm getting error CS0117 on line 54 for Animations.NONE, saying "'Animations' does not have a definition for 'NONE'. I'm using Unity 2022.3.8.
Is there something I'm missing?
nvm! I played ahead and saw that NONE was added under the Animations enum. My B
Hello, your tutorial is amazing. I did something similar but doing some improvements on it to dynamically add animations when they are played frist. So if you play "run forward" and it doesn't exist in the animations to add it and override the animation component.
In my case, since my characters logic is all bound to Observable Properties, instead of having methods inside "PlayerMove", my "CharacterAnimationController" listens to the state changes "(like, state.IsGrounded.AddObserver(b => Play(b ? Animations.IDLE : Animations.JUMP, 1));" and it adapts itself to what it should do next. It makes it so I do not have to have the behaviours on falling, jumping, etc. but it looks at the y velocity and when it is -1 it just transitions itself to falling.
Also, besides that, I am trying to figure out PlayableAPI to add certain animations to be played by one shot and then clear the animation but it is a little bit more difficult than what I thought.
I just wanted to thank you, it gave me a couple of ideas on how to do my version of the system! Really, thank you!
Yo thanks! These are really great ideas. Adding listeners would really automate it, without the need of behaviours.
If you would like, I put together a plugin called AnimatorCoder in a later video about a week ago.
ua-cam.com/video/9tvDtS1vYuM/v-deo.html
It has very little setup, it takes the ANIMATIONS enum and coverts its values into hashes so it basically skips a step. It also adds animator parameter logic and a few other things. I believe it might be the most optimised you can get with this technique.
Can you explain what "locking the layer" actually does. What changes in the actual Animator that says this is "locked"
The ability to lock a layer is not a native Unity feature. It is simply a bool[] in the animator brain script. When you set it to true (lock the layer), it changes what happens when you call AnimatorBrain.Play(). Now calling AnimatorBrain.Play() does nothing if the layer is locked. When the layer is locked, the AnimatorBrain won’t allow any new animations to play. This is required for animations that need to play all the way through and cannot be interrupted, such as a reload, hit, or death animation. When you come to play these animations, you set the layer to be locked, so no other animation can play.
Then there is the option to bypass the lock. These are animations that should play regardless if the layer is locked, such as a death animation. Now if the player is reloading and gets hit, if the animation is set to bypass the lock in AnimatorBrain.Play(), it will play regardless if the layer is already locked.
So nothing changes in the Unity Animator itself. It is simply additional logic in the AnimatorBrain script to keep track if it should call Animator.Crossfade() on the requested animation through AnimatorBrain.Play(). Does that kind of make sense?
The opposite of locked animations is unlocked animations!
Don't try to play tricks on me!
xD
this is awesome, and I even thought this was a channel with thousands of subs. Keep it up man
Thank you!
You are the real hero that the world needs. You just singe handedly solved a problem as big as the world hunger!
Solving Unity’s problems one burger at a time!
you can already play animations through code without all these wrappers. i dont understand what the point of this is.
1. Hold the CurrentAnimation: So you don't use Animator.Crossfade() on an already playing animation
2. Ability to lock/unlock layers: Some animations need to play all the way through without interuption
3. Play consequent animations: When an animation finishes, choose what animation to play next
4. Select animations through enums: Passing through an enum to play an animation is quick and easy
In a nutshell, it adds a bunch additional checks to Animator.Crossfade() to ensure the requested animation is allowed to play.
This is all possible within the animator. Crossfading, Logic, Sequencing, Layering is all possible within the animation. If your animator state machine tree looks like the example images you showed, then you‘re not using it correctly. Animation state should never be managed by manually coding behavior. Animations should be derived from the state of the target object and not the other way around.
Amazing!
player controller isnt there to test it have you a link ? great video and concept
thanks! For the player controller, Brakeys has an excellent tutorial for it ua-cam.com/video/_QajrabyTJc/v-deo.html&pp=ygUgYnJha3lldHMgZmlyc3QgcGVyc29uIGNvbnRyb2xsZXI%3D
@@SmallHedgeHQ The site has closed.
After many years of delivering game dev apparel we have decided to shut down Line of Code. It has been an absolute pleasure and we owe a big thanks to everyone who has bought and used our products.
We wish all of you the best of luck in the future!
Kind regards,
The Brackeys Team
Amazing ❤❤❤ thx
You are welcome 😁
I never understood the problem with animator, I have a game with A LOT of animations and transitions between them. If you think about the animator like a behaviour tree, you can put all the 10 idle animations inside a "idle" sub-tree with its own logic and maybe even more sub-trees inside the sub-tree and all the 25 movement animations inside a "movement" sub-tree with a blend-tree or two. So you only have an idle node with its parameters to go for movement node in the main tree, and inside each you can have it similary clean. It all becomes incredibly well organised and easy to read...
I really think the problem is people don't know how animator works, and they just drop all animations there and start linking them in the same "node"...
8:56 I mean, that animator looks more confusing than mine with more than 50 animations...
Yeah you can really optimise the Unity animator tab if you know how. I suppose it’s down to preference. Whether you prefer the animator tab or scripting.