- 1 The Beginning
- 2 What Makes Android Different?
- 3 The Pros and Cons of Going Indie
- 4 Concept Development and Creative Challenges
- 5 Blood, Sweat, and Tears – Building the Game
- 6 What Does It Take to Execute a Successful Launch?
- 7 Staying Up to Date: Updates, User Input, and More
- 8 Closing Thoughts, Predictions, and Advice
One of the great things about Android's ecosystem is the number of indie developers who are able to enter the market successfully, providing a great product and inspiring would-be developers to join in. For many though, Android development in general is a mysterious topic. How an app or game goes from an idea to an entry in the Play Store is unknown, but (thankfully) not unknowable.
Of course, considering how major development studios bring apps to life doesn't require too much thought – major companies like EA, Disney, or Rockstar have no problem hiring designers and developers to crank out and maintain polished apps. The real wonder enters when considering how independent developers on limited budgets with small, intimate teams can bring to light games like Great Little War Game and World of Goo.
To get a handle on just what independent developers are up to – how they come up with ideas, what their work process is like, what they think of developing for Android – I got in touch with several indie developers responsible for games both big and small. Here's a full list of developers who graciously contributed:
Naomi Kokubo, LavaMind (Beetle Bounce)
Tomas Rawlings, Red Wasp Design (Call of Cthulu: Wasted Land)
Gil Carmel, 2D Boy Android Port (World of Goo)
Using their candid input as guidance, we'll take a look at the full story of independent Android development.
From free online tutorials to meticulous guidebooks, there are a ton of ways to get started in Android development.
Some come to Android only after having experienced development for other platforms, and some start fresh with Android as their first platform.
Naturally, each developer has a unique reason for coming to the platform, so I asked the panel of indie developers how and why they got started.
"I began developing apps for the Android because I like the idea of multiple app stores. For an indie developer, having a chance at getting featured by more than one app store can mean the difference between earning something and earning practically nothing. With iOS, if Apple doesn't feature you, then your game will make very little money. I like the idea of having a 2nd, 3rd and 4th chance." – Naomi Kokubo, LavaMind
"I've been developing games for more than a dozen years. In the past, I used to develop games for GameBoy, GameBoy Advance and PlayStation … As for Android, it was just the next logical step to me after iPhone. I'm not particularly exclusive in what I develop for; I'm actually rather notorious in game development circles for being the guy that develops for everything." – Mike Kasprzak, Sykhronics
Experienced developers like Mike Kasprzak, Paul Johnson, and the team at Red Wasp Design seem to have come to Android as part of a natural progression. After moving in to the mobile space with platforms like iOS and witnessing Android's growth, developing for the ever-expanding platform seemed to be an obvious choice.
Others, like Naomi Kokubo from LavaMind, have their own reasons for choosing Android – be it the chance for widespread exposure to the teeming mass of potential customers to the "open source feel" of Android development (cited by Gil, who is responsible for 2D Boy's WoG Android port).
Whether coming from other platforms or starting with Android because of its , there's one thing all the developers we spoke with agreed on – Android is a unique platform.
What Makes Android Different?
To some this is a rather obvious question. While putting together the narrative of independent Android development, I wanted to get a handle on what actual developers thought made Android stand out from other platforms – for better or worse.
While it should be obvious that one mobile platform is different from others, it's worth looking at what differences are perceptible – and important – to real developers who have experience with both the platform and the associated market.
"The Android platform is so much faster (hours!) to update a version too than say iOS - which means we can iterate when we want. Apple by contrast takes 7 days. But another example where it is the other way is true - Apple allow you to give review codes of games to bloggers, journalists etc, but there is no equivalent system for Android. However Google are iterating fast, so it will be interested to see how it develops." – Tomas Rawlings, Red Wasp Design
"The development environment for Android is truly appalling. We recently upgraded our pc's and I'd not noticed how many disparate widgets and gizmos needed to be tracked down and installed, and in the right order, to get even a basic "hello world" program running. The fact that we use mixed C++ and Java makes this even more fun … I know all the bits and pieces are provided free by various firms and people, but the truth is that as professional developers we don't need free, we need good and reliable." – Paul Johnson, Rubicon Development
One of the things that came up time and again in our discussions with developers was the sheer speed at which the Google Play Store allows iteration of apps and their updates. With an audience that expects functionality and quality, it's important to iterate quickly.
Consoles often took many-months of waiting for approvals, and your publisher often dictated when it would come out. Apple lets a lot of content though after about a week, while Google publishes to the store within hours. I'm a big fan of the freedom Google provides here. I was able to push a compatibility update out the same day my Nexus 7 arrived. – Mike Kasprzak, Sykhronics
Another thing that makes Android development unique is that when it comes to the development environment, some assembly is required.
Gil Carmel explained "the Android development environment definitely has more of an "open source" feel to it, for better or worse. Some of the basic every day tools need to be cobbled together to be made to work, which is annoying."
This echoes Paul Johnson's sentiment that having to jigsaw various tools together is a hassle, and that – for many developers – reliability and the ability to easily find and assemble a practical toolkit is more important than the fact that all necessary tools can be found somewhere for free.
The Pros and Cons of Going Indie
As with anything else, being an independent developer for Android has its ups and downs. Some of these are inherent in the Android environment, while other issues arise from external factors that effect the very nature of the market (remember Google's 10bn App Promo?). Still others do not "arise" at all, they are simply facts of the Android world with which developers looking to make a successful entry are forced to deal.
Some of the "pros" account for the very reason some developers entered the Android ecosystem, while some of the "cons" are also reasons that developers like Paul Johnson find the development environment for Android to be "truly appalling."
"The brain-achingly large number of potential customers … Low barrier to entry … [And] a warm audience. Feedback from our own customers has usually been very positive and helpful, and if you treat them right you'll get a lot out of it. Suggestions to tweak the game, feature requests, bug reports, etc., all help you in the long run. You can't reach people that easily making console games." – Paul Johnson, Rubicon Development
"The biggest drawback of developing for the Android is supporting a huge number of devices, each with their own specs and idiosyncrasies … I wish Google had placed restrictions on hardware manufactures to help standardize the devices. But then again, that goes against the open policies Google champions, so I guess it was impossible." – Naomi Kokubo, LavaMind
One of the biggest cons associated with developing for Android, and one which came up over and over when the question was broached with our contributing panel, was the existence of scads of devices, each – in the words of Naomi Kokubo – "with their own specs and idiosyncrasies." It's easy to see why this would be an issue – when customers buy an app or game, they expect it to work. Lack of compatibility will translate to poor reviews and lost sales. While developers don't theoretically need to test on every physical device that exists, it does help to sample from various manufacturers to maximize compatibility.
There are, of course, ways to eliminate much of this hassle without needing to break the bank buying test devices, using preventative coding measures, rather than reacting to bugs that manifest themselves on specific devices. Gil Carmel:
Supporting and testing on myriad different devices can be a challenge for smaller studios. That said, good programming and careful study of the documentation and community forums gets you 95% of the way towards having your game work on every phone. Just feeling your way towards code that happens to work on the first device you test on – that's how you get in trouble.
Another con, discussed by Mike Kasprzak, is visibility, not only within Android, but within Android as a part of a larger, ever-evolving mobile market.
The main problem today is visibility, but that said it's not really the fault of Google, but due to the shear quantity of apps … So to make money, you need to stand out from the crowd. This is main battle we developers are having with each other these days. The big guys have more money to throw at this, plus their own names often carry weight. There's no easy answer to this.
The benefit of indie is we can react faster.
On the other hand, devs cited a lot of plusses to developing for Android. One of the major plusses mentioned was the huge audience and enormous pool of potential buyers within the Android community. With Android holding a large market share around the world, there are tons of people looking for new games.
Paul Johnson of Rubicon also noted that the Play Store has a "low barrier to entry," meaning games do not have to be revolutionary to succeed – they just need to be well-made:
… you can't sell crap, and in fact your game will need a high level of polish to even stand a chance, but you don't need to rewrite call of duty either.
Concept Development and Creative Challenges
One of the most intimidating aspects of developing a new game (besides the months of coding) is coming up with a compelling concept, and carrying a creative vision through the entire project to create a cohesive final product.
Even after coming up with a stellar concept, individual developers may be lost in the design process. A game's visual appeal is one of its most important aspects, so just how do indie developers execute the visual and creative aspects of a project? And for that matter, how are initial concepts developed?
"As a person that does anything, ideas are all around you. The hard part is deciding what ideas have enough merit to pursue, and the harder part is making them a reality." – Mike Kasprzak, Sykhronics
"For us this was easy. I've always wanted to make exactly this game … That's it really. There never was a design document or anything so formal, I carried it around in my head for years." – Paul Johnson, Rubicon Development
For some, it would seem that the game concept is a no-brainer. In some cases (as with Paul from Rubicon), developers simply have an idea just waiting to take its place as a game for Android. In other cases, a bit of thinking and "digging" has to be done before fleshing out an idea. Kasprzak of Sykhronics explained that "…for the most part, it's starting with a question, and spending time digging for an answer."
As for creating complete, inspired, visually compelling graphical assets, it seems that developers take different approaches depending on their own skill sets. Kokubo (of LavaMind) took a strong DIY stance, avoiding hiring a team including animators, designers, etc. for the sake of expense and efficiency. She explains
I chose to do everything myself. First, as an indie developer, I couldn't afford to hire a big team, including an animator, artist, game designer, sound designer, composer, engineer, etc. So I wore all those hats. The development also went faster because I didn't need to spend time communicating or coordinating with a team. Fortunately, I'm a good artist and I understand game design.
Those not gifted with the ability to bring creative visions to life through design often opt to bring on friends or additional team members to get the work done, finding a way to get skilled artists into the process even with limited funding. The team at Rubicon development, having 50 combined years of developing experience, took this route.
For us it was art and level design - the three of us in the office are all programmers, and I'm sure you've all seen coder art before!
Luckily we have a big old boy network and we knew one really good guy in each category. We approached them to see if they would work for royalties, as we didn't have much funding at the time, and thankfully they both jumped at it.
Now that those royalties are coming in and everyone is happy with how things went, we have a fully rounded and highly skilled team ready to take on the next challenges.
Naomi Kokubo offers more advice on this subject to budding developers: "if you have any talent for visual design and game design, do that too. If you lack the talent, find a partner who can fill those roles."
I think it would be fair to say that in many cases, as independent studios grow, so do their teams. When just starting out, Kokubo's advice of doing as much as possible yourself makes great sense – it saves money, can be more efficient, and will teach ins and outs of the various processes new developers will need to understand. As projects grow, however, having more team members makes sense – specializing and forming a cohesive, cooperative workflow can be critical in making an even better product.
Blood, Sweat, and Tears – Building the Game
Workflow. It's an important concept when completing a project. A well-defined, efficient workflow can save time, provide working structure, and allow a project to run smoothly and without issue.
To get an idea of what works (or doesn't work) when developing for Android, I asked several developers what their own workflow looked like.
"We work together in the same place so we just go into our usual 'work mode' and just go at the project. It took us 12 months to make the game - that was for an iOS release first then PC then Android, so part of the initial period was making all the assets compatible with the different platforms. So far the project has taken 18 months" – Tomas Rawlings, Red Wasp Design
"I take a step-back with my development. I do all my work in a PC version of my game, writing things in a generic way, and occasionally testing on specific devices. I've gotten really good at porting games to different devices. Some of the initial work probably took a couple months to get right, but when I get a new device to target I can usually push it out in 1-4 days." – Mike Kasprzak, Sykhronics
In general, it would seem that not only do workflows vary, but even the time that it takes to create a complete game for Android is dependent on individual abilities and work styles. Developers we spoke with indicated time spans from a couple of months all the way up to two years.
As for the day-to-day workflow, Tomas Rawlings suggested that a typical day of working on a game consists solely of entering "work mode" and getting things done one after the other. Paul Johnson on the other hand explained
We don't keep tabs on people by hourly or even daily workload, trusting them to just get on with their next task in a timely manner. Producers in AAA studios would have a fit at the way we run things, but it works for us.
In terms of code, I'm the lead gameplay programmer and the other two in-office guys are platform specialists, one each for Android and iOS. However they spent lots of time on the main game code too, so the lines are all a bit blurry.
The creatives work from home but have been kept busy the entire time - there's a TON of content in both games, and Great BIG War Game rivals AAA titles in terms of gameplay hours provided. I finished the Starcraft 2 campaign quicker than ours.
It would seem that development workflow for independent Android studios is adaptable, showing marked differences depending on the size of the team, the scope of the project, and of course what needs to be done. While some take a relaxed "just get it done" approach, others rely on "work mode," or focus on specific objectives each day.
Much of this also seems to hinge on a developer's experience – Mike Kasprzak, who has more than a decade of experience developing for various platforms, has found ways to utilize tools (like development go-between Marmalade) that speed up the process, allowing him to develop games primarily for PC and then quickly port them to various device targets, sometimes "in 1-4 days."
For many developers, even after an initial iteration is complete, there are still issues to fix, bugs to resolve, and other kinks to work out. Naomi Kokubo explained that she typically focuses on the basic product, gameplay dynamics, and essential functionality first. With her first game, Beetle Bounce, Naomi built the initial product in six months.
After 6 months, I thought I was done with Beetle Bounce, but I wasn't. It took another 3 months of iteration before I polished and perfected everything, including integrating with Facebook, In-App Purchases, and a host of other features.
What Does It Take to Execute a Successful Launch?
In a market flooded with new (and perhaps worthy) entries, how does an indie developer stand out? What exactly is needed for a successful launch and – more importantly – one that will lead to sustained sales and growth?
There's no doubt that a successful launch is critical to the life cycle of any app or game. Since, outside of those releasing products to the Play Store, little is really known about how the top games and apps get where they are, I asked our developer panel what launch looks like, and what can make or break your game's debut.
"We have it easy on that front – 2D Boy's blog is picked up by a whole lot of the gaming press, so our Android announcement was plastered all over the internet the day after we made it. In addition there were lots of fans already waiting for (and asking about) an Android version. Last but not least, obviously being featured by Google several times along the way was key." – Gil Carmel, 2D Boy
"Today … I'd say this is the #1 question on developers minds. If it's not, you're doing it wrong. I think the best way to know how to launch a game is to have launched a game and failed. Launching on new platforms is a chance to try again. You have a lot fewer choices today, but each and every launch will teach you something you can use to improve the next one." – Mike Kasprzak, Sykhronics
While there's no formula for guaranteed launch success, one thing the developers we spoke with agreed on is that visibility is king. One of the best ways to become visible is to get talked about in other outlets. While 2D Boy had already gained notoriety before bringing World of Goo to Android, other developers rely on being featured by Google or reaching out to blogs and other outlets on their own.
Even when a developer or team figures out a good launch strategy though, things can change when your second product launches. Paul Johnson of Rubicon explains this phenomenon in detail:
Our first big title (GLWG) had little in the way of formal marketing, we just did a bit of forum posting and blogging and hoped for the best. I can feel marketing guru's cringing already, but we just didn't know how to go about anything else.
I guess we lucked out because enough people bought the game early to provide a fan base and help spread the word. GLWG hit the #1 spot for a while, ably assisted by a feature placement from the store, and since then we've never been outside the top 30 or so, often higher.
This time around though, with Great BIG War Game, we had a lot more tools in the box and were hoping for true stardom with it. Here's a quick list:
1) It's a much bigger and better game generally.
2) It has asynchronous multiplayer, which makes the game better but we'd also assumed there would be more social buzz around this feature.
3) We paid for a professional marketing outfit to assist the launch.
You might be able to tell where this is heading.. The game is failing and we have no clue why. Currently the original game is way outselling it and we just can't seem to build up a head of steam for the new one.
There's failing and failing of course, we're selling some copies and they've all come back with sterling user reviews, we just seem to be stuck at that elephant in the room I mentioned earlier, not being able to reach critical mass.
It would seem the successful launch – and specifically one that leads to sustained popularity – depends on a mix of several factors. Exposure is without a doubt the largest, but launch success also seems to depend on the nature of the product, as well as preceding products. It would seem that – in Rubicon's case – Great Little War Game may have been so developed, complete, and popular by Great Big War Game's launch that the latter's launch was bound to stumble without a rocket boost of exposure.
Whatever the case may be, it is clear that successfully launching a new game is challenging in a market that already has thousands of new products competing constantly, even more so considering the unclear and changing factors that contribute to a product's success or failure.
Staying Up to Date: Updates, User Input, and More
To ensure continued success after launch, developers are usually expected to keep up to date with their product, bringing improvements and fixes as necessary. As discussed earlier, customers expect to purchase apps that work. They also expect that their purchased apps and games will continue to work, and – in an ideal world – continue to improve.
To get a handle on how indie developers manage the life of a product after launch, I asked our panel what the update workflow was like, what role user input played, and how updates/fixes/enhancements were given priority.
"…For Smiles, I only update when something isn't working. iOS I haven't touched in a couple years, but Android I pushed an update the other day when I found out the game was being flagged as incompatible with the Nexus 7 (lies). Some hair pulling and manifest tweaking later, the update was in the store. As far as I'm concerned it's done, but I do have some cosmetic fixes I plan to make." – Mike Kasprzak, Sykhronics
"User feedback has been huge – it's a great way to see what issues people are having and pretty much dictates how we handle updates." – Gil Carmel, 2D Boy
When asking the devs who contributed their words for this post about updates, user input, and what changes get top priority, it became clear that many developers handle things differently from one another.
While Sykhronics takes a hands-off approach to updating in which the finished game is finished unless something needs fixing, other developers like Gil Carmel completely rely on user feedback. Likewise, Naomi from LavaMind believes that "anyone who takes the time to give me advice is worth hearing. Even when I don't agree with the advice, I appreciate hearing it."
Rubicon keeps in touch with their users as well, especially through their forum. Paul Johnson explained that the workflow for updates looks just like the normal workflow:
We regularly updated GLWG right up to releasing GBWG, and now we're full time expanding that. There were some release day bugs that caused some panic around the office, but they've been sorted out now and we can get back to adding new stuff for future free updates.
Overall, it would seem that updates and fixes comprise another area of development that varies between studios, especially in the independent space. Some games are simply finished unless something breaks. Others (presumably those that focus on a more social or interactive element) require more attention, and in these cases many independent devs find user input invaluable.
Closing Thoughts, Predictions, and Advice
Well, there you have it. A lengthy yet candid peek at the world of independent game development for Android. In the course of speaking with the developers who contributed to this post, a lot of great information was revealed, particularly for those who may be looking to enter the Android development world themselves. To that end, our developers offered some encouragement, predictions, and advice for hopeful newbies.
"The AAA console world is basically dying, trotting out the same old risk averse cruft month after month. Indie is where it's at and you can get published on Android for almost no money. All the future innovation will come from this space, and the big boys can't do a thing about it. Now's the time!" – Paul Johnson, Rubicon Development
"Do it yourself! There's nothing you can't learn. I had zero experience coding a year ago, and now I'm the one helping newbies out on the forum. And if you have any talent for visual design and game design, do that too. If you lack the talent, find a partner who can fill those roles.
And most importantly, don't let anything stop you. Finishing what you start no matter what obstacles you face or how exhausted you feel is the most important thing. It's not worth anything unless you finish.
Lastly, make a great product. Don't compromise. Good games don't sell. Only great games sell." – Naomi Kokubo, LavaMind
In the end, there's a lot to know about the world of independent development. There are both benefits and drawbacks to the process, and a great deal of factors to consider at each step. That being said, entering the Play Store successfully with a game that experiences sustained popularity is not impossible – in fact, the same "low barrier to entry" discussed earlier is one of the reasons many developers love Android.
Whether these accounts have inspired, dissuaded, or simply educated you on the topic of independent development, there is no doubt that the words "from the trenches" are invaluable to the Android community in understanding the platform and its ecosystem.