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_YT 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.
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.
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.
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
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.
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.
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!
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.
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.
@@ChapC_YT 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
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.
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_YT 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.
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_YT 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.
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.
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.
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
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_YT 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 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!!
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.
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.
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
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.
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.
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.
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!
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.
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.
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!
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_YT 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 ^^
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.
@@ChapC_YT 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.
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.
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.
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.
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_YT 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!
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.
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_YT 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.
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_YT 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?)
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?
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.
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.
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_YT 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
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.
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.
![[FINALE] มีคนคิดแค้นลักพาตัวเด็กไป🔪หญิงชราใช้ชีวิตตัวเองเข้าแลก👩🦳 #โลกการละคร](http://i.ytimg.com/vi/C_BPHPoZFOg/mqdefault.jpg)
![โอ้เธอช่าง... - บี้เดอะสกา ft. ต๋อง เทวัญ (Prod. by ป๋าเพชร) [Official MV]](http://i.ytimg.com/vi/zbWhiLFmVL0/mqdefault.jpg)
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_YT 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.
@@ChapC_YT irl first, always. But I can't wait to see what you have. If I could sub twice, I would 😅
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.
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.
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!
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.
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.
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!
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?
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.
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.
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_YT 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
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.
☝
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_YT 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.
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.
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_YT
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.
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
you deserve like, don't lost hope for your game keep learning
Sweet words, apreciate this a lot.
Thank you for the knowledge
You are so welcome!
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.
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
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_YT 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.
yes! please make a tutorial with your version, I'm rather curious :D
Will do, stay tuned!
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
Your game looks awesome!!
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 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!!
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.
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.
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_YT Even better. I think I'm already subscribed, but I'll certainly be following your tutorals then :)
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.
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!
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.
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.
AMAZING!!!!
Thank you s much!
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_YT ❤
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
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!
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.
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.
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!
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_YT 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 ^^
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.
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.
Joseph Seed teaches me how to make games.
Haha, ahhhhh ffs this will forever haunt me.
make a crouch in the air to bonk enemies and to clutch safe for a failed jump.
hey could you make a tutorial for the background setup at 0:30
Yes, multiple tuts in the pipeline
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_YT 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.
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.
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.
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.
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.
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_YT didn't believe it too since I was only focusing on 2d when I was using Godot 3
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_YT 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.
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.
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_YT 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.
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_YT 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?)
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?
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 👀
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.
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_YT 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.
You look like Joseph Seed from Far Cry 5..
hahaha nooooo not you as well! Gosh this meme will never leave me.,
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...
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_YT 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
Hello, I have a question, can you help me?
It can never hurt to ask. Whatsup?
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 😂
here a fellow comment
here a reply to your comment
>memedot
could have been a worse comment XD
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.
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
bullshit
lol