Should I use autoload or static classes with C#?

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By Marin Mario

I’ve been using Godot with gdscript for a while, and the autoload feature was quite convenient if I wanted to preload resources or store data between scenes. Now I’m trying it with C# and everything works just the same with static classes. Should I keep using static classes? What’s the point of the autoload feature with C#?

:bust_in_silhouette: Reply From: Zylann

There is a slight difference between Godot autoloads and C# static variables.

Autoloads are just nodes in the scene tree, like every other node. What makes them “autoload” is that they are created when the game starts, and are not wiped out when you use change_scene(), because they live under the scene tree root:

- root (Viewport)
    - CurrentScene
    - Autoload1
    - Autoload2
    - ...

They can be accessed using GetNode("/root/AutoloadName") as well, and as such, they are available to any script language. And because they are nodes, they will be automatically freed on game quit, and it is possible to know when they are about to be removed, by implementing _ExitTree().
GDScript has a feature that makes autoloads available as if they were globals, allowing them to be accessed even when you don’t have a reference to the scene tree.

C# static variables, on the other hand, are specific to C#. They mostly behave the same in terms of “global variables”, however they don’t natively have access to the scene tree, and are only created when you access them the first time, not when the game starts. Also, C# has different kinds of destructors which might not get called in a good time (I don’t know much about the specifics of that in Godot). And if you have Godot objects within a static variable, you have to make sure you don’t leak them because of that.

Now wich one should you use?
Personally, I avoid static as much as I can to keep code self-contained (so easier to test or re-use), and not have states hanging around having to manage everywhere, but they have their use cases. If you use them to hold Godot objects, make sure you properly manage their lifetime.

Right, thank you. That’s a good answer. In my case I just wanted to preload resources at the start of the game. Since static variables are created when you access them the first time I think it’s better to use an autoloaded node for that.

Marin Mario | 2020-09-24 14:38

If you want to load resources when your game starts, an autoload is not the only way though. You can litterally do it in _Ready() of your first scene as well. You’d use an autoload only if you want them to remain available from the same place from anywhere throughout the whole game.

Zylann | 2020-09-24 14:41

Yes, that’s why I want to use an autoload. Also, not sure about this one, but if I just load all the resources at the beginning, won’t the game work better because it doesn’t have to load them every time it changes the scene? (I don’t care about performance that much at the moment, it’s more of a curiosity. But if I can make it faster without much work I don’t see why I shouldn’t do it)

Marin Mario | 2020-09-24 16:13

It can make in-game loadings faster, while making startup slower. The question is more, are you happy with loading all the assets of the entire game up-front? For a small game it won’t matter, but if that adds up to hundreds of megabytes it starts to be a concern.

Zylann | 2020-09-25 10:33