Spritesheet Question

The auto sprite sheet feature sounds pretty neat but I don't understand how it actually works for managing memory. In the blog post I see a sprite sheet with 2 enemies and bullets in it, which is great if they are all needed on that layout. But what happens if you need them separated because those 2 enemies don't ever exist together?

For example, in my current game I have a lot of death animations for the player. Each animation is a different sprite objects so they exist on separate sprite sheets. When the player dies, I spawn one of the death animation sprites.

This way I don't load 10 different death animations into memory that aren't needed. Will the system in C3 automatically lump all the sprites together into one sheet? Is there a system to tag objects that can be spritesheeted together and separate others? Or am I completely confused about whats happening?

I was also asking for this sort of feature. In Aseprite you can create tags for animations and exported as metadata in the form of a .json file.

Something similar could also be done inside C3 in which as you said, you create tags for animations and only the tags required are loaded.

It's a shortcoming of spritesheets that you can only load entire spritesheets in to memory. In the extreme case there would be all content in a single sprite sheet, and you therefore load all content in to memory at once. However spritesheets themselves save memory by packing multiple images together, and they tend to be fragmented over a set of different spritesheets anyway. For example one of the demo games we test with is very large, and still uses 100 sprite sheets, which allows for quite a lot of granularity around what is loaded.

TBH unless your player animations are absolutely huge with loads of frames, splitting things out in to separate objects is probably a micro-optimisation that doesn't make much difference. It also can jank the game as it loads textures mid-frame if the object isn't already preloaded by being placed on the layout. And currently the engine doesn't release textures until the end of the layout, so the peak memory usage will be the same.

I don't think the spritesheet system will cause any memory issues, but if there are cases where it causes a problem then we can look in to figuring out how to address that. If we had to do that, I'd try to avoid any kind of manual configuration, the groupings can probably be determined by which objects are used together on layouts.

That seems like a crippling feature of C3 to me. I guess I just can't imagine not managing and optimizing graphics assets. Why would I want to load frames from a giant boss creature when I want to fire a bullet that may be auto sprite sheeted into the same texture. For another example, in my game I include a bullet graphic plus fx for the bullet all into the same sprite object so they will be in the same sprite sheet at around a 64x64 texture. In C2 I can load that on the fly no problem. No jank. In C3, if the system decides to split that off into different sprite sheets, then it will load in a sprite sheet that could be 1024x1024 for the bullet, then it might need to load in even more large sheets to get the other bullet fx in. Wouldn't that also be more jank?

TBH unless your player animations are absolutely huge with loads of frames, splitting things out in to separate objects is probably a micro-optimisation that doesn't make much difference. It also can jank the game as it loads textures mid-frame if the object isn't already preloaded by being placed on the layout. And currently the engine doesn't release textures until the end of the layout, so the peak memory usage will be the same.

I am probably in the minority, but I am working on a larger game with lots of animations in larger layouts. I depend on being able to smartly load in textures. Peak memory usage would not be the same, because as in my previous example, instead of loading in 10 death animations, I only load in the one that I need when it is needed. I never need all 10 death animations. Also there is no jank, even if there was, it wouldn't matter that there's jank when you die.

I also don't understand all of this jank concern. Ori and the Blind Forest had jank when you got to new areas because it would stream them in instead of loading. Who really cares? Feeling like you were in a huge connected world was amazing. As long as you smartly load in textures in areas where it doesn't matter, the majority of the gamers won't mind. I guess thats personal preference though

I've already had to make changes to my game design because I can't have large layouts (due to not being able to unload graphics.) .

The current spritesheeting method has worked fine for some of our large test games - but as I say if there are any issues we can make some changes. We'll see how it goes in the public beta.

Jank has in the past been a major concern for a lot of users. So we have carefully designed the engine to pre-load all the textures it needs based on what's placed on the layout. If you don't care about jank, we still have to design the engine for people who do.