May 27

Small game downloads

Small GamesA lot of people wonder how do we make our game downloads so small. Magic Match installer download with everything including all 7 cut-scene songs was 6,5 MB and our upcoming game Ancient Quest of Saqqarah which is packed with high resolution graphics is only 25 MB. It is easy to find games with far less content that are much bigger in size. But is shrinking the games to the largest possible extent worth the effort? After all broadband connections are more popular with each day and portals often sell games which are more than 100 MB.

According to our knowledge, the size still makes a huge difference. Statistics tell us that every minute 50% of the users brake the download. The effect is that smaller games can sell better even with worse conversion rates in comparison to games with excellent conversion rates which have a poor number of completed downloads. Magic Match is a good example of such a game – the CR was not so good (about 0.7% on most portals) but at that time the game outsold the competition with huge numbers of completed game downloads. There were two reasons for this – the game looked good and intriguing on the screenshots which encouraged downloading the game and the download size was very small and that affected the number of completed game downloads. According to some recent statistics I’ve  seen on the Indiegamer developer forums the sweet spot for games is currently at about 25 MB and slowly getting bigger.

The size of our game downloads is a direct effect of us obeying several simple rules.

No redundancy

It’s just like with optimizing your source code for speed – the best possible optimization is to get rid of the Khufu Textureslow code in the first place (the fastest code is the one which is not executed). Storing several graphics which differ only in hue is a waste of space, because such altered versions can be computed by applying filers at runtime. Also when storing animations there is always the temptation to save them as movie strips or consecutive frames of the same size. This can be easy to produce and to code but it’s not optimal as most animations have very little differences between frames. A good example is an in-game 2D character with blinking eyes. You could choose the easy path and store two frames of the whole character, but this of course would be a terrible waste. On the right you can see a part of the texture from Saqqarah with animation sprites for Khufu, the magical monkey from the underground oasis. 

Reuse, reuse, reuse, etc..

Khufu TextureWhen brainstorming new ideas at Codeminion we always give preference to options that include reuse of the assets we already have. This has many benefits including smaller game size, less work and coherent look and feel of the game. Of course it’s even better when planning ahead with asset reuse in mind. Let’s take Saqqarah GUI (graphical user interface) as an trivial example. There are many dialogue frames, option windows, message boxes, etc. in the game and it would be an awful waste of space if we decided to make separate graphics for each one. Rather than that the GUI is broken into small building block sprites and assembled at runtime. Many developers use similar techniques but still you can often see games with full bitmap screens for GUI windows. 

Every bit counts

Games consist of hundreds of assets – be it graphics, sounds or functions. When adding an asset to the game you’re tempted not to optimize it. After all 2 kilobytes won’t make a difference, or will they? 2 kilobytes won’t make a difference but 2 kilobytes shaved off all several thousand files will make a huge difference. Many a pickle makes a mickle.

Use right assets from the start

We hate to use temporary art when developing our games. Sometimes there is no other way and you just have to insert some placeholders here and there, but if you can avoid it I advise you do it. It’s good for prototyping, but it’s bad for the final size of the downloadable game. When replacing placeholders with final art you won’t be eager to rebuild your textures from the scratch. The resolutions of the final graphics will be in most cases different and the numbers of frames will also vary. Having to rebuild and optimize texture space for reuse and getting rid of redundancies in the final phases of the development will always be tedious, slow and will introduce a lot of new bugs to the game. On the other hand making it right from the start will make the whole process transparent and unobtrusive.

Know your compression

Compression is a quick way to save lots of space but the real challenge is finding the best possible compression ratio for your game without introducing any visible our audible artifacts. At Codeminion each file in our games is compressed separately to determine the best possible compression level. For lossy graphics compression we use the JPEG 2000 codec and we use uncompressed TGA format for files that can’t be changed. You may be wondering why we use the uncompressed TGA format instead of other lossless formats like PNG. This is because the entire game is compressed using a lossless scheme (LZMA) when creating the installer. Compressing PNG files will only make them larger while TGA will be properly compressed and smallest possible size will be obtained during the creation of the installer. What is also interesting is that we use lossy compression on most graphic files and that it includes the alpha channels. Somehow many developers refuse to compress the alpha channels with lossy compression and I really don’t why that is. What’s more, we have even discovered that we are able to apply more compression to the alpha channel than to the color channel and still have acceptable quality levels. When it comes to game audio we store all files in the excellent OGG format.

Here are some links to tools that we use:

In case you know any other tips to make the games smaller, do not hesitate to share them!


Related Posts

Leave a Reply