Declutter Your Godot 4 Project: Singletons/Autoloads All Over The Place...

[@Gdquest]

class_name Mob static var deleted_count := 0 static var hurt_count := 0 ... If you use a class name, you can avoid using preload(), and you can access Mob.deleted_count or Mob.hurt_count from anywhere in the project.

[@kbkmn]

does this mean that preload approach will reset all variables on scene change and class_name approach will persist throughout whole app run?

[@icefoxzettai]

What if you need to reset the counter at any instance, where would it be the best place to do so?

[@Joel2Million]

thanks, the preload felt clunky for someone with a oop background, this is perfect

[@KyleLuce]

This is fine for prototypes, but i prefer a decoupled approach here. E.g - create an Autoload global Game event bus - enemies emit a signal when dead ln a Game event bus - create a Singleton that only manages the statistics on death (targeted per use case) - stats Singleton listens for appropriate Game events - Singleton manages statistics and only it is allowed to perform operations/math on these values This provides a decoupled design without any need to keep script resource references artificially held etc and avoids leaky abstractions with many objects directly altering low level details like individual variables.

[@bahamajo]

Not really sure I understand this. Doesn't this just mean creating two Autoload Singletons? The event bus and the "Singleton Death Handler"?

[@KyleLuce]

@@bahamajo the global event bus should be an autoload (an established pattern) , the statistics manager can be wherever's appropriate. This stats management depends on your games needs. The idea here isn't "Singleton/autoloads need to be avoided" it's that "error prone design patterns and leaky abstractions need to be avoided". If you were directly changing autoload members from another class, this would also be an anti pattern. Improper uses like these led to autoloads being loathed. When you avoid accessing member variables directly and only mutating state through async events (or at least methods), your system is easier to maintain and refactor later. This is typically summed up as the "Law of Demeter". Static variable usage may make sense in some use cases, but in general if you have other "non owner" classes manipulating these, it can be more error prone and harder to keep track of what's going on (and refactoring challenges mentioned above). Please feel free to ask anything else or if this perhaps was unclear.

[@bahamajo]

Thanks for the feedback @@KyleLuce!

[@Timikator]

Note that this applies everywhere in programming, not only in game programming. It's strange that, in every other programming field (e.g. Web dev), global variables are banned and mostly avoided, meanwhile here in the game dev industry people make tons of tutorials on how to use them without explaining the downsides.

[@petethorne5094]

@@KyleLuce Event bus is a really powerful pattern. I use it all the time, it's a pillar of maintainable code in Godot, along with StateMachines and Composition over Inheritance.

[@TheNightShirt]

I would love a tutorial about Composition.

[@Gdquest]

Thanks for the suggestion :) Will keep it in mind.

Firebelley Games has a video that was key to me starting to understand composition. kzbin.info/www/bejne/qHTYaamHp8l3eqs Would recommend

[@whatsupbro3]

@@GdquestPlease! this is probably one of this biggest things i struggle with after switching from unity to godot

[@vibingLieke]

Me too!

[@Cigam_HFden]

The best one I had seen so far for composition was this one: kzbin.info/www/bejne/bWXcZ62Nj8uEgc0 How You Can Easily Make Your Code Simpler in Godot 4 by Bitlytic

[@testoftetris]

if I'm not mistaken, you can also use the class_name property on your script with static variables to make them accessible through ClassName.static_var (so you don't have to load the script through its filepath)

[@Ichthyoid]

would the syntax for that be like this? var VariableName: ClassName.static_var = variable

[@danielw7685]

​@@Ichthyoid it would be: var VariableName: Type = ClassName.static_var

[@dairyfreelemonstreams9493]

Daniel's example is correct as for testoftestris: tested earlier today to verify and yep you can just use ClassName.StaticVar from any node in the scene, even if none of the nodes present in scene are said class. The remote view won't show static variables in playtest as far as I can tell so one of those debugging plugins or just classic print() will be how you peak at it in playtest. (Please feel free to prove me wrong, i can easily have missed it but I spent a solid few minutes looking and not seeing any mention of it in the remote views or in debugger)

[@Gdquest]

class_name Mob static var deleted_count := 0 static var hurt_count := 0 ... If you use a class name, you can avoid using preload(), and you can access Mob.deleted_count or Mob.hurt_count from anywhere in the project.

[@EricAbroad]

PERFECT timing! I just recently got ibtroduced to Autoload scripts, but quickly found that they overtook most of my code and made things easy to break/hard to update later. I will play around with static variables in my next coding session. Thank you!

[@Dharengo]

Every tool has its use case. It's nice that static variables are here. That will put more value on autoloads for actual autoload things.

[@Gdquest]

Agreed

[@scarfanzi]

Helpful! I'm a beginner Godot dev and generally new to game dev altogether. Learning about singletons was a huge step for me, and now learning about Static variables will make my code much cleaner.

[@Gdquest]

Welcome :)

[@Shanjaq]

Always wanted Statics in Godot, so glad I committed the hours to trimming/substituting dependencies for the upgrade from gd3 to gd4!

[@littleerichsenstudios2292]

So valuable - thank you! And I love the bats!

[@gablanwheel3895]

Good shout, I like the use case here too. We can reliably keep track of enemy deaths without having to store a reference to another script in the mob class. Nice and clean!

[@palmpixiplus]

This is exactly what I needed!

[@giovanemachado8339]

This is dope, I love this little tricks

[@Weahl]

I want moreeeee, your videos are a drug ❤

[@zehijean8817]

I would like to and even pay for it...i d like to see a course on non game software development with godot as the ui framework to build a business app with dynamic layouts for mobile tablet and desktop resolutions...i am heavily pushing godot at my company as ui framework ...this way i can do both software dev and gamedev in one place

[@Gdquest]

I hear you. We've actually used it to make multiple apps and we love it too. The whole workflow is pleasant from fast prototyping with a visual editor, to UI design, and the OS abstraction is excellent. Definitely planning a course. I would really appreciate it if at some point you could send me an email at [e-mail] describing your needs. It might help focus the curriculum when we get to it (GDQuest is a very small team...). Thanks for the comment and the trust. :)

[@zehijean8817]

@Gdquest alright ill send an email today thanks for replying fast.

[@dairyfreelemonstreams9493]

Today I realized for all the utlities I make for myself like a utility to queue_free all children of a node(or all signal connections!), I could just put all of these in a static function in my utilities script... Bless godot finally having static.

[@MajikayoGames]

wow i didn't know about this! the other day i was using some static utility functions and i thought, 'sigh, i wish i could use a static variable here in addition to my functions.' thanks gdquest!

[@Lansamatv]

comp you make the animations of the bats and the slimer you can make a video about the creation of the sprites What tools do you use?

[@containedhurricane]

We could implement Unity's Scriptable Object event architecture and composition to make our code more modular in Godot, as shown in Unity Open Project 1

[@sirdogegd9567]

This is so poggers

[@maze._]

If all instances of the script are gone/unloaded from memory, is it correct that the static variable will reset?

[@Shadow-cs7oy]

Probably, if there are no other instances which could held the values, then static variables are gone

[@phileon2323]

Use the mono version and declare your variable with public static

[@r.e.4873]

@gdquest it would have been nice to explore this with some more examples. A variety of cases to observe would give a deeper understanding. At the moment, I don't fully understand how this works or can be implemented generally.

[@PhoeniXCh1]

Why would the counter data be lost if you delete the last mob? Is that what would happen if you didn't preload the "static_variables_mob" script? I'm sorry. I'm new and can't quite wrap my head around this

[@Frank_G_Finster]

Very interesting video. Thank you for the upload! What about having different classes accessing identically named static variables? Will the data be shared between those classes variables or is this exclusive to instances of a specific class?

[@Gdquest]

They will be different even if identically named. Each has its own scope limited to its class. But you can still access static variables of some class from anywhere by preceding the variable by its class name.

[@AverageNeovimEnjoyer]

You literally saved my life with this. However, there is a small problem I am facing. I have an @onready var texture_rect: TextureRect in my script. I need it to me static so that texture_rect.texture property persists across scenes. But the thing is I cannot use static keyword for @onready variables. What can I do?

[@atti1120]

Is it persistent?

[@llaneelyort5599]

Can you save this resource upon exiting game scene and load in back upon game startup?

[@Gdquest]

Yes, you will have to write the saving system though of course.

[@crashito1752]

I would like a tutorial to make a grid-based movement in Godot 4.2 please!, I am stucked with the programing of it (Sorry for the bad english)

[@danielalvesldiniz]

well, it is kinda cumbersome to have to keep a permanent reference to the script so that the data doesn't go away... but interesting idea!

[@Floffffff]

Hi, I would like a tutorial about a situation like this in godot 4: what if I have 2 virtual mobile joysticks and I want to be able to move both of them at the same time? (I mean something like brawl stars' controllers) A tutorial would be really appreciated

[@Gatto_uwu]

I recently finished studying Python and wanted to learn how to program video games, but I'm not sure which engine to focus on. Can Godot work? If so, where can I find a tutorial that explains how to use this engine?

[@Gdquest]

On this channel. Watch our latest Short for a roadmap. kzbin.infov7d8uYw59jk If you know Python, Godot will feel natural to you because GDScript is basically Python for Gamedev.

[@thenamesandounts9807]

Oh. So static varibles have been ported over from C#? (I'm assuming that the concept is older than that but that's where I first encountered them.)

[@wrksless971]

Will you ever do a packedscene save example? I have been told to search and I have , but some just say save the scene, others say don't, others are saying save the children of children to a owner.... I just don't know who or what to do at this point.

[@Gdquest]

Generally you can do whichever seems simplest to you and see if you have a problem. But you do always need to set an owner on nodes you want to save. We'll consider a video on the subject!

[@wrksless971]

​@@GdquestHI, Sorry I took so long to reply. Thank you for considering a video on the subject, I look forward to it. Again sorry for the way long timeframe.

[@diligencehumility6971]

I thought you had an actual good alternative... If you know any other language than GD Script you know static variables, this is not a solution, a static variable is simply a shared variable between classes. Godot has a build-in solution for this, it's called "Groups". There is both global groups and scene groups. This would have been a perfect example of the usage of that. If you prefer code, then an Autoload or an autoload with global signals would have been fine also. Static variables is the least desirable solution

[@Gdquest]

Practically speaking, the static variable here is a simple and slightly faster alternative to setting up an autoload. In both cases you're creating a globally available piece of data, except with static variables you don't need to create a third entity to store and expose that data. So they're slightly more efficient in this context. Note that classes stay around in memory fairly similarly to autoloads. Groups are a tagging mechanism for nodes. They're a tool that's helpful when you want to give different tags to different nodes to check aspects you can't put directly in their types. When doing that you also end up making the nodes and their data globally available, but one function call away. So it's again not too far from using an autoload practically speaking, with an added layer of indirection and code that's slightly more error prone because now you rely on strings to retrieve the data instead of statically typed information.

[@ZoidbergForPresident]

On est d'accord que si one n'a pas de node avvec le script contenant les variables static, supprimer tous les objets fera perdre les données statiques?

[@eliederventura]

What about changing scenes? Will those variables keep their values and be available?

[@Gdquest]

Yes

[@RezaAkbar]

is there any example file for this videos?

[@Gdquest]

Sure. I will link it in description.

[@ukrsolid]

nice trick

[@Roddev776]

How use open gl es 2 in godot 4

[@ভোমরা]

nice godot

[@MoogieSRO]

So, don't use autoload globals, just use this other type of global. Instead of an autoload, have an extra node sitting in your hierarchy. I'm not sure I get the improvement here.

[@nadadenadak]

why using autoload here is a problem? In my head I'd just use a simple dictionary in the autoload which would hold all the mob related statistics

[@ritoon2223]

Hi, can you please tell me if you can port your app to android?

[@Gdquest]

Are you referring to your own app or our app to Learn GDScript?

[@ritoon2223]

Your application for learning gdscript

[@Gdquest]

We have no plans to port it to android in the immediate future for reasons related to reposiveness and the editor.

[@BigSauceGames]

Unrelated but I made my first game in Godot and it’s on Steam! It’s called A Christmassy Christmas! 🎄🎄

[@qingxian3870]

nice!

[@BigSauceGames]

Thank you!@@qingxian3870

[@BigSauceGames]

@@psilon6999 yes I did! I found it to be a great course, and I fully recommend it. Everything he taught has stuck with me and I feel much more confident in engine.

[@SaifKhan02804]

Link please and platforms it support?

[@BigSauceGames]

@@SaifKhan02804thanks for checking it out! Platforms are windows.

[@MegaJohnny74]

this still looks like a singleton

[@FunBanan117]

I only wish for static functions...

[@Gdquest]

You can use static functions

[@FunBanan117]

@@Gdquest oh, sorry for misunderstanding. I thought about some kind of function that would activate per each class instance when called from somewhere. For now the only option is to use singleton for that so it require a lot more extra code.

[@mariegrasmeier9499]

Is this only valid for godot 4 or does it work in 3.5, too?

[@joelgomes1994]

Godot 4.1 and later.

[@domi_dreams]

stop wasting people's time with that toy language, and focus on improving industry standards like C#. 6-year time Godot user speaking here...

[@Cigam_HFden]

Shaming people for using something that you personally do not like is not a way to get them on your side. I prefer gdscript myself, but have used many languages before, even C# for years. It is just a matter of preference, but for me it is for the efficiency and speed at which I can write gdscript. But each language has its pros and cons. Cheers.

[@Gdquest]

Advocating that people consider DSLs toys would not improve industry standards. As a gamedev specific language, GDScript works well for most use cases and when it's needed, we use C++ or C#. But feel free to use C# across the board. Industry standard should evolve to recommend what is most applicable to your use case. Languages, like engines, are tools: means to an end. If your preference is to pick up and stick to only one tool, by all means.

[@domi_dreams]

@@Gdquest you position yourself as one of the (if not THE ) main advocates of the engine, you have quite a big following and basically you seem to make a living mostly from the work around the engine. On the same hand you completely neglect such important topics as real-world usage of the tools and what industry actually needs. Do you really believe strong players, like companies or studios will switch their workflow to a semi-scripting language developed in recent yeards, with no serious tooling around it (debuggers, profilers, analyzers, refactoring) for all their codebase? From what we might observe is - you are targeting mostly solo-devs or ocassional users who just tinker with the engine from time to time, building toy games over the weekend. Have you ever considered focusing more on de-facto standards like .NET or maybe even C++ - and filling that missing gap for some serious usages of the engine? No offense, but right now, sugar-like graphics, bouncy vibrant music and python-simple-like scripting would mostly attract people entering game development - but if that's your ACTUAL target audience, not the A-AAA studios, and I am all wrong - I am taking my words back then...