Monster sized apps
This article is assuming that you are using CoronaSDK, and also assuming that we are talking about the iOS outputs only for the moment.
1. Add on Libraries, earlier about a year ago, OpenFeint was the favorite Add-on from AnscaMobile, so if one used the GameEdition, OpenFeint was added to the final app. Almost like a Happy Meal, where you get a side serve of Chips and a Soft Drink with your burger. This used to add about 8MB and a whole lot of files and nibs, etc to the final app. It was a great thing that Ansca removed this and made it conditional, so now *only* if you require "openfeint" then you get the whole whizbang added to the app.
2. The current favourite with AnscaMobile (at the time of writing this article) is Virtual Currency, so there is an add-on of resources from the Virtual Currency, irrespective of whether you use it or not. This does not add 8MB to your final app, but still does add quite a bit of *un-required* files
3. Sound (mp3 files) If only there was a library that could help create pulses and tones like in the older 8-bit computers, even BEEP from the spectrum was good to make sounds from the games. So the apparent lack of a sound making/music library, MP# compressed sound is added to the apps, these are on an average about 500K to 1 MB each, so if you have like even 5 sounds, there goes an additional 5 MB. There are quite a few articles on how to have procedural music, in fact I recollect around 2000 there was a format like MIDI that allowed to create wonderful compressed music (audio, not voice) where a 10 minute high quality sound could be compressed in about 200K
4. Graphics, now the whole revolution, shift in computer games have changed from 8-bit graphics using a combination of 8 colours to a palette of 24-bit true colour with alpha blending, and given the increasing resolution of the devices, the size of the images are increasing too. Simple case scenario, a 1 pixel by 1 pixel image in true colour had 4 bytes representing that one pixel, so the colour data in the file is 4 bytes per pixel. So for a simple graphic of 320x480 the size of the data is 600K, and for a HD, 960*640 it is 2,400KB or about 2.3 MB. So in a simple game if there are let's say 6 screen elements, including a splash screen, for the 320x480 that is approximately 600K * 6 = 3.6 MB and the HD version is 2.3 * 6 = 14 MB now you can see how the size of your app is growing without doing much really...
So, the question is How to reduce the final app size?
There are a few ways to manage that,
Point #1 and #2 are dependant on AnscaMobile because as a developer you do not have the option to not include the files.
Point #3, can be managed better by optimising the music/sound that you require by reducing the bit rate, or having smaller samples, if you are using a musician to help with the sound, get them to create music that can be looped seamlessly so smaller samples can seem like a long piece. For FX sounds, you can also convert the stereo sounds into Mono if they are just Bangs, bing, whizzes, etc.
Point #4, This is the main highlight of this article, this is what prompted me to write this article really. If you want to support both, HD (Retina) and the normal graphics, then according to Apple, the developer is supposed to have two set of graphics, one for the lower res and the higher Retina display. So for a simple game as in our example above, the graphics would be about 17-18 MB with support for both. In my games, the graphics do not take up so much space, but support all three, the iPhone, the iPhone4 and the iPad as in RetroBalls. The total size for all the files for Retroballs is about 4MB, the largest files in the app are a sound file (because it was left in wav format instead of MP3) at 1.1 MB and the default.png file at 971KB which is used multiple times over in the project and is of the size 960x640, the next few files are mp3 and wav files from 315KB to 45KB, in fact the openfeint and facebook buttons are 70-80KB. These were created from Photoshop, and I just realised while testing a theory to write, that if I open the resulting file in Preview and use the Adjust Size option and make no changes, and save the file, the size of these 70-80 KB files are reduced to 4-8 KB. Look for the Resulting Size information, in the cases where the size is smaller than the one in finder, you have some definite savings.
Another thing that I can share is that all the graphics that I make are generally created for Retina Display, so that I get a good crisp output on iPhone4 devices. A custom Font was used so that it would reduce the requirement to have graphical buttons, and now in the new daily updates, CoronaSDK has tinting and gradients, which can help create even better graphics without relying on images alone. I had to re-colour the balls in Photoshop in different colours, now that can be achieved from within coronaSDK via code, this would have saved me about 12KB per color on the final app and lots more in memory.
The reason that I create my graphics for Retina are similar to the simple idea of RetinaText that many developers use in CoronaSDK. For those that are not aware, it is simple, the developers create the text at double the required font size and then scale it to half the size. Now think of that, 960x480 is double of 480x320, so why can we not scale the graphics to half the size? Which means we an work with the larger graphic and scale it to half and achieve the graphics for both. There are definitely some issues in this technique, think of it as pixel halving, or interlacing, let's say that by scaling it by half, every other row of pixels are displayed, so unless you have graphics with thick lines, some of these can disappear if they fall in the rows that are not displayed.
How to do this?
Here's how to manage this,
The way I have been using it, is using the scaling in the code, which means every line in code that deals with graphics has to have a scaling algorithm, this is fine on the iOS, but I *guess* this causes some issues with Android devices. I mean if people have Androids that cannot have a decent processor, why even bother with Androids? Right??
The other way where it should have been managed by itself *could* be to set the size in config.lua where the size can be set to 320x480
Hope this helps you in your projects too and helps you reduce the size of your output apps. Imagine the near future when iPad get retina and had a screen resolution of 2048 x 1536, that would be about 12MB each. That is about the size of what I see on my iMac 27" and that screen real estate is no joke, really. So if you do not start managing your app sizes now, you might end up with issues soon. Plus everytime you update your app, imagine pushing a CD to the users to download. Those apps never get updated on my devices and if I do not use them often, they do not even remain on my device.
Picture Source : Daily Monster
I want to point out, to avoid any misunderstanding, that midi is NOT a format meant for compressing high quality audio to low files sizes. It is simply a container of data (note down, note up, velocity of note, not length, which note, etc) that can be previewed via the system default midi synth. This means that not only is it a data file not suitable for playback, it will not sound the same on all computers and may very well not even play on some devices if they don't have the support for it. It is not an audio file, that's why it is so small. For lack of a better comparison think of midi files as xml files, data only. :)
I am aware about MIDI being a representation of the notes, I believe that it must have been misunderstood by you or the reader when I said " a format like MIDI", I mean it was a format like MIDI, where the notes were represented but of compressed samples than just representations, slightly better than the MOD/STM, etc formats (I hope you are aware of what I am talking about here)
I am unable to get the name of the program and the file format, I need to search all my archives to see if I can find any apps/data from my Windows days ;)