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 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.
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 feel like I'm on a weird TH-cam 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.
I really love the distinciton between gamdev who is on TH-cam versus TH-camr who sometimes develop games. A lot of the tutorials on TH-cam 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: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
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.
Always fun to catch your streams. You definitely should do more TH-cam 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!
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.
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!
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.
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"
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!?"
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
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)
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 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.
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!
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.
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 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.
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!
When i saw the Godot winodw being called "Hexagod", i was like "wait, i swear I know that game."
I did know
I feel like I'm on a weird TH-cam 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.
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.
Chess Survivors: purchased; Hexagod demo: installed. Cheers!
Hell yeah! Enjoy :)
I really love the distinciton between gamdev who is on TH-cam versus TH-camr who sometimes develop games. A lot of the tutorials on TH-cam 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: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
9:16 I appreciate the candour 😄
the info about the unique name option/setting is gold.. this will help alot! thanks buddy
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.
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.
Always fun to catch your streams. You definitely should do more TH-cam 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!
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.
Subscribed. Thank you for the tips!
Very nice tips, thanks!
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!
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.
Great! Very inspiring, it really help me
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.
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"
Trying Hexagod now. Really satisfying sounds. I like it so far.
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!
Omg thank you for this video. Instant sub
Hell yeah!
HOLY MOLY bro has never created a file for organization! :O
haha anyways, great video! :)
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
I was always wondering how to use Enums better, so thank you!!
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)
very cool tips!
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!
Tip 2 is great, also makes me think you could use the GUI Auto Layout plugin 😉
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. ;)
hold up I've seen hexagod in the godot subreddit
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
thanks!
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.
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
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!
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.
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.
ho this is so useful
I'd appreciate if you make games and explain things as you go
I don't really understand the functional difference between enums and arrays/dicts
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?
"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!
This was a helpful video! Thank you!