I'm trying to understand how Unity works behind the scenes. Let's say I have a GameObject that has a large number of sprites attached to it in an array (think a deck of cards). Each GameObject represents 1 card.

For simplicity, each card has all the sprites for all the card faces. So it has 52 sprites + 1 for the card back (all in a sprite sheet of course).

If I have all 52 cards placed in the world. Does this mean I have 53*52=2756 sprites, or is there only one instance of each sprite that's being displayed (ie does it only use the resources of 52 active sprites)?

I guess what i'm asking is if I have a bunch of sprites attached to a GameObject, are they all instantiated when the object is created, or are they only created when they are actually attached to the sprite renderer?

Would it be more efficient to only attach the current cards value sprite (ie just the back and the face for the cards value)?

  • \$\begingroup\$ Profile it and find out! Make an empty scene. Run it and see what the profiler says about your memory use. Then add a card referencing a single sprite. Check again. Then add a card referencing all the sprites. Check again. Then add a second card referencing all the sprites. Check again. The great thing about testing stuff like this yourself is that you get verified information for the exact setup you're using - no internet hearsay or ambiguity. \$\endgroup\$
    – DMGregory
    Sep 30 '18 at 20:37
  • \$\begingroup\$ @DMGregory - While I appreciate what you're trying to say, profiling only observes behavior, it does not equate to knowledge of that behavior. Observation can, and often is incorrect (Gee, every time I wash my car, it rains... washing cars must cause rain..) \$\endgroup\$
    – Mr Magoo
    Sep 30 '18 at 23:09
  • \$\begingroup\$ And how do you suppose the users here gained the knowledge they have about working with the Unity engine, if not by observation? Recall that most of us are not the developers of the engine itself. We use the same profiling tools you do to inspect the performance impacts of the choices we make in our games. I'd trust direct observation of a carefully constructed, reproducible test case over "somebody on a website said..." any day of the week. ;) \$\endgroup\$
    – DMGregory
    Sep 30 '18 at 23:57
  • \$\begingroup\$ @DMGregory - There are many ways to get direct knowledge. Documentation from the vendor, presentations by said vendor, books and other sources produced by people with inside access, Decompilation, and many others. Are you seriously suggesting that there have been zero "Unity Internals" training courses? I'm also aware that one can capture the IL2CPP code that gets generated. Regardless, it seems nobody really knows how their tools work in this industry. \$\endgroup\$
    – Mr Magoo
    Oct 1 '18 at 3:10


The answer is going to depend entirely on how you're generating the sprites. If you're doing something like Resources.Load in a single place and querying or assigning them to the array manually, then no, you won't have 2756 sprites in your scene (only 52). e.g. like this.

On the other hand, if you're calling new Sprite(...) yourself and passing in a texture, and doing this in a script that runs on each GameObject, then yes, you'll have 2756 total sprites (and waste memory as they will not die on their own).

I learned this by mistake in one of my own projects where I had a menu that was being rebuilt every frame and invoking some utility code that called new Sprite(...) and Unity would chew through memory like no one's business until finally crashing. Once I was able to isolate the problem to "its this screen..." I was able to locate the errant (and extraneous) UI construction and remove it.

If you're doing Resources.Load on each GameObject then I'm pretty sure Unity caches the results and only creates a single copy (52 sprites not 2756), but I haven't actually tried to break it. With the same kind of code but for Asset Bundles I suspect the same thing, but haven't messed with it.

  • \$\begingroup\$ I'm trying different methods of object creation... I've heard Resource load can be quite slow, more than likely i'll use some form of Instantiate on a prefab \$\endgroup\$
    – Mr Magoo
    Oct 1 '18 at 4:26
  • \$\begingroup\$ @ErikFunkenbusch Resources.Load being slow only matters if you're doing it either every frame (which you shouldn't be doing anyway) or a few thousand times. Once on startup isn't even noticeable. That said, as long as you're either referencing a single location for your sprite references, you'll be fine. \$\endgroup\$ Oct 1 '18 at 14:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.