Experiences of the best mobile game studios indicate that game sales is linked to the quality for even the simplest games. Attention to details, sophisicated game play and superb graphics make a big difference. However to make such compelling games you will need to work against the size constraints.
To maximize size it is typically an important strategy to sell a game on as many carriers in as many countries as possible. Many carriers today still impose maximum size limits on their gatway. Some typically limits are 100kB, 150kB, 200kB, and 300kB. Even if your application fits into limits imposed by the target handsets, its distribution potential could still be limited if it exceeds the gateway limit.
Many of the most popular handsets today are mid-end and low-end handsets with quite severe size limits. For example Nokia series 40 handsets have 64kB or 128kB JAR size limit.
In emerging markets such as China and India, the cost of handsets is a key consideration for consumers. Low end handsets are likely to have an enduring presence in these markets. Can we afford to ignore these emerging markets? Today there are over 330 million mobile users in China, tomorrow they could be playing your games. In China 85% of the mobile games sold are for Nokia series 40. Nokia series 40 imposes a midlet JAR size limit of 59kB in China.
Due to the consumer business model of most mobile operators, they have a vested interest to have a mobile game available for multiple handsets. In fact most operators require games in their catalogue to support most of their handsets, including low end handsets such as Motorola triplets and Nokia series 40.
So where do the bytes go?
For a typical mobile game for Nokia series 40, resources such as graphics and sound files typically occupy 32kB. Java classfiles encoding the game logic occupy the remaining 32kB.
Java classfiles contain the necessary information for executing the J2ME program. For a typical commercially available J2ME game, obfuscated and manually optimized, the breakdown of the component of Java classfiles is show below. The methods and the stack maps together comprise about 65-70% of the total classfile size.
PNG compressors automatically reduce the size of PNG images, by recoding the image in a more size efficient manner.
Obfuscators reduce the size of Java classfiles by shortening the signatures of classes, fields and methods. In other words they reduce "signature constants" as shown in the previous graph. Obfuscators typically perform little or no optimizations on other aspects of the Java classfiles.
ZIP compressors reduce the overall size of midlet JAR file through compression.
mBooster targets opportunities for size reduction where existing J2ME development tools do not. mBooster optimizes Java classfiles using compiler based technologies, focusing on the methods and stack maps.
mBooster incorporates an advanced compiler, and a high performance ZIP compressor. Please refer to Optimization Technology for more details.
mBooster complements existing optimization tools to allow you to develop the most compelling content thus increasing revenue, while reducing development cost and time-to-market.