App Development and the Art of Plumbing

This is the story of a one man Android game studio, and a renegade central heating system.

It all started around five years ago when a man, a younger man, was asked to do some work on a poker game. The man was an artificial intelligence specialist, and relished the opportunity. But his ideas never quite got into the published game, so like most game programmers, he started a personal project. Then around three years ago, that man published his ideas to the world, here on Gamasutra. Two more years passed, and the opportunity arose to build an App, and the man was pleased, but the plumbing wasn’t.

The first task was to decide on a platform. Android was the obvious choice due to low (virtually no) barrier to entry and the personal project already existed as Java code. The Android SDK is free and you already have the hardware – any half decent PC will do. The latest Android SDK now even comes with the Eclipse IDE included. The two are well integrated for development and debugging, not perfect, but for a grand total of $0 they are a great investment. Of course iOS was an option, but would have required the purchase of Apple hardware for development. The project wasn’t going to be low budget; it was going to be ‘no budget’. But the man was not naïve. He knew that it is much harder to make money on an Android project, because Android users simply do not like to pay. But he would take that risk.

Next was staffing. As well as the AI and Poker engine the man needed a graphics and UI programmer, sound, art, design, and later on, marketing. There was, quite literally, only one man for the job. Art work was going to be the hardest. The man could have asked one of his many artist friends for favours, but he asked himself, “would I be willing to provide my professional skills for free?” No of course not. So art would be in-house, in the back room in fact. But the project was low on art requirements and by carefully designing the UI and game flow the amount of art required could be kept to a minimum. That would also mean no complicated loading or compression would be required to deal with memory restraints.

Next was Design. Now the man was a professional. He had spent many years making games and knew it was important to have a solid outline of various parts of the project before development could begin. So the man produced a mission statement for the project – “An app designed to help learn basic and advanced skills for No Limits Texas Hold’Em poker and practice those skills in an environment most suited to do so” - or something like that. There would be a scripting system to allow different games to be set up (Scenarios) and also for lessons to be built where the game engine could be stepped through example of plays. The UI would be simple, and uncluttered. This would be a learning tool, so there was no need for a back story or secondary game objectives. Indeed these often obscure the poker play itself. The man had seen many other single player poker games where the objective of making a million as quickly as possible, or having to beat player X before progressing had led him to frustration and the habit of playing poker for quick gains in the sure knowledge he could just start again. In multiplayer social games with imaginary money the same is true, the game is distorted into a high rolling game by individual maniacs (a poker term for super aggressive and loose players, not a personal sleight). That is no way to improve your skills for the beautiful and highly tactical game of poker. True, a good poker player must learn to deal with maniacs as well as more sedate opponents, and the AI would feature specific playing styles, but the man would not set up a game that would encourage unrealistic play which, if you tried it in the wild with real money, you would become very poor, very quickly. No, this would be a simple app, it would just allow you to play as you should in real life, just Play Poker; hey – now there’s a good name. It was spring and there were flowers. The man was happy, and started to code. The plumbing was happy, and it was mostly on vacation.

Next - the development. Unlike iOS where the number of platforms is limited, Android has a huge range of mobile phone and tablet sizes to cover, with different screen densities, aspect ratios and API versions. But the man was not fazed; he had seen this before with J2ME. He could have used an engine like Marmalade which allows coding in one language but manages deployment to many platforms, but this costs money that the zero budget did not allow for. So the code would need to be entirely in-house, fortunately time was one thing the man had in abundance. Luckily Android has one big advantage over J2ME: even using the earliest API versions objects on the screen can be re-sized and freely rotated. Indeed even in API 1 and without using OpenGL you get access to a 2D transformation matrix. You can do a lot with that. So the code developed in layers: an application layer – containing the details of the UI layout, management of the poker engine and all the actual game content; and a core layer which contained all the common graphics, resource handling and an application stub. If the game ever did get ported to other platforms, the core layers would only need porting once, or at least not very often. The main substance of the core was a 2D scene graph to contain all drawable objects for the UI or in-game. In fact there would be multiple SGs, switched in and out depending on the game state. Much like a 3D game the SG would encompass matrix operations, transparency, draw depth and branch disabling so that objects could be grouped and treated together for animation as efficiently as possible. The spring turned to late summer, it was damp, but warm, and the plumbing remained undisturbed.

Next was testing. Now the man always built automated testing into his game and AI engines, so that was not a problem. Indeed that could be left alone to automatically optimise the AI using a learning algorithm. But the UI and general state flow all had to be tested manually. Now this was a problem. Thus far development had used the myriad of emulators available with the Android SDK. But it would be far too risky to release the app having never been used on a real device. So the ‘zero budget’ rule had to be broken. But the man reasoned that if the app works properly and at an acceptable frame rate on older low spec devices, and emulators proved all the permutations of screen size and density rendered properly, then that would be enough. It would have to be. So a used mobile phone was purchased, an old one, cheap. And a cheap tablet was purchased, but that did not work – it seems very cheap tablets like the Disgo do not actually allow debugging as most Android devices do. So a slightly more expensive HTC tablet replaced it, and that was good. It was autumn now, the dampness had got cooler, but the plumbing was still there, bubbling away.

Next was deployment. The one thing you have to pay for with Android is a one off fee of $25 to register as a developer using a gmail account. The app was packaged, using Proguard (which comes within the Android SDK) to obfuscate the code and protect it from those pesky pirates. The man could have included Google licensing for extra protection, but the internet forums said it wasn’t really worth it, and he wanted his app to be independent of any need to connect to the internet to play – a mobile app should be play anywhere, regardless of connection availability. The game, Play Poker, was then uploaded to Google Play and payment methods were set up. The app was published as a paid app for a measly few dollars. The man did need a bit more artwork now, for icons and promo images on Google Play and some screen shots, so they were done, in a day. It was winter now, and getting cold. The heating was on, but the water was not as hot as it should be.

And now – we are brought to marketing. The app languished. There was a Facebook page, but there was no big viral avalanche of interest. Facebook is like a closed central heating system. You have your friends and social network, but they mostly circulate within the same limited confines. To break out of your immediate circle you have to promote the page, and that is not free. The structure of the Google marketplace does not help. Your app is like one tiny drop amongst hundreds of thousands in the hot water tank, individually invisible to anyone browsing in. They say the cream rises to the top, but that is not the case. You could have the best app in the world, but if it has no visibility it will go nowhere, just sitting in the sludge at the bottom of the tank. In fact it is the hot water droplets that rise to the top – simple physics. But how do you make your droplet hot? The big developers heat it, with money, lots of money. And once it starts to rise a hot app will pick up momentum. The Google Play search engine is designed to favour apps which are popular and have lots of good feedback. Really it would be better to actively promote the apps at the bottom of the tank which show potential. But why would they when they can receive the majority of their profit form the superheated apps at the top? The rest of the cool droplets just make up the numbers in the battle with other distribution platforms for who has the most apps. But the man did not accept that argument. The whole premise of development was that there are in fact many apps with a few tens of thousands of downloads, and that would represent a healthy income for the one man.

The plumbing was making strange noises now. The hot water heater would shut down for no reason with error lights on the console. Now in the UK professional plumbers can be difficult to find, and especially so for small, difficult jobs. There are local guys who can do the easy stuff, but will they really guarantee success. And the expert plumbers charge hefty fees, and often just want to replace the whole system and give you an eye-watering bill. So what does every good man do – he ‘does it himself’. It turned out that it was just a build up of sludge preventing proper circulation, and draining down and using a magic cleaning fluid fixed the problem. And the man thought … this is very similar to marketing. To do a proper job would cost a fortune and effectively take the success of the poker app out of his hands, and while there are smaller marketing experts who will push the app for a small fee, will that cost actually produce results? What the man needed was a bit more circulation – get his little droplet to been seen at the surface now and again. But there is no magic fluid for Android apps.

And that’s where we are now. The man has drained down the system, re-evaluated the app based on feedback and upgraded it in some areas (mostly the art). There is now also a free version of Play Poker on the Google Play marketplace. This is a cut down version with adverts. Ads are easy to add – there is a built in API for Google Ads with the Android SDK. They can produce some revenue, but the returns are still small until the download numbers get very large. The Ads, along with restricted functionality are really there to help drive people to the paid app by providing a free taster of the game. Google users love free. There are also plans to publish on Amazon. This is also quite easy; there is an approval process, but the Kindle Fires are basically plain Android devices and you can add Kindle emulators within the Android SDK. Amazon users also don’t mind paying for their content. The man is also engaging in a promotional campaign: posting on Android forums and requesting reviews from magazines and web sites. It will be a long hard road though as this approach is now common knowledge and those sites must be inundated with requests. Indeed one review site actual states that they receive 50+ submissions per day and only review 10% of those. This may just be another large tank for the droplet to swim in.

So was the ‘zero budget’ option correct? Well it was for the plumbing. But for app development I’m not so sure. It may have been better to pay an artist and have a marketing budget, even if the programmer man worked for free. But if there was a budget of say $30,000, then the app would need to make two to three times the revenue to make a reasonable income. And is a few thousand dollars of marketing really going to achieve enough downloads? Would more and more marketing spend ever break even? The man would love to continue to make bigger and better Indie games, but he also needs to eat, and is asking the question is it really worth it? Of course the app could simply be not very good – and maybe that news would end the pain. The poker app has now become some sort of bizarre experiment in the realities of app publishing. We shall see how the plumbing holds up.