Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 30, 2014
arrowPress Releases
October 30, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
File Size, an important factor often overlooked
by Tobiah Marks on 10/28/13 01:21:00 pm   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

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.

Why does this matter?

There are multiple reasons why file size is important for the success of your app.

Downloads

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.

Uninstalls

Even if I'm more likely to uninstall Where's my water? first before Active Fitness because of its file sizeIt'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.

Value of keeping users

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.

What should my file size be?

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.

How can I reduce file size?

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.

Design your assets with file size in mind

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.

Using multiple background images has other advantages, such as parallax scrolling to create perception of depth.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!

Generate assets dynamically

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.

Use sprite sheets where applicable

An example sprite sheetA 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.

Compress assets

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.

Remove junk code

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?

Download new assets from web

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).

Remove temporary files

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.

What did I miss?

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


Related Jobs

Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan
[10.30.14]

Programmers
Blizzard Entertainment
Blizzard Entertainment — San Francisco, California, United States
[10.29.14]

iOS Engineer, San Francisco
DeNA
DeNA — San Francisco, California, United States
[10.29.14]

Software Engineer, Game Server
DeNA
DeNA — San Francisco, California, United States
[10.29.14]

Full Stack Engineer, Games






Comments


David Amador
profile image
Excellent article. I usually have all these concerns, but mostly by a small amount of personal OCD. Never really though the impact it could have on uninstalls, even though that's something I do. Whenever the device is running low on memory there goes those 200MB+ games.

Curtiss Murphy
profile image
Got a solution for texture size? That's the #1 size problem, and it varies by platform. iOS for instance has terrible compression, and doesn't support PNGs, so a UI texture sheet ends up costing 1-4Mb for a 1024x1024! That's a file size killer!

Craig Timpany
profile image
I don't know what it is in your tech stack that doesn't support PNGs, but it's not iOS. iOS apps have built-in PNG support via NSImage etc. XCode defaults to doing weird non-standard things to them to reduce size, but AFAIK that doesn't affect the ability to load standard PNGs.

Curtiss Murphy
profile image
Maybe the limitation is Unity combined with iOS.

Tobiah Marks
profile image
Hmm, iOS absolutely supports PNGs, and I am pretty sure Unity (and Unity on iOS, as well as other platforms) does as well.

What errors were you running into? Perhaps it had something to do with the type of png used?

Michele Kribel
profile image
Thank you Tobiah. Very helpful.

ganesh kotian
profile image
Thank you so much for sharing this post

Lars Kokemohr
profile image
I am afraid the thing about textures being stored in power-of-two sizes is not true (see "Use sprite sheets where applicable").
Using textures that have dimensions that are not powers of two is bad for the performance on many graphics cards. That's why there are engines that optimize textures right away by storing them in power-of-two sizes. Maybe there are some that even store all textures in this enlarged size on the hard disk, so that there's no difference between storing a 130*300 texture (and automatically enlarging it to 256*512) or manually enlarging it ot 256*512, but that's not the operating system's fault.

The difference between "size" and "size on disk" stems from the fact that the start of a file has to be stored in a table of contents for the disk. This start address is stored in a certain format, so there is a limited number of bytes reserved for each address. Therefore it is not possible to adress every bit on the hard disk, so after the end of a file a small portion of bytes is left empty before the next file starts at the next addressable location.
That's the reason why larger partitions will waste more space on small files and why more space is wasted on FAT16-disks (using 16 bits for addresses) than on FAT32-disks (using 32 bits for addresses).


none
 
Comment: