sublic static managers with public static GameObjects

Scripting
1

Heyo,
I use HarvestingData.cs, CombatData.cs, and lots of public static data scripts to store global variables and functions that different scripts make use of throughout runtime. Inside of these I sometimes store a public static GameObject like felledConifer, so that anytime a player cuts down a conifer I don’t have to call Resources.Load because I already called it once at start and the object is stored in HarvestingData ready to be instantiated.

As I move out of the base coding into more expansion of content for my game I foresee that I will have to store a lot of different types of felled trees(and other objects), say for arguments sake 500. I’m sure the answer will be somewhat opinion based, but is this a sound practice for trying to avoid Load calls?

I’m assuming this will put the GameObjects into RAM as opposed to waiting on the disk, in hopes of eliminating the need to spin any HDDs as much as possible.

I don’t like using prefabs with loaded public variables as I’ve had that go awry more than a couple times. I hard code everything, all my UI children, all my public variables, everything.

What say you?

2

I’d use a List or Dictionary to cache items if you want to avoid doing Resources.Load and wrap their reads in functions:

public static T GetCachedResource<T>(string path) where T : Object
{
    if (_cachedResources.ContainsKey(path))
    {
        return _cachedResources;
    }
   
    var resource = Resources.Load<T>(path);
    _cachedResources[path] = resource;

    return resource;
}

Or something thereabouts

1 Like
3

Thanks for the reply.
you’re saying to load them into a list or dictionary at start and then call them out of the dictionary during runtime as needed? (or at least minimize loading to only once as the function you posted above does nicely) That’s basically what I meant. Certainly more organized that just making a separate variable for everything which I made it sound like.

Is that a good way to go though? I’m was curious if someone would be like “Oh god no! Don’t load them all into memory!!” makes sense to me to do it this way though =o That’s a great idea making sure things only load once too.

4

Weather or not to load them into memory in advance depends a whole bunch on just HOW MUCH memory that is. If you find it starts slowing systems down, because they need to say…cashe memory to the Hard-drive, then you probably don’t want to do it. For a couple dozen items, I’d definitely say do it; thousands of items, i’d say don’t. Hundreds, is kind of on the border- afraid you will need to test this out, and possibly limit the cashe use to the most often loaded up items…

5

word. That’s what I was thinking. They’re not overly complicated meshes or variables I’m putting in memory, it just seemed like good practice to avoid accessing the disk when you can get everything setup during the one wait during load.

I’d much rather have a 30 second load screen than lots of little jumps throughout the game.

Thanks for the input.

6

I’d much rather have a 30 second load screen than lots of little jumps throughout the game.

With some additional effort, neither of these should actually be necessary. You only need to load the resources you need immediately during scene load. The ones you WERE loading “as-needed”, can be loaded, on a short timer, after the scene starts. Only if you need a particular item in the first 30 seconds or so, and it hasn’t been loaded yet, would you see a delay of anykind. Otherwise, the load should be able to run asynchronously with your normal scene stuff. (Unity - Scripting API: Resources.LoadAsync)