Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
Pay close attention to the file size of your apps. The difference between a few megabits may be thousands of installs (or uninstalls prevented).
The question is, how can you do that? Here are some ideas to help reduce your size.
When making the executable for your app, pay close attention to your file size.
When you compile your code, images, sound, videos and other assets all together, your apps can easily become quite large. I've seen too many games that sit in the 250mb to 2gb range. Some games need that much, but many could be done very similarly with a smaller size, if they just put a little extra effort into it.
Sometimes the game wasn't that large at release, but with the "Apps are a service" business model the content grew over time and the file size grew in equal proportion.
There are multiple reasons why file size is important for the success of your app.
No matter what, if you have a large file size you're imposing requirements the user may not be willing or able to overcome.
Users will judge the value of your app, and only download if it's greater than the additional "cost to entry" requirement. First, they have to get access to WiFi. Second, they must have enough room on their device. The second could be harder to get than the first, depending on exactly how big your app is.
For whatever reason, let's say they cannot download your app at the moment. If they liked your app enough to want it in the first place, that extra "cost" pushed them over the edge to decide to not buy it, losing a customer. Even if they decide to "get it later", they'll resume going about their day, and by the nature of people naturally they're likely to forget about you. Never making the time to go back to the store later and download.
Again, you've created a friction point and lost potential customers. Or worse, and most likely, they won't look at the file size requirement before purchasing. When they realize they aren't able to use the app they just tried to download (possibly paid money for!), they might decide to rate you poorly on the store in frustration. Even if they haven't actually used the app yet.
It's one thing to talk about file size in terms of being harmful to the struggle to get a user to download your app, but it's equally important for preventing uninstalls afterwards.
When I run out of space on my phone, first thing I do is look at my apps sorted by size. If you're app floats to the top of that list, you're that much more likely to get uninstalled. Even if the user overall likes your app, if they need the space that may not enjoy your app enough over being able to fit more mp3 files or other new apps on their device. If you're one of the smaller file sizes, at the 3g download level or under, the user has to scroll way down their list usually to reach your app.
Your competition, other apps that are larger than you, become much more appealing targets to uninstall first, even if they use them more often than yours. If you're app is 25mb and theirs is 100mb, I would rather have one app I kinda like + 1-3 other apps or files I may enjoy than one 100mb app I use semi often.
Even if you're a premium app with no in app purchases or ad revenue, active installs matter. Users who don't keep your app on their phone will harm your business. With every uninstall, you're losing potential:
Marketing. Users often find new apps by observing which ones their friends/strangers use or have installed on their devices.
Recommendations. Users are more likely to recommend an app to a friend if they use it/keep it on their phone constantly.
Ranking. Active installs probably plays a key factor in app store rankings. Also, long time users are more likely to positively review the app, which will also help your rank.
Future Revenue. What if you add IAP some day? If they no longer use your app, no longer a potential customer of new content.
Future Apps Success. It's a lot easier to advertise a new app to an existing user base of an older app.
Just to name a few.
For mobile platforms, I would highly recommend you to make your best effort to fit your app under the cellular download limit.
Depending on the persons carrier, plan, and which store they're downloading from, that could be anywhere from 20mb to 50mb. That may not sound like much, but I assure you, there are many complex apps with long-lasting meaningful content under 50mb. Unless your app is asset heavy and hours long, users aren't very tolerant of large file size.
Yes, there are some kinds of games can get away with larger file sizes. If you're a premium game (especially if you cost more than $3) and/or target core gamers with realistic 3d graphics, generally users will be more forgiving of larger file sizes. Only if it's warranted.
The difference between 48mb and 75mbs can easily be thousands of installs (or uninstalls prevented). Take a second look at your app before shipping it. Can you reduce the file size? It could be worth the extra time and effort to decrease the size as much as possible before you ship. Here are some ideas to help reduce the size of your app.
When you design elements of your app, keep in mind what needs a unique asset, what could be generated on the fly, and what doesn't need to be there at all.
Sure, that fancy menu border might look cool in the concept drawing, but would a simple beveled edge look almost as nice, and take up less texture files?
Small, repeatable textures can replace larger background image file. When you have a large asset, ask yourself, can you break it up into smaller elements? If so, perhaps you should use repeating textures instead.
If your game has a huge image of a grassy plain, mountains, and a one little house on one of the mountains. Try instead making a repeatable texture for each element. The grass, the mountains, and then a tiny image for the house. If you break up the image into smaller pieces, then assemble them in code, you can make them look like a larger more detailed background without using any large asset files.
You can even recycle elements when creating new areas. For example, the desert zone can use the same mountain textures as the grassy plains. Not only will you use less file space, but you'll also be able to create new content faster and cheaper!
It makes sense an important button would be highlighted/look different from others. But does each kind of button need a unique image?
Could you have a grey "template" button and in the code recolor it to create differentiation instead?
Background music for games can also be a huge hog of disk space. Yet, you don't want the same 30 second loop to repeat over and over and drive players crazy. Try layering your music. Have various 30 to 60 second "base" loops (Ex. base/drums) and then randomly layer on 15 to 90 second "tunes" (Ex. guitar/sax/whatever melody) on top.
That way, the player will hear a randomly generated "song" each time they play. It may have repeating elements, but the unique way it's continuous streamed together will (hopefully) be good enough to keep the player's interest and make them think the music tracks are longer than they actually are.
A sprite sheet is a collection of sprites (aka, image assets) placed together into one larger image.
Why is this useful? A couple of reasons, but for our purposes, it's because of powers of two.
Computers are binary, and file storage is all based on powers of two. 16, 32, 64, 128, 256, 512, 1024, etc. If an image is larger than a power of two, it uses up the same amount of space in memory as the next power of two.
Try looking at an images properties, you'll see two values. "Size" and "Size on Disk". An image that's 130x300 uses up the same amount of memory/size on disk as a 256x512 image. If you take your image assets and combine them into large sprite sheet, you will likely save on overall disk space. One 512x512 or 1024x1024 sprite sheet is big by itself, but could potentially be much smaller than the sum of its parts.
This method does need more work on your part. You will have to write some extra code to render the sprite sheet, only using the appropriate region of the image for each asset/texture. The rewards don't just end with file size however. When done correctly, this will also save on the number of draw calls being made to render the scene, giving you better performance as well.
Use the compression format that makes the most sense.
JPGs are great for heavy compression, although they are notorious for artifacting. PNGs are great for sprites, as they allow transparency, however make note if you're using PNG-8 or PNG-24. PNG-8 allows for up to 256 different colors, and PNG-24 supports up to 16 million.
The question is, do you need all 16 million colors, or can you make your asset look nice using only 256? It isn't wrong to use PNG-24 (or even PNG-32 if you need per pixel alpha transparency), just make sure you aren't using them when a more compressed version would look just as nice.
Also, remember to crush them.
It seems like every advertiser out there wants you to integrate their SDK.
"Get set up in five minutes!" they'll claim. Well, that's right, but often you aren't using 100% of the features they offer in their platforms. Most of the time in my experience, you just end up using one aspect of their framework.
Consider using ad mediation to reduce the number of SDKs you need to import.
ake the time to go through their SDK and look at what you really need. Can this be simplified? Can whole files and assets be removed if you're not using them? Some times, some frameworks will bundle in whole SDKs you aren't even using at all, can you remove them completely and still have your app run fine?
I like to call this "Cheating"!
Sometimes I've downloaded a game under 25mb, then when I open it up it wants to download "Extra content" at each new area. Suddenly, it becomes a 100mb+ game on my device!
Don't get me wrong, cheating is a good thing! Well, at least, it isn't a horrible idea. Allow players to download and do something with a small download, then if you can't live without those extra assets, make the player download them before going to new areas.
If the player hasn't unlocked or doesn't want to visit the Jungle world, don't download those assets. This allows the player to get going faster, and the app size to scale with the content they're actually using rather that every potential place they could go to.
However, there is a major problem to this. It requires an internet connection to unlock new content. This could cause horrible player experiences if they don't want to use up their 3g bandwidth bill, or don't have access to WiFi. When a players forced to download something and they can't or won't, they may rate the game poorly due to "Lack of content".
I would only recommend doing this if it's completely optional game content, or if your game already requires an internet connection (like a multiplayer only title, or only download during an in app purchase).
Speaking of downloading extra content from the web... When you're done, clean up after yourself.
If you app is ever generating or downloading files (Save games, internal images/screenshots, extra data, etc), keep close track of them. Likely, your users will never notice or care until one day your apps ballooned to such a huge size it ends up first on the chopping block when they go to uninstall.
Pay attention to what files are necessary, and which can safely be removed. Have code to clean up temporary files, even if the app crashes/was suddenly closed last time it was used.
While testing you may constantly install, uninstall, and reinstall your app again, but in the wild a user will likely only install your app once per device they use. You don't want to accidentally bloat over time.
I hope this advice was helpful to some of you! I'm sure there are lots more tips and tricks out there for reducing file size. If you know one that I neglected to mention, please send me a message! If you'd like to read more of my writings, you can find me on my blog (where this was originally posted) at TobiahMarks.com.
-Tobiah
Read more about:
Featured BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
