Galaxy Devlog #15 · Read the Galaxy build log
I do not write code and I cannot read it. Call the Cat: Galaxy, the Unity sequel to a game I already shipped, is written line by line by AI agents. My job is to say what I want, set the rules they work under, and check whether what comes back is actually right.
This one is about splitting apart a number before trying to shrink it.
Splitting the cause apart before shrinking the number
The Android AAB measured on August 22, 2026 was 218MB. Instead of “let’s just compress it,” we checked the big chunks inside the install package first. The 218MB and 160MB figures in this post are each dated past measurements — they don’t mean the latest build is always 160MB.
| Largest items in the AAB | Compressed size |
|---|---|
| Game data | 128.78MB |
| Resources | 27.28MB |
| Code | 18.45MB |
| Mobile intro video | 11.26MB |
| Unity engine | 9.24MB |
This table isn’t a complete accounting of every byte in the 218MB — it’s the largest items pulled out of that build. This comparison is exactly why cleaning up code wasn’t the priority. If you’re new to this, the order to remember is: find the big items in the build report first, then separately measure the source folder tied to each one.
The order: install package, source folder, one change, rebuild.
Counting the source art separately, too
Counting the actual source art folder, the main game’s images came to 130 files at 26.00MB, and the mini-game mode (LogMode) included in the game came to 901 files at 51.76MB. Combined, that’s 1,031 files. This is a source-folder measurement as of August 22, 2026.
But a 78MB source folder does not mean the install package shrinks by 78MB — Unity’s re-import, compression, and the AAB’s internal structure all get reapplied.
A measured breakdown of what’s inside the 218MB AAB.
Why we didn’t jump straight to a Sprite Atlas
A Sprite Atlas (a tool that packs multiple images into one for optimization) is a good approach, but it has to match the existing code. That mini-game’s roughly 900 images already had code written around `Resources.Load
Add an Atlas on top of that structure without changing it, and both the original individual files and the Atlas can end up in the build together — which can make the size you were trying to shrink go up instead.
Using an Atlas properly means first changing the loader to be Sprite- or bundle-based — a separate piece of work on its own. So we didn’t build an Atlas at this stage. Not because the tool is bad, but because it didn’t match how the code currently reads assets.
Mobile only, first
The source files were left untouched; ASTC 6×6 compression and a 2048 cap were applied only to the mobile distribution textures. The Steam standalone build kept its original import settings.
The reason we didn’t change art, audio, and video all at once is that doing so would make it impossible to tell what actually reduced the size.
The result: the Google mobile AAB, measured by hand on August 24, 2026, came to 160MB — down 58MB, or about 26.6%, from 218MB. Planet-surface assets were added afterward according to later records, so this number should be read as a result from that point in time. Confirming on-device visual quality on mobile and checking for quality regressions on the Steam original are still separate items left to verify.
Copy this
Follow this order for size optimization.
| Step | Task |
|---|---|
| 1 | Log the install package’s contents by size |
| 2 | Separately count the source folder for the big items by file count and size |
| 3 | Don’t treat source-folder size and final install size as the same number |
| 4 | Change one thing at a time and compare against a fresh build |
| 5 | Check per platform that visual quality, playback, and loaders aren’t broken |
Before adopting a new tool, ask this one question first.
“Can the current code read whatever this tool produces, as-is?”
If the code that reads the asset has to change first, that tool isn’t a simple optimization — it’s a structural change.
What this post is worth
A post that only showed the number 218MB would just be search-engine filler. What actually matters here is measuring where the size is, changing one thing at a time, and checking the tool’s compatibility with the current loader before adopting it. Treating install size, source-folder size, theoretical savings, and a new build’s actual measurement as different numbers follows the same principle.
Next post
Measuring size only matters if there’s a record of what changed and what got confirmed. The next post covers a case where the code was fine, but two events overlapping in the same frame flipped the result.
Solo dev of Call the Cat, shipped after 178 days
on Google Play
and Steam.
Now building the sequel, Call the Cat: Galaxy, in public.