May 28, 2013 Page 5 of 10
Ralf Knoesel (CTO), Matt Small (CEO)
Prior dev background (platforms): PC, N64, PS1, PS2, Xbox, Xbox360, PS3, Wii
Shipped Android titles: Riptide GP, Shine Runner, Beach Buggy Blitz
Preferred toolset: Our own game engine/tools, plus Bullet Physics and FMOD
Is fragmentation still a major issue for you?
RK: Fragmentation is a worry, yes, but not a major worry anymore. We design our games to support any aspect ratio from 4:3 to 16:9 and beyond; lack of Neon floating-point math is not a big deal anymore with today's clock speeds and CPU performance; OS version support is not such a big deal for us since we're now able to require 2.3 (Gingerbread) so that we can use NativeActivity.
The biggest issue for us is the tendency for the manufacturers to ship with subtle shader compiler bugs in their OS flavors. This can be a bit of a nightmare because the same device can have different bugs based on which OS version the consumer is running.
Do you have any tips for optimizing the Android dev process?
RK: For dealing with texture compression, we use ETC1 for non-alpha textures, and DXT5 for textures containing alpha. For devices that don't support S3TC, we decompress at load time (starting with lower-level mips on RAM-limited devices). This significantly simplifies asset packaging.
MS: On the content side, the biggest gotcha is UI. But designing the UI for multiple resolutions and aspect ratios does not have to be a huge headache. The key thing is to make it flexible, with elements that float, stretch, or are locked to different edges of the screen. Also don't integrate the front-facing UI elements (like buttons) too tightly with the background, or make your backgrounds aspect-ratio-dependent.
We design for a 3:2 default aspect ratio, and make everything slide up/down or left/right from there. The backgrounds are made up of tiling/stretching graphic elements or 3D scenes. That way you can basically throw your UI against any aspect ratio and you're good to go.
Do you target and test for specific devices?
RK: At this point we have a decent selection of popular devices representing the various GPU manufacturers, plus a few quirky troublesome devices that are popular enough to warrant support. Generally, we have coverage for the top five to 10 devices according to the developer console statistics. When a hot new device comes out that we know is going to be huge, we pick one up and add it to our roster.
MS: If we get a lot of support emails on a device we don't have, we have to balance the popularity of the device with the severity of the problem and the time we think it'll take to fix it. If it's a serious problem on a popular device, we'll buy one and fix it. If the problem is showing up on an obscure or very old device, we may choose instead to filter that device in Google Play.
Page 5 of 10