King Oddball 1.1.0 update and the Diamond Competition

King Oddball, released in September, has been received really nicely. The App Store rating is 4.7! We updated the game last week, adding the ability to replay levels and tweaked a bunch of levels to make the difficulty curve more coherent.

The real story with the update is the Diamond Competition we held. For once we wanted to arrange a competition which was all about skill and skill only. We decided to award a real diamond to the first player to beat the Hall of Diamonds, which is a new and overly challenging game mode we added.

To emphasize the level of challenge, let’s just say the competition expiry date of July 1st, 2013, seemed appropriate. None of us at 10tons has cleared Hall of Diamonds. We verified it’s theoretically doable by using our relentless autoplayer, which plays the game really bad, but at hyperspeed.

We announced the competition on December 12th. We couldn’t have been more surprised when we found a valid winning entry in our email inbox the next morning. But there it was, a perfectly legit screenshot of the completed Hall of Diamonds, with an authentic watermark.

We knew gamers always take developers by surprise with things like this. Gamers are always way more skilled and persistent as developers can imagine. So when creating the competition, we stretched our imaginations. Not enough though!

With permission, here’s a few quotes from the winner, who goes by the Game Center nickname Snooptalian.

”I really thought I was gonna be way behind in finishing the diamond levels. Figured somebody else would have done it first, but went for it anyway.”

”I played the new levels on an off for probably 6 hours, restarting overall probably in the neighborhood of 500-600 times. Was able to get a lot of levels in one go, but some of the later ones had me close to giving up.”

”Some of those levels were down right evil, but I would get on a roll and just kept at it. Next thing I knew I had completed them all and it was 2:00 in the morning.”

”Only side effect is now I got the in game music soundly stuck in my head.”

”Awesome game, and a very cool contest. You can’t beat winning a real diamond for collecting virtual diamonds in a game.”

We’re sure Snooptalian will appreciate the oddness of the situation (which is very much what we we’re going for): Having a loose diamond and needing to figure out what to do with it.

This is the one, by the way:

And since everyone’s dying to get the game after such a heartwarming story, here it is:

Azkend 2 on Android ICS x86

It seems that there’s at least one x86 Android Phone available. That inspired us to try out our games on Android x86. This is something that won’t probably be relevant to mass audiences for a while if ever, but it was still interesting to see Android and Azkend 2 running on a x86 netbook. Most Java-based games work straight away and native apps like Azkend 2 need only to be recompiled.

However, with Medfield the situation is even better: It seems that Intel has integrated some kind of binary translation magic into the SOC which means that even native apps compiled to ARM will work without modifications. Many sites also report that the x86 battery hog myth was busted with Medfield and that devices can compete with the likes of SGS2 in terms of batter life.

So, from a game developer’s perspective supporting Android x86 shouldn’t be a problem if it becomes popular.

We used a live bootable usb stick created from a iso here on a HP Mini 100e. See Azkend 2 Lite running on an Intel Atom equipped HP Mini 100e here.

Android and the strange world of APK sizes

Google just upped the maximum single APK size to 50 MB. After this the developer needs to do some add-on package juggling up to 4 GB. This can be done with Google’s own tools or developers can roll their own. For us this small change meant that we could fit Azkend 2 in two single packages on Android: APK for phones and another for tablets. However, the reality of things proved to be a bit different.

We just released Azkend 2 Lite on Google Play and one of our own test devices is a HTC Wildfire S. It’s one of the cheaper Android 2.3 devices. After the release, we were baffled why we couldn’t find the game with that device. We saw no apparent reason why Azkend 2 Lite would filter out on a Wildfire S.

Turns out that the cache partition size where apps from Google Play are first downloaded varies from device to device. On the Wildfire S this size is 35 MB. On a Nexus S the size is 500MB. On a HTC Sensation the size was around 80MB. If the cache partition size is smaller than the app APK, the app will not be visible on the Google Play for the device. This is an interesting and unadvertised limitation that probably affects cheaper models more than expensive ones.

So, it seems that even the 50MB single download can’t be achieved on all devices. I’m not sure if there’s going to be a fix or if this is just a feature. From the little details we’ve learned, it would seem likely that this is something that could be fixed in Google Play. If there is a storage device with more capacity attached, why not use that for saving the apk? World of Goo by 2D Boy is also affected by this strange feature.

If you suspect that you aren’t seeing some apps with your device, you can check the cache size with a free tool called Cache Fixer. You can even move the cache on a rooted device. However, this moving fix isn’t an option for the majority of users.

The story of Mali-400 MP and GL_RGB

We’ve had our share of compatibility problems with Android but most of them were quite straightforward. That said, it has still taken a lot of time if you sum up all the little bits of work we’ve done to improve compatibility. Maybe this note will help some other developer solve this particular issue more quickly.

For some time we’ve received reports that some Galaxy Note devices and some Galaxy S II devices may have problems with our games. When we started investigating, we discovered that the trouble was with games that used frame buffer objects (FBOs) or render targets if you prefer that term. We already knew that despite the similar model names, there are several kinds of SGS2 and Galaxy Note devices.

Samsung Galaxy S2 has three possible SOCs (System On a Chip): Snapdragon S3, Samsung Exynos 4210, or a Texas Instruments OMAP4430. Galaxy Note has two possible SOCs: Exynos 4210 or Snapdragon 8255T. After some more research we discovered that the trouble occured on devices with the Mali-400 MP GPU which can be found from inside the Exynos 4210.

After we had narrowed down the suspects, some googling produced this. In the end it was all down to the following sentence.

You are trying to create a framebuffer object with RGB of 8-bits per channel. Mali doesn’t support this because of memory alignment issues that would impact performance.

We had used GL_RGB in our OpenGL ES implementation and it seems that Mali-400 MP doesn’t support this at all.  So, now we know that. All other devices we’ve encountered have supported it, so this was exceptional. The fix was obvious: use GL_RGBA. Further investigation also revealed that GL_RGB is an optional feature so our code was a bit too optimistic to begin with. Anyways, problem solved!

In the end, as a developer I’d really hope that manufacturers would use a different model name if they decide to use a completely different SOC. Even though your average user doesn’t mind what’s munching the bits, this situation makes a developer cry. Granted the manufacturers have used different technical model names, but our customer will say he has a Samsung Galaxy S2. Most don’t know that actually they might have a GT-I9100G instead.

You really can’t say that your app is tested to work on a SGS 2 if you don’t have all the three different devices. And that wouldn’t account for the operator tailoring which might also be a factor in some cases. With that you might have somewhere between one and two dozen different versions of SGS2. For most developers it’s impossible to acquire AND keep acquiring every possible common Android device so it would be great if the manufacturers wouldn’t make the situation even harder :)

Upsides and Downsides of Retinafication

Let’s be honest. I can’t wait to get my hands on the new iPad. The new “Retina Display” looks amazing — as everyone seems to agree. But besides the great visual quality, what does this mean for consumers and developers?

The 2048×1536 resolution is huge. Insanely huge. 4x more pixels. Don’t get me wrong, I’m very glad Apple is pushing the boundaries, but it does come with a price — and no, not talking about the $499.

Consider this. You’ve got an iPad app with 30MB worth of graphics. Nothing unusual in a game app. Making everything Retina Compatible would in theory increase the size by 4*30MB = 120 MB. That more than doubles the download size! Sure, you can do all sorts of tricks to bring the size down a bit. You can reduce the jpeg quality. You can scale dimensions to 1.5x instead of full 2x and hope nobody will notice. Furthermore, not all images take exactly 4x more space: png images with hand-painted scenes seem to increase only about 3x. But making high quality Universal apps which support all four iOS resolutions (480×320/1024×768, non/retina) will make the app bundles massively large compared to last week.

It’ll be interesting to see if Apple addresses the issue in any way. Or if it’s that big an issue in the first place. They could enable downloading parts of the app on request, but I’m not sure the added complexity is worth it. This is what Google is doing on Android Market Google Play: the maximum app size is ridiculously low 50MB, but you can download extra packages later.

While the extra pixels come with extra download cost, they also require extra work for developers carefully crafting them. Surprisingly, simply scaling up the images in Photoshop doesn’t add in more detail.

iPhone vs. iPad Retina

We’ve been prepared for this for some time now, so updating the latest apps for higher res wasn’t that much work in our case. We’ve already updated 5 of our games to support the new resolution. The lucky games are Ironworm, Swingworm, Joining Hands, Belowscape, and the upcoming Azkend 2 HD. And they do look great. Just take a look at the comparison shot between the original iPhone resolution vs. the new iPad to see the difference in Ironworm. Admittedly you wouldn’t normally compare these two together, but nevertheless the leap in content resolution developers need to produce now vs. then is definitely significant.

There are some additional problems developing for the new iPad. We’re doing most of our development on Windows PCs. We support multiple platforms, even minor ones including webOS, bada, and Symbian^3. We’ve built our development tools so that we can make our apps resolution independent almost automatically. We’ve got our own simulator which we use to test the apps. However, the problem with simulating the new iPad is that we haven’t got an external display with large enough resolution to fit the 2048×1536 pixels on screen. Even the best Apple Cinema Display doesn’t have enough resolution to fit it in!

The otherwise excellent iOS Simulator is not really useful with 2048×1536 sized games. Instead of FPS, we’re measuring SPF. The performance is nowhere near usable. I’m glad the sim exists as otherwise we wouldn’t be able to do anything before the launch, but if a new iMac can’t push that many (simulated) pixels, is it safe to assume the new iPad will be able to handle it? We submit into the unknown.

Now of course, all those problems are mostly minor nuisances that will go away with time. The next iPad after this (the new new iPad?) will most likely have even more horse power much like iPhone 4S had over iPhone 4. The display makers will start selling wallet-friendly high resolution displays. We will all have unlimited amount of lightning-fast bandwidth. And flying cars.

Can’t wait to play our games on the new iPad.