Storage Optimization

So after going over all the New User Experience problems (Navigation, A FUN easy mode, and Improved Tutorials) I was able to take a step back and look at what the project really needed next.

If you're not interested in the technical details and instead want a straightforward update to the project, please see:

https://funkyducke.itch.io/leshy-prelude/devlog/782910/storage-optimization-and-...

Lighting

One of the very first things I noticed was the size. At ~1.8GB uncompressed size, this game was a chonker and really did not need to be as big as it was for the art-style I was going for. So I decided to do a clean build and get a build report breakdown of my game.

The first thing that jumped out to me was the file headers at 618MB. WHAT IN THE WORLD?! There's absolutely no way I have 600MB worth of code, so I had to look at it a bunch more.

After a bunch of digging, turns out that that light baking is one of the primary culprits of massive file headers. I found this odd, as I did try baking the lighting once, but it really didn't improve much of anything so I disabled it once again. Why would it still be taking up so much space if it's not being used?

Turns out, Unity keeps the baked lighting data in the final build even if it's not being used. The only way to truly remove it from the final build was to delete the lighting data that it generates from.  

Just like that, I saved  ~570MB (26% storage savings from the original build). I tested it in-game and there was no noticeable loss in quality either, which makes sense since I decided to rely on realtime lighting anyways before release. 

Meshes

Next thing of note was the meshes... I was pretty curious about this as I did have a few meshes but definitely nowhere near 400MB of them.  Two things stood out to me when I was looking over the build-report when it came to meshes. 

• Several "Built-in Mesh: Combined Mesh (root: scene)" meshes that averaged ~2-5MB.
• Terrain meshes that take up a bit of space too.

First things first, I knew there was a bunch of unused terrain in the intro-level that could be cleaned/deleted. 

The edges of this with the red paint  on mountainous regions were used to simulate far-away vistas, it has quite a nice effect combined with the post-processing and in-game effects. But there were a lot of "in-between" portions that were never visible from within the game, so I just culled/removed them.. Let's see our new build report!

(Oops I forgot to screenshot it so just imagine there's a cool image here)

Turns out, since the terrain was so barebones (No details, trees, just a splatmap with heightmap data), deleting the un-used terrain only saved ~1MB from the final build report. So I decided to take a look at the 2nd mesh issue.

Looking into it, turns out that it stems from the "Static Batching" option during build. 

So to offer a bit of explanation, in-order to save on draw calls, Unity allows you to mark objects as "static". This informs the engine that, if a model and material is being re-used/altered several times, then instead of doing a separate render call once for each model and once more again for each material. It can instead do a draw-call once for one model/material and then save on draw calls by batching the rest of the same model/material. (This is relatively simplified explanation, but should be good enough for the purposes of this devlog)

I utilize static batching and GPU instancing in a lot of places of the game to save on draw calls, like the above rock splines. It would be an absolute killer on the GPU if each individual rock on the trail would have 2 draw calls EACH. But this size thing was an issue...  I found it confusing as I was already technically batching it during runtime by marking everything as static, I thought. 

Out of curiosity I disabled "Static Batching" in build settings to profile the change in performance and size. 

holy moly

405.6MB down to 14.8MB. 

That's a 96% decrease in our mesh size. 

Surely performance is going to take a massive hit though, right?

Well, when profiling on my machine, there wasn't really a noticeable difference. So I guess this just... works? If you wind up testing this and notice a significant decrease in performance, please do let me know. 

Though I'm definitely happy with the new mesh size, so onto the final culprit, Textures.

Textures

So... textures. When it comes to PSX-games, the textures are deliberately low-quality and highly compressed to save space. After going over my build-report, however, I realized that I missed *A LOT* of them. 

There were 4K textures uncompressed just laying around and used maybe once or not even legible with the PSX-rendering pipeline. So what came next was some classical music, a log on one monitor, going through all the textures in my project, compressing them, and finally making sure it doesn't ruin the aesthetic of the game. For every single texture in my project. I usually decreased the size to around ~256-64 and applied crunch compression.

There were certain textures I had to keep at slightly higher res, as they're sort of "fake" pixelated, but needed to be the way they were for the effect I wanted to achieve. But after about 30-40 minutes of this, I was done looking at Unity's import window and decided to generate a build report. *drum roll please*

414.2MB -> 290.2MB, 124 MB or a 30% decrease! That's a pretty significant drop that I'm happy with! (Excuse the mesh size, I think I messed up the order of screenshots 😅)

Final Thoughts

I think I'm pretty happy with the end-result.

Before:

After:

1.9GB all the way down to 710.6 MB!! That's 1.189GB of savings (Or 62.6%!), I can basically fit 2 of my compressed game into my old game, with space leftover! (I'm probably going to use the space for a beanbag)

That being said, I probably would have saved a lot of time, especially when it came to textures, if I had a proper pipeline for importing and processing textures. There's likely still a few textures in the game that are bigger than they should be. And I still strongly believe that there's a lot more space I can save in parts of the game when it comes to audio or textures, but I think this is a fantastic starting point.

Thanks for reading! I hope you enjoyed reading or learned something new during my journey!