Starter state machines in Godot 4
ฝัง
- เผยแพร่เมื่อ 16 พ.ค. 2024
- Here's an updated look at how I like to do state machines in Godot 4. I'm going to go over some simpler, starter techniques today, and in the next video I'll go in-depth about techniques you can use when today's examples don't cut it.
Text version: shaggydev.com/2023/10/08/godo...
Sample project: github.com/theshaggydev/the-s...
Simple state management: 00:00
Node-based states: 02:22
A few examples: 08:00
Theory video: • An introduction to fin...
As a newbie to Godot and game design but not to coding in general, the exploration of using a node based approach to state machines was fairly eye opening. Thanks!
This is a great explanation and breakdown of state machines. State machines are one of those things that beginner game programmers should learn as soon as possible.
Of all the YT videos out there on state machines this one is the most straightforward and easy to understand. The idea of each state as a “hot-swappable” brain made it really click for me. Thank you for making this and looking forward to the next video!
Nice to see this topic covered again for Godot 4.
It's been a while since I worked with state machines, so I really appreciated this video as a refresher.
Yes please more in depth one. Keep it up!
this is the best video about node base state mechine in Godot. the examples helps A TON! ty for the video!
How much was i waiting for this, thanks !
I really like how this implementation is clean and explicit. You can compose different states on different players or enemies.
thanks for the video, so useful, waiting for the next
Keep it up man, waiting on the next more advanced FSM tutorial!
Thanks, really needed help with this. Planning on making a platformer game and this really helps achieve that, straight to the point and easily explained. You've got a sub from me, looking forward to more State machine Tutorials for Godot 4
i just wanted to let you know, thank you for leaving text-based versions in the descriptions. :)
Thanks for including the Enum + Match statement approach for making simple state machines. I exclusively use this approach for minions/enemies as its less resource hogging compared to the State Pattern approach.
The node based State pattern approach is fine to use for Player character and Enemy Bosses.
Thank you!
I can't wait for the next video!
This is my favorite video on Godot state machines. Love the node-based approach, simple - clean, effective. Thank you Shaggy!
ahh, a great recreation of your classic videos. this is the state machine foundation i've been using in godot ever since your original videos. i'm EXTREMELY excited for the next video on (unless i misunderstood) what to do if you need a more complex state machine! perhaps one with a ton of different states...??
Thanks! I had a similar implementation except I was using the processing of each of the individual nodes, I think I ran into some overlap where some states were still running while the new states were active. Your way of using the parent's processing sorted this out.
Thanks :)
Great video! Most of the time, I use almost exactly this approach. The only difference I have is that my separate states fire signals that allow the owner of the state machine to decide what its next state will be based on the owners properties or configurations. By not having separate states reference other states it means that all combinations of states can be used, since the owner of the state machine controls what happens next based on individual state signals. Sometimes these states even have their own 3D nodes in order to determine if it sees a target using a raycast for example. Child nodes of separate states can be interchanged per scenario, thus making it customizable per instance of that single state.
Oh I like that idea! Signals would give you a good bit of flexibility, as you've mentioned.
I've been using the node-based approach for a while now, but using a generic state script + lambda functions and overwriting them in the state-machine script as needed.
This is a pattern I utilize greatly, and always advise beginners learn to use. My current opinion on the best implementation for node-based state machines is a single node that behaves both as a state and a machine, which allows for hierarchical state machines, although it can lead to some mess if structured improperly.
Great!
Thanks for sharing your info with us. I had an old game where the character has several states (run, slide to a stop, turn around, crouch, jump, climb up, climb down, use action) and the code was growing untenable. I've been wanting to go back and add to the game, but the state controller is over a hundred lines and so messy. I'm converting it to your style of node base states and it's so clean. I appreciate it. And your website version of the explanations is an awesome addition. I'm sure I'm dozens of web clicks on it. Thank you!
Thanks! Always happy to hear about people using the site! I prefer reading to watching so I like to offer that to others like myself.
As for giving the state machine a reference to the parent, you can use the state machine’s `owner` property; that will always be initialized to the scene root: in this case, the player. Even if the hierarchy changes, whether when you restructure the Player scene or later during runtime, a node’s `owner` won’t change unless you change it manually using `Node.set_owner()` in code.
Please please pl3ase do more on state machines this helelped so damn much
Great explanation. I have a game here with a player built using node composition. I believe my next step would be to extract those node that handles jump, movement and so on to their own state. I'll try to do it without copying exactly what you did, but I could grasp the general idea: 1 state manager has many states, which extends the base state node. The state manager will handle the logic between states, while the states has logic for handling input, animation and gravity as it seems fit
for simpler sate machines (like your turret) i like to use a setter to handle changing state.
would love an in depth video on hierarchical state machines in godot 4
No way, I was just watching your old videos on this topic because I started studying finite state machines, what a coincidence lmao
Great general overview. Really easy to follow and implement. That said, i do have some issues with using it when i want to react to other signals.
In my case, its for character attacks that can combo. I want to trigger a knockback effect on each hit, so i have a knockback state with special behavior, and then each state listens on a signal that the hurtbox has been entered, and transitions to the knockback state. What happens is my signal in the Idle triggers, and transitions to the knockback state, where the signal for the knockback state triggers and applies its effect again. This somehow happens even when i check if the state is active in the signal...
You really make hight quality videos! Thanks alot for all of them!
I wonder if you'll ever make a video of an implementation of utility ai in godot 4. Would really love that!
Thanks! And possibly! I covered the high level design in my last devlog, but didn't show much code related to it, so might be worth diving in further.
The Godot state chart addon is good and handles a lot of this for you, but lacks some of the flexibly of writing your own. I've used it in a couple of projects and really like it so far. It's worth checking out.
I met you thanks the introduction to Utility AI video. I would like to see a video about its implementation in Godot.
It would be interesting to see how you handle various different types of Entities (Player, NPC, Object)
thanks! I'm curious how you might implement parameterised states with this set up? Say, I have a 'stunned' state, but the stun time might vary. Would you add a parameter somehow or have some sort of player.stun_time variable? Similarly - how do you handle states that are imposed on the character by external entities. Looking forward to the next video!
In the script you can write
@export var stun_time: float
And it will allow you to modify the variable out in the node Inspector. You can then give the script to different nodes and change their stun times accordingly!
For your second question, it depends on what you are trying to do. For instance, if there is a bullet fired at the character, I would suggest adding an Area2D node to the character. You can then connect the Area2D's area_entered or body_entered to changing the state:
@onready var bullet_detector = $BulletDetector
func _ready():
bullet_detector.body_entered.connect(take_damage)
func take_damage(body):
if body is Bullet:
change_state(States.Damaged)
Or something like that. Sorry for formatting, this is on my phone.
Good stuff 🔥
Don't forget to try your own things without looking at vids or else you won't progress guys 😉
This is the best state machine explanation around, yet i still cant wrap my mind around it sommehow. Maybe its the language barrier that sometimes gets to me. But awesome vide as always love your content!
It's because you don't try by yourself, videos are great, yeah, but ONLY after you've struggled a lot
yeah really is great technique, for no use match and more clean code, one mob from my game the main code has more line than bible using match.
Funnily enough, my implementation of a state machine is more or less the same.
Except, that for some reason, I decided to switch between states based on strings, rather than exporting them as variables as needed for each state. In hindsight, I really don't know why I came up with this idea myself! :D
Oh, and I also did decide to change states manually, rather than as a return value of a function.
I thought I was crazy at first but they did tweak state machines quite a bit. I get whiplash from all of these changes sometimes. Open source engine problems, I suppose.
✨🙏🏼✨
How would you handle concurrent states? For example if the player is attacking mid jump or while moving?
I'll touch on this more in the next video, but there's nothing wrong with multiple state machines if you have independent states to manage, such as for a run and gun type of game.
Thanks for explaining things. Question I have is what if your "idle" state needs to access another node inside the character scene. Like to get a particle system and enable it. Its okay to use a reference to that from the "Idle" class? Seems weird because you are referencing up the hierarchy instead of down.
Sure, it is what is is sometimes. I'd probably @export that reference, but you could also pass it in like you do the player if you'll need it a lot of places.
I'm going to watch your other video on state machines next to figure this out, but I'd like to raise a question. What is and isn't a state in a state machine? As far as animation handling goes, this system is flawless. Each state has a distinct animation and that part is easy to get for me. But for movement handling, jump and fall control the opposite ends of y-direction movement, while move controls both directions of x, and idle is responsible for the lack of either. Since platformers tend to have x-direction capabilities in air, three of the four states can control when the player moves left or right.
I think the concept of states being both directly responsible for movement (jumping velocity is instant once entering the state) and indirectly able to be controlled based on input without switching states is tripping me up. Outside of these four main actions, I'm confused on what actions should and shouldn't have separate states. Overall the idea of "swapping brains" with states is clear and concise, I may just be thinking about this too rigidly.
Rather than breaking it down into movement or not, I like to think of it as "Is this something that would require conditional logic to process?" I might need to do X if I'm falling or Y if I'm not, for instance.
The next video should help clarify how to build out functionality and reuse some code to help with some of what you're talking about, but I think you've also actually stumbled upon a common criticism of state machines without even realizing it: they can get complicated pretty quickly.
Hey, if anyone could help, when I call for the state machine to initiate itself I receive and null instance. Why is this so?
I love you platonically
So this may be a dumb question, but I'm trying to learn this while doing a state machine on a simple racing game, but I'm getting my wires crossed somewhere. On the state machine, I need to be able to control the vehiclebody3D, which is of course its parent. But the VehicleBody3D controls things like steering and throttle. The state machine doesn't seem to be able to access those functions (Or exported variables), even when trying to access the parent (Or parent of the parent, to be fair, as the actual states are another layer below the state machine).
Any idea how to have the states "latch on" to those functions so they can be modified? Or am I aiming for something fundamentally flawed?
Hmm, I'm afraid I'm not aware of any reason why you couldn't use this technique on the vehicle. Though I'm not overly familiar with the VehicleBody3D node, I don't think there's any specific reason why it wouldn't work.
@@TheShaggyDev
All good, I'll keep playing around with it. Thanks for the reply!
If you embed a separate 'state machine' and define local 'states' for each type of object 'node', how do you know if you're getting the main supposed benefit of 'state machines' in that you're handling all possible states (and combinations of states...) in a deterministic way?
What if not every piece of data in your game is trivially synchronous?
What if you have a non-trivial amount of nodes, and in aggregate, they may not complete their state updates within 16ms?
What if you have a non-trivial game that has at least one behavior, data or operation than affects a 'state' that could take more than one frame to calculate?
The states are still organized on that object, but there's no need that every object needs to run through one large state machine that keeps everyone in sync. They can, and will, change states at different times depending on the interactions each object has with the world. These small per-object state machines have a minimal impact on performance, which will be a game dependent detail anyways. If the state's can't update in time, profile and adjust where needed.
While a lot of common state machine uses in games should be able to run synchronously just fine, long running or asynchronous tasks won't impact the implementation that significantly, nor will that make the state non-deterministic. We still got to this long running task based on some set of inputs to the machine. Depending on the exact use case, a processing state for that object might help to make it clearer what's going on and help prevent invalid state changes while it's processing everything, but that can, again, vary based on the game.
how do you make it auto-complete in the states?
i'm using my own component "move_component" witch is a class "MovementComponent"
I'm passing it to the state_machine and to idividual states aswell
but when I use it inside the a idividual state is dosen't auto-complete when I'm writing a function, it works, but I need to keep bouncing to the component script to get the functions...
As long as you type your variable (ie "move_component: MovementComponent") it should autocomplete for you, though sometimes Godot can get a bit confused on types...
I’ve tried this in a test project but am having problems with the process_input function.
After one state checks Input and returns another state the new states process input doesn’t get called
Yep, that's to be expected. This state machine lets one state respond to one input, so if a new state is returned, it has to wait until the next input event to respond.
You'll need to modify the project if you need to let multiple states respond to the same input, though I don't know if that's really a traditional approach to state machines.
I'm utilizing C#, and working through this tutorial and a conversion process from GDScript. What would be the equivalent of this section of the Statemachine code:
func init(parent: Player) -> void:
for child in get_children():
child.parent = parent
in C#?
public void Init(Player parent)
{
foreach (Node child in GetChildren())
{
child.SetParent(parent);
}
}
@mel-du-studio-coco thanks! Though, i don't think SetParent exists (I get an error saying it doesnt). What would be the alternative?
here the 'set parent would be a custom function that you've made that assign the property 'parent' of your state script.
child.parent = parent
@@zacklewan4183
when I try to run this scripts I get an error that reads "invalid call. nonexistent function `enter` in base `Nil`" in the state_machine node, func change_state final line `current_state.enter()`
Make sure you've set the starting state on your state machine. That should be an exported node you can edit from the inspector.
Do you go through doing this in the video? I'm trying to assign the starting state in my state machine but none of my nodes are able to be assigned@@TheShaggyDev
@@Chase_Is Are your states inheriting from the State class? The export should be typed to State, so will only accept nodes that inherit from State. Can take a look at the sample project if you want to see how everything should be set up.
I have everything that you have in the file in your description. All of my states all extend the State class. So idle is the same as what you have in your sample@@TheShaggyDev
Oh I fixed it. All of my States were extending state except for the actual State script. Thank you so much for the reply, your videos are so helpful!!@@TheShaggyDev
isn't class_name supposed to be under extends in scripts? 5:57
Either way is acceptable in Godot! I personally tend to put it first as that mirrors other programming languages where you typically have the pattern of "X is a subclass of Y"
could owner property simplify the code so that we dont have to pass the parent down?
Sure, that would work just fine for something like what's shown in the video.
I don't fully understand. Can someone tell me, what in that code (of the node based approach) causes the code to know, which State is inactive? With match, I get, why only one gets selected. But when I "return jump_state" for example... How does it know, that idle_state is no longer active and should not be executed anymore?
The trick is in the code for the State Machine node. When a state returns a new state, that triggers "change_state()" in the state machine, which changes which node is marked as the current state. As the machine only allows for one state to be active at a time, only the current state is ever processed and given inputs from the parent.
IMO, using Nodes for states falls down hard for larger projects. We use Resources for states instead, with a StateMachine node holding an Array of them. States can be dropped into the statemachine's inspector. The states have initialize, enter/exit state methods and a process method that's called by the StateMachine node every frame for the current state.Much cleaner than a huge list of nodes in the scene to enable/disable all the time. ANd Resources don't need all the extra internal bulk of Nodes. IMO, using nodes is just asking for a maintenance nightmare as soon as the project grows a bit. And I don't even think Nodes is simpler for new devs. But hey! They are a thousand ways to do everything. Just my thoughts. Peace.
Ok Fine. But why not just use the statemachine already implemented in an animationtree?
you should NOT have state machines in gdscript for a production build.
@@zerofallstudiosi didn't say that. i said not in gdscript.
the reason is that the overhead of gdscript composition is way too large. specially in the scene tree.
what is needed for a proper state machine to run efficiently is inlined c++ functions.
i'm not saying gdscript shouldn't be used for anything' i'm saying you will end up having something like 100x overhead for this usage.
"Let's go through this line by line" -> *proceeds to skip all functions*. As a beginner it's incredibly frustrating that every single state machine tutorial skips over major parts of the things they are supposed to teach. For example: I'm currently trying to find from Godot documentation whether functions enter() and exit() are default functions (like _ready()) or not, or how they work or why they are defined here, but once again the tutorial doesn't tell it. Googling enter() and exit() gives some info, but what exactly makes Godot call these custom functions and when? You just write them and they somehow magically work? For a beginner like me, a state machine is incredibly difficult to figure out and this is, like, the fourth tutorial that does the exact same mistakes.
The biggest problem with these tutorials is that they never seem to tell WHEN or WHY stuff happens, like what is the logic. I'm inferring that maybe the enter() function is called automatically when state is entered yet I'm unsure why. Another thing that is difficult for a beginner is that you have two things running in parallel: game logic and animations. This causes some weird stuff to happen like being able to change direction during dash animation. None of these state machine tutorials give tools to understand the process better.
From what I can remember about how state machines work, the enter and exit functions are called from within the states themselves. For the example from the video, when the player is initialized in the world the _ready() function inside the player calls the state_machine's init() function.
Inside of the state_machine we can see what the init() function does. Looking at the code it seems that all we do in this function is tell the state machine who the parent object is, and then tell the state machine to enter a new state using the change_state function.
The change_state function takes in a state as a parameter so that it can know what state to enter. Looking in the body of the change_state function, the current_state is fed the parameter of the change_state function and then the enter() function is called from within change_state.
This way, every time a new state is entered, the enter function in the state itself is called. This is how we tell the object what to do when the state is entered. Each time we need to exit a state we use a condition that tells the state machine to enter a new state.
Inside the idle state, inside the process_input() function, we tell it what state to enter based on what input is pressed. When we press the "jump" button we enter the jump state. We do this by returning the jump_state inside of the process_input() function. The way that we return this is by telling the function that it will be returning a variable of the type State at the end of the function declaration (the part after the arrow operator).
This takes us back into our state_machine code. The process_input() function holds a local variable called new_state. It sets this variable equal to the output of the process_input() function in whatever the current_state is. So going from idle to jump it would be something like, "var new_state = idle.process_input(jump)"
This is only the way the code itself is interpreting it, not the way it is literally written. The next line says that if a new_state exists, then we will execute the following code. The code that follows would be translated as, "change_state(jump)." This is how we will be calling the change_state() function, which will in turn, call the enter() function on the jump state.
Sorry for the wall of text, but I hope this helps.
@@PeaceInExile Ok, this helps a bit. Can you also comment on why, in the video at 8:55, there is a function called
func process_input(event: InputEvent) -> State:
Yet it does not reference the "event" at all. Instead it takes Input, which I presume is available inside the state itself?
@@PunCala I haven’t come across a reason to use that parameter yet. For now I’ve been ignoring it
Oh yeah, so "simple" that my code isn't working.