Indie Android Interview

I was doing “Office Hours” at Google I/O, and this guy walked up with a question and we got to talking. His name is Derek James of Polyclef Software; he comes from a different planet from the one this Web guy has been living in, one where Psychology Ph.D. candidates build actual real businesses, starting part-time, via single-handed mobile-device programming. I did an email interview with him.

Numbers · Tim: Let’s start by establishing your credentials. I’d say that by most metrics, you’d rank as a successful Android game developer. Care to give us some numbers?

Derek: Sure. First of all, I don’t just develop games, though those are generally my more popular apps. In terms of quantity, as of now my apps have over 300,000 combined downloads. As for quality, I have over 10 published apps with a 4-star rating or higher. And as for revenue, I’m on pace this year to exceed six figures solely from monetizing Android apps. So yeah, I consider myself a successful Android developer. My experiences with Android have already exceeded my expectations.

History · T: What’s your background, and how did you get into this?

D: That’s the funny thing. I have no formal software development training. My undergraduate degree is in English (from UT Austin). I worked as a high school teacher for a few years, then did web-based training for a while after that, before deciding to go to graduate school. I’ve been working on my PhD in Cognitive Science for several years, and then last March a friend of mine who works at Google sent me an interesting birthday present. He’d gotten a G1 as a bonus at work, but already had an iPhone. So he gave it to me as a present. At that point I hadn’t heard of Android. I read up a little about it online and downloaded the SDK out of curiosity.

I have a couple of friends who develop for the iPhone, one who makes a little extra cash each month from simple niche apps like construction calculators. I thought I could maybe do the same on Android and just earn a few bucks for pizza each month. I was already familiar with Java, having used it to do some computational modeling in graduate school. Writing a concrete calculator in Android was far easier than modeling neurons. Hitting the publish button for my first app was pretty cool. I saw a trickle of sales, so I kept on releasing simple apps, learning more and more features.

I love games and so it was natural at some point to try my hand at working on an Android game. My first one was a version of Spades. It was the first Spades app on the Android Market, but someone else released a competing version within a week after mine. I then released a version of Hearts, but initial ratings were poor, so I pulled it. Golf Solitaire was my next game, and it’s still one of my most popular apps.

I spent all of the summer of 2009 working on an entry into the second Android Developer Challenge. It was a game called Relativia. I was a big fan of the game Puzzle Quest, which is an RPG/Match-3 hybrid. Though I really like that game, and I love the concept of blending genres, I never really thought Match-3 worked very well as a head-to-head battle system. So I designed a puzzle game as the battle system for Relativia that worked like a variant of Connect Four. The player fights enemies by dropping tokens into a slots in a grid. If they match 3 or more gems, they get money to spend on gear like swords and armor. If they match 3 orbs, they get mana, which lets them cast spells. And if they match 3 skulls, they do direct damage. I planned on adding the additional wrinkle of geolocation, so when you launch the game, you search for markets and dungeons local to you, and they coincide with real-world locations, such as your local coffee shop. You would need to travel to that coffee shop in order to enter the dungeon in-game. Now I thought this was a cool twist on mobile gaming and potentially a clever new method of monetization. If the game was popular enough, I could make deals with businesses to be featured as locations to visit to unlock game content. The game placed in the top 25%, but that was it. And when I released it on the Android Market, I got a nice dose of reality. People overwhelmingly liked the RPG elements and the game system, but they didn’t want to have to walk or drive around town to play the game. So I revamped it as a non-geolocation-based game, and renamed it Puzzle Lords. Even though it’s very highly rated, it doesn’t do nearly as well as the staples: well-known, high-demand casual games.

So my next game was Dominoes, which has done very well. And most recently I’ve worked with another developer to release WordWise, which is an asynchronous, 2-player crossword-style board game. We decided to use Google App Engine as the back end, since it uses a Google account for authentication and Android devices are also set up with with a Google Account by default. It’s been a lot of work, and there have been a lot of issues, but the app seems to be doing pretty well so far. It’s got about 800 users and a 3.5-star rating.

Future · T: What’s next for you?

D: Well, we released WordWise as a paid app initially because we didn’t want to have a massive user base while we were working out any issues with the server. It’s getting pretty stable now, so we’re hoping to release a free, ad-supported version soon. There are also lots of features that we want to add in. If that does reasonably well, we’d like to get other clients made, such as Facebook and iPhone. I think it would be great to have a game that lets iPhone users play against Android users.

I’ve also got another word game in the works, a solo casual game that’s sort of a hybrid between Match-3 and word find games.

I’m also sketching out plans for a social networking app that uses the Bump API. That could be really exciting if I decide that it’s going to be feasible technically and cost-wise.

Needless to say, grad school is on hold right now.

Irritants · T: What’s the biggest problem an Android game developer faces?

D: As far as development, I know the Android team doesn’t like the “F” word, but fragmentation is a very real issue. There’s the increasing number of hardware configurations. There’s vertical firmware fragmentation in the sense that there’s a spectrum of versions in the ecosystem ranging from 1.5 to 2.2. And then there’s horizontal firmware fragmentation in the customized variants by the manufacturers, like Sense UI and MOTOBLUR. This rapidly expanding diversity is great in terms of expanding the user base, but it increasingly makes development and testing a pain. The Android team has done a great job of trying to mitigate these issues. The development tools associated with Android are very nice. But it will become more and more difficult to develop apps and games that run on more and more configurations if the gap between the oldest and newest firmware version continues to grow and manufacturers continue to release their own versions.

As for the business side, Google Checkout needs a lot of work, specifically in the area of reporting.

Dos and Don’ts · T: Are there any special tools you use and would like to recommend? Conversely, are there any Worst Practices that other developers should stay away from?

D: In terms of development, I just use Eclipse and the tools that come along with the Android SDK, which are great. I use Flurry for analytics, and I highly recommend it for providing detailed information about how users are interacting with your apps.

In terms of worst practices, probably a lot of what I do are worst practices. :) Actually, there’s very basic stuff like not being very rigorous about commenting code, tracking versions, and basic development practices. Because the Android approval process is post hoc, you can basically publish or update a live app nearly instantly. It’s very easy to get lazy and sloppy when your app is not subjected to a rigorous approval process. I’d also strongly advise against developing and testing solely in the emulator. There are often stark differences, especially when it comes to interacting with the user interface, between an emulated device and a real one.

---

---

Contributions

---