The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

When BlastPoints was in the early stages of development we, like many game developers, were targeting both iOS and Android platforms for a simultaneous release. Our goal was to have a similar experience across both platforms - the same game, same mechanics, and visuals that were almost indistinguishable between platforms. We were ambitious enough in tackling a high-end project for even one system, let alone two, and as development went on a few things held us back from really pushing both releases as hard as we expected.

We quickly realized that we were going to need to dedicate far more resources to getting our Android build running, stable and looking good, so a decision was made to focus on iOS as our primary platform. We did what so many end up doing - treating Android as a second class citizen.

This treatment isn’t necessarily unwarranted. Android is a very difficult platform to develop for, for a number of reasons. Most developers will cite hardware fragmentation as their key concern. There are well over 1500 unique Android devices, all with different hardware specifications, from different manufacturers and different video chips. Each of these devices has their own features, aspects and supported renderer features. Code that works on one device can crash on another, and so there are plenty of edge cases that have to be built into core code. Some optimizations that work well on one graphics chip will crash or cause a performance hit on a different chip. For us, couple these complexities with our initial unfamiliarity with Unreal Engine 3 as well as Android and its understandable why we deferred our Android release. For iOS, on the other hand, we only have to deal with about a dozen different devices which are all very well defined for ioand easy to find and test on. That’s not to say that iOS doesn’t come with its fair share of problems, but those problems don’t often extend to hardware compatibility.

But thats just one issue. Being a more open platform, it’s also well documented that many developers have experienced very high piracy rates on Android, and as a result, low monetization due to fewer store sales, or fewer in-app purchases. Our recent stats for iOS show about a 97% piracy rate for BlastPoints, mostly through China.

The relationship between these is, for us, still unclear. Past suggestions are that Android users tend to be power users, which results in more technical competence and therefore more piracy. But with the market share of Android up over 50% (provide screenshot of a graph + link source) it’s definitely the dominant platform amongst regular users. Perhaps it just means that developers need to treat Android as a different platform altogether - different pricing models, different ways for players to spend money in-game and let players know that they aren’t just an afterthought compared to their iOS counterparts.

BlastPoints running on an iPad2

BlastPoints running on a Nexus 7 Tablet

So how are we, as developers, aiming to solve these issues for the Android version of BlastPoints? Platform fragmentation is not a new problem in the games industry. In fact, we’ve been dealing with it ever since PC gaming has existed. Computers all have different graphics cards, memory amounts and processors speeds, and developers have worked around these limitations for a long time. For BlastPoints, we have some metrics in place to help define how powerful any given device is, based on some graphics chips properties, free memory and edge cases for devices that we know don’t fit inside our metrics. The game attempts to make a “best guess” from one of about 9 different performance & memory level combinations. Each of these combinations has a set of rendering features enabled or disabled (normal mapping, specular mapping, post-process effects such as lightshafts) as well as game effects (secondary explosions or projectile impact effects, for instance). Texture quality is also scaled back on game launch depending on available device memory to reduce potential startup crashes. All of these are “best-guess” scenarios based on some metrics that aren’t always accurate for any given device, which is often the same scenario for PC games.

That’s why we’re also providing a way for players to change the performance level themselves, or scale the screen resolution. While we won’t be providing fine grain options (ie toggling of specific features such as normal mapping, or lightshafts) using higher level performance buckets should cover a vast majority of cases for players. Finally, we’ve also put a flexible system in place for overriding performance levels for edge cases. This is critical for some devices that we know fall outside of our metrics - for instance any Tegra 2 based device is powerful, but post-process effects have a huge performance impact. This system is just in the form of a text file that dictates a device model or chip, and a forced performance level. The game will update this file from our servers on a regular basis. Performance reports (which users can opt-out of) with device model information and framerate information will be sent to our servers to help inform decisions on edge cases, and metrics for future releases. Mobile users may be used to just being able to pick their game up and have it run on a given devices, rather than having control over their visual settings. This presents a bit of a risk for our approach - players may just see the game performing poorly and give it a negative review. The best way to mitigate this is simply to inform players about the options they have. It is putting a bit of trust in the players, but it is a risk that we see as one worth taking. The benefit is getting the game into the hands of more players across a larger range of devices.

BlastPoints running on a Galaxy SII

BlastPoints running on a HTC Desire HD

The challenge for Android will be ongoing support and maintenance for new device releases, and ensuring that we can tweak and optimize for popular devices worldwide. As a small studio, we don’t have the resources to be able to test on more than a dozen of the most popular devices. While this should cover a large portion of the market, it’s still not good enough. The integration of analytics and some custom performance reporting features will greatly help us bridge the gap for feedback from our players. Analytics providers such as Flurry help provide a breakdown of all devices that have played the game to ensure that we’re covering as much of the market as possible. The previously mentioned performance reports will go some way to helping us optimize the game. Our attitude towards development for Android is to aim to support as many devices as we can, and to support the “games as a service” style of delivery. There are several other ways that we’re going about this, and we’ll have some announcements leading up to the release of the Android version of the game. However, we are committed to simultaneous content and patch updates in the future - that is, any content that is developed will be done for both platforms, and released for both platforms at the same time.

BlastPoints running on a variety of devices

For Blastpoints, we’re technically “feature complete” on Android - we’re in a position where the features across both platforms are very similar, for the most part.

The future for Android is looking bright, with platforms such as the Ouya and the recently announced Project Shield providing developers even more opportunities to create games that can match the quality of PC and console games. Time will tell as to the success of these platforms - there have been no pre-order sales numbers released for the Ouya, and the Shield hasn’t had a price point announced. But mobile processing power is fast catching up to that of consoles and PCs, and whether a winner emerges this year or next, Android will continue to rise as a viable and even critical platform for game developers to support.