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.
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.
@@ChapC_YT the shit is so long i just say a dev that hasnt finished his game in 10 years and is still not finished because the person behind is just playing games despite people supporting him in patreon for finish the game
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.
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!? 😀
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.
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.
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!
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.
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.
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
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?
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!
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.
@@ChapC_YT i use: >for child in get children: <to link the children back to my base state machine script and this dosn't happen anymore. i first had it stored as a var wich worked 'till the update, after the update i tried switching to a custom signal, but nothing seems to work.
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.
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.
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
Good lord... I say 'Basically' quite a lot, basically... Also, I was quite sick during these recordings, so I sound like a robot more than usual. Anyway, check out the State Machine videos I used to learn about this topic: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-oqFbZoA2lnU.html ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-bNdFXooM1MQ.html
It was not working for me so I downloaded de 3.13 version (My blender is 4.1) and then I closed my blender and opened again, then I installed the Add-on.
This is the kind of stuff I like. I don't know much about godot, especially in 3d, but could you not use Sprite3D even though it's for the background? I suppose it's something super big, so maybe the 3d sprite, would be too huge for a background. I also heard you can mix 2d in with 3d (which you are obviously doing) but what I mean is, maybe Godot in a 3d scene can use 2d nodes, I think that's what the UI is any way. So maybe you could use a "2d" parallax layer? Suggestion about gameplay, you could constrain your character to only x and y axes (you know left and right/up and down), so it's played like a traditional platformer, with a fixed-z -- otherwise people might get frustrated missing jumps because they weren't at the right "depth". The only other suggestion (although it's more work, so you may not want to) is to animate perspective, on those 2d sprites (the front ones not the floating islands in the back) -- do maybe 3 or 5 frames for perspective based on where the camera is. It will still retain the 2d look, but won't look like a flat cardboard cutout (unless you like that look). And yes I do mean hand draw the different angles - you could keep it to as little as 3 if you wanted.
Thank you so much for your detailed feedback and suggestions! I did try using Sprite3D, but it was quite a hassle to make them static and ignore the camera perspective. I’m not too experienced with UI yet, but I believe it does use a canvas layer for that. Depth is definitely a challenge-I’ve been discovering that during recent playtests. I’ll test out your suggestion; good call on that. I was considering creating different angles for the enemies and the main character, but drawing in perspective is tough! Anyway, thanks again for the input!
Hi Chap.C, I made the water shader that you're using 😊 and I wanted to confirm it's open source (I'll update the description to clarify). Use it however you'd like, I love the edge detection! The visuals (even the placeholder ones) are stunning and very relaxing. Looking forward to seeing this project grow!
So cool! I revisited your shader today since mine broke for some reason after the Godot update. I noticed you added some nice edge detection yourself. Another change I made is that the shader works on any mesh size, even if it's, for example, twice as wide as it is deep. Anyway, thank you for visiting, and see you around soon. FairBear8974's Shader: godotshaders.com/shader/psx-style-water-surface-pixelation-waves-scrolling-textures/
Yes! 2 ways: - in the import settings, disable compression and reimport - click on the sprite2d/3d node, go to inspector, go to flags... and set the texture filtering to nearest Drop by our discord so I can show you: discord.com/invite/4DMnyEDrTC
