Resources vs. Autoloads for Coupling Systems

Help Programming
, ,
1

Godot Version

4.7

Question

I am trying to understand when to use Resources vs. Autoloads or decoupling systems.

Info:

My Autoloads are usually either of the “Data Storage” or “Event Bus” type.

I have usually been trying to avoid Autoloads to try and create reusability across projects without flooding each project with them. By doing so I realized that Resources can pretty much just do exactly what I used Autoloads for, hold signals and store data, so their overlap is kinda confusing.

Where’s the actual line between them for Data Storage/Event Bus use cases?
When does one make sense over the others? When does it make sense to use a Autoload with Resource References?

I have looked at the following Forum Post already, and have looked through the Documentation of Autoloads, Resources, as well as the segment on Static References, but I am still unsure.

2

If you are only using Autoloads to hold data and signals you are using them wrong, Autoloads can be entire scenes and should function on nodes to make the most out of the fact that they exist in the scene tree usually for the game’s lifetime.

I personally hate the “Event Bus” pattern, I have never found a good use case for it. Resources are great for data storage for a lot of reasons, any file in Godot is an extended Resource and you can go wild with your own.

3

I am aware that Autoloads are not solely supposed to created a global Storage, and that they provide a lot of versatility to create permanent systems at runtime outside of that, but that is kinda my point.

–

I just wondered why even use Autoloads to store data and manage signals, and Resources can do so just the same, why not use those instead. I guess there is literally just no point at all in doing that, unless you really want stuff to be globally accessible, but even then it might be better to just have a Autoload which is a Container for those dependent Resources.

Whenever I see people talk about EventBuses, its usually just a full Autoload made to get everything interconnected, which I don’t like, as it risks a lot of cross-reference spaghetti across systems.

I used to split them into smaller buses, which would then be a seperate Autoload, or class within a Autoload, per-system, but even then, why would I have that at all when each system could just have its own Bus.

Now I’m using a Resource per-system, and while it also might lead to overdependency once I try to couple multiple systems together, it currently just provides a proper source of information, such as Data to reference or Signals to listen to, for each individual system, where any component can just connect itself to the Resource, and pass on its “message” to it, and anything else within the system can just as easily connect to it, without every having to risk nulls with dependency, as the Resource itself is just the “Bus”.

Ultimately it will probably go towards the same problems as a simple Autoload, but at least it works WITHOUT having to autoload, making reusability way cleaner imo

I guess instead of adding dependency I could then write some sort of translator/adapter between the Resources, which would then be project-specific, so I don’t bloat dependencies.

Maybe I’ll move away from EventBuses at some point, but currently I just love them way too much… especially for UI, where they are my main use case, as I still struggle with coupling UI properly, and having a way to just listen in without needing to couple is nice…

4

You can use static classes instead of autoloads to store global data. I’d only use an autoload if I needed actual permanent node functionality in the scene tree, which is extremely rare. Never used something like a signal bus as I prefer to organize stuff in a way that always keeps all signals local.