Abstract

We achieved a massive reduction in the size of our game app Flipping Blocks, which was developed on the Unity platform.

Here’s a summary of the measures and the corresponding reduction in download size:

Measure

Before

After

Saving

Reduce the size of the graphical assets

105MB

79MB

26MB

Build for ARMv7 only

79MB

70.5MB

8.5MB

Remove unused assets

70.5MB

67.5MB

3MB

Use language dependent asset bundles

67.5MB

25MB

42.5MB

TOTALS

105MB

25MB

80MB

Gory details below.

Background

Flipping Blocks is the best casual smartphone game there is. Yes, we’re biased. And it has to compete with hundreds of thousands of other smartphone games.

So we don’t want to have anything scaring people off from downloading our app, they just have too many alternative choices. One thing that puts people off installing is a big download. You’re about to download some game and you notice, “Wow, it’s 90MB, I don’t really have that much room and I can’t be bothered to make room”, means one player and one potential source of revenue lost.

Flipping Blocks had a pretty big footprint. The APK, the file you install on your Android phone, was originally over 105MB. After decompression and installation on the smartphone, it would bloat out to as much as 384MB.

Not a problem on a phone with 64GB of memory. But what about all those small phones with 8GB? There are a lot of them out there. My wife has one. The phone is always chock full of photos and videos, although she transfers them to the iMac regularly. I spend a fair amount of time clearing app data and deleting superfluous apps to make room for important stuff – like Flipping Blocks.

So it was time to take the knife to our beloved game.

What did we do and what did we achieve?

Reduce the size of the graphical assets

The buttons used in the game are all graphics. This is because each word (like “Cancel” or “Menu”) is made to fit into the oval area of button, so the beginnings and ends of the words are small, the second and last but one letter are a little bigger, the third and last but two a little bigger again and the letter in the middle is the tallest. Here’s the menu screen so you can see what I mean.

I wasn’t able to find anything on the Asset Store that enables you to achieve this effect with plain text, so Mike had to produce an appropriate graphic in Photoshop for each and every button – in seven languages.

We found an online tool called TinyPNG (https://tinypng.com). Mike was so impressed with it that he bought a license for the Photoshop plugin for $50. It reduces the size of the graphics by up to 80% without any noticeable change in quality.

This took us from about 105MB down to 79MB.

Build for ARMv7 only

The original build was for FAT (ARMv7 and x86). This is set up in the Build “Player Settings“ / “Other Settings” / “Configuration” section.. Now, the Intel x86 CPU family has only 1.3% of market share (http://hwstats.unity3d.com/mobile/cpu.html). I checked the stats for Flipping Blocks and found that none of our users has an x86 CPU. So I changed the device filter to ARMv7.

This took the APK size from 79MB to 70.5MB.

Remove unused assets

You probably know that anything in a Resources folder is loaded into a build by Unity regardless of whether it is used. It’s necessary to ensure that there is nothing superfluous in the Resources folder. If there’s anything there you don’t use, throw it out, because Unity won’t do it for you. Your app may contain several Resources folders, e.g. plugin examples often have a Resource folder. After throwing out quite a few unused resource files including a bunch of tutorial graphics that we didn’t use any more, I managed to get the size down by another 3MB to 67.5MB.

Asset bundles

One aspect that obviously needed to be addressed was internationalization. We had around 70 graphical assets, mostly buttons. Each of these was present in 7 languages: English, German, French, Italian, Spanish, Chinese and Japanese. Each language’s assets added about 5MB to the size of the build. Most users will only ever use one language, and that is the one set for the phone as a whole.

I created asset bundles for each language. Each relevant asset must be assigned to an asset bundle.

Each asset bundle averages just over 5MB. The German asset bundle is called de_assets, the French one fr_assets, and so on. These were uploaded to the game’s server.

If you’re interested in the details of building and integrating the asset bundles, let me know, and I will post separately about it. Some things I’d like to mention:

Frank at Inter Illusion helped me to patch the superb I2Localization software to complete this solution

Unity will add the files to the build even if they are in asset bundles (at least this is the case when the assets are kept in a Resource folder). I prevented them from being added to the build by removing the read permissions on the language specific folders (“de”, “fr”, “zh”, etc.) before building the APK. On OS X or Linux you can do this on the command line with “chmod –r de fr …”

Asset bundles are kept on a server in the Internet. If the smartphone has no Internet connection the first time the app starts, the language specific assets are not available and the English assets will be used. Some coding is necessary to handle this.

Asset bundles are platform specific. Separate asset bundles must be built for Android, iOS and the Editor.

I didn’t make an asset bundle out of the English assets. These are always in the build and are used if the user’s language is not available in Flipping Blocks.

To cut a long story short, this measure reduced the size of the APK from 67.5MB to 25MB.

Altogether we got rid of 80MB out of the original 105MB. The footprint once installed on the phone has gone down from an occasionally observed 384MB to under 50MB.

We consider this “good enough” for the time being, so we’ve done no obfuscation or application binary splitting (.apk + .obb).

Next steps

The next step is to merge these changes back into the iOS branch and reduce the size of the IPA file, which is currently at around 75MB.

We hope you enjoyed this post. If you have any pointers on how to improve on what we’ve done, please comment, we’re always more than ready to learn. Thank you for reading.