Postmortem- Nanosaur 2 on Amazon Appstore

We recently released the Android version of Pangea's excellent Nanosaur 2, and it's available exclusively on the Amazon Appstore.  A number of folks have asked me about our experience working with the Amazon team, so I thought it would be helpful to post a mini "postmortem."

While Nanosaur has enjoyed tremendous success on iOS, it's widely know that premium apps like Nano have a tougher time in the Android space.  Knowing this motivated us to search for a way to successfully introduce Nano to the Android market.  It didn't take much for us to realize that Amazon presented an interesting opportunity in their new Appstore.

What Went Right

1. Communication-- right from the beginning, the Amazon team was responsive and fully engaged.  We approached them to see if they were interested in doing some kind of promotion with us for Nanosaur, and we got a response in less than 24 hours.  Over the course of about 2 weeks, 2 conference calls, and a handful of emails we were able to work out the details of the agreement.
2. Promotion-- Amazon.com is an e-commerce powerhouse.  Being featured on their site-- even in their fledgling Appstore area-- is a big boost for a small studio like citizen12.  They have a variety of promotional tools in their toolbox, and we were able to work out a combination of features that we felt would help get Nanosaur the kind of exposure it deserves.
3. Infrastructure-- One of the last things you want when working on deadline is to have your tools fight against you.  Amazon's Developer Portal worked great and enabled us to deal with the nuts and bolts of uploading the game and associated marketing materials with ease.
4. Test support-- This may be the #1 benefit of working with Amazon.  Developers in the Android space have rightly complained that there's no good way to test your apps on all the different Android devices out there.  Like Apple, Amazon runs all their appstore submissions through a validation/test process.  This includes testing on many popular devices, including numerous devices we don't have on-hand at citizen12.  The result was awesome.  Their test team identified 4 issues that would have caused lots of customer heartache, had we released the app as-is.  They worked with us to re-test the fixes and in the end the collaboration meant that the Nanosaur 2 which went live was much improved over the Nanosaur 2 we had initially submitted.

What Went Wrong 

1. Communication-- After Nanosaur 2 went live on the Amazon Appstore, we realized that we didn't fully understand how the various aspects of the promotion would be managed by Amazon's marketing team.  We had expected Amazon to lead with the major component-- 50% off and prominent placement on the Appstore landing page-- but instead they led with some of the smaller promotional tools.  It only took a couple of emails to work out where the misunderstandings were, but it definitely made it a bit more challenging for us to coordinate our marketing efforts with the Amazon promotion.
2. Timing-- This one lies squarely in citizen12's lap.  The studio was taking some planned downtime during July, which unfortunately was the same time we decided to launch Nano.  I had somewhat foolishly thought I could manage the rollout from abroad, but my absence caused some unnecessary work for folks at both citizen12 and Amazon.  Basically, we should have waited a few weeks before launching.

Conclusion

Overall, Amazon's presence in the Android market is a positive for both developers and users.  They provide a much-needed service by offering a "curated" portfolio of Android games and other apps.  They help small developers like citizen12 by providing QA services that would otherwise be out of reach.  They also provide healthy competition for the Android Marketplace.  

Our experience working with Amazon was a positive one, and we'd definitely work with them again.  

The Art of being Done. Almost.

One of the funny things about game development is the art of being “done.”  We finished the port of Cro-Mag Rally from iOS to Windows Phone 7 at the end of December, where we hunkered down in our San Diego office amid torrential downpours.  So you would think it’s all margaritas and frosty bugs while we wait for the royalties to roll in.

Not so.

While we had managed to complete all features, there were still a number of bugs to be retired.  Bugs included things like:

• Skeletons and animations didn’t work right for all models
• Effects and particles didn’t look… quite right
• performance, though much improved, was still not as good as we wanted
• weapons often fired in the wrong directions

 
Poor Brog and Grag.

Who would have thought it was so hard to make a nice fire?

So, after porting thousands of lines of code, four bugs should be nothing to worry about.  Ha.  These four bugs alone represented about 40 dev-hours of effort.

But now that we’ve got those bugs retired, we should be done, right?

Almost.

It’s true that we have resolved all known issues at this point, but when you’re publishing to a platform like Xbox LIVE Arcade or Windows Phone 7, you have to meet certain technical certification requirements (aka “TCRs”).  So onto the task list go things like:

• Handle “tombstoning” (when the user puts your app to sleep then returns to it)
• Manage resource loading to avoid long waits without screen refresh
• Create trial version
• Review Windows Marketplace “Best Practices”

So with all this work to do how come we said we were “done” back in December?

I have had some pretty heated conversations about the nature of “done” in software development, and in particular game development.  A lot of people think, with good reason, that devs tend to be rather… optimistic in their notion of what constitutes being “done” with a feature.  People who run large projects are held accountable for getting these projects out the door and into customers’ hands, so when they hear a dev say they’ll be “done” by some date, they automatically tack on another 20% or more to estimate when the thing will transition from “done” to “ready to send to customers.”

Entire methodologies are centered around getting the subjectivity out of the definition of “done.”  There’s some good in these practices in that they help people be more introspective about how they spend their time and effort, but I don’t believe “done” is a four-letter word to be vilified and analyzed until its meaning can be explained with a flow chart.

I think, maybe, that “being done” is something we need on a more human level.  We need “done” to be kind of squishy and subjective because we need something to strive toward while we’re in our basements or garages or cubicles putting our blood and sweat into making games.  We humans (and even we devs) need “done” to be a friend.  Someone we can look forward to coming over and having a beer.  We need it to be a little flexible because we undertake these efforts to build features and fix bugs knowing that we don’t know for sure how long it’s going to take or how many nights we’ll have to sit in bed or on the couch with our laptops working on a problem long after the rest of our families have gone to sleep.  We need that sense of being done in order to recharge and prepare to do it again, as we know we will.

So if I’ve just checked in a fix for a bug that was supposed to take a couple of hours and instead took me 3 days and 42 cups of coffee to resolve, perhaps I can be forgiven for calling the feature “done” even if it’s not accompanied by a full complement of unit tests and documentation.  If you’re a manager who has chewed someone out for calling something done when it didn’t meet your 15-point Checklist for Completeness™, then shame on you.

So—tldr—is Cro Mag for Windows Phone 7 done or not??

Because we’re a "Managed Indie” title we’ll need to add Achievements once we get the necessary tools from Microsoft.  And we need to localize the game to 5 languages.

But then!  Then we are truly, truly done.

Until it’s time for a Title Update.