State machines and state charts in Godot

[@GregX999]

I'm very impressed with this asset. I've made various different state machines (and even a state tree) from scratch in Godot and Unity, but would totally use this one instead for anything I would ever need states for. I'd love to see more videos covering more advanced use cases (even if just an overview rather than a step-by-step tutorial).

[@TheLastPhoen1x]

I am not a big fan of adding 3rd party addons for things I can do myself, but damn this one looks tidy and organized, like a better version of state machine.

[@hiiambarney4489]

I think the icons and all make it pretty professional. I'm just wondering. If you write all your code in signal called methods, wouldn't this get super jarring, quickly? Like for a larger (say like a Fighting Game or Metroidvania, etc.) Player Character, I could imagine this to be a script filled with 100+ of these signal methods in the end. @@TheLastPhoen1x

[@gonderage]

​@@hiiambarney4489 If that's the case, then you should probably split that logic into its own script and node and connect the signals from the state machine to that new node

[@romanperryaudio]

​@@hiiambarney4489 late to the party, but i feel like you could have a node for each state (or group of states) that holds the logic.

[@otapic]

@@hiiambarney4489 like what romanperry mentioned, you can split the script into nodes like the usual FSM. the tool really just comes down to making the initial setup quicker and having that parallel state is a massive plus compared to an fsm

[@commentingexistentialcrisi9564]

This is probably the best addon in the asset store. I have used it in every single one of my projects.

[@chutney88]

This is such an elegant solution! I've wanted something like this ever since I started using state machines and you absolutely nailed it. Thank you.

[@Pettfej]

This is my new favourite Godot tutorial channel! Keep it up!

[@localvoidlander8093]

Finding tools like this is exactly why I fell in love with Godot, thank you so much for making this!

[@4.0.4]

When I think of state machines, I either imagine a chart or code, but here they're represented in nodes which looks like the native Godot way of doing everything 😅 I love the debugger! It really tells you all you need, and so easy to add.

[@Asguardian22]

I noticed this in the assetlib tab a while ago but didn't get a chance to read through the documentation. This video is VERY helpful. Thanks for taking the time to create it. It makes me want to use your addon for my game. More videos would be very welcome. You did a really comprehensive job at creating this asset.

[@godotneers]

Glad you like the video! Regarding additional videos are there some subjects you would be particularly interested in?

[@flora265]

@@godotneers I think a guide on the behavior tree addon Beehave would be useful, there are very little guides on it and none for the current version, the documentation is not very good with basically no examples.

[@Asguardian22]

@@godotneersI wouldn't mind understanding the differences between a state chart and a behavior tree? When I saw the Parallel node, that was the first thing I thought of. Also, some more examples outlining each different node type in the state chart would be beneficial I think. And, of course, more examples of implementing a state chart is always helpful. Your presentation style is very clear and I think it saves people a lot of guessing.

[@godotneers]

@@Asguardian22 behaviour trees and state machines/state charts have some overlap in that they are concepts for running a process in a stateful manner. The execution method is different though. Behaviour trees have a concept of "success", e.g. they run actions and these can succeed or fail. Then the nodes react to the success by switching to other parts of the behaviour tree. On the other hand a state chart has no such concept of "success". It just reacts to whatever events it receives and switches states according to the events and the configured transitions. In a behaviour tree the node type is some hard-coded behaviour, e.g. a parallel node in a behaviour tree will run all its children for as long as they are successful, a sequential node will always run its children in sequence, etc. In a state chart the behaviour is more fluidly defined by the transitions and the events that come from outside of the state chart. In the end both are tools in the arsenal and you can probably model a wide range of problems in either one of them, so one isn't necessarily better than the other. As for additional tips, I'm going to make a few more videos on the state charts library, one of them will be a deep dive on how the controller in the platformer was made and why it was modeled the way it is. Making these videos takes a good while though, so it will probably not come up tomorrow ;).

[@Asguardian22]

@@godotneersGreat explanation. Thank you for taking the time!

[@adammikulis6211]

Thank you for making this! I am currently using Godot State Charts to make a neolithic village simulator game. It makes adding/controlling behaviors a lot easier and modular.

[@ChrisTutorialsYT]

Really cool plugin. Love the parallel states concept and will be trying this out in my projects. Also the tutorial is really well explained and makes it easy to understand. Thanks for the guide.

[@tsplitart]

I HAVE SUBSCRIBED. Saw another video of yours. I believe you should keep it coming and this channel will be big. Godot is going to be big

[@bananabarddev]

I am making a metroidvania and my character controller is a mess, I have a lot of verifications to see if I can move the player, like if is not getting attacked, if it is alive, if is not dashing, etc. Your videos are making the process x100 faster and easier, thank you a lot!

[@iminuru2974]

I have seen many different tutorials and addons for state machines. For me this is the best statemachine addon there is. This tutorial is also perfect. For the first time after months of back and forth from one implementation to another, I finally understand statemachines perfectly and can implement them onto anything I need. Not only that, but I because of this tutorial and addon something just clicked in my head and I can code my own statemachine now also. Thank you for this tutorial. Just subbed because your an amazing teacher!

[@woodenfences]

Really enjoyed the zoom in on 'delay'. Made me go "Ooooooh..." But, I hadn't seen the parallel states at that point. Great stuff!

[@Android480]

Pretty powerful. I discovered states as entities, and nested FSMs, but transitions as entities is clever. That and parallel states.

[@thepolsehorn]

Love this video. Thank you for the great work. Can you please do second video, where you explain some of the other state nodes and a more advanced state game example. Would love that.

[@netlooker5841]

Respect! Quality content here :) I cannot wait for more.

[@willd2609]

i have been coding state machines by hand, this is SO MUCH BETTER!

[@Standbackforscience]

you make amazing guides, please keep it up!

[@tabatecuenta7192]

Such great news for me! Yeah. State Machines look so menacing, Im glad there is something to make it easier. Love the color also 😂

[@LukasSkywalker_]

This looks amazing. I'll sure try it on my next project

[@zedmanul7472]

That's a really neat tutorial! I wish i found that addon earlier, although writing my own state machine was a useful experience in the end anyway x)

[@godotneers]

I'm glad you found it useful. What kind of game are you working on?

[@zedmanul7472]

@@godotneers A 2D platformer with a combat system! The state machine is for the enemy ai

[@mohamedmoh5789]

Wow I dunno why I haven't heard of this till now it's simple and easy to get started with thanks for showing it out

[@georgezimmer5622]

This is the most impressive plugin in the entire AssetLib, it's almost an auto include in every projects.

[@godotneers]

Thank you very much, I'm glad it is this useful to you!

[@georgezimmer5622]

@@godotneers Wait I'm confused you're the author ? That's quite impressive, your channel has few videos but they're very qualitative, thank you very much for what you're doing.

[@godotneers]

Yes I'm the author. I created this video for people who like to learn visually rather than reading a manual.

[@tayete]

Simply fantastic. This addon should be included with Godot core (as Beehave and YAFSM). Awesome work.

[@TheValkire]

This is perfect. It feels just so much more organized than using any other state machine. It would be great to see smooth transitions between states and handling animations.

[@godotneers]

Glad this is useful for you! Could you give me a bit more details about what you mean with "smooth transitions"?

[@Crabtorias]

I think you want more a way of scaling with parameters like the PLC world or the node would be called Map Range in blender. took some time messing around with spreadsheets but this maps one range of numbers to another, I use it to map my characters velocity to stand -> walk -> run animation # remap ranges of variable, good for leveling mechanics and scaling numbers, quite a bit of math so staticly typed func map_range_float( range_input: float, out_clamp: bool, in_low: float, in_high: float, out_low: float, out_high: float ): return (clamp((((range_input-in_low)/(in_high-in_low))*(out_high-out_low)+out_low),out_low,out_high) if out_clamp else (((range_input-in_low)/(in_high-in_low))*(out_high-out_low)+out_low)) wish this was built in to godot like it is blender, its so handy

[@godotneers]

There is actually docs.godotengine.org/en/stable/classes/class_%40globalscope.html#class-globalscope-method-remap which seems like it's doing the same thing.

[@Crabtorias]

@@godotneers well hot dang, thanks!

[@justyoutubin]

This is a very good tutorial/video. Amazing job, thanks! This addon is very interesting, but seems like it moves all the code for the different states back into the base class (Watchman), instead of having the state specific code compartmentalized in the various state nodes.

[@godotneers]

Yes, this is actually intentional. It makes accessing of shared variables (like health, position, etc.) a lot easier without having a lot of up and down communication between single nodes. Also for smaller examples like this I feel that having all code in a single script aids in understanding how everything works. Because the library uses signals to call into your code it doesn't prescribe any way in which you organize the code. So if you want a separate node per state, then you can add some per-state nodes below the watchman, attach scripts there and then connect the signals to these nodes.

[@davvedp9309]

I second this. Since exposing mutable state is seen in many other tutorials and examples, it’s great to see someone actually displaying some good architecture! A shame that these plugins can’t be ported to c# for now, but one day we’ll get there. I’ve been using partial classes to nest the states directly in the context class in c#, which ruins modilarity. Seeing it all as nodes really opened my eyes. Especially how you serialized guard expressions in the editor. Performance-wise im not sure if the events are cached and the expressions pre-evaluated, but I’d imagine that it isn’t that relevant for most projects. Great work ❤

[@godotneers]

@@davvedp9309 The state charts plugin actually has C# support, so you can also use it in C# based projects.

[@maxmustermann3938]

You might also want a guard on the timed transition from berserk to normal so that it only happens if it is also currently in the Idle state

[@vladislavkorecky]

Great asset and an underrated channel. Thank you.

[@zemeio1184]

Amazing plugin! One thing though, at 20:11 the AlertState switches to Idle, even though you are currently within range. I think you might have had a bug there?

[@Demozo_]

This happens because the transition is already running, I assume there would be some way to configure the transition to reset when the event fires again though.

[@Interfacetypeseven]

This moment jumped out at me as well. It highlights the problems we run into with complex state interactions all the time. I'm not persuaded that scattering it across multiple nodes, which I have to dig for in the editor interface, is more convenient than doing it in a few consolidated blocks of code, where I can quickly surmise the bigger picture at a glance. I was hoping to see something more "chart"-like ala a state machine diagram I might create in advance of writing the code I use today. The star of this plugin is the visual debugger, which beats the heck out of my print(state)'s everywhere.

[@jasonm911]

I think that is due to the delay, it's tough to really understand what you are dealing with when you don't know the back-end well enough. This plugin definetly looks useful though

[@joga_bonito_aro]

Thats because the timer does not get reset when you go back into the collision zone and it will still count down. Timer are always very hackish in my opinion

[@MHellman]

Leaving a well deserved like and comment on your excellent work to help the growth of your channel. Really well explained! 😀

[@BigWin24410]

Thank you for showing State Charts, looking forward to seeing what I can do with that.

[@SattarPahlavan]

one of best teachers I've ever seen . thank u so much

[@juanch.1484]

I'm very impressed with this asset. Thanks for the tutorial man, keep it up 😊

[@Anonyross]

Love this, and I'm especially grateful for the manual!

[@Abood_king_brol_stars]

Wow and finally I learned to thank you, the sweetest person❤❤❤

[@kentang5103]

happy to see plugin helps writing state machine.

[@Musicalcode313]

I'm pretty sure I'm never making another state machine again in godot. this is so much cleaner looking.. I'm at that point with my enemy ai that I'm running into conflicting situations and my code is full of "If this and this and not this" type stuff and it makes it hard to read coherently. Plus this addon might take some of the headache out of thinking over those edge cases. i don't think ill change what i got but i will use it for future scenes that require states.

[@_asyncawait_]

This is brilliant! I’m already thinking about how this is going to make my code a lot simpler.

[@Manu0jedi]

thank you for this, I love this addon now. I always waste a lot of time implementing my own state machines for AI characters because I keep introducing bugs, this makes it so much better to work with

[@heagandev]

This is a godsend. Ty

[@norvelx1]

Amazing tool. I am currently use it to implement enemy logic in my game.

[@ahurafsfsa]

I've been using own state maschines for godot all the way. But for my new project I will be using this one.

[@HomeFrogGames]

More than anything, I think relying so much on signals is a very 'Godot way' of implementing state machines and it just feels so natural. I have been learning state machines recently and been trying to implement them on my own. This feels so much easier to use so far, especially parallel states are such a great simplifier. I'm already okay doing simple state machines with the enum and match statements. I wonder if you would still recommend to learn implementing finite state machines (like node-based) the traditional way just to get better at programming. I assume you would. Thank you so much for your great asset!

[@godotneers]

It never hurts trying build something yourself to really understand how it works and why it works, so go for it!

[@ghostradiodelete]

I'm not sure if I have a use for this but in a future game I might give it a go and see if I can apply it. Nice tutorial!

[@egormeno]

Thanks! I was recently had worked in a similar solution! But this add-on seems to be very solid! But my solution needed to inherit from a "StateManaged2D" node that, is an Area2D

[@red3tango]

This looks super interesting, can't wait to refactor my code and find new ways to use this haha

[@froggin-zp4nr]

Nice tutorial, it took some effort for me to follow along for the first time as I'm using C# but I got a working example. Few notes; This part isn't necessary if the signals are setup in the godot editor: for the state_processing equivalent in C# when I was setting up the signals, I was getting an error trying to pass the delta, the manual didn't give C# example with a parameter but I got it working looking like this under the _Ready() - 'state.Connect(StateChartState.SignalName.StateProcessing, Callable.From((float delta) => OnObservingStateProcessing(delta))); Where state is the 'Observing' node state and OnObservingStateProcessing is my callable method that does the LookAt(enemy.Position). As that event is processing on every frame the callable method should look like that to accept a parameter. The callable method can also be used more verbosely like this: new Callable(this, nameof(OnObservingStateProcessing)) One other thing that threw me off which is not C# related specifically, but that by leaving the Delay in Seconds value of the transition blank instead of 0.0, I was getting an expression exception in the console debugger, but I thought that was a problem with the ExpressionGuard set in the ToBerserk transition. After some trial and error thinking I needed to call or defer SetExpressionProperty of the enemyentercount it was just me assuming a blank value was being handled. That's my oversight but would be good if the debugger could spit out a more direct message. Also introducing the parallel state and restructuring the nodes broke my GetNode calls for the Idle and Observing nodes, returning null as it couldn't find them until I changed the path to include the StateChart/Root/Alertstate. Might be a language difference with godot but that can be fixed with a singleton or something to manage the node paths, plenty of tutorials for that I'm sure. Besides all that I can't wait to expand on it further for more states, and hope the C# support continues!

[@Notreal76]

Thank you for this very informative tutorial.

[@kindavacant7843]

Very well done visual explanation of this add-on. While reading the add-on docs it was recommended to watch this. You're using version 0.3.1 and I'm using 0.13.0 and all of this is still valid which is amazing in itself. My only qualm is keep the name of the states and add *_whatever*. IE: AtomicState_idle. This allows the viewers to understand what line/state is what all the time instead of only when added and completely renamed. So many tutorial vids rename all the nodes that even 2 minutes in I'm like, "f-m, wth was that "fluffy_bunny_burps" node again?" Followed by, "Geez, KZbin needs a 10sec rewind button.." Otherwise great tutorial and I'm going to explore using this add-on in more complex ways!

[@ScumlordStudio]

Double tap your screen on the left side or press your left arrow key to rewind

[@kindavacant7843]

@@ScumlordStudioHey thanks, I only use a computer the the left arrow key is a rewind! You're awesome!

[@ScumlordStudio]

@@kindavacant7843 no worries!!

[@oliviermalige1733]

Thanks you for this clear explain for this addon and state charts in generaly

[@apoorvpandey3D]

wow wow wow. This is a gamechanger

[@BazSupport]

This is my go to FSM now, thank you!

[@manligheten]

Very nice job, thank you for the guide and the addon!

[@olson5000]

Great addon and tutorial - subbed!

[@accumulator4825]

Incredible plugin, thank you!

[@MoogieSRO]

It took me about a day of studying and copying the example projects, but I think I've gotten the hang of this now, and I'm already loving it. EDIT: Coming back to this comment after about a week using it. I want to start by saying the dev is very kind, responsive and patient, and helped me understand the system when I was struggling with it. However... I've come to the conclusion that statecharts aren't for me. I have a number of problems with this system, starting with the fact that all the code gets dumped into a single script file, which is a massive pain to work with. Sure, you can separate it out into different scripts, but then you have to start adding more nodes to the tree to hold those scripts, and the state chart is already a giant spaghetti mess, now I'm having to add even MORE nodes just to keep the code separate and readable? Another issue I have with it is the examples that come with the addon. You'd think you could get started by studying these... Well, I tried, and from an end-user perspective they're pretty awful. I was primarily using the "anthill" example to try to create a creature behaviour. So I looked at how the nodes are named, and they're all these very simple, shorthand names like "On Next Destination", "On Dropped", etc. So naturally, I copied this pattern in my own project because I didn't know any better. But as soon as my chart started getting more complex, I look at all these nodes and my eyes just glaze over like... wtf am I even looking at? This all means nothing to me! ESPECIALLY because, most of the nodes don't have any scripts or signals attached. Most of the signals happen higher up in the Compound or Parallel nodes that are handling all the subnodes. So I might have a deeply-buried transition node "On Food Picked Up", but if I'm following the anthill example, that transition uses no signals, has no script, so I'm staring at it having no idea how it's triggered or when, and I have to look further up the node chain, to "Picking Up", which has a state_entered signal to call _on_picked_up(), but this script STILL doesn't mention the "On Picked Up" transition anywhere, so I'm still left wondering how and why it's ever triggered, and more importantly, why my own project attempting to mimic this behaviour doesn't work correctly. Now, don't get me wrong: If I stare at it long enough, I can figure out when "On Picked Up" gets triggered, and I did get my behaviours working after hours and hours of troubleshooting. But it's so convoluted and not naturally-occurring at all, and the whole point of using an addon is supposed to make it easier to handle, not harder. My experience has been that this has made creating a state behaviour tree so much LESS manageable than even just doing it fully in code would be! Another thing that repeatedly tripped me up is how transitions can have a Delay, but regular state nodes can't. And the Delay doesn't seem to correspond with when the associated signals get triggered, so you end up with things being mis-timed because you expected the delay to happen *before* the code, not after. I'm not 100% on this because honestly I never really figured it out, it was too confusing. And maybe I missed something in the documentation, but nowhere does it seem to state the UTTER IMPORTANCE of what order the nodes are placed in the heirarchy. Not knowing the importance of this caused me so many headaches. Lastly, the lack of colour-coding on the node icons is a surprisingly big issue, too. They all sort of blend together being the same dull orange. Sure the pictures are different, but they're not massively different, all some variation of circles inside a bevelled box, and it takes a few more CPU cycles in the ol' brain to recognize what they are and understand what they're supposed to be doing. Ultimately, I think I'm not going to be using state charts moving forward. They may work for somebody else, but now that I have a slightly deeper understanding of how to use them (beyond the "ooh shiny!" stage I was at when I first saw this) it's just not for me. I wish the creator luck and I don't want to say this addon is "bad" by any means. It's just not for me.

[@DerSolinski]

Well, lets feed the algorithm... Good work keep it up.

[@YasserKSA911]

thanks master now i can aply it☕️🌹

[@OneCSeven]

holy shit ive been hyperfocusing on figuring out how to build a state chart addon for godot !! what are the chances !! hell yeah

[@larrylevandowski8023]

Really good stuff. Well explained.

[@bbsnake01]

Thanks for this great tutorial and the dive into this Plugin. If you decide to do a second part to this, I was wondering how I could implement the following: 1. Take the traditional body mechanics states, like idle, move, jump, attack etc. but then also take mindset states like, normal, wounded, low profile, aggressive, etc. With a traditional state machine someone would need to create a state for each combination. But I was wondering how these multiple state chart would help solving that issue. That way different animations could be played when a character is moving aggressive vs move wounded. 2. As an alternative it could be interesting to have a character who is controlled by the player but then can become an autonom character in a scripted sequence (in a cut scene for example) and then return the control to the player. Thanks again!

[@godotneers]

1. You don't necessarily need to use different states to blend animations. Godot's animation tree can blend different animations together, so you could for example just calculate a "hurt" value, maybe current_health / health and use that as a blending value in a Blendspace1D which blends the hurt animation with the normal animation. I'm not an expert on the animation blending, but this seems easier than trying to do this with a state machine. 2. I feel this would also be easier to do with a smoke and mirrors solution. E.g. you can insert a copy of the player with a different script for animation in a cutscene and then just delete the copy when the cutscene is done, while suppressing player input in the meantime.

[@friendlyfox2189]

thank you for this!!!

[@AgustinQuetto]

Wtf, it's super easy! Thanks man!

[@ilyashinaurov4846]

Great guide, thank you.

[@NeZversSounds]

After a delay state could be invalid. Same happened in video - "To Normal" while enemy was inside. So my only question is how to cancel timer or override transition?

[@godotneers]

Nicely spotted! In this case this could be fixed by adding another transition to the "Observing" state which listens to "enemy_entered" and transitions to the "Observing" state (e.g. itself). There can only be one delayed transition active at any time in a state (you can have multiple transitions concurrently active in multiple states though). Running any other transition for a state will automatically cancel any running delayed transition in that state. Also when you leave a state and it still has a transition pending this will be automatically cancelled. This could be the case if some parent state transitions and deactivates its child state.

[@Draidzeven]

This is a neat implementation, and I love that there's a debugger out of the box, but it does look super verbose. Not only do you have to write code to mirror signals into the state chart via the root script, but each transition being a node looks like it will quickly overwhelm the scene view. Do you have a more complex sample that demonstrates the kind of complexity y'all reckon deserves this verbosity?

[@godotneers]

Well you need to model the transitions somehow. There were also discussions on using a graph view for this but this would have been very tedious to edit (though nice to look at). If you're interested in the whole story check this issue: github.com/derkork/godot-statecharts/issues/13 As for examples, there are a few examples that come bundled, but none is particularly big, mainly because their intent is to teach the usage of the plugin without being overwhelming. This is also the reason why the example in this video is rather simple. The point of the library is to decouple state switching logic from state execution logic. So your code can focus on what happens in which state, while the library focuses on receiving events and switching states based on the rules that are set up. I found this to help tremendously by removing a ton of if/else structures from the code, making the code more readable and concise. For a small example like this video, this is probably overkill, but again the point was to teach how to use it not to show its feasibility for any specific kind of project. Whether this library is a good fit for your particular application is something that probably only you can answer. Since the library only has a minimal API surface (all you do is `send_event` and maybe `set_expression_property`) it should be easy enough to try out without having to change a ton of code and also to get rid of it if you decide it is not for you. And if you don't like the style in which the library does things, well then that's fine too. There are other ways to do state handling that may be a better fit for your particular project.

[@lassipls]

If you get errors like "Must be a child of StateChart" while the node clearly is a child of one, restart Godot and it will work.

[@scottwelfare9267]

Great tutorial as always! The only downside I can see here is that with a complicated character, you would end up with a very long script. Is there any easy way to break the code for each state into its own script?

[@godotneers]

Because the library uses signals to call into your code, you have a lot of freedom how to organize your code. You can write everything into one script like done in this video, you can have scripts dealing with certain aspects (e.g. movement, attacking) and call into these, or you can make one script per state and call into that. Whatever way works best for your game. See also this discussion here: github.com/derkork/godot-statecharts/issues/113

[@KIBERTAIM]

Thanks add More Videos

[@Zane_2029]

I'll be taking that

[@BarcelonaMove]

Props to you master!

[@MemeMand1996]

Amazing vid!

[@comaharmonium3807]

OMG! god tier! thx u

[@gadmas2670]

Great video!

[@Bigsperg]

really cool. Talented!

[@intropret]

Thanks man.. Can you make a tutorial how to implement this to player control and manage animation

[@lalalala99661]

Hello and thank you for all your high quality tutorials. I have a question: I have a car and a player , both are its own scene. I want to give each scene a own StateChart to make the car and the player as well indepnendent to which Parent scene they are used in. Is it possible to use own state charts for each indibidual (subscene) or is that not how the system is meant to be used?

[@lalalala99661]

I had the same question, finaly i just testet it yes you can use multible state Charts.

[@noirlavender6409]

I don't understand shit... yet. Thanks for the video ♥

[@goblinslayer5404]

Thanks for the video! I was looking into state machines and state charts recently, from my understanding state charts helps solve certain problems that occur with finite state machines (state explosion) and it overall makes things a bit clearer and easier to understand. My question is, is there a reason to use FSMs over state charts? (perhaps performance reasons?)

[@Korn1holio]

AFAIK, ease of use. If you're only going to be at one state at a time, you don't really need state charts. State charts have been really useful for me to combat so-called 'state explosion', when you need separate states for every combination of atomic states.

[@elderdragon7856]

I just found out about this amazing tool. I usually use a node tree for the state machine so every state gets there own code. But in the video you use a single script for all logic? I still would like to have a script for every state for better organisation. Should I make a separate States Node (as sibling to the State Chart) with all states (as children)?

[@godotneers]

Well the library is somewhat opinionated in that regard. You can of course divide your script up into multiple scripts which you add to additional nodes and the library will happily work with it, because it uses signals to communicate with your nodes. Godot also now has code regions with 4.2 so you might not even need multiple scripts anymore to keep things organized.

[@quebrandojogos]

Hmmm, I really don't like this approach. The entire behaviour ended up being coded inside the watchman script. So if I wanted to code another entity who also observes enemies but has different behaviour, I would have to copy and paste a bit of the code. The way I would do this in Unity would be by writing a component/script for each state (or action inside a state) and transition, then I would plug my actions and transitions inside a StateMachine component. That way I could have a "follow target" component that I could plug into any state machine that needed that behaviour.

[@godotneers]

You can do a similar thing in Godot even though Godot has not the GameObject/Component concept of Unity. Make a child node and add a script for following other entities there. It will control the parent node and move it, similar to the component you would have in Unity. Then in states where following is relevant you can connect the `state_update` signal to this child node. This way you can have different state trees but still reuse the behavior. Signals can be bound to multiple things at the same time so there is no hard requirement that would say every code related to the state handling needs to be in the same script or node.

[@iamsecrets]

i'll check this out!

[@mictony999]

Hi im very thankful for this tool but im currently confused as to how to set up historystate nodes. the docs says i just put them under a compound state and set a transition to it. But I did that, I had a movement compount state with atomic states (walk, sprint, idle, jump). I want to be able to go back to the last state after transitioning to jump. so I transition to my history state after the player is on floor yet the historystate keep going to the default state.

[@0MVR_0]

nice asset all this can be done with godot two dimensional nodes with scripts yet the debugger is very convenient

[@godotneers]

I agree that this example can probably also be easily implemented with a few scripts and without a library. In fact it _should_ be done without a library if it is that easy. But the idea behind this video was to show how the library works in general and what features it provides and how to use them. A more complicated game logic would probably have made a better case for using this library over hand-written code to simplify things. On the other hand it would have gotten in the way of understanding the concepts. So I decided to go for a simpler example. If you want to see some more complex examples, have a look at the bundled example projects.

[@wrong1029]

Seems needlessly complicated versus rolling out your own state system with match statements and signals. Plus each node you add incurs additional costs versus having all the state and transition logic in one script.

[@godotneers]

Depends on what you need. If you just need 3 states then this is overkill. Make a script and be happy :D. If you have more complex logic and maybe a lot of timed stuff, then this really can help. The library is pretty optimized, so it will not incur costs for states which are currently not active.

[@Korn1holio]

That was initially my thought, but I gave it some time and it's brilliant. It basically allows you to create any amount of concurrent states, so "Move while attacking" becomes super easy to implement, whereas in traditional FSMs you can be in only 1 state at a time (either moving, or attacking).

[@ivysly]

This is so cool

[@zachnewby4739]

Thanks man.

[@sibotime]

Maybe I missed something, but I don't really like the states knowing how/what to transition to. I prefer to have a parent notice what's going on and transition to different states without the states knowing about other states. But maybe I'm getting too deep into decoupling, and I should be okay with states knowing about each other. I do end up with a decent amount of code in the parent object going through logic deciding which state to be in 🤷

[@godotneers]

Well in the "classic" way of doing things, there is usually code which actively activates/deactivates states, like you said. In such implementations the concept of a "transition" doesn't even exist. Which as you observed translates in a lot of if/else if you control everything from a central parent. Alternatively you have code in states which directly transitions to other states. In this case the states also know about other states. With the transitions this logic moves into the state chart. You just send an event and based on the current state that event can lead to different things. Nothing could happen, or one or more transtions could fire. The states themselves don't really know about other states. They just send events and the state chart is reacting onto it. The state chart is the entity that knows all the rules. So you basically replace your big if/else with a bunch of nodes in the scene. If you rather control stuff in code there is nothing wrong with that and you can just do that as well and don't use the library. I personally find the separation quite beneficial and things like delayed transitions are quite useful as well and putting these into a big if/else is probably a bit more difficult. But just because it works for me doesn't mean it works for everyone. So if you rather roll your own because that works better for your project and your personal preferences, that is totally fine - in the end we just want to make a game and nobody really cares how its done internally as long as it works.

[@boozebeard9501]

Looks useful, but doesn’t having that transition guard code hidden away in the inspector, rather then being part of the script get a bit confusing?

[@godotneers]

If you have more than a single expression in there it can be, yes. Usually there should be only a simple expression in there like `health > 0`. If you need complex logic in your guards, it may be better to put this in your code and just send an event as the result of this complex logic which will trigger a state change.

[@ElNightmareYT]

I'm having trouble reusing basic states such as Wander or Chase, where any enemy does basically the same. Since the code is handled in the main script of the enemy and not on the State itself. Any suggestions on how to use this addon whilst being able to reuses states effectively, without having to duplicate code? Many thanks for the addon and the tutorial.

[@kacaii3349]

Could you please make a tutorial on how to make a 2d platformer with this tool? ( beginner/intermediate here ) Btw this is going to save me a bunch of time

[@Korn1holio]

not OP, but there's a sample platformer project included with the addon, you might examine it, since it's pretty straightforward and commented.

[@RealPigeonz]

I rly love this State Machine Addon!

[@DizzyTurtlz]

Could you make a video showing how the animation features of statechart work? Its hard to wrap my head around it.

[@owenlloyd2528]

Thanks :)

[@Lukfin]

do you know if synchronizing the states with godot built in multiplayer would work? I got the state chart working with my movement animations and some combat states. trying to know if this is usable in multiplayer. Thanks so much!

[@bennicus4901]

If you didn't have parallel states, could you get the same functionality by implementing them as another state tree? Apart from having to mirror the events and expression properties to two trees rather than one, it would do the same thing right? Also, is it possible to write scripts on the actual states themselves? In some cases it might make sense to contain it there rather than having to put all logic into one large parent script. They have a script icon in the tree, but blue rather than white, I wonder what that means.

[@godotneers]

Yes, depending on what you're trying to do you might be able to model this with multiple trees as well. If you need state changes across the trees this might become a bit more difficult. As for your script layout you can pretty much use any layout you want because the library uses signals to call into your code rather than requiring you to derive from some base class. E.g. you can also put components on the root node and each component can be called by the state chart depending on which state it is in (e.g. a movement component, a targeting component, etc.). Technically you can also extend from the AtomicState class and write your code directly into each state - just be careful to call "super" when you override functions otherwise you may see _interesting_ behaviour ;).

[@byj5970]

It looks great, but I have a question. After using this plugin in Godot ', do I need to make additional annotations or apply to the original author? If you want to publish a game that has used this plugin, what specific steps do you need to take?

[@godotneers]

The library is provided under MIT license, so the only thing you need to do is put the copyright notice somewhere alongside with your software. Most programs solve this with a LICENSE-3RD-PARTY.txt file where they list all the libraries they use and which licenses these libraries are provided under. Some programs also have a similar list in their _About_-dialog (e.g. Godot itself has a 3rd-party licenses tab in their about dialog).

[@vettie]

I was trying to use the other nodes/methods based on the provided documentation but they are not functioning for me at all. _run_transition specifically isn't working. I assume that since you did not show any of the other nodes/methods in this video, that not everything has been fully implemented/tested, but perhaps I'm just misunderstanding the documentation.

[@godotneers]

The only node you need to interact with is the root state chart node and there you basically only need one method - `send_event`. If you have two states A and B and want to switch between those, you will first create a transition in the editor below A that transitions to B and reacts to some event, e.g. `some_event`. Then from your code you just call `send_event("some_event")` and the state chart library will switch from A to B if A is currently active. So you never call `_run_transition` manually. In general all methods and fields starting with an `_` are intended to be private and not be called/used from outside.

[@kevinpatel4873]

Hey this is an amazing plugin! Thanks for creating this! I'm having one issue. How do I make it so after an animation plays it goes back to the idle animation. I'm trying to add an attack animation to your frog from your platformer example but I'm having some issues. I added the attack animation to the animation tree and added the required nodes for the attack state but I'm not sure how to make it so the attack only goes back to the idle state after the animation finishes. The only thing that's working for me right now is if I add a delay to go back to the idle state which is the exact length of the attack animation. Any help would be appreciated.

[@godotneers]

Would you mind opening up an issue at github.com/derkork/godot-statecharts/issues and posting some screenshots of what you have set up and what the goal is? Just from a textual description it's really not possible to give solid advice.

[@Gamed-dd7tj]

Hey, great video. I had a slight problem while using it though, which is if I check for an Input inside of a state"s _physics_process, if the state transitions, there seems to be a short window in which the Input is not being acknowledged by either of the states. Is there a way around this?

[@godotneers]

State transitions are usually done within the same frame so there should not be any delay during state transitions. Could you maybe open up an issue at github.com/derkork/godot-statecharts/issues/new and give some more details about your case?

[@Gamed-dd7tj]

@@godotneers Hey sorry I haven't had much time recently, but I found a workaround. I spent a while trying to replicate what was happening and couldn't so I probably messed something up really badly on my end lol. Also I haven't really used github before but if I get the time I'll try to put something up But just in case there's a simple answer I'm missing, what I was trying to do was set up a coyote jump mechanic for a platformer, but whenever I changed states from wall to air or from floor to air, there would be a couple frames where the jump input wouldn't be registered by my states, but it would be registered by the normal _physics_process. Whenever I would check to see if the state was active whenever I jump, it would return active, but the state physics_process wouldn't detect any Inputs. My workaround was just to put the coyote jump logic in the main _physics_process, and it works well enough. Either way, this addons made my time in godot way better, so I'm not complaining lol

[@FromNewRadius]

What would be the correct wat to implement the attack state on area/body entered during that state since you don't have the enemy reference?

[@godotneers]

I'm not sure I understand the question but you basically get the reference when the body enters as parameter to the `body_entered` signal. You can save that reference to a field and use it later for attacking (the video does this as well starting at 12:06, but only uses the reference to look at the enemy).

[@FromNewRadius]

@@godotneers Thank you, thats what i meant. But didn't look clean to me saving the reference since there may be multiple enemies or only 1 and managing that reference/s when enemies enter or die didn't seem to belong to player node responsability. But i'll do it that way.