This is the first episode of my brand new podcast, Be Indie Now! In the show I will discuss topics of independent game development with various guests hosts.
For the first episode, I invited my friends Katherine Harris and Davain Martinez to talk about monetization, specifically the differences between Freemium and Premium, and which one your game should use.
As this is the first episode, I am really eager to hear any and all of your comments, criticism and feedback. We are all new to talking on camera/mic, and are learning and iterating on our process. What did you like about the show?
As I talked about earlier this week, to maximize your success you want to reduce your apps file size by as much as possible.
Apps with a smaller file are easier and faster for users to download, especially over 3g connections, and are much less likely to be uninstalled.
The question is, how can you do that? With the constant drive for new updates in the Apps as a Service business model, it’s easy to get carried away adding new assets and SDKs.
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.
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
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 130×300 uses up the same amount of memory/size on disk as a 256×512 image.
If you take your image assets and combine them into large sprite sheet, you will likely save on overall disk space. One 512×512 or 1024×1024 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.
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.
Take 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 or leave a comment here!
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. Sometimes the game wasn’t that large at release, but they added content over time and the file size grew in equal proportion. 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.
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.
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.
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.
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.
UPDATE 10/25/13: I have created a follow up article with advice on how to reduce file size here.
I wish I could have been there for the whole time, but I had to duck out early to make it to the San Francisco Game Development Meetup‘s monthly gathering. This is always a popular meetup, over a hundred game developers met in the Marriott bar to hang out, talk, and show off each others games.
I had some great conversations with fellow independent game developers (and a few freelancers) while I was there. I don’t always go to this meetup, but I went last month as well, and I enjoyed myself. It’s nice to see such a large group of developers interacting with each other. Although due to the nature of the bar, it’s sometimes hard to get around the room to meet many people.
Also this week was Corona SDKMeetup Group’sMonetizing Cross-Platform Apps panel, hosted at YetiZen. Surprisingly I haven’t visited YetiZen before. They host many events there, but I just haven’t been able to make one until now. It’s a nice space, I appreciated all the art on the walls and the pile of board games in the middle.
Corona ran the meetup, but it wasn’t Corona specific. It was more about monetization of apps in general. The panel had representatives from Inneractive, SponsorPay, Vungle, and PlayHaven. It was nice to see so many competitors sitting together talking about monetization in general, and not trying to pitch themselves as why they are better than one another. They also each have slightly different offerings, and even brought up the fact that many profitable games use services from multiple companies, and they work nicely together.
Those are the San Francisco Meetups I went to this week. If you’d like to meet up with me at a future gathering (or even just one on one), please send me a message and we can work out the details!
The most common mistake I see unsuccessful* developers make is treating their apps as products, rather than services.
Now by unsuccessful*, I mean financially. I hate to classify the ability to make money as a success for a game. There are so many games I would classify as successful that don’t make any money, and likewise there are games that may make some money (maybe not enough?) that I wouldn’t call successful.
Let me try again:
The most common mistake I see unprofitable developers make is treating their apps as products, rather than services.
I just learned about this program and thought some of you might be interested.
AppCampus is a program run by Aalto University in Espoo, Finland to help developers create apps for mobile. It’s sponsored by Microsoft and Nokia, and is taking applications from people all over the world.
Developers can receive $27,000, $68,000, or $95,000 in funding to help develop their app ideas. AppCampus won’t take any owner or equity for this investment, they just require that your app be exclusive to Windows Phone/Nokia Store for the first 90 days. (Afterwards can release cross platform everywhere else)
Cool program, I would encourage you to submit an application! Never know if you’ll get selected and can get some funding to help out your development.
Last week I had the honor of guest lecturing for CIS105 at Arizona State University.
Students created their own apps for Windows Phone 8 and submitted them to the real Windows Phone store. It was cool helping them sign up for DreamSpark and go through the entire development process in just a matter a days. Very inspiring considering most students had not done any kind of development before.
My favorite part was hearing student’s questions after the lectures. There were some good ones! I hope some of the students felt inspired to continue learning about programming and app development.
I’ve never been before, and I am glad I got the opportunity to. It was a fun event with a very diverse variety of people, from students just starting out to experienced industry veterans.
I didn’t get to go to as many talks as I would have liked, but I got to hang out at the Microsoft booth for a bit and talk with people. We had a few different Microsoft devices for people to play with, and let people know about some of our resources such as App Builder, MVA, DreamSpark and BizSpark.
I had planned to just go Saturday and take Sunday off to rest, but I ended up making it back there for a couple of hours on Sunday just because I enjoyed myself so much the day before.
I definitely look forward to the next time I get to visit ASU, and will make plans to attend SVCC 2014!
I was going through my RSS backlog and ran across this blog entry on Gamasutra. Ethan Levy, a monetization design consultant, makes an excellent point about in app purchases.
It’s not just enough to have them in the game, but you have to make them present. Let the user know about them, and why they might like to do so, without breaking the game flow or interrupting their experience.
It was a small-ish group of 30 or so people, which gave me a chance to talk with everybody who was there. Some were showing off their games, and others like me were just there to socialize. I always worry about going to meetups in bars, sometimes they can get really loud and it’s hard to talk to people. 7 Stars was a good venue. It never got too loud, and while I didn’t have any myself the food looked pretty good.
I got there early and stayed late, and when I left there were still over a half a dozen people taking turns trying out a game on the Oculus Rift somebody had brought. I will definitely make to their next meetup on October 29th. If you’re able to get to San Jose I would recommend that you do too!
The other meetup I made it to this week was Tech in Motion’s Mobile Gaming event. Tech in Motion is a group that runs a series of tech related events, from mobile UX design to healthcare. This month’s theme was game development.
This first and last parts of the event were for socializing, including free drink tickets which was rather nice of them. In the middle they had two lectures. One from Nvidia talking about the Shield, and the other from Raindrop Games, a small indie studio that released an (unsuccessful) iOS game. I like listening to post-mortems of projects, both successful and “failures”. You can learn a lot from what doesn’t work. I didn’t agree with everything Josh said, but he had learned some valuable lessons the hard way and was able to realize some of his mistakes.
Many of the people I met there were new to game development. It was interesting to talk to people who weren’t experienced with game dev, but eager to learn more about it.
I like going to new meetup groups. It’s nice to see a mix of new and familiar faces. If you’re aware of any other awesome San Francisco Bay Area meetups I should check out, send me an email and let me know!