Best practices when dealing with many high-res animations?

In my game, there are a large set of high-res animations for each player/enemy combination. To provide come context, I expect the total size of the animations for my game (after C3 processes them) to be upwards of 1gb.

I currently have all the animations in a single "player_combat" sprite, that I place when and where a combat occurs. I only have one instance of player_combat that I make invisible when not in use.

This is convenient because I have all the animations in one place, and can easily copy animations, image points, and collision polygons between different "enemy" folders in the object's animation page. However, C3 is taking a long time (several seconds) to instantiate the object at the beginning of the game, and I believe it's because of the number and size of the animations it contains. My C3 editor is running slower these days as well, especially when opening the animations dialog for any sprite object, and I'm wondering if the size of player_combat and its large animation count is contributing.

I'm thinking it may be more efficient to separate the "player_combat" sprite into multiple "enemy_combat" sprites, each of which only contain the animations for that enemy. Seems logical that these sprites would take less memory, and even if I have 1 of each instantiated all at the same time, the combined performance hit would be no more than a single player_combat sprite.

I want to run this by the community before I go down this route, because if it turns out to be a bad idea, going back to a single player_combat sprite would be a lot of work (I'd have to recreate all the collision polygons for each animation since there's no way to transfer those from one sprite to another).

So my question is: is separating the "player_combat" sprite into multiple "enemy_combat" sprites a good idea for this situation? And are there any other best practices I should keep in mind with large numbers of high-res animations?

Thanks

Before

The important question is how much memory your animations require. You can estimate this by placing the player_combat sprite on an empty layout and then run this layout in Debug Mode (Shift+F5), or check Project statistics.

If the sprite alone is using 1GB of ram or more, you should optimize it. Reduce the number of frames and the size of frames if possible. Crop any empty space from the images.

For example, if you have an animation with 100 frames and 1000x1000 px images, this animation will take ~400MB of memory. Reducing images size to 600x600 px and the number of frames to 50 you can save ~330 MB!

Splitting the object into multiple sprites is also a good idea, if you don't need all these animations at the same time in the same layout. For example, if there is a boss enemy which you only need on the final level of the game, it should definitely be in a separate sprite.

Combine all enemy sprites into Enemies family to optimize your events.

Reducing images size to 600x600 px and the number of frames to 50 you can save ~330 MB!

If memory optimisation is important, I'd recommend going a little under a power-of-two size - in this case 500x500, as it is a little under 512. The reason for this is the images are packed on to spritesheets that are a power-of-two size (2048x2048 by default) with a couple of pixels padding. Images just under a power-of-two size pack much more efficiently on to spritesheets, as more of them can fit on a single sheet. For example a 600x600 image can only fit 9 times on a 2048x2048 spritesheet (3 in each direction), but a 500x500 image can fit 16 times on a 2048x2048 spritesheet (4 in each direction).

In my game, there are a large set of high-res animations for each player/enemy combination. To provide come context, I expect the total size of the animations for my game (after C3 processes them) to be upwards of 1gb.

It's hard to say without knowing what kind of game you're making, but you might want to look into a paper doll system. If you've got PNGs for every combination of player and enemy, your memory consumption will increase multiplicatively (or maybe exponentially?) if you ever want to add new enemies.

The images directory of my project is 1.1gb. Why does the profiler show 3700mb for images? 3700mb image memory is for uncompressed images.

PNGs are technically compressed; if I remember correctly they take up 4 times as much space in-game. They're also existing in your GPU's dedicated memory. Keep an eye on that under the "Performance" tab of Task Manager in your benchmarks as well.

Your best bet is to split everything into as few sprites as possible and get really creative with load/unload system actions to keep memory usage low but keeping gameplay smooth.

- x=1: profiler shows "Est. image memory = 3700mb"

3700mb image memory is extraordinarily high. Many systems will fail to run the project if it uses that much memory. You should try to reduce it to a quarter of that or less. It's an old blog post but there's still good advice on using images efficiently in Remember not to waste your memory.

Why does the profiler show 3700mb image memory if Task Manager is only showing .8gb usage?

Memory usage accounting is actually very complicated: GPU memory is separate to system memory, and I don't think Task Manager includes GPU memory at all; browsers are multi-process architectures and memory usage can be distributed across different processes; and shared memory can be accounted for in seemingly unrelated processes or even double-counted depending on what you're looking at. It's best to go by the numbers Construct tells you, as it knows what it's loaded.

The images directory of my project is 1.1gb. Why does the profiler show 3700mb for images?

Images are always decompressed in memory. See Memory usage in the manual for more details.

Thanks everyone, this is very helpful. The 2 articles mentioned provide great detail and I have a strategy now to deal with this. Luckily I'll be able to break up the sprite into a number of smaller ones, and I only need a few per layout. I'll also work to reduce the overall image size and crop the dead-space around the images.