I'm just starting out on Godot so I'm grateful for the tip. Makes perfect sense as I was just coding some charcter movements and thought about how I could do this. Your game looks totally dope btw! love the character and the 2D/3D hybrid vibe.
The video title will make people expect a dedicated tutorial. Like, imagine you're in a rush to code something for a deadline or game jam, you find "state machines explained" on youtube, and you skip through the first 10 minutes of the video until you finally see code. That's how a lot of people will interact with this video, if they don't close the video first
Experienced Godot developers with deadlines, or those participating in game jams, are likely going to be just fine. This is a beginner's video, though. I understand what you mean; I deliberately avoided words like 'how to' or 'tutorial' and immediately provided tutorial links. But I like that you're not coming in guns blazing. ;) What would you change about the title? ;)
I'd personally change it from "explanation" to "game showcase" or "game spotlight" (e.g. State Machine showcase). Either way, great video, love watching your journey through Godot.
@@ChapC_Creates I can't speak for everyone, but I definitely didn't understand finite state machines before finishing my first game jam. And there's plenty of summer/college courses with assignment deadlines that teach coding to complete beginners Even if I'm wrong and no one ever needs to learn this quickly, it's still good to respect your viewer's time, instead of making them watch 4 minutes of talking (3:50 to be exact) before you say "this isn't necessarily a tutorial". Especially nowadays when people's attention spans are adapting to 1 minute videos, it's very generous to say that 4 minutes in is "immediately" providing links. By then, a lot of people will be skipping through the video to find the info they're looking for, and might not even see you saying that My title suggestion would be put "Devlog" somewhere at the start, since that's what about half of the video is, and cause most of the explanation part is at the end. My biggest suggestion is saying "this isn't necessarily a tutorial" in the first 30 seconds, if not less But I recognise that youtube rewards you for convincing as many people as possible to watch, even if the video isn't very useful to them, and it rewards you even more for getting those people to comment about it. So I can't really make you change the way you package content. It would benefit others if you made things more clear though.
I agree, I watched the full 16 minutes of the video and I still wouldn't know where to begin implementing this in Godot. Now I have to go watch ANOTHER video to try to understand it. I don't want to be mean but this is just an ad for his game. I wish him good luck but it was a waste of time for me.
Thank you! Please keep up the great work. We need more creators making tutorials, and pointing people to updated tutorials. There's not enough for 4.0+, and even less for 4.0+ in 3D (or 2.5) Bravo m8
Thank you! More coming soon. I'm working on two tutorial videos right now. I wish I could release more, but some real-life stuff is taking up my attention.
I cant wait for your tutorial bros. I'm sure it will be one of godot greatest teachings. And I hope to apply the knowledge you taught me to my game, which is similar to River City style. Respect
Just read another comment ripping into you for talking too much before saying this is not a tutorial… I dont know whats wrong with people 😂 I wouldn’t have even known to search for a state machine tutorial without watching this video, and yet it’s EXACTLY what I need and your video brought me up to speed. I found myself in exactly the same situation, with a crazy-long piece of messy code that checks if a player is jumping / attacking / sliding / knocked over / etc etc. And I too had some weird dreams after getting lost in code! Your video is great, it’s brought me up to speed on the best approach to solving my problem, and it’s pointed me in the right direction to some great tutorials. Keep up the good work, new sub here! (Your game looks great too, love the visual style 👍)
What a sweet thing to say. For every negative comment I get 99 lovely ones like this one. But I do want to be more transparent next time. They were, from a certain pov not wrong 😅 - anyway, keep it up. Recording new videos this weekend and next week.
State machines are really awesome for many use-cases in software development. Not that important for many types of games, but maybe worthwhile to mention for anyone who wants a lot of units active (RTS, sims, ...): The big disadvantage of the node-per-state approach is performance because of the high number of active nodes. Using classes (or interfaces in C#) is usually my preferred approach and is just as simple to use.
I don’t see how “many units” has anything to do with state machines. Does a thing have discrete states with defined transitions? Then give it a state machine. Doesn’t matter if it’s a top level game manager, a player character, a gun, whatever. Doesn’t matter if it uses nodes, simpler classes, or a match statement. A state machine is just the pattern.
@@panampace It does matter for performance. Each node consumes CPU and memory during construction, deconstruction and each game loop iteration. Even calls to an empty _process cost a little bit. If you have a lot of states and a lot of units it quickly adds up. With the object approach you can either completely avoid additional nodes or work with a single node per state machine. Depending on the complexity of the state you can even share the state implementation objects between all units, or at least only allocate them if a unit actually reaches a certain state. With a lot of units this can be the difference between smooth gameplay and stuttering once the actions starts. If you only do something like Mario with a hand full of units you can usually do what you prefer though. Hope that clarifies a little bit.
@@yannick5099 Yes, but that's more a reason to move away from node based state machines to something that just sits in memory somewhere. FSM don't need to interact with godot nodes and they're commonly used in high performance computing.
@@novembermike512 I think we are saying the same thing. I'm not arguing against state machines, I'm arguing against the node based approach which is common in Godot.
What you did is called Refactoring great job, its something i'm too lazy to do in my game which my player script has reached over 900 lines of code :( well done man
Thanks, man! I kind of started over again in my latest video regarding the state machine. I now use the LimboAI addon since I really loved how they went about behaviour trees. But I also need to watch out refactoring too much, because progression would be nice too. 😉
@@ChapC_Creates I wish you all the best brother your journey is what matters, I have watched your recent videos and I loved it, I want to see your progress ofc, and don't worry too much about refactoring the fact that you redesign your player script and used state machine instead of a spaghetti code is way better and it is smarter overall and its good enough! Good luck bro all the best!
Having this type of nightmare is so reliable, in fact I had one today. Plus I was always worried that I was a weirdo for having them. Good to know I'm not alone
I can’t agree more that beginners should learn state machines ASAP. It makes life SO much easier when putting together something like a character controller. Before, I had spaghetti code. With a state machine each ability I add to my character is just a new short script.
First of all the art is incredible!!Nightmares of code… after 40 years of programming (started as a 10 year old) I still wake up with the awareness that something has a potential gap, a bug a security issue and lots of improvements. I guess my subconscious works at night: so I will bill my Dutch banking client for my nightly work 😂
@@ChapC_Creates btw, in working on another theme in Godot for my channel. A bit larger than the first one (video last year) for making a Sokoban clone called pirate ban. And no I don’t use a state engine, as I couldn’t be bothered to look into an idiomatic way in Godot - hence I watched your video as I cursed myself for not taking the time and spending 3 hours, getting the grabber in the game to work. Especially with the asynchronous workings of the nodes, makes it unnecessarily complex. I would’ve been quicker using Zig and RayLib Because there’s no out of the box concurrency except for music/sound that just runs in its own thread. But now I’m more educated and doing a node based (composition) FSE in Godot next time 🤣 This one I’ll probably spend another week on. So a two week game. It’s a clone of the Stone Age game of the Atari ST/Amiga/DOS a puzzle game. But with overhauled graphics. Eventhough, I was a VFX artist (compositing and technical development) Im no artist unlike yourself. So I truly envy your abilities.
I think this video is a good stand alone video! but if you feel like making a part 2 that goes into depth on your coding i feel like that would also be pretty useful too! Keep up the good work man
Thank you so much! I am currently figuring out LimboAI and how behavious trees and state machines work with that add-on. Im currently comparing the custom code of this video with the video I am working on currently. I am planning to make more videos once I am a bit more experienced. Keep an eye on the channel for more.
Funnily enough this is exactly what I decided to learn. I've been learning godot for about 5 weeks, around 2 hours a day after work. Totally new to Any programing. I feel like I've learnt a lot by doing this.
Ah, great to hear! Sometimes I feel like a fraud, telling others what to do while I'm still a beginner myself. So it's reassuring to receive some affirmation from the field.
I actually have had nightmares similar to what you mentioned. Those kind of dreams, where the point seems to be that I’m stressed out and experiencing sensory overload, are often worse than the classical nightmare of just being scared by something.
Yeah these are the worst. I rather have an scary dream instead, at least I don't wake up as broken. It's always the software dreams that hit the hardest.
Another way of describing the state machine improvement vs. spaghetti code is that they increase cohesion. A piece of code is cohesive if all the statements contained in it "belong together" in the sense that they access or modify a common subset of program variables. Whereas "spaghetti" code contains interwoven statements, some of which accessing one subset of variables and others accessing a completely different subset. Other fancy terms for the same concept are "separation of concerns" and "aspects" (pieces of logic that appear throughout code, but which can be extracted and centralized, and "woven in" at appropriate places declaratively). For OO interfaces (which contain no implementation, just method signatures), cohesion is when all the methods of an interface are likely to be used together in a typical use case, i.e. you don't have "odd ones" that are not directly related to the others (and that relationship is created by logical state the methods operate on). These insights also apply to business, engineering, and organizations of any kind, at the bottom it is a mutidimensional mathematical "cost function" which you are optimizing while designing something. And maintainability/comprehensibility to humans is just one cost component.
Very good statement. The problem is a core issue in software programming. I would also say, that "relying on abstraction, instead of implementations" is a key design thinking pattern. Building common abstractions for concepts and then build your application code arounds them, iterate, build new abstractions. I totally agree with you statement, coming from a long business software engineering background. I would say, refactoring your code and concepts while adding new features is essential in any project of any kind.
@@u.n.v.e.u.9696 Yes, the problem with just recommending abstraction, though, is that it gets fuzzy and can be done incorrectly, and can lead to religious debates. E.g. hiding too much of implementation could be detrimental if exposing it would allow optimizations. A classic example is shooting yourself in the foot by making batch processing inefficient in favor of invoking single-object operations (with overhead) in a loop. Then there's the issue of "leaky abstractions" which look on the surface as if they were hiding implementation details, but in reality many scenarios exist (e.g. when it comes to troubleshooting) when the abstraction breaks down and you have to understand the actual implementation anyway to reason about behavior. Finally, there is the ergonomic problem with too much function call indirection / too deep class hierarchies where your code is "neatly modularized" in principle, but distributed across so many different files that it becomes a nightmare to navigate through it and to remember where exactly each piece of functionality is coming from (especially if it is only plugged in at runtime). I suspect this is main reason why some people grow to hate OO and revert to a more "linear" and down-to-earth style of coding. So we need more concrete (!) criteria for what "good" abstractions are, and cohesion is one of them. Any improvement in one dimension usually comes at some cost in another.
@@clray123 also agree, going just with one concept will also lead to a mess. I feel your statements. Abstractions for well defined, single responsibility, neat, small, maintainable pieces of code. I am messing with god classes and god implementations all day, duplicated and derived code. Code which actually got the same function everywhere with a small difference here and there. This is what I meant by abstractions over implementations. Of course well defined, small scoped, separated into its responsibilities.
@@ChapC_Creates I like that idea, also you know how Kerby can do a slam move while in the air. It'll be cool to have the similar affect while shielding in the air to slam down and knock back enemies. Increase downward force and maybe a cam shake for effect
Cool video. I've been thinking about giving up my IT job and designing an ARPG. For combat, movement, animation and whatnot I kinda started reinventing state machines in my head it seems. I did not know this concept was an established one.
Excellent video your explanations are top notch, one suggestion I'd make is have you tried making a shadow/indicator on where the character is going to land when jumping? I think it would improve the feel of it quite nicely
The way I would've done it is to have the states each be a class snd if there were something similar about everystate make a parent class. the script handeling the character logic would then be able to store an array of a reference of each state class so the functions of the state classes can be directly called without node middlemen and would make implementation of future states easier.
That makes sense too. There are many ways to approach it, even through add-ons or extensions. Once you understand the overall concept, there are multiple ways to implement it, I think.
Your right, you could also use the command pattern in order to implement player actions and call the execute command on the action using classes and inheritance. I'd rather use a state machine for states of the overall game. But it's an approach I think. Looks nice though
Great video! I'm currently working on implementing the movement system, which is already around 200 lines of code. I'm concerned that adding a combo feature could push that to an additional 400 lines. So, I'm going to look for other videos on this method to simplify the game and keep my sanity intact! 😄
I was in the same boat. Try and download the shaggy devs source files and play around with it for a bit. Really helped me out a lot. Its im de description of his vid. What game are you making!? 😀
@@ChapC_Creates I'm creating a hand-drawn, story-driven platformer about a political insurgency in an underground world. It's a short game since I'm a solo developer.
As nice as the sunset in the background looks, I think you should reposition the sun overhead so that you can adjust the shadows. In your small demonstration playthrough, it almost looked like even you, the person who made it, almost failed to line up to hit a bee floating in the foreground. If the sun was positioned overhead, the shadows on the ground from the floating monsters would assist with lining up with the character model, so that they could more accurately hit the monster after they jumped.
In the latest build, I added an extra decal circle that always points directly to the ground. This way, I can still have different sun positions based on the story's narrative. But you are completely right, the depth perception is an issue!
@@ChapC_Creates yea, there is a draw back. fsm can be slower than hardcode. thats why many oldschool dev for old school competitive fighting game still preffer 1000-2000 line code.
Seems like you could handle these states using bitmasks. That is the most efficient way to represent "states" in programming. A 32-bit unsigned long int offers you 32 possible values (including 0), and you can combine states if you need more. Not sure if godot has the ability to declare char (8-bit int) or short (16-bit), but if it does then you can optimize further by not using a 32 bit int where you only need 8 to 16 possible conditions. You could then use switch statements to quickly figure out which state the player is in, and then call the relevant code from functions. For example. WALKING | (1
Once upon a time this was the only viable solution in handling state machine due to memory constraints in old computers and video game systems. It's a handy skill that can extend into so many other areas too despite the abundance of space in environments now.
@@thedrunkmonkshow Not just about memory use but also about being able to check states more often without any real performance hit. This approach would also have benefits for people that are making a game that depends on low network latency, with regards to broadcasting player positions to the connected clients.
@@alphaforce6998 for most cases it seems over-optimization at the cost of code clarity. If checking and handling states is in the scope of a performance bottleneck one might consider these low level optimizations, otherwise it just makes you code less readable and maintainable.
@@SystemUpdate310 Code readability is entirely up to the programmer. You can use comments to explain things or put reminders for your own references. But with bitwise fields, you actually gain readability because you can set them as constants, using descriptive names. For player state contstants, you can name them: PLAYER_STATE_* You can get as descriptive as you need to be, but you can also use the same approach for other instances where you are using bitwise fields. As I said to the other person, checking states is not the only reason to do this - you can effectively condense a lot of data into a single integer, which is foundational for network protocol design. A single "player_state" int variable can contain all possible player states, and this can also include permissions, unlocked game features, achievements, buffs/debuffs, ability properties. If your game is going to be exclusive to 64-bit systems you can use 8-bytes to contain up to 63 statuses.
I had these code nightmares while developing a software that was part of a research work that I needed to do in order to graduate. They are TERRIBLE! I wasn't sleep but I wasn't awake either. And when I noticed the sun was raising already and I didn't slept at all. Thank God these times are over!!
I had a situation in my game that was getting into 13+ levels of if-statement hell and was getting very flakey. I feel your pain. Instead of going your way of separating the code into separate files, I set a series of boolean toggles to define the state. For example, in your case, they would be isJumping, isFalling, isMoving, isAttacking, etc. Then if an action was state dependent, I'd check that simple boolean "If isJumping ..." before calling the correct action code. I could then add multiple actions based on the same state or separate the actions for different states. if isMoving: key_down = slide() If isFalling: key_down = fast_drop() If isJumping: key_down = short_hop() If isAttacking: key_down = duck() This reduced the incomprehensible series of nested ifs into basic if-else statements. This also eliminated 90% of the bugs introduced while trying to fix stuff since the error in that if statement was exclusive to that if-statement. So long as the states are not being changed by everyone and their cousin, it's a simple matter of knowing why x code is / not being run.
Honestly, I’m learning something new every month-working with components, state machines, behavior trees, and so on. I would probably do everything differently each time I start over. I agree with your idea of not overcomplicating things just for the sake of it. Great insights, thanks!
@@ChapC_Creates My situation was a lot simpler w fewer states to monitor than what u end up implementing / are planning to do. The needs of the project will determine the level of state machine u need to work w.
Dude! Great video! But I've been thinking about your state machine code work. I think you can improve further. Make a script that is a node called state handler and make your sates become resources. After they're resources, you can save save them as a file and they become reusable for other playable character you make in the future. Most of the code in your states are in the same shape which means you're reusing a lot of code, that's why you can use a state handler node inside your playable character scene tree. That node will hold most of the code. In the states you can save your sibling states directly associated with the input they're expected to occur with or something else (like taking a hit). The framework is the same. Let's say your on the ground and take a hit you might wanna make your character stagger but if you're jumping and take a hit you might wanna fall flat. Same code but different output states. Anyways, this got longer than what I thought. Have fun bro, nice game you're making!!
Very interesting. This is my first attempt at a state machine, and I'm pretty sure I'll eventually end up with something completely different. I like your setup; it would accommodate many 'in-between' states. I'm currently managing that by setting information in the global player.gd file. Thanks for the input!
I think this is good for him to do further along, then again this project is simple from a coding stand point so he might be able to get away with it... but once his logic is done then just taking that code and putting them in resources is good, otherwise the time spent on the boiler plate will increase a lot and quickly as he lizard brains through it.
As I start trying to get game 1 off the ground, I have been trying to learn about this. More specifically, "Game programming patterns" and what a lot of developers seem to be calling "components". Breaking individual code tasks into new nodes. So you have a node for controlling physics on a character, separate node for input, separate node for each mechanic. Honestly, the project isn't complex enough to need it, I just decided to try to commit to such patterns to improve my game dev as I started. Hasn't fully clicked yet, though, in my head. I feel like the decision for what goes into its own node is arbitrary, and the overall execution feels wrong to me for reasons I can't identify. Even though so far it's a node for controlling physics on the player, a node for controlling player input, and a node with just one line of code for returning what the collider is looking at for interaction mechanics not implemented yet. Anyway, video gave me some thoughts. I knew about state machines, but I hadn't give it much thought.
It will click eventually. Just by making games and implementing small ideas at your own pace, you'll get pretty far. I still have a bunch of videos in my watch later list about the component-based approach to programming your game. Hopefully, I can share some insights about that later on this channel! For now, this noob needs to grind for another week. ;)
Yeah, I'm just bad at getting past that point. At least I made one piece of code I liked that I don't see used: @onready var main = self.owner No need to export what node you're manipulating. it goes off the assumption that the root node is what you're working on, which I feel will be the case.. pretty much all of the time since Godot has you break stuff down into scenes. Anyway, I'll keep an eye out for that video when you get there; probably gonna follow after I get around to watching a couple more videos. I got more tutorials to go through before I try to re-code my game and see if it clicks better.
Gosh I say 'basicly' soo many times, so annoying. To those expecting an actual tutorial, I just uploaded one regarding the basic setup of my camera + gridmap: th-cam.com/video/6T_TDuzEo9o/w-d-xo.htmlsi=Ih-ppKiNAWSwaPP7 More to come. Check out the State Machine videos I used to learn about this topic: th-cam.com/video/oqFbZoA2lnU/w-d-xo.html th-cam.com/video/bNdFXooM1MQ/w-d-xo.html
@ChapC_YT Hey, in another post you asked about the method of setting up animations in a more modular way. I responded but checking back on the messages I saw your question is not there just my response. I also contacted you via Discord with an offer to simply show you the result in my own project of the systems involved and share the code/theory on how to do it. I offered this because you asked if there was a video for reference on how to make it and tmk there isn't one. I made it out of a need to have quick access to any animation in a human readable way. I believe I joined your channel and sent you a hello directly, but then this morning I noticed I did not see the discord. Is it fair to assume that I violated some part of your terms and/or that you aren't interested? If it is the latter you could just say so, I asked that if you were not interested you just say so, after all it is my time as well to have to explain this.
The first thing any godot beginner should learn is learn to go through the official tutorials and also learn how to read the official documentation. So many questions could be answered if they could do just these two things.
It would be very nice of you expanded the code window and increased the text size. I find it very difficult to actually see any of the code you're talking about on my laptop.
Your completely right. I am finishing my 'first tutorial' right now, since this was more a showcase video. The upcoming video will be zoomed 150%. Stay tuned!
Very interesting video. State machines are so underrated, but often a game starts with a PoC that is slowly growing into spaghetti code. Often you don’t start with the state machine, because it seems like over kill for just trying some stuff out.
Yeah, it's all part of the journey. I am currently in my third refactor phase. The more you learn, the more you'll optimize. I do have to be careful that over-optimizing isn't holding back my first game, though. At some point, it's okay if the code isn't 100% optimized.
I'm curious about how you'll implement the shadow under the turtle. It's super important in such a 2.5D game so you can see where the turtle will land when she jumps. Does Godot have a decal projector? It might look weirdly stretched on cliffs. Sure, adding a cos to a shader is easy, but that's if Godot lets you access that shader at all. Maybe it's easier to cast a ray down and center a semitransparent dark disk there, but it'll hang over cliffs. I don't know, I'm a Godot noob and that's not a feature I need. Still, I'm super interested in those tiny details :D.
I'm curious too! XD I have it figured out in my head. I know exactly how it should look. But how am I going to implement it? No idea yet. But honestly, that goes for everything I implement. Currently, I'm taking a step back and working on the story for a while. Next, I'll be working on the actual game loop, enemy AI, etc. After that, I'll probably start working on the first level design and optimize many things, such as the jump projection.
I am currently using state machine in my game but my biggest issue currently is code reusability. A bunch of states have the same code. I need to figure out how to make states share the code. I guess i could use inheritance but i dont know if that is the right approach or is there a better way.
Wow, I really found this state machine you made interesting. Could you make a video explaining it better and how to implement it later, and the call logic? My state machines never work that well XD
Would be cool if you could slide down a slope while crouching in the shell. But I can also understand if you want to limit the ideas so it doesn't get out of hand :D
Great idea! I recently wrote the intro scene where the mother goes into her shell to pass through fire and save the kids. This made me think I should probably add this move to the movelist. Going into the shell from a standstill will allow the character to defend themselves from falling debris. The slide can then be used to pass through small spaces, fire, and other hazards.
I on my way to click the subscribe button, but then I saw your dog and subscribed even faster. This was a great video that helped me understand how to bridge some of my existing programming knowledge with the Godot system.
I'm so glad to hear that! At some point, I was doubting myself, wondering if the video was too vague and if it should have been a 100% tutorial instead of a showcase. But personally, I would have found practical examples like this video helpful, and I'm glad more people feel the same way.
I will be looking into it! there are probably multiple ways to go about these things. Many devs use different state machines for different parts of the character, for example the weapon handling / animations.
Sir you could have use this technique like make a function for movement where there is also the input movement like sprint, run and idle and the next function for the jump and fight and so on, after that you can simply use the function on physics process or process . I personally do that all I do is copy and past it on the other function and just need to adjust the code the way I want. Hope that also help😊
All feedback helps! There are multiple way to go about this. But having single purpose functions that are easy to review (also after a few months) will probably be included in all good working solutions.
All your states extend the 'State' class, which is defined in the state.gd file. In that file, you can see the 'enter' function, where the animations are played for each state. You'll also notice that each function (for example, process_physics) in this file can return a State. In the statemachine.gd file, it checks whether a state is returned, and if so, it swaps the current_state variable. Its difficult to explain in just a comment, but feel free to join our discord and ask me there. Then I can share you some screenshots.
This means that the state script needs the following functions -enter -process input -physics process and there is no need for an exit function? and if you want to make playable entities and artificial intelligences later on, do you need to separate the 2 types of entity or is that not necessary?
Exit gets handled by the state machine by simply swapping states. Each state is expected to return a state, and with that it 'exits'. I am currently researching LimboAi regarding state machines and behaviour trees. I might be using behaviour trees for the enemies. The moment I know some more, Ill probably make a devlog/tutorial about it.
@@ChapC_Creates So in the state script what required is a process_input + physics_process + Enter function and that it? (Is there gonna be a tutorial for states machines on this channel?)
So the code inside these state nodes are the ones that are exclusive to that state? For example on my shooter game I want to be able to aim while moving and jumping, so assuming there can be only active state at a time, would I write the code for aimming on the player script or is it possible to have kind of two states working at the same time? Kinda how you can move while jumping in your video.
Yes, that's correct, just 1 state at the time. BUT you can have different state machine, for example movement state machine and a weapon state machine.
@@ChapC_Creates That makes sense, will try to find a way to make a state machine that works on my project Good luck on yours, coming from a huge smash fan I love your concept and hope it goes well!
Hmm, yes, the video and the topic is really interesting, really, but I had trouble to focus on what you were saying since I was trying to remember to whom you look like, and yeah, I remember, if one day you do some kind of cosplay, please do Joseph Seed from FarCry 5 lol, you're a carbon copy of him ^^. Anyway, I'm gonna watch the video a second time to learn this time instead 😅
haha nooooooo not you as well... this is the 3rd Joseph Seed comment. I really need to finish that game, btw p.s. im working on a bunch of tutorial videos as well since these vids are more showcases. stay stuned.
@@ChapC_Creates haha lol sorry but yeah for more than half of the video I couldn't focus because I felt I knew you from somewhere lol but sure, I'll be interested in more tutorials then ^^
A few weeks after I switched over to LimboAI for both the state machine as the behaviour tree. Upcoming videos are going to be about this. I really love the add-on.
Nice video and well explained (i subscribed), i will definitely save your videos and recommendations for my future projects but i just have some feedback on your game. Since it has smash inspired combat style and tmnt i need to criticize the the camera angle. since you want to make it 2.5D when showed a bit of gameplay i found it very hard to get a good depth perception. what i mean with this is that it is very hard to know when you are able to see when you are in front of a enemy or not (or at least close enough to hit them since i saw the colision boxes around the bees). i dont know if changing the camera angle would help (giving it a more top down view) or maybe a circle indicator on the ground when you are close enough so that you can see that you are in attacking range or somewhere in those lines because it looks very frustrating seeing a nice 3D environment where you can move around and not knowing if you can hit the 2D sprite because its flat. This is just my dutch gamer/complainer side talking. the rest of the video was very informative :).
Spijker op de kop ;) You are completely right. I have been thinking about this a lot... at some point I accidentally turned off all z movement. While somewhat being a downgrade, the game DID feel more natural to control. So thanks! I will definitely test out multiple ways to fix this. Thanks for subbing too!
hmm. yeah maybe you could implement something similar and link the related states by assigning them via the properties inspector? Hopefully you will figure out something soon.
This such good timing ! I also implemented state machines using shagy devs tutorial, it made the most sense , was there other implementation u looked at too ?
I went through basicly all youtube vids out there regarding the state machine. Also ended up messing with some extensions/add-ons.. but in the end, I wanted a more simpler aproach, more close to godots node based system, and ended up with shaggies code again. Probably depends on your game type as well. Is it working for your game as well?
Yeah, I agree, I have a friend on Discord who released his game on Steam, being the guy who is notorious in various communities for his State Machine and pushing it down every dev I meets throat it sucked that his game obviously failed to employ one. To be fair he was using GameMaker not Godot but his controls didn't care about context, which was a huge turn off. I honestly thought he was going to release it as EA but when I saw full release I was hurt for him. I mean really hurt, that game could have used just 2 things more and it could have been ready for EA... but full release... Anyway for your combat stuff, you probably want to employ custom resources, and the use of a nodal combat tree to handle animations in a modular way. This way what animations you can do are based on the nodes present. You simply assign the node as a child and register it to whatever you map for controls then when you press the button the animation on that node is played and the node handles the logic for how you do the animation. This way you don't get caught in animation resource hell where you keep needing to add animations to your list and instead you can just either place them on a node or a custom resource. For the animator itself, just be sure to have blend setup to change between 2 animations when you attack and that's it, the nodes will register the animation and whatever animation currently playing will blend into the next animation, the nodes again will dynamically unregister and register their assigned animations to your animation player.
@@ChapC_Creates I mean I do not. This is something you can just design for yourself, I'm not good at doing YT videos so posting how to make one is kind of out there for me. But the principle is as described, personally I like using objects but strings are safer for reference. The key things to understand when doing it are: Collections, Regex. File/Dir - Access commands, and that gets you to a good place for accessing your resources programmatically by creating a database on the fly for your project. What I mean is Say I have animation name "Fly" in my project I can do var fly : Animation = Repository.find(Properties.Animation.Fly) Say I wanted to get all the animations in my project: var animations := [] for i in Properties.Animation: animations.append(Repository.find(Properties.Animation[i]) Okay that gets you through the door, now you can build tables for the animations which handle this kind of API for you. So in my project I like to use the passby pattern when dealing with animations to avoid entangled awaits if Animations.try_get(some_animation, out): do stuff. Not sure if that helped but if you are truly curious I'll check back here tomorrow to see... I guess I could join your discord as well.
Godot needs a proper state machine. One like Unreal where it is an actual tree you can setup that shows the transitions and such. Just having a ton of "states" as nodes in a tree with a bunch of scripts specific to each node seems like a lot to process to me when you can have a proper state machine layout with visually defined transition requirements and can actually watch it and see what state you are in and see it switch states.
I may be misinterpreting your comment, but Godot already has an AnimationTree node. There are still some quirks, but it does what I think you're asking for.
@@ChapC_Creates it would be a security vs latency tradeoff. You either have every bit of state data controlled by the server, or you risk giving the client too much power.
You're not going to want to hear this-- but 1 state = 1 script is likely nasty mental context switching to maintain all those extra files. Could just be functions. Whatever floats your boat tho.
I do want to hear that, actually, since I’m a total noob. ;) I recently tried the LimboAI state machine approach, which had all the functions in the same code file. I think it’s a subjective thing, but I still refactored it to have separate files. So far, I haven’t noticed any performance changes, but I’m pretty sure my opinions will change at least 10 times in the coming years.
Doesn't it sort of defeat the purpose of clean code state machine when you put in that "if". Wouldn't it be cleaner if you had two objects that have the same script attached to them but have a different animation for aggresive/non-aggressive idle
@@ChapC_Creates at this point, since there is no difference except for animation, you wouldn't even need to extend it, just have an animation parameter and have it have different values for aggresive/non-aggressive. If it goes beyond animation, than yeah
But, you really DONT need this at all. Just use the AnimationTree and its associated functions to control your states, at least for anything movement based. In SOME engines building state machines is great, in Godot it is entirely unnecessary because they have already built the tools for you. That entire huge mess of nodes under "movement_state_machine" could be easily replaced by a SINGLE "AnimationTree" node, which can do everything you did but with a signal node AND visual design.
You’re most likely absolutely right! The state machine was an eye-opening way to learn about game development in Godot. It helped me get to know the engine while also making progress in a short amount of time. But I’ll probably disagree with the video title in about a year.
I dont want to sound rude but I will probably sound rude but I dont think 200 even 500 lines even 1000 lines of code is a larger code file I would say in a real world project that is a medium code file and you could have fixed your indentation hell by just doing better programing rathar than having a 15+ separate code files I guess it works either way but I have a feiling like this could have been done with with just creating a state enum then creating a function for each state and then creating a swich statement that check in what state is the player is and runs the appropriate function that then can do all the stuff that your files do the only difference it would be in one place and you would not pay the overhead of having a node for each state a enum is a number (probably a 32 bit number) so each state could represented by a number what you are doing is creating a whole ass node that has methods and feilds you will never use to represent state or maybe I dont understand it well enaught I will look more into it but doing a state machine like this seems wasteful and unnecessary
Not rude at all, you are honest. Ive heard a lot about the enum solution. Sounds like something I should learn about. I already experienced the downside you just described the following weeks after uploading this vid. Keep the comments coming! Much apreciated.
The depth of this side scroller will get me very frustrated very fast. I can easily see that I'd keep trying to hit a stupid enemy, but I'm constantly bouncing between too deep and too shallow. Ugh! No.
Yes, this is something I need to figure out. The game Teenage Mutant Ninja Turtles: Shredder's Revenge does some smart things to improve this, but it’s also less of a platformer. That’s why I’m prototyping! Let’s see where it ends up.
Haha, 404 - turtle brain not found... Are you talking about the "in-shell" stuff or swimming? Going into the shell will still be a big part of the gameplay; I just don’t want it to be an easy, bulletproof mechanic. It’ll probably be used mainly for protection from environmental hazards and projectiles but not for blocking direct melee hits.
Click bait inaccurate title. This is not the first skill Godot beginners should learn at all, in fact it's pretty specific for when you'd even need state machines. Not all games need them, most don't.
Thanks! Introducing state machines early helps beginners with OOP concepts. The visual aspect (animations, movement) makes it fun, and learning should be enjoyable. You're right-many games don't need it. The title has some clickbait (it’s TH-cam), but I think it’s still reasonable.
No, games don't needs state machine, even more state machine is just one off many aprochues to the same problem, and you need find right one for you. Also starting dev journey from state machine is very hard dive. First sould be good undersding of Godot systems and GDScript scripting.
I liked you in Far Cry 5. Awesome performance 🔥
I'm just starting out on Godot so I'm grateful for the tip. Makes perfect sense as I was just coding some charcter movements and thought about how I could do this.
Your game looks totally dope btw! love the character and the 2D/3D hybrid vibe.
How sweet and glad the video helped. It was the perfect kickstarter for my godot knowledge too.
The video title will make people expect a dedicated tutorial. Like, imagine you're in a rush to code something for a deadline or game jam, you find "state machines explained" on youtube, and you skip through the first 10 minutes of the video until you finally see code. That's how a lot of people will interact with this video, if they don't close the video first
Experienced Godot developers with deadlines, or those participating in game jams, are likely going to be just fine. This is a beginner's video, though. I understand what you mean; I deliberately avoided words like 'how to' or 'tutorial' and immediately provided tutorial links. But I like that you're not coming in guns blazing. ;) What would you change about the title? ;)
I'd personally change it from "explanation" to "game showcase" or "game spotlight" (e.g. State Machine showcase).
Either way, great video, love watching your journey through Godot.
Sounds great, changed it to: The First Skill GODOT Beginners Should Learn - State Machine Game Showcase
@@ChapC_Creates I can't speak for everyone, but I definitely didn't understand finite state machines before finishing my first game jam. And there's plenty of summer/college courses with assignment deadlines that teach coding to complete beginners
Even if I'm wrong and no one ever needs to learn this quickly, it's still good to respect your viewer's time, instead of making them watch 4 minutes of talking (3:50 to be exact) before you say "this isn't necessarily a tutorial". Especially nowadays when people's attention spans are adapting to 1 minute videos, it's very generous to say that 4 minutes in is "immediately" providing links. By then, a lot of people will be skipping through the video to find the info they're looking for, and might not even see you saying that
My title suggestion would be put "Devlog" somewhere at the start, since that's what about half of the video is, and cause most of the explanation part is at the end. My biggest suggestion is saying "this isn't necessarily a tutorial" in the first 30 seconds, if not less
But I recognise that youtube rewards you for convincing as many people as possible to watch, even if the video isn't very useful to them, and it rewards you even more for getting those people to comment about it. So I can't really make you change the way you package content. It would benefit others if you made things more clear though.
I agree, I watched the full 16 minutes of the video and I still wouldn't know where to begin implementing this in Godot. Now I have to go watch ANOTHER video to try to understand it. I don't want to be mean but this is just an ad for his game. I wish him good luck but it was a waste of time for me.
Great little golden nugget of info--very well presented. Thank you very much 👍
appreciate that Jac!
Thank you! Please keep up the great work. We need more creators making tutorials, and pointing people to updated tutorials. There's not enough for 4.0+, and even less for 4.0+ in 3D (or 2.5)
Bravo m8
Thank you! More coming soon. I'm working on two tutorial videos right now. I wish I could release more, but some real-life stuff is taking up my attention.
@@ChapC_Creates irl first, always. But I can't wait to see what you have. If I could sub twice, I would 😅
I cant wait for your tutorial bros. I'm sure it will be one of godot greatest teachings. And I hope to apply the knowledge you taught me to my game, which is similar to River City style. Respect
Thnx my dude. First tutorial goes live around friday... but might be too easy for those who already have experience... but more tuts to come!
Just read another comment ripping into you for talking too much before saying this is not a tutorial… I dont know whats wrong with people 😂 I wouldn’t have even known to search for a state machine tutorial without watching this video, and yet it’s EXACTLY what I need and your video brought me up to speed. I found myself in exactly the same situation, with a crazy-long piece of messy code that checks if a player is jumping / attacking / sliding / knocked over / etc etc. And I too had some weird dreams after getting lost in code! Your video is great, it’s brought me up to speed on the best approach to solving my problem, and it’s pointed me in the right direction to some great tutorials. Keep up the good work, new sub here! (Your game looks great too, love the visual style 👍)
What a sweet thing to say. For every negative comment I get 99 lovely ones like this one. But I do want to be more transparent next time. They were, from a certain pov not wrong 😅 - anyway, keep it up. Recording new videos this weekend and next week.
Really good vid, and good presentation.
How nice, I needed that today ♥
Your game looks awesome!!
Thank you so much!
that looks great. I really like the graphics.
State machines are really awesome for many use-cases in software development. Not that important for many types of games, but maybe worthwhile to mention for anyone who wants a lot of units active (RTS, sims, ...): The big disadvantage of the node-per-state approach is performance because of the high number of active nodes. Using classes (or interfaces in C#) is usually my preferred approach and is just as simple to use.
Love the insights. Interesting.
I don’t see how “many units” has anything to do with state machines.
Does a thing have discrete states with defined transitions? Then give it a state machine. Doesn’t matter if it’s a top level game manager, a player character, a gun, whatever. Doesn’t matter if it uses nodes, simpler classes, or a match statement. A state machine is just the pattern.
@@panampace It does matter for performance. Each node consumes CPU and memory during construction, deconstruction and each game loop iteration. Even calls to an empty _process cost a little bit. If you have a lot of states and a lot of units it quickly adds up. With the object approach you can either completely avoid additional nodes or work with a single node per state machine. Depending on the complexity of the state you can even share the state implementation objects between all units, or at least only allocate them if a unit actually reaches a certain state. With a lot of units this can be the difference between smooth gameplay and stuttering once the actions starts. If you only do something like Mario with a hand full of units you can usually do what you prefer though. Hope that clarifies a little bit.
@@yannick5099 Yes, but that's more a reason to move away from node based state machines to something that just sits in memory somewhere. FSM don't need to interact with godot nodes and they're commonly used in high performance computing.
@@novembermike512 I think we are saying the same thing. I'm not arguing against state machines, I'm arguing against the node based approach which is common in Godot.
What you did is called Refactoring great job, its something i'm too lazy to do in my game which my player script has reached over 900 lines of code :( well done man
Thanks, man! I kind of started over again in my latest video regarding the state machine. I now use the LimboAI addon since I really loved how they went about behaviour trees. But I also need to watch out refactoring too much, because progression would be nice too. 😉
@@ChapC_Creates I wish you all the best brother your journey is what matters, I have watched your recent videos and I loved it, I want to see your progress ofc, and don't worry too much about refactoring the fact that you redesign your player script and used state machine instead of a spaghetti code is way better and it is smarter overall and its good enough!
Good luck bro all the best!
Nice video. You got a pleasant voice.
I can't stand my voice tbh, with all the editing I have to do.. but thank you!
Having this type of nightmare is so reliable, in fact I had one today. Plus I was always worried that I was a weirdo for having them. Good to know I'm not alone
haha, nope, you are not the ONLY weirdo in town!
I can’t agree more that beginners should learn state machines ASAP. It makes life SO much easier when putting together something like a character controller.
Before, I had spaghetti code. With a state machine each ability I add to my character is just a new short script.
Just implemented the limboai way if statemachines. Cant wait to make more videos about this topic.
First of all the art is incredible!!Nightmares of code… after 40 years of programming (started as a 10 year old) I still wake up with the awareness that something has a potential gap, a bug a security issue and lots of improvements. I guess my subconscious works at night: so I will bill my Dutch banking client for my nightly work 😂
Haha, love it. And thanks for the compliment too!
@@ChapC_Creates btw, in working on another theme in Godot for my channel. A bit larger than the first one (video last year) for making a Sokoban clone called pirate ban.
And no I don’t use a state engine, as I couldn’t be bothered to look into an idiomatic way in Godot - hence I watched your video as I cursed myself for not taking the time and spending 3 hours, getting the grabber in the game to work. Especially with the asynchronous workings of the nodes, makes it unnecessarily complex. I would’ve been quicker using Zig and RayLib Because there’s no out of the box concurrency except for music/sound that just runs in its own thread.
But now I’m more educated and doing a node based (composition) FSE in Godot next time 🤣
This one I’ll probably spend another week on. So a two week game. It’s a clone of the Stone Age game of the Atari ST/Amiga/DOS a puzzle game. But with overhauled graphics. Eventhough, I was a VFX artist (compositing and technical development) Im no artist unlike yourself. So I truly envy your abilities.
I think this video is a good stand alone video! but if you feel like making a part 2 that goes into depth on your coding i feel like that would also be pretty useful too! Keep up the good work man
Thank you so much! I am currently figuring out LimboAI and how behavious trees and state machines work with that add-on. Im currently comparing the custom code of this video with the video I am working on currently. I am planning to make more videos once I am a bit more experienced. Keep an eye on the channel for more.
I love that it feels so clean, the organization (the game too btw, awesome attacks!)
Thank you! All WIP but definitely happy with the current result.
you deserve like, don't lost hope for your game keep learning
Sweet words, apreciate this a lot.
Funnily enough this is exactly what I decided to learn. I've been learning godot for about 5 weeks, around 2 hours a day after work.
Totally new to Any programing.
I feel like I've learnt a lot by doing this.
Ah, great to hear! Sometimes I feel like a fraud, telling others what to do while I'm still a beginner myself. So it's reassuring to receive some affirmation from the field.
Hello
I just started today any tips ?
Yes, subscribe!
@@srinathsurya3005Do you know how to code?
Im subscribing because you reply to every comment, thats awesome
Its honestly the most fun part of this youtube journey, the interaction. Thank you my dude!
I actually have had nightmares similar to what you mentioned. Those kind of dreams, where the point seems to be that I’m stressed out and experiencing sensory overload, are often worse than the classical nightmare of just being scared by something.
Yeah these are the worst. I rather have an scary dream instead, at least I don't wake up as broken. It's always the software dreams that hit the hardest.
Another way of describing the state machine improvement vs. spaghetti code is that they increase cohesion.
A piece of code is cohesive if all the statements contained in it "belong together" in the sense that they access or modify a common subset of program variables. Whereas "spaghetti" code contains interwoven statements, some of which accessing one subset of variables and others accessing a completely different subset. Other fancy terms for the same concept are "separation of concerns" and "aspects" (pieces of logic that appear throughout code, but which can be extracted and centralized, and "woven in" at appropriate places declaratively).
For OO interfaces (which contain no implementation, just method signatures), cohesion is when all the methods of an interface are likely to be used together in a typical use case, i.e. you don't have "odd ones" that are not directly related to the others (and that relationship is created by logical state the methods operate on).
These insights also apply to business, engineering, and organizations of any kind, at the bottom it is a mutidimensional mathematical "cost function" which you are optimizing while designing something. And maintainability/comprehensibility to humans is just one cost component.
Very good statement. The problem is a core issue in software programming. I would also say, that "relying on abstraction, instead of implementations" is a key design thinking pattern. Building common abstractions for concepts and then build your application code arounds them, iterate, build new abstractions. I totally agree with you statement, coming from a long business software engineering background. I would say, refactoring your code and concepts while adding new features is essential in any project of any kind.
Great point! Cohesion really does make such a difference, in life, actually.
@@u.n.v.e.u.9696 Yes, the problem with just recommending abstraction, though, is that it gets fuzzy and can be done incorrectly, and can lead to religious debates.
E.g. hiding too much of implementation could be detrimental if exposing it would allow optimizations. A classic example is shooting yourself in the foot by making batch processing inefficient in favor of invoking single-object operations (with overhead) in a loop.
Then there's the issue of "leaky abstractions" which look on the surface as if they were hiding implementation details, but in reality many scenarios exist (e.g. when it comes to troubleshooting) when the abstraction breaks down and you have to understand the actual implementation anyway to reason about behavior.
Finally, there is the ergonomic problem with too much function call indirection / too deep class hierarchies where your code is "neatly modularized" in principle, but distributed across so many different files that it becomes a nightmare to navigate through it and to remember where exactly each piece of functionality is coming from (especially if it is only plugged in at runtime). I suspect this is main reason why some people grow to hate OO and revert to a more "linear" and down-to-earth style of coding.
So we need more concrete (!) criteria for what "good" abstractions are, and cohesion is one of them. Any improvement in one dimension usually comes at some cost in another.
@@clray123 also agree, going just with one concept will also lead to a mess. I feel your statements. Abstractions for well defined, single responsibility, neat, small, maintainable pieces of code. I am messing with god classes and god implementations all day, duplicated and derived code. Code which actually got the same function everywhere with a small difference here and there. This is what I meant by abstractions over implementations. Of course well defined, small scoped, separated into its responsibilities.
The shell state could be used for sliding down a mountain. Bosses could have an aerial attack that needs to be blocked.
The shell now has a slight slowdown after running, which got me to think of this idea too. Need to figure out how to program though.
@@ChapC_Creates I like that idea, also you know how Kerby can do a slam move while in the air. It'll be cool to have the similar affect while shielding in the air to slam down and knock back enemies. Increase downward force and maybe a cam shake for effect
Cool video. I've been thinking about giving up my IT job and designing an ARPG. For combat, movement, animation and whatnot I kinda started reinventing state machines in my head it seems. I did not know this concept was an established one.
Thank you for the knowledge
You are so welcome!
Excellent video your explanations are top notch, one suggestion I'd make is have you tried making a shadow/indicator on where the character is going to land when jumping? I think it would improve the feel of it quite nicely
Keep an eye on my next devlog; I'm going to mention you! 😉 Thank you for your feedback and kind words.
The style of the character, particularly the combat movement and animations, is giving me Battle Beast vibes (a game from 1995 that I played as a kid)
I had to Google it, but I can see the similarities! That game really looks and feels like a product from that time period. Lovely.
The way I would've done it is to have the states each be a class snd if there were something similar about everystate make a parent class. the script handeling the character logic would then be able to store an array of a reference of each state class so the functions of the state classes can be directly called without node middlemen and would make implementation of future states easier.
That makes sense too. There are many ways to approach it, even through add-ons or extensions. Once you understand the overall concept, there are multiple ways to implement it, I think.
Your right, you could also use the command pattern in order to implement player actions and call the execute command on the action using classes and inheritance.
I'd rather use a state machine for states of the overall game.
But it's an approach I think. Looks nice though
Wow. I really want to make a game like yours one day
I am creating a tutorial series, teaching everything I learn. Subscribe and stay tuned!
First tutorial: th-cam.com/video/6T_TDuzEo9o/w-d-xo.html
@@ChapC_Creates Even better. I think I'm already subscribed, but I'll certainly be following your tutorals then :)
Great video! I'm currently working on implementing the movement system, which is already around 200 lines of code. I'm concerned that adding a combo feature could push that to an additional 400 lines. So, I'm going to look for other videos on this method to simplify the game and keep my sanity intact! 😄
I was in the same boat. Try and download the shaggy devs source files and play around with it for a bit. Really helped me out a lot. Its im de description of his vid.
What game are you making!? 😀
@@ChapC_Creates I'm creating a hand-drawn, story-driven platformer about a political insurgency in an underground world. It's a short game since I'm a solo developer.
As nice as the sunset in the background looks, I think you should reposition the sun overhead so that you can adjust the shadows. In your small demonstration playthrough, it almost looked like even you, the person who made it, almost failed to line up to hit a bee floating in the foreground. If the sun was positioned overhead, the shadows on the ground from the floating monsters would assist with lining up with the character model, so that they could more accurately hit the monster after they jumped.
In the latest build, I added an extra decal circle that always points directly to the ground. This way, I can still have different sun positions based on the story's narrative. But you are completely right, the depth perception is an issue!
yes! please make a tutorial with your version, I'm rather curious :D
Will do, stay tuned!
fsm is the breain of the game. every game needs it.
Some devs passionately told me otherwise
@@ChapC_Creates yea, there is a draw back. fsm can be slower than hardcode. thats why many oldschool dev for old school competitive fighting game still preffer 1000-2000 line code.
Seems like you could handle these states using bitmasks. That is the most efficient way to represent "states" in programming. A 32-bit unsigned long int offers you 32 possible values (including 0), and you can combine states if you need more. Not sure if godot has the ability to declare char (8-bit int) or short (16-bit), but if it does then you can optimize further by not using a 32 bit int where you only need 8 to 16 possible conditions.
You could then use switch statements to quickly figure out which state the player is in, and then call the relevant code from functions. For example.
WALKING | (1
ive been hearing alot about bitmasks on this video. Gotta give it closer look. thnx
Once upon a time this was the only viable solution in handling state machine due to memory constraints in old computers and video game systems. It's a handy skill that can extend into so many other areas too despite the abundance of space in environments now.
@@thedrunkmonkshow Not just about memory use but also about being able to check states more often without any real performance hit. This approach would also have benefits for people that are making a game that depends on low network latency, with regards to broadcasting player positions to the connected clients.
@@alphaforce6998 for most cases it seems over-optimization at the cost of code clarity. If checking and handling states is in the scope of a performance bottleneck one might consider these low level optimizations, otherwise it just makes you code less readable and maintainable.
@@SystemUpdate310 Code readability is entirely up to the programmer. You can use comments to explain things or put reminders for your own references. But with bitwise fields, you actually gain readability because you can set them as constants, using descriptive names.
For player state contstants, you can name them:
PLAYER_STATE_*
You can get as descriptive as you need to be, but you can also use the same approach for other instances where you are using bitwise fields.
As I said to the other person, checking states is not the only reason to do this - you can effectively condense a lot of data into a single integer, which is foundational for network protocol design.
A single "player_state" int variable can contain all possible player states, and this can also include permissions, unlocked game features, achievements, buffs/debuffs, ability properties. If your game is going to be exclusive to 64-bit systems you can use 8-bytes to contain up to 63 statuses.
I had these code nightmares while developing a software that was part of a research work that I needed to do in order to graduate. They are TERRIBLE! I wasn't sleep but I wasn't awake either. And when I noticed the sun was raising already and I didn't slept at all. Thank God these times are over!!
Ahhhh .. so relatable! Just had one yesterday. Im still tired because of it XD
Steadily experiencing these days as Software dev
AMAZING!!!!
Thank you s much!
I had a situation in my game that was getting into 13+ levels of if-statement hell and was getting very flakey. I feel your pain.
Instead of going your way of separating the code into separate files, I set a series of boolean toggles to define the state.
For example, in your case, they would be isJumping, isFalling, isMoving, isAttacking, etc.
Then if an action was state dependent, I'd check that simple boolean "If isJumping ..." before calling the correct action code. I could then add multiple actions based on the same state or separate the actions for different states.
if isMoving: key_down = slide()
If isFalling: key_down = fast_drop()
If isJumping: key_down = short_hop()
If isAttacking: key_down = duck()
This reduced the incomprehensible series of nested ifs into basic if-else statements. This also eliminated 90% of the bugs introduced while trying to fix stuff since the error in that if statement was exclusive to that if-statement. So long as the states are not being changed by everyone and their cousin, it's a simple matter of knowing why x code is / not being run.
Honestly, I’m learning something new every month-working with components, state machines, behavior trees, and so on. I would probably do everything differently each time I start over. I agree with your idea of not overcomplicating things just for the sake of it. Great insights, thanks!
@@ChapC_Creates
My situation was a lot simpler w fewer states to monitor than what u end up implementing / are planning to do. The needs of the project will determine the level of state machine u need to work w.
Imagine eventually refactoring this node hierarchy for all scenes that use it. It makes refactoring a real disaster.
I'm pretty sure the final code and setup will differ significantly from what I have now, but as a first learning project, this was great.
Dude! Great video! But I've been thinking about your state machine code work. I think you can improve further. Make a script that is a node called state handler and make your sates become resources. After they're resources, you can save save them as a file and they become reusable for other playable character you make in the future. Most of the code in your states are in the same shape which means you're reusing a lot of code, that's why you can use a state handler node inside your playable character scene tree. That node will hold most of the code. In the states you can save your sibling states directly associated with the input they're expected to occur with or something else (like taking a hit). The framework is the same. Let's say your on the ground and take a hit you might wanna make your character stagger but if you're jumping and take a hit you might wanna fall flat. Same code but different output states.
Anyways, this got longer than what I thought. Have fun bro, nice game you're making!!
Very interesting. This is my first attempt at a state machine, and I'm pretty sure I'll eventually end up with something completely different. I like your setup; it would accommodate many 'in-between' states. I'm currently managing that by setting information in the global player.gd file. Thanks for the input!
I think this is good for him to do further along, then again this project is simple from a coding stand point so he might be able to get away with it... but once his logic is done then just taking that code and putting them in resources is good, otherwise the time spent on the boiler plate will increase a lot and quickly as he lizard brains through it.
As I start trying to get game 1 off the ground, I have been trying to learn about this. More specifically, "Game programming patterns" and what a lot of developers seem to be calling "components". Breaking individual code tasks into new nodes. So you have a node for controlling physics on a character, separate node for input, separate node for each mechanic.
Honestly, the project isn't complex enough to need it, I just decided to try to commit to such patterns to improve my game dev as I started. Hasn't fully clicked yet, though, in my head. I feel like the decision for what goes into its own node is arbitrary, and the overall execution feels wrong to me for reasons I can't identify. Even though so far it's a node for controlling physics on the player, a node for controlling player input, and a node with just one line of code for returning what the collider is looking at for interaction mechanics not implemented yet.
Anyway, video gave me some thoughts. I knew about state machines, but I hadn't give it much thought.
It will click eventually. Just by making games and implementing small ideas at your own pace, you'll get pretty far. I still have a bunch of videos in my watch later list about the component-based approach to programming your game. Hopefully, I can share some insights about that later on this channel! For now, this noob needs to grind for another week. ;)
Yeah, I'm just bad at getting past that point. At least I made one piece of code I liked that I don't see used:
@onready var main = self.owner
No need to export what node you're manipulating. it goes off the assumption that the root node is what you're working on, which I feel will be the case.. pretty much all of the time since Godot has you break stuff down into scenes.
Anyway, I'll keep an eye out for that video when you get there; probably gonna follow after I get around to watching a couple more videos. I got more tutorials to go through before I try to re-code my game and see if it clicks better.
Gosh I say 'basicly' soo many times, so annoying.
To those expecting an actual tutorial, I just uploaded one regarding the basic setup of my camera + gridmap: th-cam.com/video/6T_TDuzEo9o/w-d-xo.htmlsi=Ih-ppKiNAWSwaPP7
More to come.
Check out the State Machine videos I used to learn about this topic:
th-cam.com/video/oqFbZoA2lnU/w-d-xo.html
th-cam.com/video/bNdFXooM1MQ/w-d-xo.html
It was fine man. Dont stress it. Thanks for the content.
goodby random bool var named after random string characters" spinny, hit, air, fix"
@ChapC_YT
Hey, in another post you asked about the method of setting up animations in a more modular way. I responded but checking back on the messages I saw your question is not there just my response. I also contacted you via Discord with an offer to simply show you the result in my own project of the systems involved and share the code/theory on how to do it.
I offered this because you asked if there was a video for reference on how to make it and tmk there isn't one. I made it out of a need to have quick access to any animation in a human readable way. I believe I joined your channel and sent you a hello directly, but then this morning I noticed I did not see the discord.
Is it fair to assume that I violated some part of your terms and/or that you aren't interested? If it is the latter you could just say so, I asked that if you were not interested you just say so, after all it is my time as well to have to explain this.
Listening to yourself talk is a nightmare... but you sound great man, don't worry about it
@@danielmace406 ahh thats nice. Im always soooo sick of myself after hours of editing, lol
The first thing any godot beginner should learn is learn to go through the official tutorials and also learn how to read the official documentation. So many questions could be answered if they could do just these two things.
☝
1:50 Dude I had that nightmare so much times, it's literally torture
The ones I had with the fever where the obsolute worst :D
It would be very nice of you expanded the code window and increased the text size. I find it very difficult to actually see any of the code you're talking about on my laptop.
Your completely right. I am finishing my 'first tutorial' right now, since this was more a showcase video. The upcoming video will be zoomed 150%. Stay tuned!
Very interesting video. State machines are so underrated, but often a game starts with a PoC that is slowly growing into spaghetti code. Often you don’t start with the state machine, because it seems like over kill for just trying some stuff out.
Yeah, it's all part of the journey. I am currently in my third refactor phase. The more you learn, the more you'll optimize. I do have to be careful that over-optimizing isn't holding back my first game, though. At some point, it's okay if the code isn't 100% optimized.
I'm curious about how you'll implement the shadow under the turtle. It's super important in such a 2.5D game so you can see where the turtle will land when she jumps.
Does Godot have a decal projector? It might look weirdly stretched on cliffs. Sure, adding a cos to a shader is easy, but that's if Godot lets you access that shader at all.
Maybe it's easier to cast a ray down and center a semitransparent dark disk there, but it'll hang over cliffs.
I don't know, I'm a Godot noob and that's not a feature I need. Still, I'm super interested in those tiny details :D.
I'm curious too! XD I have it figured out in my head. I know exactly how it should look. But how am I going to implement it? No idea yet. But honestly, that goes for everything I implement. Currently, I'm taking a step back and working on the story for a while. Next, I'll be working on the actual game loop, enemy AI, etc. After that, I'll probably start working on the first level design and optimize many things, such as the jump projection.
I am currently using state machine in my game but my biggest issue currently is code reusability. A bunch of states have the same code. I need to figure out how to make states share the code. I guess i could use inheritance but i dont know if that is the right approach or is there a better way.
Try look up some videos about godot components. I really think that is THE way to go about reusability in Godot.
Wow, I really found this state machine you made interesting. Could you make a video explaining it better and how to implement it later, and the call logic? My state machines never work that well XD
Yes, im preparing a 2.5d tutorial that has the statemachine inplemented! Stay tuned!
Would be cool if you could slide down a slope while crouching in the shell. But I can also understand if you want to limit the ideas so it doesn't get out of hand :D
Great idea! I recently wrote the intro scene where the mother goes into her shell to pass through fire and save the kids. This made me think I should probably add this move to the movelist. Going into the shell from a standstill will allow the character to defend themselves from falling debris. The slide can then be used to pass through small spaces, fire, and other hazards.
I on my way to click the subscribe button, but then I saw your dog and subscribed even faster. This was a great video that helped me understand how to bridge some of my existing programming knowledge with the Godot system.
I'm so glad to hear that! At some point, I was doubting myself, wondering if the video was too vague and if it should have been a 100% tutorial instead of a showcase. But personally, I would have found practical examples like this video helpful, and I'm glad more people feel the same way.
Is it possible to have multiple active states? I currently use bitflags (think booleans, but more storage efficient)
I will be looking into it! there are probably multiple ways to go about these things. Many devs use different state machines for different parts of the character, for example the weapon handling / animations.
hey could you make a tutorial for the background setup at 0:30
Yes, multiple tuts in the pipeline
Sir you could have use this technique like make a function for movement where there is also the input movement like sprint, run and idle and the next function for the jump and fight and so on, after that you can simply use the function on physics process or process .
I personally do that all I do is copy and past it on the other function and just need to adjust the code the way I want.
Hope that also help😊
All feedback helps! There are multiple way to go about this. But having single purpose functions that are easy to review (also after a few months) will probably be included in all good working solutions.
@@ChapC_Creates ❤
i dont undertand from this and shaggys video how and why returning a state node makes it the active state. what function is being called?
All your states extend the 'State' class, which is defined in the state.gd file. In that file, you can see the 'enter' function, where the animations are played for each state. You'll also notice that each function (for example, process_physics) in this file can return a State. In the statemachine.gd file, it checks whether a state is returned, and if so, it swaps the current_state variable.
Its difficult to explain in just a comment, but feel free to join our discord and ask me there. Then I can share you some screenshots.
make a crouch in the air to bonk enemies and to clutch safe for a failed jump.
In my latest video I added something that could work with this idea!
This means that the state script needs the following functions
-enter
-process input
-physics process
and there is no need for an exit function?
and if you want to make playable entities and artificial intelligences later on, do you need to separate the 2 types of entity or is that not necessary?
Exit gets handled by the state machine by simply swapping states. Each state is expected to return a state, and with that it 'exits'. I am currently researching LimboAi regarding state machines and behaviour trees. I might be using behaviour trees for the enemies. The moment I know some more, Ill probably make a devlog/tutorial about it.
@@ChapC_Creates So in the state script what required is a process_input + physics_process + Enter function and that it? (Is there gonna be a tutorial for states machines on this channel?)
i recommend adding some nice screenshake and or some freezeframes for the uppercut attack. rn it looks very dull and weak.
Thank you! Yes, lots of work is needed. Thank you for the tips.
So the code inside these state nodes are the ones that are exclusive to that state?
For example on my shooter game I want to be able to aim while moving and jumping, so assuming there can be only active state at a time, would I write the code for aimming on the player script or is it possible to have kind of two states working at the same time? Kinda how you can move while jumping in your video.
Yes, that's correct, just 1 state at the time. BUT you can have different state machine, for example movement state machine and a weapon state machine.
@@ChapC_Creates That makes sense, will try to find a way to make a state machine that works on my project
Good luck on yours, coming from a huge smash fan I love your concept and hope it goes well!
How sweet! Same to you. Make sure to watch the vids in the pinned comment by the shaggy dev, he also shows an example on how 2 statemachines work.
Hmm, yes, the video and the topic is really interesting, really, but I had trouble to focus on what you were saying since I was trying to remember to whom you look like, and yeah, I remember, if one day you do some kind of cosplay, please do Joseph Seed from FarCry 5 lol, you're a carbon copy of him ^^. Anyway, I'm gonna watch the video a second time to learn this time instead 😅
haha nooooooo not you as well... this is the 3rd Joseph Seed comment. I really need to finish that game, btw
p.s. im working on a bunch of tutorial videos as well since these vids are more showcases. stay stuned.
@@ChapC_Creates haha lol sorry but yeah for more than half of the video I couldn't focus because I felt I knew you from somewhere lol but sure, I'll be interested in more tutorials then ^^
nice vid, how hard was it to animate the sprites? could you include a bit of the artsy process even if they are just placeholder?
Hi, and THANKS! My next video will be about this process. How I (with not too much talent) went about my sprites. Keep an eye out on the channel.
Can you please teach us some art tips since i really like the way your game looks also tour game is also looking very good keep it up
Thank you so much, the next video is going to be about this. Stay tuned
Joseph Seed teaches me how to make games.
Haha, ahhhhh ffs this will forever haunt me.
I had a dream years ago where I lost my keys, and I thought I could just "grep" to find them... true story...
haha, oh man... Reminds me that I had some sort of command line issue in a grocery store.
+1 for limbo ai (godot plugin).
A few weeks after I switched over to LimboAI for both the state machine as the behaviour tree. Upcoming videos are going to be about this. I really love the add-on.
Nice video and well explained (i subscribed), i will definitely save your videos and recommendations for my future projects but i just have some feedback on your game.
Since it has smash inspired combat style and tmnt i need to criticize the the camera angle. since you want to make it 2.5D when showed a bit of gameplay i found it very hard to get a good depth perception. what i mean with this is that it is very hard to know when you are able to see when you are in front of a enemy or not (or at least close enough to hit them since i saw the colision boxes around the bees).
i dont know if changing the camera angle would help (giving it a more top down view) or maybe a circle indicator on the ground when you are close enough so that you can see that you are in attacking range or somewhere in those lines because it looks very frustrating seeing a nice 3D environment where you can move around and not knowing if you can hit the 2D sprite because its flat.
This is just my dutch gamer/complainer side talking. the rest of the video was very informative :).
Spijker op de kop ;) You are completely right. I have been thinking about this a lot... at some point I accidentally turned off all z movement. While somewhat being a downgrade, the game DID feel more natural to control. So thanks! I will definitely test out multiple ways to fix this. Thanks for subbing too!
its funny that you mentioned that the update didn't broke much for you, while on my game the state machine is busted since and i can't fix it.
Oopfh.. beyond repair? The candidate version (or whatever it was called) broke my game completely.
@@ChapC_Creates i use:
>for child in get children:
hmm. yeah maybe you could implement something similar and link the related states by assigning them via the properties inspector? Hopefully you will figure out something soon.
This such good timing ! I also implemented state machines using shagy devs tutorial, it made the most sense , was there other implementation u looked at too ?
I went through basicly all youtube vids out there regarding the state machine. Also ended up messing with some extensions/add-ons.. but in the end, I wanted a more simpler aproach, more close to godots node based system, and ended up with shaggies code again. Probably depends on your game type as well. Is it working for your game as well?
@ChapC_YT yep so far so good, I'm creating 2.5d platformer like you too!
Just checked it out.. I love the extra angles your character has. Are those are 3d renders into sprites?
Noice tips , I do use it on my projects , did u know that Sega used Godot 3 to make sonic color it was a very lovely game
Wait what? No I didnt. Thats insane.
@@ChapC_Creates didn't believe it too since I was only focusing on 2d when I was using Godot 3
Yeah, I agree, I have a friend on Discord who released his game on Steam, being the guy who is notorious in various communities for his State Machine and pushing it down every dev I meets throat it sucked that his game obviously failed to employ one.
To be fair he was using GameMaker not Godot but his controls didn't care about context, which was a huge turn off. I honestly thought he was going to release it as EA but when I saw full release I was hurt for him. I mean really hurt, that game could have used just 2 things more and it could have been ready for EA... but full release...
Anyway for your combat stuff, you probably want to employ custom resources, and the use of a nodal combat tree to handle animations in a modular way. This way what animations you can do are based on the nodes present. You simply assign the node as a child and register it to whatever you map for controls then when you press the button the animation on that node is played and the node handles the logic for how you do the animation.
This way you don't get caught in animation resource hell where you keep needing to add animations to your list and instead you can just either place them on a node or a custom resource.
For the animator itself, just be sure to have blend setup to change between 2 animations when you attack and that's it, the nodes will register the animation and whatever animation currently playing will blend into the next animation, the nodes again will dynamically unregister and register their assigned animations to your animation player.
Sounds good. Dont fully understand it yet 😅 by any chance know about any useful videos regarding ur suggestions?
@@ChapC_Creates I mean I do not. This is something you can just design for yourself, I'm not good at doing YT videos so posting how to make one is kind of out there for me. But the principle is as described, personally I like using objects but strings are safer for reference.
The key things to understand when doing it are:
Collections, Regex. File/Dir - Access commands, and that gets you to a good place for accessing your resources programmatically by creating a database on the fly for your project.
What I mean is Say I have animation name "Fly" in my project I can do var fly : Animation = Repository.find(Properties.Animation.Fly)
Say I wanted to get all the animations in my project:
var animations := []
for i in Properties.Animation:
animations.append(Repository.find(Properties.Animation[i])
Okay that gets you through the door, now you can build tables for the animations which handle this kind of API for you.
So in my project I like to use the passby pattern when dealing with animations to avoid entangled awaits
if Animations.try_get(some_animation, out):
do stuff.
Not sure if that helped but if you are truly curious I'll check back here tomorrow to see... I guess I could join your discord as well.
Hello, I have a question, can you help me?
It can never hurt to ask. Whatsup?
Godot needs a proper state machine. One like Unreal where it is an actual tree you can setup that shows the transitions and such. Just having a ton of "states" as nodes in a tree with a bunch of scripts specific to each node seems like a lot to process to me when you can have a proper state machine layout with visually defined transition requirements and can actually watch it and see what state you are in and see it switch states.
Interesting... I have no experience with Unreal, so I had no idea it was that easy to do in that engine.
I may be misinterpreting your comment, but Godot already has an AnimationTree node. There are still some quirks, but it does what I think you're asking for.
Looks organized, but it's not so good if want to add multiplayer. You will want to have int's / enum's then for your states.
For like online? its probably my lack off experience, but I cant see way this setup wouldnt work for client side multiplayer for example?
@@ChapC_Creates it would be a security vs latency tradeoff. You either have every bit of state data controlled by the server, or you risk giving the client too much power.
You're not going to want to hear this-- but 1 state = 1 script is likely nasty mental context switching to maintain all those extra files. Could just be functions. Whatever floats your boat tho.
I do want to hear that, actually, since I’m a total noob. ;) I recently tried the LimboAI state machine approach, which had all the functions in the same code file. I think it’s a subjective thing, but I still refactored it to have separate files. So far, I haven’t noticed any performance changes, but I’m pretty sure my opinions will change at least 10 times in the coming years.
Doesn't it sort of defeat the purpose of clean code state machine when you put in that "if". Wouldn't it be cleaner if you had two objects that have the same script attached to them but have a different animation for aggresive/non-aggressive idle
Yes, i think a seperate script that just extends the other one would be cleaner indeed ✅🫣
@@ChapC_Creates at this point, since there is no difference except for animation, you wouldn't even need to extend it, just have an animation parameter and have it have different values for aggresive/non-aggressive. If it goes beyond animation, than yeah
clean code is BS
But, you really DONT need this at all. Just use the AnimationTree and its associated functions to control your states, at least for anything movement based. In SOME engines building state machines is great, in Godot it is entirely unnecessary because they have already built the tools for you. That entire huge mess of nodes under "movement_state_machine" could be easily replaced by a SINGLE "AnimationTree" node, which can do everything you did but with a signal node AND visual design.
You’re most likely absolutely right! The state machine was an eye-opening way to learn about game development in Godot. It helped me get to know the engine while also making progress in a short amount of time. But I’ll probably disagree with the video title in about a year.
I dont want to sound rude but I will probably sound rude but I dont think 200 even 500 lines even 1000 lines of code is a larger code file I would say in a real world project that is a medium code file and you could have fixed your indentation hell by just doing better programing rathar than having a 15+ separate code files I guess it works either way but I have a feiling like this could have been done with with just creating a state enum then creating a function for each state and then creating a swich statement that check in what state is the player is and runs the appropriate function that then can do all the stuff that your files do the only difference it would be in one place and you would not pay the overhead of having a node for each state a enum is a number (probably a 32 bit number) so each state could represented by a number what you are doing is creating a whole ass node that has methods and feilds you will never use to represent state or maybe I dont understand it well enaught I will look more into it but doing a state machine like this seems wasteful and unnecessary
Not rude at all, you are honest. Ive heard a lot about the enum solution. Sounds like something I should learn about. I already experienced the downside you just described the following weeks after uploading this vid. Keep the comments coming! Much apreciated.
The depth of this side scroller will get me very frustrated very fast. I can easily see that I'd keep trying to hit a stupid enemy, but I'm constantly bouncing between too deep and too shallow. Ugh! No.
Yes, this is something I need to figure out. The game Teenage Mutant Ninja Turtles: Shredder's Revenge does some smart things to improve this, but it’s also less of a platformer. That’s why I’m prototyping! Let’s see where it ends up.
Basically I also work on my game and have to extend my fighting and also days are bad when it breaks 🤣 lol about nightmare
Now im very curious about ur game 👀
Lol iwas just thinking today that i need to learn how state machines work
Hopefull this video and the shaggy dev tuts I provided give you some helpful insights...
You look like Joseph Seed from Far Cry 5..
hahaha nooooo not you as well! Gosh this meme will never leave me.,
Nice
You're saying you plan to make it so a turtle can't turtle? :P
Haha, 404 - turtle brain not found... Are you talking about the "in-shell" stuff or swimming? Going into the shell will still be a big part of the gameplay; I just don’t want it to be an easy, bulletproof mechanic. It’ll probably be used mainly for protection from environmental hazards and projectiles but not for blocking direct melee hits.
BROKEN THE SHELL AND GO WITH A NAKED TURTLE WITH PIJAMA
Haha, turtle in pijama looks cuter and less gory than what I had invisioned 😂
"GODOT Beginners" "Game dev beginners"
ehmm... YES!
here a fellow comment
here a reply to your comment
>memedot
could have been a worse comment XD
Click bait inaccurate title. This is not the first skill Godot beginners should learn at all, in fact it's pretty specific for when you'd even need state machines. Not all games need them, most don't.
Thanks! Introducing state machines early helps beginners with OOP concepts. The visual aspect (animations, movement) makes it fun, and learning should be enjoyable. You're right-many games don't need it. The title has some clickbait (it’s TH-cam), but I think it’s still reasonable.
Disagreed. Heavily. Any game of significant complexity, will need fundamental concepts of OOP
No, games don't needs state machine, even more state machine is just one off many aprochues to the same problem, and you need find right one for you.
Also starting dev journey from state machine is very hard dive.
First sould be good undersding of Godot systems and GDScript scripting.
You've heard the man!
Lots of npcs and dialogue eh? Name 3 that arent related to aj. XD
Yes? Villagers mainly. Even the old demo had a bunch. After saving somebody for example, the fisherman.
bullshit
lol