What are your favorite tips or tricks for using Godot? Please checkout the demo for my upcoming game Hexagod: store.steampowered.com/app/3059390/Hexagod/
Small Tip for the Ctrl+Drag: I used to have to deselect-reselect to get the ctrl-drag to work; it was very finnicky. The better approach is to just click and drag the node w/o pushing CTRL, and then when you're ready to drop it, THEN push Ctrl
@@Aarimous if you hold shift instead of ctrl and dropping it, you get the full node path to that object in relation to that script. This includes automatically using .. to go up a parent level
Small warning about enums. If you save it into something, like a variable using a dropdown with export, a resource or something like that, and then add or remove something from the enum list, it can shift the selection to a wrong one. enums are great, but it's something to be mindful of when using them in anything that saves and loads.
You can technically avoid this by explicitly assigning the values, so the first enum = 0, second is 1, etc. So no matter what you remove, the values for each one remains the same.
@@sataStrike That's true, but things will still have the value that you saved to them unless you change it. So if you add A = 10, then remove it, you'll have an invalid index, and if you later add X = 10, then that thing will suddenly be X. You could get around that as well though, by setting things to a default value if it's no longer in the list, never fully remove something and keep it as placeholder, or some other method to ensure validity. There are many ways to handle it, my point was just that it is something worth keeping in mind that it works that way so you can work around it to prevent unintended behavior.
Thanks for the warning - I think he's about to find that using dictionaries is a better approach in some cases, of course. Here’s a quick summary of what I've gathered about enums vs dictionaries: Use Enums if you need a fixed, small set of related constants that won’t change frequently and where performance and memory efficiency are critical. Use Dictionaries if you need flexibility, dynamic content, or need to associate additional data with each key. Dictionaries are more forgiving with changes and are better suited for complex or evolving game data. Both Enums and Dictionaries have their strengths, so the best choice depends on the specific needs of your project. This video might need a follow-up with all the gems that people are sharing :) Feel free to chime in with more tips or experiences!
I was about to call this out too. Enums ARE a powerful tool that you SHOULD use, but only people that are great at planning ahead really get the most benefit out of them. I've had a couple of nightmarish project refactors caused by using enums before I'd nailed down the scope of the system.
I've been using Godot for years and I've watched a lot of videos to help me be a better creator of games. You sir are one of the best. Not sure how long you've been doing this but I'm very happy to have found you. This video feels like getting advice from a better version of me. It's super clear and relatable. Thanks!
I haven't delved into the godot source but there has to be a tiny performance advantage to using % of $. $ must be parsed each time in case the scene tree has changed, whereas % is a location independent reference ie. it's a link to its location in memory, not it's location in a tree.
@@CouchBit I think the downside is that those % reference won't survive loading a new scene. In my opinion using an event bus via auto-loaded script is a more robust solution, as it remains persistent.
This video was one of those rare instances where I want to hit the like button at the end but realize I already hit it earlier. Great video, keep it up!
Good stuff! If you're making a script where the relationship between the nodes is irrelevant you can also use @export to reference nodes instead of using @onready, which will let you connect it up in the inspector. This gets around any renaming issues, and is especially useful when the script is intended to be modular. I personally use both in different situations, so I'd just recommend playing around with each and seeing which works best for you in each scenario.
8:48 last tip is very reassuring, I am constantly finding new and better ways to do things and feeling like I should rewrite my code, but every time I do I get closer and closer to burnout. it's nice to hear that its okay for things to be imperfect by someone who has actually released games before
I feel like I'm on a weird RUclips path where it keeps recommending me all the devs of the indie games I play. Watched through this whole thing, then went to the description for the links, and I had no idea you made Chess Survivors.
Related timesave to ctrl-dragging a node into the editor to make a reference: After you've done that, it's really easy to change it to an export variable (changed onready to export and delete everything after the =) which helps keep your code modular.
The getters and setters are huge. It makes it so easy to throw a bunch of logic down the chain. You get hurt? When your health gets set, you throw out a signal with your old health, new health, damage type, anything else you want. Update UI, communicate with other systems that manipulate damage, calculate weakness/resistance, proc items your character that has that have on hurt effects, etc. etc. Love that one, definitely a great tip to share.
Another tip is combining #1 and #2 Export a variable with the type of the node you want, for example I use a marker2d for spawn points. When you click to assign, it only shows the nodes that match the type you defined
A few weeks ago, I competed in a game jam using Godot for the first time in years. It took a while to get used to all the changes, but I was really impressed by how much easier a lot of things are to do now!
Dude your timing is perfect on this as I just started up a platformer as my first game 2 days ago. I really hope you do more of this cause it all goes such a long way.
as a dev by profession, in my opinion setters/getters are an antipattern because it makes it extremely unclear to someone reading the code that an assignment is going to run some hidden function, and if you use it once then they have to be aware it could be happening anywhere... makes it much harder to work as a team, and it's not great for your own readability either Alternatively, you really should have a scoped function that sets the variable, and even better if you can handle the common case that would make you want to make that assignment It also looks like you could really use some folders :p
First I'll say, awesome job learning more things that can help you in your dev journey :D There are always things to learn and I hope you learn more things to help you along the way :D You could create groups back in 3.x, but it was a hassle and pain in the arse. Made much easier by just having that tag in 4.x The onready and unique names can be names for sure, but personally i prefer just using the export and assigning them in the inspector. It removes any chance of error from typing names out, and like unique names you can move them around in your tree and not need to update your code.
Always fun to catch your streams. You definitely should do more RUclips content too! Would love to see you showing more details on each tip you just showcased. Adding examples and showing how your approach is. Especially use of set/get and global @export variables. Thanks for the video!
great vid, but i do have 1 thing that i think would help you a TONNN, look into custom resources, much easier to maintain and expand, was a huge game changer for my projects :3 really suggest godotneers vid "Data models - using data to create extensible, maintainable games in Godot"
Neat, guess I gotta read up on enums and setter states a bit! Thanks! During this last game jam I did, I was using a slew of signals. Some of these signals connected to instantiated scenes (projectiles like bullets), but the signals would disconnect when being instantiated. Came across a post talking about creating a Signal bus using autoload in project settings. You then connect or emit two or more scenes by pinging off of the Signal bus, which made connecting to instantiated scenes so much easier. Performance-wise, I don't know the impact of having a Signal bus too large. Swap connect() with emit() for outgoing pings. Effectively just using signals, with one more reference name at the front, lol. [SignalBusName].[SignalName].connect(function_name_you_want_to_connect_to) (Having a debug os reset scene in autoload is also pretty snazzy)
Try visual shaders. They use node-based shader editing. If you are familiar with Blender's node-based shader setups you will find the visual shader editing very easy to use. When adding a new shader change the type from Shader to Visual Shader.
I really love the distinciton between gamdev who is on RUclips versus RUclipsr who sometimes develop games. A lot of the tutorials on RUclips are geared towards beginners or getting things done quick and dirty. That might be fine for a tutorial or a gamejam, but I'd like to see what are the things that are important in the "real world"
8:50 being a Perfectionist made it so much harder for me to learn game development. whatever I do I never feel satisfied with the results. so I stop working on my games completely. unfortunately
Love the video! I would love to hear more about how you use setters/getters and enums in your state machines. I have a "working" state machine in my game but it feels clunky.
My state machines are usually very light weight and are basically, if state changes to another state change things based on that. I normally use a match statement and then change things like color, animation, or whatever I need to.
@@Aarimous Thanks for the reply! I'll have to see how I can fit some of those concepts in. Right now I use new nodes for each state and have one StateMachine node that manages switching between them
All the features you covered in this video were awesome, but the biggest news for me was: "OMG I can just drag and drop nodes from the scene tree to my code, seriously!?"
Awesome stuff mate! Keep making videos please. I have subscribed. I am working on an enemy AI system and I could use some help with setting up a state machine and use getters and setter like you did. Have you got any tutorials on how to do that?
I use export dictionaries does a very similar thing, Can access normally as a dictionary. Neat they added a feature for it, curious if it works better/different.
this is likely personal preference but I really dislike setters. Assigning a value to a member variable looks like a simple assignment but it can have many repercussions and function calls behind it that are 'hidden' in the setter. Using a setter-method implies that there will be something happening other than just setting the value. But that is just me being old. On the $ and % prefixes to access nodes on the scene's tree: I agree that % is a huge improvement in readability over $ but it loses type info. I usually create an onready-var of the correct type that resolves the node via find_child.
I started by watching GQ Quest and Heartbeast videos. Then I started making my own projects and joining game jams. My early games were all bad, but they got better over time. You can see my history here: aarimous.itch.io/. Then one day I finally had the urge to make my first commercial game Chess Survivors. Keep learning, keep growing, and keep making more games. You got this!
How much of a programming background do you need before getting started? I took a java course before and I was completely lost. I wasn't able to give it a serious effort because it was too difficult to balance that on top of my other classes at the time. I guess my main question is should I just learn through trying to making games rather than studying a course independently?
I don't think you need any and in fact learning programming by making game would be a pretty nice way to learn. The only thing you need is a heavy does of curiosity and then stick with it over the long haul. Learning anything takes time, and you will make a lot of game that you think suck, but stick with it. And before you know it you'll start making games you are proud of that you can share with others. But then keep learning, keep growing, and keep making games. Good luck, you got this!
Just make sure to keep your ideas in check. Don't do what i did and think you can make a mmorpg on your first ever game. Sure i learned some things, but it was not the way to go. Make pong. Like completely finish it, title screen, music etc. Then move on to maybe tetris? then scale from there. Just watch some youtube videos on basic programming, like what a variable is, and how to use them.
this video isn't about the new features of Godot but rather the features that exist in Godot but he found out about them later and he wishes he found out about those features before
I see how I misspoke here, I was referring to the @export_group stuff and all the general changes they made. Those might have been added in Godot 4, or at least improved?
"To be a game developer who makes YTube videos, not a YTuber who makes games" => Subscribed! Let's see if I can get some help from your videos. From a "software engineer who wants to be a game developer" "Have fun, work hard, make cool games!" - (Not Amazon affiliated) 😅
What are your favorite tips or tricks for using Godot? Please checkout the demo for my upcoming game Hexagod: store.steampowered.com/app/3059390/Hexagod/
Small Tip for the Ctrl+Drag: I used to have to deselect-reselect to get the ctrl-drag to work; it was very finnicky. The better approach is to just click and drag the node w/o pushing CTRL, and then when you're ready to drop it, THEN push Ctrl
Oh wow, I run into that issue to. Thank you!
@@Aarimous if you hold shift instead of ctrl and dropping it, you get the full node path to that object in relation to that script. This includes automatically using .. to go up a parent level
Small warning about enums.
If you save it into something, like a variable using a dropdown with export, a resource or something like that, and then add or remove something from the enum list, it can shift the selection to a wrong one.
enums are great, but it's something to be mindful of when using them in anything that saves and loads.
You can technically avoid this by explicitly assigning the values, so the first enum = 0, second is 1, etc. So no matter what you remove, the values for each one remains the same.
@@sataStrike That's true, but things will still have the value that you saved to them unless you change it. So if you add A = 10, then remove it, you'll have an invalid index, and if you later add X = 10, then that thing will suddenly be X.
You could get around that as well though, by setting things to a default value if it's no longer in the list, never fully remove something and keep it as placeholder, or some other method to ensure validity.
There are many ways to handle it, my point was just that it is something worth keeping in mind that it works that way so you can work around it to prevent unintended behavior.
Thanks for the warning - I think he's about to find that using dictionaries is a better approach in some cases, of course. Here’s a quick summary of what I've gathered about enums vs dictionaries:
Use Enums if you need a fixed, small set of related constants that won’t change frequently and where performance and memory efficiency are critical.
Use Dictionaries if you need flexibility, dynamic content, or need to associate additional data with each key. Dictionaries are more forgiving with changes and are better suited for complex or evolving game data.
Both Enums and Dictionaries have their strengths, so the best choice depends on the specific needs of your project. This video might need a follow-up with all the gems that people are sharing :) Feel free to chime in with more tips or experiences!
I was about to call this out too. Enums ARE a powerful tool that you SHOULD use, but only people that are great at planning ahead really get the most benefit out of them. I've had a couple of nightmarish project refactors caused by using enums before I'd nailed down the scope of the system.
Use Dictionary or Arrays and not enums if you have to save/load anything in a list. Enums should be static.
I've been using Godot for years and I've watched a lot of videos to help me be a better creator of games. You sir are one of the best. Not sure how long you've been doing this but I'm very happy to have found you. This video feels like getting advice from a better version of me. It's super clear and relatable. Thanks!
Wow, I'm happy this helped you out so much. Good luck on your game dev journey!
I haven't delved into the godot source but there has to be a tiny performance advantage to using % of $. $ must be parsed each time in case the scene tree has changed, whereas % is a location independent reference ie. it's a link to its location in memory, not it's location in a tree.
Oh perfect, I love % because of the QOL, but good to hear you also think it's the more performant of the two options.
@@Aarimous This has been stated by GDQuest and others who have done the tests. % is more performative
Isnt the only drawback is that theres a limit on how many %s you can use? Its not like 20-50, a LOT more, but I think theres a limit
@@CouchBit I think the downside is that those % reference won't survive loading a new scene. In my opinion using an event bus via auto-loaded script is a more robust solution, as it remains persistent.
This video was one of those rare instances where I want to hit the like button at the end but realize I already hit it earlier. Great video, keep it up!
Good stuff!
If you're making a script where the relationship between the nodes is irrelevant you can also use @export to reference nodes instead of using @onready, which will let you connect it up in the inspector. This gets around any renaming issues, and is especially useful when the script is intended to be modular. I personally use both in different situations, so I'd just recommend playing around with each and seeing which works best for you in each scenario.
8:48 last tip is very reassuring, I am constantly finding new and better ways to do things and feeling like I should rewrite my code, but every time I do I get closer and closer to burnout. it's nice to hear that its okay for things to be imperfect by someone who has actually released games before
Chess Survivors: purchased; Hexagod demo: installed. Cheers!
Hell yeah! Enjoy :)
I feel like I'm on a weird RUclips path where it keeps recommending me all the devs of the indie games I play. Watched through this whole thing, then went to the description for the links, and I had no idea you made Chess Survivors.
When i saw the Godot winodw being called "Hexagod", i was like "wait, i swear I know that game."
I did know
Related timesave to ctrl-dragging a node into the editor to make a reference:
After you've done that, it's really easy to change it to an export variable (changed onready to export and delete everything after the =) which helps keep your code modular.
Great tip!
The getters and setters are huge. It makes it so easy to throw a bunch of logic down the chain. You get hurt? When your health gets set, you throw out a signal with your old health, new health, damage type, anything else you want. Update UI, communicate with other systems that manipulate damage, calculate weakness/resistance, proc items your character that has that have on hurt effects, etc. etc.
Love that one, definitely a great tip to share.
Another tip is combining #1 and #2
Export a variable with the type of the node you want, for example I use a marker2d for spawn points. When you click to assign, it only shows the nodes that match the type you defined
Added Hexagod to my wishlist! I'm on a mission to support my felow developers :D Thank you for this video! I'm sure it took some time.
The set and get joined to the variable declaration and the shaders web are the highlight for me. Thanks for the video!
Thanks for making this video. Great tips and I didn't even know about Godot shaders. Definitely going to explore that.
the info about the unique name option/setting is gold.. this will help alot! thanks buddy
A few weeks ago, I competed in a game jam using Godot for the first time in years. It took a while to get used to all the changes, but I was really impressed by how much easier a lot of things are to do now!
This is the rare really powerful video for Godot. Every tip brought in something new for me and my code will level up a ton. Thanks a lot!
Happy this helped, I'll try and make another one with small tips like this.
As someone just picking up Godot and following a couple 4.x tutorial, these are useful tips. Cheers.
Dude your timing is perfect on this as I just started up a platformer as my first game 2 days ago. I really hope you do more of this cause it all goes such a long way.
Awesome tips. Especially the shader stuff
Great video!! These are really useful tips. Would love to see more on how you actually figure stuff out for example how you actually use those enums.
as a dev by profession, in my opinion setters/getters are an antipattern because it makes it extremely unclear to someone reading the code that an assignment is going to run some hidden function, and if you use it once then they have to be aware it could be happening anywhere... makes it much harder to work as a team, and it's not great for your own readability either
Alternatively, you really should have a scoped function that sets the variable, and even better if you can handle the common case that would make you want to make that assignment
It also looks like you could really use some folders :p
First I'll say, awesome job learning more things that can help you in your dev journey :D There are always things to learn and I hope you learn more things to help you along the way :D
You could create groups back in 3.x, but it was a hassle and pain in the arse. Made much easier by just having that tag in 4.x
The onready and unique names can be names for sure, but personally i prefer just using the export and assigning them in the inspector. It removes any chance of error from typing names out, and like unique names you can move them around in your tree and not need to update your code.
Omg thank you for this video. Instant sub
Hell yeah!
0:57 This frame made me spit my tea all over the tabe. WHY TF YOU NEED THAT MANY @export VARS?!!!
I am a collector of export vars. ;)
Thanks for sharing, cheers!!
Always fun to catch your streams. You definitely should do more RUclips content too! Would love to see you showing more details on each tip you just showcased. Adding examples and showing how your approach is. Especially use of set/get and global @export variables.
Thanks for the video!
Trying Hexagod now. Really satisfying sounds. I like it so far.
This was a helpful video! Thank you!
great vid, but i do have 1 thing that i think would help you a TONNN, look into custom resources, much easier to maintain and expand, was a huge game changer for my projects :3 really suggest godotneers vid "Data models - using data to create extensible, maintainable games in Godot"
Subscribed. Thank you for the tips!
9:16 I appreciate the candour 😄
Great! Very inspiring, it really help me
Neat, guess I gotta read up on enums and setter states a bit! Thanks!
During this last game jam I did, I was using a slew of signals. Some of these signals connected to instantiated scenes (projectiles like bullets), but the signals would disconnect when being instantiated. Came across a post talking about creating a Signal bus using autoload in project settings. You then connect or emit two or more scenes by pinging off of the Signal bus, which made connecting to instantiated scenes so much easier. Performance-wise, I don't know the impact of having a Signal bus too large.
Swap connect() with emit() for outgoing pings. Effectively just using signals, with one more reference name at the front, lol.
[SignalBusName].[SignalName].connect(function_name_you_want_to_connect_to)
(Having a debug os reset scene in autoload is also pretty snazzy)
Try visual shaders. They use node-based shader editing. If you are familiar with Blender's node-based shader setups you will find the visual shader editing very easy to use.
When adding a new shader change the type from Shader to Visual Shader.
HOLY MOLY bro has never created a file for organization! :O
haha anyways, great video! :)
very cool tips!
I've still been using the dollarsign and node path like a big dummy and it has been annoying, thank you for telling me this.
Wow Godot Shaders is crazy!
I really love the distinciton between gamdev who is on RUclips versus RUclipsr who sometimes develop games. A lot of the tutorials on RUclips are geared towards beginners or getting things done quick and dirty.
That might be fine for a tutorial or a gamejam, but I'd like to see what are the things that are important in the "real world"
8:50 being a Perfectionist made it so much harder for me to learn game development. whatever I do I never feel satisfied with the results. so I stop working on my games completely. unfortunately
i would love an in depth ENUM tutorial
I was always wondering how to use Enums better, so thank you!!
Love the video! I would love to hear more about how you use setters/getters and enums in your state machines. I have a "working" state machine in my game but it feels clunky.
My state machines are usually very light weight and are basically, if state changes to another state change things based on that. I normally use a match statement and then change things like color, animation, or whatever I need to.
@@Aarimous Thanks for the reply! I'll have to see how I can fit some of those concepts in. Right now I use new nodes for each state and have one StateMachine node that manages switching between them
All the features you covered in this video were awesome, but the biggest news for me was: "OMG I can just drag and drop nodes from the scene tree to my code, seriously!?"
You can even drag and drop properties to get a string of their names. Cheers!
Awesome stuff mate! Keep making videos please. I have subscribed. I am working on an enemy AI system and I could use some help with setting up a state machine and use getters and setter like you did. Have you got any tutorials on how to do that?
i use export variables so often for animation based things like combat
Hexagod looks exactly my kinda game. I love Settlers of Catan which this looks like it has strong vibes of.
Glad those Catan vibes come through a bit here. Cheers!
hold up I've seen hexagod in the godot subreddit
I use export dictionaries does a very similar thing, Can access normally as a dictionary. Neat they added a feature for it, curious if it works better/different.
Tip 2 is great, also makes me think you could use the GUI Auto Layout plugin 😉
this is likely personal preference but I really dislike setters. Assigning a value to a member variable looks like a simple assignment but it can have many repercussions and function calls behind it that are 'hidden' in the setter. Using a setter-method implies that there will be something happening other than just setting the value. But that is just me being old.
On the $ and % prefixes to access nodes on the scene's tree: I agree that % is a huge improvement in readability over $ but it loses type info. I usually create an onready-var of the correct type that resolves the node via find_child.
The % thing is a life saverrrr omg
Just found our channel, subscribed!
How did you learned godot? I have hard time with it
I started by watching GQ Quest and Heartbeast videos. Then I started making my own projects and joining game jams. My early games were all bad, but they got better over time. You can see my history here: aarimous.itch.io/. Then one day I finally had the urge to make my first commercial game Chess Survivors. Keep learning, keep growing, and keep making more games. You got this!
Love your last advice :D I am making my first game and because of lack of skill in coding it is really just barely working :D Sort of :D
Thanks!
How much of a programming background do you need before getting started?
I took a java course before and I was completely lost. I wasn't able to give it a serious effort because it was too difficult to balance that on top of my other classes at the time.
I guess my main question is should I just learn through trying to making games rather than studying a course independently?
I don't think you need any and in fact learning programming by making game would be a pretty nice way to learn. The only thing you need is a heavy does of curiosity and then stick with it over the long haul. Learning anything takes time, and you will make a lot of game that you think suck, but stick with it. And before you know it you'll start making games you are proud of that you can share with others. But then keep learning, keep growing, and keep making games. Good luck, you got this!
Just make sure to keep your ideas in check. Don't do what i did and think you can make a mmorpg on your first ever game. Sure i learned some things, but it was not the way to go. Make pong. Like completely finish it, title screen, music etc. Then move on to maybe tetris? then scale from there.
Just watch some youtube videos on basic programming, like what a variable is, and how to use them.
I don't really understand the functional difference between enums and arrays/dicts
Are these shaders open source and free to use?
thanks!
Fantastic
I'd appreciate if you make games and explain things as you go
Variable exports been there for a while its not new to godot4
this video isn't about the new features of Godot but rather the features that exist in Godot but he found out about them later and he wishes he found out about those features before
I see how I misspoke here, I was referring to the @export_group stuff and all the general changes they made. Those might have been added in Godot 4, or at least improved?
who noticed the cat 9:03
ho this is so useful
Ill play your games if you play mine 😘
Jk lol, just found your channel! Definitely earned a sub 🙏
"To be a game developer who makes YTube videos, not a YTuber who makes games" => Subscribed!
Let's see if I can get some help from your videos.
From a "software engineer who wants to be a game developer"
"Have fun, work hard, make cool games!" - (Not Amazon affiliated)
😅
Good luck on your journey!
نعم فيديو عن grub و grub2 لأنه مهبلني
4:21 @onready
Very nice tips, thanks!
thank you!