Also use git to manage your source code. Make commits regularly, such as before you stop working for today or when you have a large chunk of changes done. You can use this to revert the project back to an earlier point. You can branch off and work on different components separately and merge back in later. If you work out of a project folder with no backups and restore points, you will be living in constant fear that you will break something and be completely unable to undo it. But with GIT, you can create save states for yourself and undo all current changes if your attempted solution to a problem grows out of hand.
While good for the purpose of always having a backup accessible (granted the Github/Gitlab or whatever server doesn't go down of course), it's also important to remember that it indeed means putting your code publicly online. And what's more, is that the likes of Github are owned by Microsoft, all and any code uploaded there is then under their full ownership. Not sure about Gitlab though, but I don't fully trust them either. I still prefer storing things on hard drives or USB sticks, and considering how available and cheap they are nowadays, I don't see a reason not to.
@@iamyourgreatgreatgreatgrea6291 Everything you said is wrong. Your repositories on github can be private so only you and a select team see them. Neither Microsoft nor Github own your code if you use Github as your origin. Also even if you really don't want to use an origin server, you can still use git locally to stage all your changes in the exact same way, so you can manage all your branches and commit history on your own hard drive without ever having to ever upload it anywhere
@@iamyourgreatgreatgreatgrea6291 He talks about local git repository. It is not related to Github or Gitlab in any way, it is stored on your local machine.
@@iamyourgreatgreatgreatgrea6291it isn't actually means putting your code publicly. If you want to use github/lab you can choose private repository. And main comment doesn't talk about centralised systems like GitHub, only about using git system, which you can use on your own server
When it comes to having a lot of exposed variables, it can also help to make a Resource for it. PlayerData is a good example of that sort of thing. Instead of having the data directly on the player, let the player expose only a resource variable and put all the data you need into that resource. You can set up that resource as its own file, so if you need it in multiple places, you can drag and drop it in the inspector, and it frees up the variable definition in your other classes to only have the variables they need for what they are specifically designed to do. Also makes it easier to pass as a parameter, since all the data is already bundled up. You can even offload some functions into a resource like that, as long as it doesn't need any functions derived from Node. As of, I think, 4.2, there's even collapsible code regions, which allow you to define regions in your code, that you can fold in, so they only take up 1 line. Typically, it's better to have smaller scripts in general, but sometimes it can't be helped, and this can help you stay on top of the mess.
The style guide page in general is incredibly helpful for organising your scripts, and making it easier for other people to read your scripts in the cases of programming teams, teaching or open source
Code formatting should definitely be done by the editor itself. Other modern languages come with their own formatters out of the box. The more opinionated/strict the better, it means less bikeshedding decisions I need to make. I've seen there's a separate formatter for Godot but it should be built-in.
Good stuff. I already ordered my code but I don't think I was using the godot standardization for it. It's been a while, but I'll have to go through the style guide again. Good stuff. Also good for sharing all that info about the exports. I knew about that stuff but it's good useful info for anyone who didn't!
This was awesome. I'm subscribed since months ago, and I always give you an insta thumbs-up. But with this video I'm also gonna save it in a specific playlist. You're doing the Lord's work. Thanks, man.
yes yes yes yes and more yes :) I always get lost, but mainly bcs I'm doing it alone and loose focus. I'm already organized like this, but didn't know there was an order for vars, thx for the info.
I don't strictly follow the order because I like to sort things categorically, so all movement related variables and signals would be next to eachother (ordered by type ofc)
Good tips nicely presented, though I would have appreciated a less vague title and thumbnail as I personally learned literally nothing new from this. Something as little as "organise your variables!" or "write tidier scripts!" in finer print at the bottom of the thumbnail would've given us an idea of what the video was about and whether or not it's something we're already familiar with.
Haha, I do signals at the bottom, but otherwise the same. It's just a habit. I like having signals right above my first true function for some reason. Lately using setters in my member declarations a lot has made it look a bit messier, but I can collapse those or add code regions for that now, so it's all good.
The really important thing is to have a standard, any standard, so you're doing well. For anyone who doesn't have their own standard, Godot's is a good place to start.
You forgot the important one about organizing resource folders. I'm already using this tips, but all yes anyway:( I think the answer is design document, but I hate paperwork
Just a couple of notes about terminology: 0:50 "Constant" and "variable" are antonyms. A "constant variable" is an oxymoron. Those would be "constant property" and "variable property". 1:23 The "export property" is actually the "export attribute".
This way of organize code is pretty same in other langues. Const are const, not const variables. Second @export_group are no use for me as I always make scripts short with few exports, so it solving it self. And I think is better to use short scripts that you don't have to use @export_groups than using @export_groups in long scripts.
🔥 GET TUTORIAL SOURCE FILES ►► www.patreon.com/StayAtHomeDev_
👉🏼 FREE BASIC FPS SETUP SOURCE FILES ►► github.com/StayAtHomeDev-Git/FPS-Godot-Basic-Setup
First 15 seconds: "ugh preach! Wait are we talking about gamedev or my life?"
Organize your life variables too?!?!
@@stayathomedev too many variables, not enough RAM 😵💫
@sandrinowitschM obvious noob. You're supposed to download more RAM. :/
My life has got plenty of RAM, but my CPU has a few bent pins and my GPU is a 6500 XT, i.e. crap.
@@tiacool7978we're talking about your adhd
Also use git to manage your source code. Make commits regularly, such as before you stop working for today or when you have a large chunk of changes done.
You can use this to revert the project back to an earlier point. You can branch off and work on different components separately and merge back in later.
If you work out of a project folder with no backups and restore points, you will be living in constant fear that you will break something and be completely unable to undo it. But with GIT, you can create save states for yourself and undo all current changes if your attempted solution to a problem grows out of hand.
While good for the purpose of always having a backup accessible (granted the Github/Gitlab or whatever server doesn't go down of course), it's also important to remember that it indeed means putting your code publicly online. And what's more, is that the likes of Github are owned by Microsoft, all and any code uploaded there is then under their full ownership.
Not sure about Gitlab though, but I don't fully trust them either.
I still prefer storing things on hard drives or USB sticks, and considering how available and cheap they are nowadays, I don't see a reason not to.
@@iamyourgreatgreatgreatgrea6291 Everything you said is wrong.
Your repositories on github can be private so only you and a select team see them.
Neither Microsoft nor Github own your code if you use Github as your origin.
Also even if you really don't want to use an origin server, you can still use git locally to stage all your changes in the exact same way, so you can manage all your branches and commit history on your own hard drive without ever having to ever upload it anywhere
@@iamyourgreatgreatgreatgrea6291 He talks about local git repository. It is not related to Github or Gitlab in any way, it is stored on your local machine.
@@iamyourgreatgreatgreatgrea6291it isn't actually means putting your code publicly. If you want to use github/lab you can choose private repository. And main comment doesn't talk about centralised systems like GitHub, only about using git system, which you can use on your own server
Good video. I would suggest zooming in to the sections of the window you're talking about. On mobile i can't really make out what you're showing.
Noted!
yup, nice narration but bad camera perspective.
When it comes to having a lot of exposed variables, it can also help to make a Resource for it. PlayerData is a good example of that sort of thing. Instead of having the data directly on the player, let the player expose only a resource variable and put all the data you need into that resource. You can set up that resource as its own file, so if you need it in multiple places, you can drag and drop it in the inspector, and it frees up the variable definition in your other classes to only have the variables they need for what they are specifically designed to do. Also makes it easier to pass as a parameter, since all the data is already bundled up. You can even offload some functions into a resource like that, as long as it doesn't need any functions derived from Node.
As of, I think, 4.2, there's even collapsible code regions, which allow you to define regions in your code, that you can fold in, so they only take up 1 line. Typically, it's better to have smaller scripts in general, but sometimes it can't be helped, and this can help you stay on top of the mess.
As a newcomer to Godot, this was fantastic. Thanks!!
Wow, I didn't know about the inspector organization. I am definitely going to start using that!
Liked and added this to my GODOT playlist 😊
The style guide page in general is incredibly helpful for organising your scripts, and making it easier for other people to read your scripts in the cases of programming teams, teaching or open source
We definitely could need a linter for this. would help a lot for solo and even more for development within teams.
Trying to climb out of tutorial hell and only two short videos into the YT suggestion and already gotten so much from your content.
Code formatting should definitely be done by the editor itself. Other modern languages come with their own formatters out of the box. The more opinionated/strict the better, it means less bikeshedding decisions I need to make.
I've seen there's a separate formatter for Godot but it should be built-in.
Good stuff. I already ordered my code but I don't think I was using the godot standardization for it. It's been a while, but I'll have to go through the style guide again. Good stuff. Also good for sharing all that info about the exports. I knew about that stuff but it's good useful info for anyone who didn't!
This was awesome. I'm subscribed since months ago, and I always give you an insta thumbs-up. But with this video I'm also gonna save it in a specific playlist.
You're doing the Lord's work. Thanks, man.
yes yes yes yes and more yes :) I always get lost, but mainly bcs I'm doing it alone and loose focus.
I'm already organized like this, but didn't know there was an order for vars, thx for the info.
I'll have to keep this video in mind.
So precise and short, I really like it !
You just got a new subscriber ❤️
Wow!!! That's awesome. Thanks for the video. 😀🙌
this is awesome!
I don't strictly follow the order because I like to sort things categorically, so all movement related variables and signals would be next to eachother (ordered by type ofc)
I will definitely start using these, thanks!
Good tips nicely presented, though I would have appreciated a less vague title and thumbnail as I personally learned literally nothing new from this. Something as little as "organise your variables!" or "write tidier scripts!" in finer print at the bottom of the thumbnail would've given us an idea of what the video was about and whether or not it's something we're already familiar with.
great video!
Awesome life hack's,as always! Thanks a lot!
Awesomeee, I didn't know those
Nioce you could have mentioned the #region that is pretty new
Very useful! ❤
Its great that you only gave 1 advice :)
Haha, I do signals at the bottom, but otherwise the same. It's just a habit. I like having signals right above my first true function for some reason. Lately using setters in my member declarations a lot has made it look a bit messier, but I can collapse those or add code regions for that now, so it's all good.
The really important thing is to have a standard, any standard, so you're doing well. For anyone who doesn't have their own standard, Godot's is a good place to start.
I like to do @exports and @onreadys next to each other, but otherwise I follow what the guide has.
AS long as you are consistent, it's really fine. Especially if you are doing solo game dev.
You forgot the important one about organizing resource folders. I'm already using this tips, but all yes anyway:(
I think the answer is design document, but I hate paperwork
very helpful
Just a couple of notes about terminology:
0:50 "Constant" and "variable" are antonyms. A "constant variable" is an oxymoron. Those would be "constant property" and "variable property".
1:23 The "export property" is actually the "export attribute".
Eggcelent!
Love it
This way of organize code is pretty same in other langues.
Const are const, not const variables.
Second @export_group are no use for me as I always make scripts short with few exports, so it solving it self.
And I think is better to use short scripts that you don't have to use @export_groups than using @export_groups in long scripts.
ok nerd
I loved the video thank you. Just one tiny thing. Constants are not Variables. I feel like a triggered Code Karen 😅
Good point!