Search Unity

How to store and access a large number of objects

Discussion in 'Scripting' started by naked_chicken, Jan 18, 2014.

  1. naked_chicken


    Sep 10, 2012
    Say you have a large number of objects that you need to access at any point in the game but not that you'll need all the time.

    As a simple example:
    Code (csharp):
    1. [System.Serializable]
    2. public class Thing {
    3.     public string name = "NAME";
    5.     public string description = "DESCRIPTION";
    7.     //And a few other variables and whatnots.
    8. }
    10. public class Lib : MonoBehaviour {
    11.     public Thing[] arrayOfThings;
    12. }
    So I put the Lib mono behavior on an object in the scene and in that I put 100 of the Thing objects. Each Thing has a bunch of data that I'll need to access.
    The problem with this (in my limited understanding) is that all those 100 Things will be constantly loaded in memory. So my question is, is there a better way to store a library of data that I can access at any time without having to have a bunch of stuff loaded in to memory all the time.
    I don't ever need to create a Thing at run-time. This is all stuff that I create in the editor and just use to look up data in the game.

    I've used the Resources.Load method in editor scripts before but not in actual game script. I'm thinking this could be a good solution but need to do more research into the overhead of accessing stuff from resources somewhat frequently (a couple of times per "turn" in the game, not every frame or anything so frequent).
    Last edited: Jan 18, 2014
  2. TheShane


    May 26, 2013
    How much memory do these things take up? If your objects are just a handful of strings and variables, each one would only be a few dozen or maybe 50 bytes. You should be able to get close to loading a million (~50 MB) of them before you start running into memory problems (even on mobile). On PC you can probably push it into the billions.

    Is this actually a problem, or are you trying to prematurely optimize things?

    If you are attempting to visualize incredibly detailed real-world data (say, scans of the ocean floor or something), and you're working with gigabytes of data then you'll need a robust system for dealing with that. Otherwise, I wouldn't worry about it.
  3. MDragon


    Dec 26, 2013
    Use ScriptableObjects and Serialization. I'd tell you to Google it, but I JUST got through with this, after days of endless confusion. Read through the following thread (and also I link back to my first thread in my first post if you want to see how I converted it, from something like yours to something like my final product):

    Hope that helps!

    Edit: Also, as a more direct answer..
    If all you need is data, there's absolutely no need of using many gameObjects. Technically, you'd need a database, and if you want a more simpler route, using ScriptableObjects to make .asset files with all that data will help. I currently have one .asset file per world and one .asset file per level in my game.

    Also, you'll have to get creative to access all that data efficiently. Have fun with that part ;)
    Last edited: Jan 19, 2014
  4. naked_chicken


    Sep 10, 2012
    Yeah this is just me preemptively optimizing.

    I actually started out using Scriptable Objects for all my little data objects but from what I saw, making .asset instances of the objects took up more space then just having an array of the objects in one centralized scriptable object. I don't know if/how much overhead is added to a scriptable object if you save an instance of it in your project but it didn't really seem worth it to create a bunch of them.
  5. naked_chicken


    Sep 10, 2012
    So after playing around and running some tests I think I'll go with TheShane's idea of just not worrying about it. In my game I've got one object which holds a few arrays of different data-holding classes and then a few arrays of strings, numbers and whatnot. Nothing major and after making a test that filled it probably more so than I ever actually will, it still only weighed in at about 15kb. And you're right, having that in memory really isn't an issue and working around loading and unloading it with Resources.Load wouldn't gain me much.

    Thanks for the input.