Thanks for making such great sprites! They're one of the first ones I reach for when prototyping. I'm happy you don't mind me using them in a video like this
If I hadn't known Finite State Machines for years beforehand, I would definitely know by now! Your concise concept & excellent explanation makes FSMs - an often over-complicated yet rather basic topic - easily understandable by beginners as well as intermediate developers IMHO. Awesome content quality I have rarely encountered with video tutorials, and especially on RUclips. Nicely done, keep it up!
@@impregnat0rI mean if you are coding you should take it into consideration yourself. Also, most people don’t start coding with GDScript. Surely some do, but not the majority. In those instances they should already be familiar with scripts working in conjunction with one another. I’ve never thought to put all my lines in one single script, but I also am in school for computer science and have had an advantage of learning good habits because of that.
UPDATE: For this video, I wasn't able to release the source code because of paid assets, but I have created a new project for my most recent video and it uses nearly an identical state machine. If source code would help, I highly recommend checking that out: github.com/Bitlytic/Strategy-GDScript/tree/master/Objects/Scripts/Enemy ERRATA - For the state class, the Process and Physics_Process functions are different than the built in _process and _physics_process functions. This should be clearer and I recommend using names like state_process and state_physics_process to avoid confusion. - 3:31, the enter and exit functions called off of current_state and new_state should be capitalized
a good idea. Thank you for your great video. Ill propably input an "EnemyState" extending "State" as for my navigation code i am working with a NavMesh and the export values are already exploding
@@zysdotaas far as i understood he is using "Process" because it gives him more control as in the State Manager he then assignes _process() state_process is just a better name to differenciate it from the base godot class
I don't think it's ya'll's faults... He does a lot of things in between the cuts and it really disrupts the flow of it. I found myself having to watch the same parts over and over again only to realize it's not working because he did something in between the cuts that I didn't notice. It's a truly awful way to approach a video like this, in my opinion. He's trying to streamline it but what actually ends up happening is critical steps become exceptionally easily overlooked.
For anyone who is encountering an "invalid call" error, change the .exit() and .enter() at the bottom of the state machine scripts to .Exit() and .Enter() , this fixed all my issues.
Just wanna say that you did a great job explaining everything. Lots of youtubers often forget to bridge the gap between what they know and what actual beginners know. In the military we used to call it "barney style". Directions given in a way that a child could understand, and under the assumption that an adult could then branch out and use these tools for a complex mission.
I concur. This youtuber has the good stuff in regards to teaching absolute beginners to understand things like State, Finite Machine State, etc. This channel is a treasure for indie godot devs.
@@PhotoBomber unfortunately tutorials are very general and you wont find perfectly catered material online or even in a classroom the only way you can achieve that is with a 1 on 1 tutor. i will say if it didnt make sense to come back to it after taking some notes and see if it comes together better with a different perspective. remember that learning how to code or really any skill has less to do with curriculum and more with immersion. aka if you want to learn how to code a game, the most efficient way is to actually code a game. along the way you will be able to identify what you know / don't know and then tutorials like this will become much more useful.
Awesome video! A neat trick for switching states: using the return value from the state's process function instead of signals. That way, you can have @export variables for each state to define its next potential states, and return them to the state manager that does the switching This also removes the need for a dictionary!
I dont even understand state machines yet, I used this purely for knowing how to make something which follows the player. Already its been an incredible help, given a few months of learning I imagine the other parts of this will help me too. For some reason the previous things I'd tried like 'get_root' and copying node path were not working and I don't know why. But this worked, and knowing about groups is good too!
To those unfamiliar, don’t be hard on yourself. There’s layers of abstraction operating to grasp this easily. One can recommend: To understand state machines or the state pattern; learn design patterns; to learn patterns learn oop to a basic degree; to understand oop learn programming at a procedural basic level There’s layers here, I genuinely went from this video before my Java oop course building a gui learning about polymorphism, encapsulation, overloading and overriding , events and interfaces And now coming after that I grasp everything instantly
Thank you for the video. I understood more here than I have from other state machine tutorial videos. I wish there was a video that extended the explanations of the logic behind each step. If I can understand why something is doing something else, I can usually remember how to code that situation in the future.
This is a great tutorial! I learned how state machines work and was even able to change the code to make it work as a hierarchical state machine! Thanks!
I do not comment that much on RUclips videos. However I wanted to say that I wanted to learn how states machines were implemented on Godot and I never really grasped how. But this video that I found randomly explained perfectly the way. It changed my to make enemy AI. Thank you so much !
i'm new to really getting into the code, gamedev and godot overall, but i find it so interesting to see advanced methods since i only see beginners' guides that don't show how to make more complex mecanics so thanks !
Thanks for this intro to the state machines! I kinda improvised my state machines for the first time in my game recently, and implemented bird behavior with them, and later moved my player code to state machine. And I am glad to see that I pretty much got the same structure for the code: my states have start, end, shouldTransition and next (state), which is very similar to yours!
Super good video, great outline to start making Finite State Machines in a game. Used this with other tutorials to get a basic Idle/Run/Airborne state machine working in a 2D platformer. Great lesson overall! Took a little while to realise i needed to add "owner" as the prefix to a lot of values, as it's not the state nor statemachine that was holding the velocity and gravity variables, but the Player Object instead.
You deserve all the subscribers in the fucking world. Your video is well explained and structured. Waaayyyy better than a lot of other "tutorials" where they talk, code and record on the fly, resulting in them jumping around and not being coherent.
Wow thanks m8, this worked like a charm for my own project. I can't wait to keep building on it! With component architecture, Godot really is so unbelievably intuitive relative to other software.
I loved that you pre-typed/pasted your code to make it faster and remove typos while going, and holy cow that went by fast! I'm going to have to really rely on the spacebar 😅, but I really liked the content! Very clean explanation.
What I think is great about this tutorial is that you don't need to know about the way each state behaves. I like that this isn't the main focus as each state for each game is different for each game dev. At the same time, each state explained here is also extremely versatile due to it's simplicity so if you wanted to you could still use it and just iterate upon it later. But just to know how states work is quite wonderful.
Long time had i suffered having no idea how to build such a state machine thing, before I found this. This tutorial is of great help. Thanks a lot for your work!
Good example! Nice and simple. I usually use an enum for the states instead of strings...though this can be mildly difficult in Godot since the enum has to be imported into everything somehow. For one project I had an autoload class just for all the enums, but I'm not sure this is the best way to do it. I like the way the editor knows what the states are called after because these are in the enum. Maybe it's not as simple, but I find it harder to mess up.
As an experienced programmer who has had to deal with node-based state machines written by others: please start using enums and stop overcomplicating state machines with subnodes, signals, impostor update functions, etc.
@@SafetyKitten They're harder to debug and navigate around, they have more potential for bugs that are difficult to spot, and they add computational overhead, for little benefit in most cases.
@leejesm Basically, yes. If the amount of code starts being too much, I split it first into sensible, state-independent components, and if that's not enough, into scripts containing each state's logic. Crucially, those scripts are just holders for functions - they don't inherit Node, I don't have to cross-reference them with the scene tree, they have no implicitly called logic, so they're much easier to follow and reason about. The state machine script is the only authority on which state we're currently in, and therefore which logic will run.
@@Outfrost That sounds really efficient, to boot, but I'm only just understanding. I get the second part where you talk about scripts containing just each state's logic. these states don't inherit from Node, or anything and are called upon by the SM Controller. Please, what do you mean by "state-independent components" in a single script state machine? can you give me an example? are the components the states themselves as methods/functions? are they methods/functions that more than one state might share? (ex. "falling" state and "jumping" state being similar, they might share a 'component').
One of the best godot tutorial videos. In the past with Unity, I had built a very complicated state machine without any tutorials, and I wish I had seen something such as this, because I wouldn't have so much spagghetti (e.g. once the physics state machine was merged with AI behaviour, tech debt was sealed)
ideally you would want to have the states to be independent of each other, since if you wanted to create a new enemy that instead of following, it runs away when the player you would have to make minor rewrites to your states to make it work. (Instead of using the same wander state, and just changing export variables for example)
@Entropy Will Destroy Us All you could either extend the state machine class for more complicated ai, or you could create an event listener that waits for a condition or a set of conditions ( probably just a signal) and then asks the standing to transition to another state
thank you so much. this guide helped me alot. I ended up re-writing the whole player code but I've finally managed to implement player movement and auto attack system without weird ass bugs. so it was worth it!
I used this approach for a while in situations when the `match` switch approach gets too complicated. In a project with action platformer controls this approach wasn't enough too. So I blended it with the behavior tree style - states having under states that get checked every frame if that will execute its logic for the current frame. Like PrimaryState (WallSlide, Fly up, Fall, Run, Idle) and JumpGroup( Walljump, JumpBuffer, DoubleJump, JumpDown, Jump). In a hierarchical order. Now I'm thinking about ways to improve it.
For me, the next step was to define hierarchical states so that shared behavior can be defined in ancestor states. For example, WalkState inherits TravelState. TravelState exports a speed property that it uses to determine velocity along with the input_direction property that it inherits from the DirectionInput state. Most of my states also are descended from an AnimationState which exports a property for the animation name, the animated sprite node, and starts the animation in the enter method. The downside to this approach in Godot 4 is that since there is no longer any implicit super() call, you need to remember to call that anytime you override one of the state methods, and as well check if the superclass logic returned a new state that you should transition to instead. Lastly, there's also no reason your StateMachine class can't also inherit State and be a state of its own with its own child states to further modularize your behavior, especially if there's cases you want to consider some external conditions and don't want to bloat your root state machine.
@@zarblitz Do you guys use gdscript or C# for your code? Would writing state machines be better in one or the other? Do you have source code for your method? I'm just interested in learning how your method works.
I did not see such useful video for a while. Al three for Godot actually. Subscribed. So please do more :) It really helps me to structure knowledge I already have and get new tricks to use.
I got into Godot literally yesterday, and I've already watched all your videos on it. You provide perfectly concise and understandable content. Thank you for doing what you do, will be looking forward to more!
Finally! I find tutorial with good code. With early return implementation, value verification and without other smell code. It's simple and brilliant 👏
HEY YO MY MAN im one of those that spends hours researching tutorials and i have a very large bone to pick with how the majority of people (even in great istitutions like universities) teaches things. and since others already pointed it out im not gonna repeat myself and just say: you u got som good shit goin. please keep on making godot/gamedev tutorials im sure your following will grow! and of course, thank you very much for the effort you put in making these videos!
This is one of the best tutorials and implementations I have ever seen. It's a shame that you haven't posted any recent videos as your content is very helpful. :(
@@Bitlytic Please make a "Utility AI" tutorial video. I know how to create a Utility AI in Unity, but Godot structure is different and really mess with my way of thinking.
@bitlytic - I know these are probably really time intensive to make but I have to say you do it so well. I hope you can do more. They've really helped me understand a lot of complex issues as a new developer in Godot.
Coming from Unity my first approach was to create states as Resources and add them in a list in the State Machine. Your solution utilises the Node methods like Update, which I had to call externally from the state machine. It looks like a logical way of doing it matching the usual Godot modular architecture.
There's a much simpler way to visualize a state machine. to implement any state machine that is valid for ANY kind of state, you only need 1 function, one function that takes a state as input and returns a state as output. so change_state(new_state: State) -> State If you accomplish that, through category theory analysis you have a complete functional and valid state machine. Cuz a state machine is just a monoid in the category of types. (if you want to know the theory and rigorous reason why is that true is because a state machine can be defined by a monoid in the category of types) and that's also why languages that dont have strong typing like python are obsolete in comparisson to C# or C++, cuz type matching allow you to use category theory to simplify your code by an insanity. the way i do it is simply inside the change_state function that is a public method in the state_machine class i call only 2 things. first i change the current_state property of the state_machine to be equal to the new state, then i call new_state.onAttach(state_machine, Entity) the onAttach is a method that is present on every single State object (which can be guaranteed to be true using interfaces) and is the basic functionality that must be called at the momment that state is activated. this method also allows that this same state machine structure can be used for anything in my code, player, NPC's, animations, sounds, events, anything that requires state changing i can control using the same structure. if anyone is interested in learning more about this functional approach for statemachines just call me out.
Such a simple and brief, straight to the point tutorial. I'd like to see more states as a part two, like one to circle/strafe around the player and attack, and maybe a second type of attack.
Top marks from me! I particularly like how you've approached decoupling the reference to the CharacterBody in the state by using an exported variable. This was always my gripe with other implementations and didng feel very clean at all.
Good Tutorial. However when it comes to somewhat beginner Tutorials like this one, I'm a big advocate of "Show, don't tell". The examples at the very end are certainly worth tackling, if not for code-re-usability and decoupling, which is a hard concept to grasp for game development. The Video being this short would certainly not be degraded by 3 more minutes of you showing these concepts, at least briefly.
Pro tip: if you’re designing your state machine to check if the state is valid _inside_ the state itself rather than the main state, make sure to set current_state = new_state _before_ state.enter() is called on the State Machine, otherwise your entity will get stuck in the transition forever. E.x. the main “idle” state will always transition to “move” if an input is pressed, then “move” checks if it’s actually _allowed_ to move in the enter() function before deciding to continue or transition back to the idle state. I’m doing this for my player’s state machine because there’s a lot of variables to check per state if the player is actually allowed to enter the state, and it’s easier to check within the state’s enter() function rather than the main state.
I've done something similar, but handled the processing inside each state, making a State Machine handler unecessary. I think this also grants more independence and flexibility to states as long as you do not have some very obvious common behavior you want handled by the State Machine script.
How a awesome tutorial! it's clear and useful. I am newbie in program and i can understand from this video. I really hope you keep doing them! I miss you Bro😄
Amazing tutorial! I would love to hear your explanation on concurrent state machines as that's still something I'm struggling with. (For instance: Having a bird enemy which can idle, wander, follow and attack, but also be on the ground or flying, without having to make 8 states in a single state machine)
Great video man, very helpful. But man do you go fast in some parts. i had to throw it on .25 speed at 5:40 to see what you were even doing. Edit: I spent at least half an hour trouble shooting errors I kept getting. Turns out it was the fact that I capitalized the "player" group so it wasn't finding the player's global position because it was searching for "player" not "Player". Gotta love case sensitive code...
I started to notice a lot of traffic coming in from RUclips and I think I just found one of the reasons why. Thanks for linking my sprites. 😊
Thanks for making such great sprites! They're one of the first ones I reach for when prototyping. I'm happy you don't mind me using them in a video like this
I feel like I've used your dinos for prototyping every platformer I've made, you're a legend within my group
@@alt-q1y That honestly almost made me tear up...
@@ArksDigital My whole college class uses your sprites! :D They're too cute.
Yeah those dinos are super cute. I kinda wanna make a whole game using them (maybe one day) 🖤
If I hadn't known Finite State Machines for years beforehand, I would definitely know by now!
Your concise concept & excellent explanation makes FSMs - an often over-complicated yet rather basic topic - easily understandable by beginners as well as intermediate developers IMHO.
Awesome content quality I have rarely encountered with video tutorials, and especially on RUclips.
Nicely done, keep it up!
so you are telling me that there is better way to manage code than writing 2000+ lines in single Gdscript?
@@impregnat0rjust write good code lulz
(obv joke is obv)
😂😂😂
Can I get a side of garlic bread with that spaghetti code? 🍝 🍝 🍝
@@impregnat0rI mean if you are coding you should take it into consideration yourself. Also, most people don’t start coding with GDScript. Surely some do, but not the majority. In those instances they should already be familiar with scripts working in conjunction with one another. I’ve never thought to put all my lines in one single script, but I also am in school for computer science and have had an advantage of learning good habits because of that.
@@impregnat0r also the approach of using dictionaries in this tutorial is an inefficient method.
UPDATE:
For this video, I wasn't able to release the source code because of paid assets, but I have created a new project for my most recent video and it uses nearly an identical state machine. If source code would help, I highly recommend checking that out:
github.com/Bitlytic/Strategy-GDScript/tree/master/Objects/Scripts/Enemy
ERRATA
- For the state class, the Process and Physics_Process functions are different than the built in _process and _physics_process functions. This should be clearer and I recommend using names like state_process and state_physics_process to avoid confusion.
- 3:31, the enter and exit functions called off of current_state and new_state should be capitalized
THANK YOU!
Im confused, so is it supposed to be _process and _physics_process like in the video, or Process and Physics_Process like in the comment?
@@zysdota The main issue for me was my Exit and Enter functions weren't' capitalized
a good idea. Thank you for your great video. Ill propably input an "EnemyState" extending "State" as for my navigation code i am working with a NavMesh and the export values are already exploding
@@zysdotaas far as i understood he is using "Process" because it gives him more control as in the State Manager he then assignes _process()
state_process is just a better name to differenciate it from the base godot class
Unashamed to admit I set the speed of the video to 0.75 and rewound the video dozens of times.
How else would you learn
I understand almost none of this. I tried to follow, but my brain keeps tuning out lol
@@micahrobbins8353 Do it in bite size amounts.
I don't think it's ya'll's faults... He does a lot of things in between the cuts and it really disrupts the flow of it.
I found myself having to watch the same parts over and over again only to realize it's not working because he did something in between the cuts that I didn't notice.
It's a truly awful way to approach a video like this, in my opinion.
He's trying to streamline it but what actually ends up happening is critical steps become exceptionally easily overlooked.
I assume most people do
For anyone who is encountering an "invalid call" error, change the .exit() and .enter() at the bottom of the state machine scripts to .Exit() and .Enter() , this fixed all my issues.
It took me forever to discover this. Thank you so much!
Just wanna say that you did a great job explaining everything. Lots of youtubers often forget to bridge the gap between what they know and what actual beginners know. In the military we used to call it "barney style". Directions given in a way that a child could understand, and under the assumption that an adult could then branch out and use these tools for a complex mission.
this is what everyone needs to adopt!
I concur. This youtuber has the good stuff in regards to teaching absolute beginners to understand things like State, Finite Machine State, etc.
This channel is a treasure for indie godot devs.
definitely not a beginner tutorial, way too fast and didn't explain a lot of things, or maybe i'm just slow
@@PhotoBomber unfortunately tutorials are very general and you wont find perfectly catered material online or even in a classroom the only way you can achieve that is with a 1 on 1 tutor. i will say if it didnt make sense to come back to it after taking some notes and see if it comes together better with a different perspective. remember that learning how to code or really any skill has less to do with curriculum and more with immersion. aka if you want to learn how to code a game, the most efficient way is to actually code a game. along the way you will be able to identify what you know / don't know and then tutorials like this will become much more useful.
@@OHTASISAN I'm using chatgpt to learn to code, it's quite the 1 on 1 tutor, and catered to my preferences
I really love this tutorial,
Simple straight to the point and very intuitive.
Thanks for the amazing tutorial.
Please keep doing more Godot tutorials! Even as a total beginner who knows nothing about coding, I was getting something out of this.
Awesome video!
A neat trick for switching states: using the return value from the state's process function instead of signals.
That way, you can have @export variables for each state to define its next potential states, and return them to the state manager that does the switching
This also removes the need for a dictionary!
So much of this is flying over my head, I weep
UPDATE
I'VE MADE IT WORK for 2d side-scrolling character controller.
... and I only slightly don't understand how it works
Nice
It’s just basic object oriented programming.
@@marcelslofstra2157 Thanks :T
I've watched so many tutorials on state machines and never understood them until now. Thank you very much!
I dont even understand state machines yet, I used this purely for knowing how to make something which follows the player. Already its been an incredible help, given a few months of learning I imagine the other parts of this will help me too. For some reason the previous things I'd tried like 'get_root' and copying node path were not working and I don't know why. But this worked, and knowing about groups is good too!
To those unfamiliar, don’t be hard on yourself. There’s layers of abstraction operating to grasp this easily.
One can recommend:
To understand state machines or the state pattern; learn design patterns; to learn patterns learn oop to a basic degree; to understand oop learn programming at a procedural basic level
There’s layers here, I genuinely went from this video before my Java oop course building a gui learning about polymorphism, encapsulation, overloading and overriding , events and interfaces
And now coming after that I grasp everything instantly
I LOVE your Godot tutorials, I really hope you keep doing them!
This is the most beautiful explanation of state machine I have come across. Kudos!
Thank you for the video. I understood more here than I have from other state machine tutorial videos. I wish there was a video that extended the explanations of the logic behind each step. If I can understand why something is doing something else, I can usually remember how to code that situation in the future.
a good tutorial that doesnt start with a 2hours intro , thank you
Man, this tutorials are amazing. I subscribed and I'm waiting for more.
Thanks
This is a great tutorial! I learned how state machines work and was even able to change the code to make it work as a hierarchical state machine! Thanks!
I do not comment that much on RUclips videos. However I wanted to say that I wanted to learn how states machines were implemented on Godot and I never really grasped how. But this video that I found randomly explained perfectly the way. It changed my to make enemy AI. Thank you so much !
fairly dense for me but VERY helpful and not too dense to implement one step at a time. This is exactly what I needed.
i'm new to really getting into the code, gamedev and godot overall, but i find it so interesting to see advanced methods since i only see beginners' guides that don't show how to make more complex mecanics so thanks !
Thanks for this intro to the state machines! I kinda improvised my state machines for the first time in my game recently, and implemented bird behavior with them, and later moved my player code to state machine. And I am glad to see that I pretty much got the same structure for the code: my states have start, end, shouldTransition and next (state), which is very similar to yours!
A little too fast-paced but I get it from a video that says "under 10 minutes" great way to explain things dude! I learned a lot
Thank you for the intro to this. Really good help at the beginning stages of developing a game.
as a complete beginner to godot but experienced with programming i could hardly follow sometimes, but its a good toturial and in the end it made sense
Super good video, great outline to start making Finite State Machines in a game. Used this with other tutorials to get a basic Idle/Run/Airborne state machine working in a 2D platformer. Great lesson overall!
Took a little while to realise i needed to add "owner" as the prefix to a lot of values, as it's not the state nor statemachine that was holding the velocity and gravity variables, but the Player Object instead.
I really like how the tutorial is fast paced but still gives enough info to understand the code
You deserve all the subscribers in the fucking world. Your video is well explained and structured. Waaayyyy better than a lot of other "tutorials" where they talk, code and record on the fly, resulting in them jumping around and not being coherent.
Wow thanks m8, this worked like a charm for my own project. I can't wait to keep building on it!
With component architecture, Godot really is so unbelievably intuitive relative to other software.
Wait how did you get past the error with the transition?
@@soundrogue4472 What do you mean. Signals handle state transitions as per the video
You have made the best Godot tutorials i have seen. You explain everything so clearly. Keep up the good work.
I loved that you pre-typed/pasted your code to make it faster and remove typos while going, and holy cow that went by fast! I'm going to have to really rely on the spacebar 😅, but I really liked the content! Very clean explanation.
What I think is great about this tutorial is that you don't need to know about the way each state behaves. I like that this isn't the main focus as each state for each game is different for each game dev.
At the same time, each state explained here is also extremely versatile due to it's simplicity so if you wanted to you could still use it and just iterate upon it later. But just to know how states work is quite wonderful.
Long time had i suffered having no idea how to build such a state machine thing, before I found this.
This tutorial is of great help. Thanks a lot for your work!
Good example! Nice and simple. I usually use an enum for the states instead of strings...though this can be mildly difficult in Godot since the enum has to be imported into everything somehow. For one project I had an autoload class just for all the enums, but I'm not sure this is the best way to do it. I like the way the editor knows what the states are called after because these are in the enum. Maybe it's not as simple, but I find it harder to mess up.
As an experienced programmer who has had to deal with node-based state machines written by others: please start using enums and stop overcomplicating state machines with subnodes, signals, impostor update functions, etc.
Can you elaborate a bit on what's so bad about these?
@@SafetyKitten They're harder to debug and navigate around, they have more potential for bugs that are difficult to spot, and they add computational overhead, for little benefit in most cases.
Hey, can you also elaborate what you mean by this? Are you just using a single script using enums and switch-case to control the state?
@leejesm Basically, yes. If the amount of code starts being too much, I split it first into sensible, state-independent components, and if that's not enough, into scripts containing each state's logic. Crucially, those scripts are just holders for functions - they don't inherit Node, I don't have to cross-reference them with the scene tree, they have no implicitly called logic, so they're much easier to follow and reason about. The state machine script is the only authority on which state we're currently in, and therefore which logic will run.
@@Outfrost That sounds really efficient, to boot, but I'm only just understanding. I get the second part where you talk about scripts containing just each state's logic. these states don't inherit from Node, or anything and are called upon by the SM Controller. Please, what do you mean by "state-independent components" in a single script state machine? can you give me an example? are the components the states themselves as methods/functions? are they methods/functions that more than one state might share? (ex. "falling" state and "jumping" state being similar, they might share a 'component').
One of the best godot tutorial videos. In the past with Unity, I had built a very complicated state machine without any tutorials, and I wish I had seen something such as this, because I wouldn't have so much spagghetti (e.g. once the physics state machine was merged with AI behaviour, tech debt was sealed)
This looked really complicated :D I will watch again and see if I can understand.
This video is amazing. I had to watch it 5 times to understand it, but knowledge comes with experience. IT REALY HELPED ME to build my projects :3
This was one of the best videos on FSM. I hope you start to post more. like Player Movement / Attack and how you would handle that in a FSM.
I want you to know that your Godot tutorials are very good, and that you should continue making more of them.
ideally you would want to have the states to be independent of each other, since if you wanted to create a new enemy that instead of following, it runs away when the player you would have to make minor rewrites to your states to make it work. (Instead of using the same wander state, and just changing export variables for example)
@Entropy Will Destroy Us All you could either extend the state machine class for more complicated ai, or you could create an event listener that waits for a condition or a set of conditions ( probably just a signal) and then asks the standing to transition to another state
Just getting into Godot myself. Interesting use of nodes for the state machine.
thank you so much. this guide helped me alot. I ended up re-writing the whole player code but I've finally managed to implement player movement and auto attack system without weird ass bugs. so it was worth it!
The way you explain things helped me understand Godot so much better. Thank you : )
I used this approach for a while in situations when the `match` switch approach gets too complicated.
In a project with action platformer controls this approach wasn't enough too. So I blended it with the behavior tree style - states having under states that get checked every frame if that will execute its logic for the current frame. Like PrimaryState (WallSlide, Fly up, Fall, Run, Idle) and JumpGroup( Walljump, JumpBuffer, DoubleJump, JumpDown, Jump). In a hierarchical order.
Now I'm thinking about ways to improve it.
For me, the next step was to define hierarchical states so that shared behavior can be defined in ancestor states. For example, WalkState inherits TravelState. TravelState exports a speed property that it uses to determine velocity along with the input_direction property that it inherits from the DirectionInput state. Most of my states also are descended from an AnimationState which exports a property for the animation name, the animated sprite node, and starts the animation in the enter method.
The downside to this approach in Godot 4 is that since there is no longer any implicit super() call, you need to remember to call that anytime you override one of the state methods, and as well check if the superclass logic returned a new state that you should transition to instead.
Lastly, there's also no reason your StateMachine class can't also inherit State and be a state of its own with its own child states to further modularize your behavior, especially if there's cases you want to consider some external conditions and don't want to bloat your root state machine.
@@zarblitz Do you guys use gdscript or C# for your code? Would writing state machines be better in one or the other? Do you have source code for your method? I'm just interested in learning how your method works.
I really hope these tutorials continue. I watch it slowed down a bit because you speak quickly, but your concise and informative so I subbed
I did not see such useful video for a while. Al three for Godot actually. Subscribed. So please do more :)
It really helps me to structure knowledge I already have and get new tricks to use.
I got into Godot literally yesterday, and I've already watched all your videos on it. You provide perfectly concise and understandable content. Thank you for doing what you do, will be looking forward to more!
As a Programmer new to Godot your Channel is gold.
Please more
Finally! I find tutorial with good code. With early return implementation, value verification and without other smell code. It's simple and brilliant 👏
My godot game and game dev skills grow stronger with every video! Thank you so much!
HEY YO MY MAN
im one of those that spends hours researching tutorials and i have a very large bone to pick with how the majority of people (even in great istitutions like universities) teaches things.
and since others already pointed it out im not gonna repeat myself and just say: you u got som good shit goin.
please keep on making godot/gamedev tutorials im sure your following will grow!
and of course, thank you very much for the effort you put in making these videos!
This is one of the best tutorials and implementations I have ever seen.
It's a shame that you haven't posted any recent videos as your content is very helpful. :(
I'm actually working on more videos! I'm just a terrible procrastinator
yeah! go go go@@Bitlytic
@@Bitlytic Please make a "Utility AI" tutorial video.
I know how to create a Utility AI in Unity, but Godot structure is different and really mess with my way of thinking.
Nice. Very clean. It is also no problem to introduce more states and transitions between them.
@bitlytic - I know these are probably really time intensive to make but I have to say you do it so well. I hope you can do more. They've really helped me understand a lot of complex issues as a new developer in Godot.
OMG Thank you so much Quick and very useful tutorial! This will really speed up the prototyping for the NPC AI on my current project! Subbed
As a code architecture and statemachines fanatic, I thank you for this.
Coming from Unity my first approach was to create states as Resources and add them in a list in the State Machine. Your solution utilises the Node methods like Update, which I had to call externally from the state machine. It looks like a logical way of doing it matching the usual Godot modular architecture.
Thanks for the tutorials ! I'm still new at Godot, you really helped me well !
Your tutorials are so easy to understand! Thanks for being such a good teacher!
There's a much simpler way to visualize a state machine.
to implement any state machine that is valid for ANY kind of state, you only need 1 function, one function that takes a state as input and returns a state as output.
so
change_state(new_state: State) -> State
If you accomplish that, through category theory analysis you have a complete functional and valid state machine. Cuz a state machine is just a monoid in the category of types.
(if you want to know the theory and rigorous reason why is that true is because a state machine can be defined by a monoid in the category of types)
and that's also why languages that dont have strong typing like python are obsolete in comparisson to C# or C++, cuz type matching allow you to use category theory to simplify your code by an insanity.
the way i do it is simply inside the change_state function that is a public method in the state_machine class i call only 2 things.
first i change the current_state property of the state_machine to be equal to the new state, then i call new_state.onAttach(state_machine, Entity)
the onAttach is a method that is present on every single State object (which can be guaranteed to be true using interfaces) and is the basic functionality that must be called at the momment that state is activated.
this method also allows that this same state machine structure can be used for anything in my code, player, NPC's, animations, sounds, events, anything that requires state changing i can control using the same structure.
if anyone is interested in learning more about this functional approach for statemachines just call me out.
Hello, I'm super interested, any code snippet to provide as a base example?
Such a simple and brief, straight to the point tutorial. I'd like to see more states as a part two, like one to circle/strafe around the player and attack, and maybe a second type of attack.
Top marks from me! I particularly like how you've approached decoupling the reference to the CharacterBody in the state by using an exported variable. This was always my gripe with other implementations and didng feel very clean at all.
Holy shit this is actually really high quality
Loved the video! Can't wait to get home to set it up. Thanks.
Good Tutorial. However when it comes to somewhat beginner Tutorials like this one, I'm a big advocate of "Show, don't tell".
The examples at the very end are certainly worth tackling, if not for code-re-usability and decoupling, which is a hard concept to grasp for game development.
The Video being this short would certainly not be degraded by 3 more minutes of you showing these concepts, at least briefly.
Got to say, this channel is truly underrated and it needs more audience, your videos so far are all I need for my new project using Godot 4. Thanks :)
That's the most intuitive implementation of a finite state machine I've ever seen 👍
Pro tip: if you’re designing your state machine to check if the state is valid _inside_ the state itself rather than the main state, make sure to set current_state = new_state _before_ state.enter() is called on the State Machine, otherwise your entity will get stuck in the transition forever.
E.x. the main “idle” state will always transition to “move” if an input is pressed, then “move” checks if it’s actually _allowed_ to move in the enter() function before deciding to continue or transition back to the idle state. I’m doing this for my player’s state machine because there’s a lot of variables to check per state if the player is actually allowed to enter the state, and it’s easier to check within the state’s enter() function rather than the main state.
Very quality video for such a small channel. Looking forward to more
I don't think I ever learned things regarding Godot or coding as fast as I do here. Also I like your voice.
I thought i was starting to get the hang of godot, but now i realize that i am nothing but an absolute beginner.
this is incredible🌟 thank you for all those clean useful concepts
please make more Godot tutorials
Nicely explained.
Will definitely use this one to show to others on the beginnings of a FSM!
This channel motivated me to start learning Godot the explanations are soooo good
Thanks for this, really helped to see a bare bones example. Was able to easily adjust for 3D nodes
Awesome explanation! This helped me out a lot! Good mix of theory, then demonstrating on how to put it into practice.
Im gonna have to rewatch this video so many times
Dude this is best tutorial for State machines!
I've done something similar, but handled the processing inside each state, making a State Machine handler unecessary. I think this also grants more independence and flexibility to states as long as you do not have some very obvious common behavior you want handled by the State Machine script.
Your video are so great! i really want to see more.
Please keep making more the last 3 videos are amazing.
Your videos are better than some university classes. Great job!
Really love your tutorials. Hope you make more, im learning a lot from them
I'm absolutely subbing and keeping this as my note on gd script thanks
Great tutorial! maybe you should make one about context-steering behaviour to make the enemy moves smarter around
Great video, I was actually looking to clean up the way I handle state machines in my game, and this video is going to be very helpful!
One of the few good tutorials on godot
These videos are great. Cant wait for whatever you ake next.
How a awesome tutorial! it's clear and useful. I am newbie in program and i can understand from this video. I really hope you keep doing them! I miss you Bro😄
Amazing tutorial! I would love to hear your explanation on concurrent state machines as that's still something I'm struggling with. (For instance: Having a bird enemy which can idle, wander, follow and attack, but also be on the ground or flying, without having to make 8 states in a single state machine)
than you need a statechart with parallel states. Here's an example:
ruclips.net/video/E9h9VnbPGuw/видео.html
Used the basics of it in my game. Great video thanks.
It would be awesome if you could provide the source code for this tutorial so it would be easier to reference ^.^
Great tutorial. Eagerly waiting for your next one
Great explanation, as always! 💙
I loved your code! Thanks for sharing :)
Great video man, very helpful. But man do you go fast in some parts. i had to throw it on .25 speed at 5:40 to see what you were even doing.
Edit: I spent at least half an hour trouble shooting errors I kept getting. Turns out it was the fact that I capitalized the "player" group so it wasn't finding the player's global position because it was searching for "player" not "Player". Gotta love case sensitive code...
im begging you to explain, I went to on base nil error to on base GDScript error doing what you said
thanks so much for this. I'm currently splitting up my 2000 line single script into 10 smaller scripts