Memory is the worst
Again, memory is the biggest constraint, so here are some tips to reduce it to target the lowest end devices:
- Initial memory size should be 32MBs - It will grow, but we found low end Android devices didn’t like anything larger than that initially.
- Fonts should be static (Import settings), when its dynamic we observed memory jump throughout gameplay. Keep the compression as low as you can manage and be careful of spacing in the atlas, as it impacts how much shadow/glow you can apply to the font materials.
- Stick to the forward renderer, even for 2D. We’re using URP, but the 2D renderer added so much to the memory usage and we weren’t making much use of its features.
We have a few cool scripts that remove unnecessary packages and optimise all the project settings for WebGL. I’ll share it when we have it a little more polished up as its genuinely useful and an amalgamation of currently available open source scripts.
Asset Bundles!
Depending on the size of your game, they may or may not be useful. But odds are, even if your game is small, they will be.
The main advantage is that time to first interaction, Unity loads everything in the build on launch. This can, especially on mobile, cause significant stutter. Users might think its broken. Splitting all your assets into a bundle allows Unity’s build to load really quickly, as its super lightweight. The Bundles can then be downloaded and loaded after which we’ve found to be so fast you don’t even notice it most of the time.
Our games are small, so we tend to get away with 1 (well, two, because scenes and assets can’t be in the same one) bundle for the content. But this allows us to also do some cool things, like swapping the bundle out to change content without updating the build.
The upside for larger games is now you basically have direct control of whats in memory at any one time. You can unload unneeded assets and stream in the next ones.