Posts Tagged ‘ android ’

A year of being published – but what now?

InterSceptre, my first released game, launched a year ago. Since then, two more have followed it and been progressively more successful. But with Windows 8 imminent, my hobby has an uncertain future.

The figures:
Title Launch Date Total Downloads Revenue Model Revenue Gathered
InterSceptre 13/6/2011 128
(of which paid: 16)
Paid app with free trial $15.84
Rummycomb 1/12/2011 8582 Free app with advertising None
Incoming! 19/4/2012 11482 Free app with pay-to-play credits None

So basically, no money.

InterSceptre (and Ben’s game AstroSwag) had a big launch (well, we thought it was big) – plenty of coverage in popular blogs, we did a few presentations at UK WP groups, YouTube trailers etc., and the Marketplace was a lot smaller a year ago. I’m sill pretty disappointed with how it turned out.

By the time Rummycomb came out, we’d met people at Microsoft and Nokia, through people we’d met at the XNA-UK groups; they helped promote Rummycomb which immediately got it to a wider audience. Rummycomb uses AdDuplex – a cross-referring network, which at one time also offered paid ads. The idea was that people playing other games would find out about this great free puzzle game and download it too… but I’m really not sure how well that worked, if at all. From AdDuplex’s paid ads, it made less than $2 on an install base of 5000 with 200 daily players before AdDuplex closed the scheme and went referral-only. Shortly, it will re-launch using AdRotator which will mix AdDuplex referrals with Microsoft PubCentre pay-per-shown adverts.

Incoming!, along with the other games in the Leda Arcade Collection, allows you a handful of free-to-play games per month, and beyond that you need to purchase game credits (10p to play) – which Ben engineered using PayPal integration via our web site. But the credit sales have been practically non-existent. We had practically no press coverage despite us approaching the usual blogs and forums with press packs and YouTube videos. Nokia however offered to promote the LAC games in their early days; subsequently Microsoft (without our involvement) have Featured several of the LAC games in the Marketplace, which helps downloads immensely and kept us near the top of the “Free Classics” section – but the download graphs make it obvious when a promotion is underway.

Forget about the price tag

Not that I’m in this for the money, per se – money would be nice, but I spent 20 years writing games for fun that were seen only by me and my best friend. So the download counts themselves are reward enough, for now.

But since this is a hobby and not a business, there’s only so much I can afford to spend on it – and being a family man, that’s quite a low figure. I can justify the $99/year to be an App Hub developer, and a contribution to web/database hosting costs, but that’s about it really.

Which leaves me in a dilemma about where to go next.

The Platforms

The original attraction towards XNA was not Windows Phone 7. That was a nice bonus which came later. It was because this was the way that indie developers could write games for the Xbox – arguably the largest console market in early 2010 when XNA came to my attention, and perhaps still today. There didn’t seem to be any way for indies to develop for the other console platforms – that’s changed recently with PS Vita and so on, but not so much back when we started this trip.

InterSceptre started as a game for PC and Xbox, but through the XNA-UK group it seemed there was an opportunity to win an Xbox by developing a Windows Phone game – so I quickly went about seeing what it would take to adapt the half-finished game over. Not too much as it happened; but I finished too late to enter the competition (it was won by my Leda Entertainment partner Ben). InterSceptre has subsequently been launched for PC via IndieCity, and I’m still toying with an Xbox XBLIG release.

The seed, however, was sown. Mobile Gaming was on the up and up, and seemed to suit the kind of games we liked writing – cute puzzlers, simpler retro-style 2D arcade games. Neither Ben nor I were particularly inspired by first-person shooter MMORPGs which seem to dominate the console world. We felt we could fill the “5 minute rag” niche that mobile gaming offered.

However, the life expectancy of XNA, and XBLIG, is… uncertain. Microsoft have still not declared whether XNA will continue to be supported and developed for Windows 8 (we already know Silverlight will be dropped). We think we know that “legacy” applications will continue to run on Windows 8 (at least on Intel if not ARM), but it seems pointless to me to keep developing on a framework that is being deprecated and will see no further investment. Whether XBLIG will be available on the next generation Xbox remains uncertain, and how developers should code for Windows Phone 8 is also unclear. We are nervous.

A droid for all occasions

I’ve blogged before about my adventures with Android, but all problems aside it might be the easiest jump to make. Fragmentation is an utter nightmare, but I do know how to write in Java at least. And Android easily has the lowest cost-to-entry of the available options: all the development tools and SDKs are free, and it’s a one-off $25 fee to become a Google Play developer. If I’m happy never to make any money (since no-one on Android will pay for anything) then I could churn out games that the majority of phone users would actually be able to download (and maybe even play, if it happened to work on their specific hardware).

Interestingly, it looks like the Sony PlayStation world may be opening up to indie developers. Talking a look at the SDK, it’s all remarkably similar to Android with a thin veneer of Vita painted over the top.

Apple of my eye

Being an iOS developer has obvious attractions – the strongest ecosystem overall, with users who don’t mind paying for things. Learning Objective C will take some time, but I’ve learned my way into enough languages now to know that it’s no big deal; if you can code well in one you can generally code well in all of them, with the help of an “API translator” that helps you map concepts between libraries. Microsoft have helpfully published such a guide, albeit in the opposite direction.

The key barrier to entry here though is cost – although the App Store developer membership is the same as for Microsoft ($99/year), a games development quality environment will set you back at least £1000 for the MacBook, plus an iPhone (on contract?) and probably an iPad (another £500?). That’s money I just don’t have to spend on my hobby, and I’d be mad to go into this on the expectation that I could make it back from App sales. And it’s mobile-only, unless Apple have plans for a game console that they’ve not yet shared with the world. So this route is, basically, closed.


Unity is one of those develop-once, deploy-everywhere environments; and it seems you can partially code in a C#-like language. there have also been special offers; go through their online shop at the right time and you can get a free licence to develop for both Android and iOS. Fantastic!

But there’s currently no way to deploy Unity to Windows Phone 7 (Microsoft won’t allow any emulation/VM on the phone, perhaps because an emulator/VM would have to be written in native code to be fast enough, and they won’t allow that) – no big deal perhaps, but the same is true of Xbox or any of the console markets as Unity does deploy to all of the major console platforms. Unity is also heavily geared towards precisely the kind of ultra-realistic 3D games I hate playing and don’t want to write. And although the licence may be free, you still can’t deploy for iOS without running on a Mac, even though the code is common across iOS and Android (no, it doesn’t make sense to me either).


The other option in this vein is Mono, a .Net implementation that is available for both iOS and Android. Mono sounds perfect, particularly as there are several open-source libraries that help developers write C# XNA games for Mono (for example MonoGame and ExEn, although ExEn is being deprecated – hopefully to be merged into MonoGame), with the promise that the same code (with a few compiler directives) can be cross-compiled and deployed to Xbox, WP7, iOS and Android devices – and now also Sony PS Vita; the development kit for Vita is also free and is apparently based on MonoGame.

What’s not to like?

Well, the cost. Although all the SDKs and IDEs are free, the licence for the Mono deployable runtime is $999.99 per developer, per platform, per year – and of course doesn’t include the entry fee to be a developer on those platforms. If I were a games studio, it’d be an absolute no-brainer; I’d write everything in C# and deploy to all platforms (WP7 and Xbox thought Visual Studio; iOS, Android and PS Vita through Mono). But as a hobbyist, I simply can’t justify two grand a year just to say I’ve got something on the App Store and Google Play as well as in the Marketplace.

So what happens now?

We wait, and hope things will become clearer during the Microsoft developer conference next week (June 20th?). Surely the XNA developers’ fears are unfounded – the Marketplace is still chronically short of games and applications compared to the competition, and Microsoft couldn’t possibly be so daft as to cut us all off at the knees by deprecating the environment. We know games houses have been pressing for native code on Windows Phone rather than using XNA, but Microsoft seem to be progressing more towards managed code in Windows 8.

I have no fear of going back and writing C++ and DirectX games, if that’s what it means. It’ll be a shame to lose some of the syntactic sugars that C# offer, but I’ll write in whatever language and tool combination gives me the greatest audience at the least cost.

I just hope that Redmond don’t force me across to Java, Android and PlayStation.


Not the ‘droid I’m looking for

In my previous blog post, I talked about porting InterSceptre over to Android. I spent about 6 weeks on that project, but in the end I abandoned it and have started writing a new XNA game. I thought I’d write a quick blog explaining my reasons.

Reason 1: It’s just too hard!

Okay, honesty first. I thought porting to Android would be relatively easy. I’d need to write a simple lightweight implementation of the Microsoft XNA framework on top of the Android APIs – not too daunting since all I needed was sound, touch input, and 2D graphics. After that I could essentially copy and paste my source code, because Java and C# are syntactically quite similar.


Actually to code porting wasn’t too bad. There are some differences in the syntax, yes, but more problematic was the way Java and C# differ in pass-by-reference/pass-by-value. Java is consistent: it’s always pass-by-reference. C# isn’t, and that way lies a world of pain if buried in the logic of your code you’ve assigned a variable expecting it to clone & copy the values rather than just give you another pointer to the same structure.

Other issues that fall into the “separated by a common syntax” bracket include:

  • Need an instance of an enumeration to get all values
  • Construction: base/super, call order of member variables vs constructor
  • Java doesn’t initialise “primitive” classes (e.g. Boolean, Integer, Float)
  • for/foreach syntax
  • unqualified case values in switch statements
  • lack of Properties
  • Differences in getting the size of collection classes – size/length/count
  • No operator overloading
  • Different GC strategies (Dispose())

These are all fixable, but are a right PITA. Slightly harder to deal with are the fundamental differences between Android and XNA:

Emulation. The Android emulators are unusably slow. Basically the emulator is a Java application that is emulating a hardware device (virtual machine), which is running the Android OS, and on top of that is running a Java application (your code). That’s several layers of emulation deep. I was getting 1 frame every 5 seconds. The only way to develop is with a hardware device, which even if you have one available can be awkward.

Screen sizes! Even relatively recent high-end Android devices have screen sizes smaller than the Windows Phone standard 800×480. This can be devastating if your games graphics are pre-rendered to fit that size. The biggest problem I’d have with InterSceptre would be fitting all of the options on the options screen, with the specially crafted text font I was using (note to self: use SpriteFont from now on). The in-game could adapt to smaller screen sizes, but I didn’t bother – in the end I settled for dynamically scaling the graphics so that the screen throught it was 800×480 but the rendering shrunk what was actually drawn.

But this really is symptomatic of a wider problem with Android – no standardisation. You can’t rely on anything. Sample Android game code that you’ll read on the ‘net is riddled with per-device exceptions and work-arounds. That’s insane, for a developer it’s a support nightmare having to keep releasing emergency per-device peculiarity patches for your games as they arise. Life’s too short to have to worry about that kind of nonsense.

Threading. Not hard, but you have to keep threading in mind in Android, lest your draw and update code clash over access to anything and you find yourself crashing out because of a ConcurrentModificationException. Very easy to do if, say, you’re adding to a list at the same time another thread is iterating through it.

Android alpha blending is XNA 3.1 style not XNA 4 style. In the move from 3.1 to 4, XNA changed from unmultiplied to premultipled colour values… or maybe the other way around, I could never get my head around it. Anyway, Android graphics still expect the old XNA 3 style colour values. So if like InterSceptre your game relies heavily on colourised special effects, you’re going to have to adapt an awful lot of code.

Vector maths. Android doesn’t have any. No, I couldn’t believe it either.

But the biggest issue for me by far was Canvas vs OpenGL 2D Graphics. The first 3 weeks I spent on the InterSceptre port, I was using simple Canvas.drawBitmap() calls to copy pieces of screen around. Once I’d fought my way through understanding the Paint and PorterDuff classes this worked fairly well; unfortunately InterSceptre performs a lot of screen copy operations per screen refresh, and as a result I was hitting the performance limits at about 10 frames per second – simply not fast enough for an action game like InterSceptre.

So, I ripped all the graphics code out (from my mock SpriteBatch class) and re-implemented it in OpenGL. This brought its very own challenges. There are no beginner’s guide to 2D OpenGL graphics tutorials anywhere, again you’re relying of scraping knowledge from someone else’s project. Noddy game samples all use Canvas of course, so if you need OpenGL you’re looking at a complex game such as Replica Island, and good luck understanding that if you have no idea how either Android or OpenGL actually work. OpenGL itself is a much lower level of coding than you use in XNA; it’s a set of arcane instructions to the graphics processor, and heaven help you if you can’t understand the gibberish you have to type in, or issue the commands in the wrong order. If something doesn’t work, you haven’t got a prayer of working out why.

OpenGL textures have to be exact powers of two wide and tall. No, I have no idea why this can’t be abstracted away from you. And there’s no easy way to change the size of a texture in memory before passing it over to OpenGL either, I had to resize all the graphics on disk, adding hugely and uselessly to my application size. Why?

But I persevered, asking lots of stupid questions on StackOverflow, and eventually got InterSceptre running in OpenGL. I had just 2 problems:

  1. I couldn’t use the same trick I did with Canvas, drawing everything fullsize to an offscreen 800×480 buffer then scaling that to the actual screen. OpenGL insists that offscreen buffers are no larger than the actual screen. This meant I had to draw each graphic scaled individually, and lost the nice antialisaing effect of just doing one big resize at the end. As a result, the game looked terrible – particularly the font, which suffered badly from artefacts
  2. It still wasn’t fast enough, I was only reaching 20 frames per second. On WP7 InterSceptre sits at 30fps with no problem at all.

Even then I probably would have continued, but when I couldn’t get sound effects and music to work either, despite following 2 separate examples that used 2 different sound APIs, I basically lost interest in Android completely. But while I’d been working on it, other issues had come to my attention that probably would have stopped me even if I was being successful:

Reason 2: Cheapskates.

Anecdotal evidence would seem to suggest that sales figures for independent games are just as bad on Android as they are on Windows Phone. There’s so much free stuff on Android that that’s what people expect, and so no-one wants to pay for anything, unless it’s from a big-name studio or franchise. So what exactly am I putting all this effort in for?

Reason 3: Long-term future of the platform

Android may be becoming the dominant mobile phone platform, but it is under threat from patent wars and the possibility of the Linux license being withdrawn. Google seems to have panic-bought Motorola to head off some of these issues. But things are so unstable at the moment, I’d rather steer clear!

Reason 4: Lack of Governance

The Android app market is riddled with malware as Google doesn’t seem to perform even basic checks about what an application is doing, unlike Microsoft (and Apple) who take a very close look. Will users continue to trust the platform, or will they defect to iPhone… or Windows Phone?

– – –

So… those are my reasons. I’m an XNA-only developer again, writing games for release on Windows Phone, XBox and Steam. It’s an exciting tiome to be a wp7dev and I’m looking forward to the ride!

The aftermath

Download InterSceptre from the Marketplace now!

Download InterSceptre from the Marketplace now!

So, InterSceptre has been published for over a month now – what’s been going on?

A lot has happened since I last wrote. Ben and I put some work into creating a press pack for our games, and Ben produced a brilliant promotional video to put on YouTube. We approached and were publicised in some of the major Windows Phone 7 blogs such as WPCentral, BestWP7Games, WP7Lab, and the XNAUK User Group. We also got some bad publicity, but maybe no publicity is truly bad as it caused a spike in interest, and more importantly gave birth to Ben’s new project: TrollWhacker.

Ben and I also had a good session at the London-based Windows Phone User Group, where we presented our efforts, and feedback from those guys helped refine the latest update to InterSceptre with improved feedback options, particularly an in-app suggestion to rate the game.

The publishing process itself has proved somewhat frustrating… it takes several days for each update to be tested and made available for review, and you have to be very careful how you actually release the game; publishing from the main menu (rather than the individual project page) can cause delays.

A few weeks in, and the results are disappointing. At the time of writing InterSceptre has had just 10 paid downloads, which is not a lot to show for a year’s work. However, the latest update also opened it up for trial mode, and so the game itself has been downloaded 43 times. More rewarding than the paid downloads is seeing the reviews come in. After that first initial bad review, InterSceptre was updated with better alternative controls and a nicer looking front page, which seems to have gone down well in the marketplace (the user who posted the scathing initial 1* review updating it to 3*, and several more positive reviews have followed from a worldwide audience).

Are these the ‘droids I’m looking for?

This left me in a bit of a quandry. Was it InterSceptre itself that wasn’t liked? Or is this all that can be expected of the Windows Phone platform? It is after all a much smaller target audience than the other platforms. Releasing a different game for WP7 would not be a controlled experiment, and therefore I decided to try porting InterSceptre to Android. Since then, I’ve been in contact with other developers who have similar poor sales figures, so I feel vindicated in this approach. Maybe if I ever make $99, I’ll consider porting to iOS…

Fortunately I could already code in Java, and it’s not radically different from C# in any case. It’s basically a case of finding out what the equivalent “hooks” are (how to draw on the screen, read the input devices, and play sounds) and watch out for the gotchas. I’ve been building a mock XNA framework to help me move XNA projects over to Android without too much reworking… most of my class hierarchy already abstracts away from XNA anyway, but the base levels of that needed some replumbing. You also need to take care as Android is multi-threaded, which can raise some unexpected issues for the unwary.

Android development is frustrating. The emulator is slow. As in a frame every 5 seconds slow. That’s because it’s written in Java, and is emulating an entire hardware device from the BIOS up through the Android OS stack, and then running Java on top. It’s several layers of emulation deep. This makes developing a game almost impossible without access to a physical device. Fortunately there is no “unlocking” required, unlike for Windows Phones, so you can test before handing your cash ($25) over to Google to get a developer account. But even on the device itself, InterSceptre is getting a disappointing 10fps or so, compared to 30+ on the Windows Phone. This significantly affects the gameplay.

The other issue you have to be aware of is that Android phones all have different screen sizes, unlike Windows Phones which are all 800×480. Android phones mostly have smaller screens too – typically 400×240, or smaller. This is a problem if your game, like mine, is full of pre-rendered graphics, and particularly pre-rendered text, that wants to be a certain size. You have to do all your own resizing and rescaling at run time, or rewrite everything. InterSceptre’s main game can adjust to the screen size available, but the title screen and options pages needed to be dynamically rescaled at draw-time… which also raises interesting issues around touch mapping because nothing is actually where your original code drew it 😉

So it’s been an adventure. I hope to have the Android port done before the holidays – I’ve got another 4 weeks or so – so that when I next go to the XNA UK User Group at the start of September, I’ll be there not just as a published WP7 games developer, but as a published Android developer too.

Maybe if I keep saying that, I’ll start believing it. I’m a published games developer. Nah, still not sunk in yet.