Thursday, October 23, 2014

Idamu Caverns: Lessons Learned

I'm winding Idamu Caverns down for a bit.  Overall, I just can't justify the amount of time I've been spending on it, and if I don't get some other projects rolling, I'm going to end up with a money problem soon.  I'm not saying I'm abandoning development of the game, but there will certainly be a pause for the remainder of 2014.  Given the low level of interest, I doubt if anyone will notice, but touch base with me if you're interested in seeing development continue.

The more interesting part of the project (to me anyway) is lessons learned.  I think the easiest way to describe these various lessons is to examine the goals of the project, and discuss whether or not each goal was achieved.

Goal 1: Familiarize myself with the Android platform

I think IC was most successful in fulfilling this goal.  While I'm not a "Google Recognized Expert Developer", I find that I'm able to write Android code quickly and effectively now, without getting bogged down in problems like how to write an app that doesn't lock up, etc.  There were a lot of points during the early development of IC where I tried to use a desktop programming paradigm that just didn't work right, and I feel like I'll be able to avoid those mistakes with my next projects.

Goal 2: Familiarize myself with the Android market

I feel like this was also successfully achieved.  I know my way around the play store, I have a good feel for what is necessary to launch an app, and I feel like I can put the required pieces in place without a lot of flailing for future app launches.

With both goals 1 and 2, I feel like releasing IC as a free app was extremely helpful.  It allowed me to make mistakes (which I did, for sure) without having upset paying customers, requests for refunds, or anything else nasty come through the Play Store.  It set the expectation with the consumers and I feel like it also established goodwill -- I don't know of anyone who feels cheated by Idamu Caverns, to put it plainly.

Goal 3: Build a community around a work in progress

Utter failure, without a doubt.  My attempts at social media, as well as paid advertising, just haven't resulted in the kind of response that's needed to actually build a community.  It's tough to know why things never took off, but I have two guesses: Possibly the Rougelike genre just isn't popular enough to bring in a large community, or possibly there just aren't many people out there who want to be part of a work in progress.

A number of people commented on this when I first started, and I admit that this was one of the big conceits of the project: the idea that people would jump in and contribute.  Many people told me that it wouldn't work, in may different ways, everything from "people don't know what they want" to "you can't give people a blank slate and expect them to be interested."  I didn't feel like IC was ever a blank slate, but apparently, in some way, it was too blank for people to be inspired by.

In general, I didn't get anywhere near the level of interest I expected at all.  Even ignoring the game input, the number of people who downloaded the game was frighteningly small.  I did (what I felt was) a fair amount of paid marketing, as well as doing my rounds on the social networks.  I have to believe that it's the lack of allure of the game and not the marketing, otherwise it's difficult to believe that anyone would ever succeed at marketing any game at all.

Goal 4: Turn Idamu Caverns into a profitable venture

This goal was, without a doubt, failed.  It's failure is the primary reason I'm putting the project on the back burner.  The plan had always been "pay what you want" for the app (using Patreon).  It seems to me that this failing is a chain reaction of the failure to build a community, since I've only got about 100 persistent players (and only 200 people who've tried the game, total) I can't expect to make much money from that small of an audience.  In general, I'd planned at this point for the game to be making at least a few $100 per month.  My most profitable month to date earned me $4.

Android's NotificationManager ignoring errors

I found another one. This has been a rather frustrating week for me, working around quirks in Android, many of which are clearly bugs (like this one, or yesterday's post) and others where the jury is still out.

Today, it's a problem with NotificationManager. Specifically, NotificationManager.notify() silently swallows invalid notifications. In particular, if you create a notification without calling setSmallIcon(), the NotificationManager will simply not bother to add it to the notification panel. Like yesterday's problem, this is particularly difficult to debug because there are no errors or warnings anywhere.

What makes the whole thing more interesting, is that if your notification includes a sound or vibration, those actions will still happen, which leads you to believe that the weirdest thing ever is going on since nothing shows up after the noise. Of course, that's slightly less weird than having it do nothing at all, which leaves a developer with absolutely no idea how to debug or proceed.

I hope the Android team manages to find time to fix some of these issues.

Android SQLite and rawQuery()

It seems as if rawQuery() is unable to process data modification statements such as UPDATE or DELETE.

I don't know if this is by design of SQLite, or by design of the Android API into SQLite, or an accident of one or the other, but it would be nice if this were documented somewhere. It's possible that some part of some manual somewhere has a note on it, but when I brought myself up to speed on the tools I saw it nowhere; and over the course of two days worth of debugging to figure out why my code wasn't working, my searches didn't turn up any mention of it.

It appears that the only way to modify rows is to use the update() method. There's nothing wrong with that.

What is wrong is the fact that when given an UPDATE query, the rawQuery() method simply does nothing, without throwing an exception, logging anything, or in any way indicating that something has gone wrong.

This is the second piece of developer-hostile behavior I've come across since I started doing Android programming earlier this year. Here's hoping that Google will fix it, and anywhere else in the system where errors mysteriously disappear. If a method is passed illegal instructions, it should throw an exception. I can think of no justification for silently swallowing an invalid instruction.

Tuesday, October 7, 2014

Ahh ... the Internet culture

Less than a day after moving my new app, This is Why I'm Right, to production, and before starting any of the launch activities (such as marketing or an actual announcement) I've got a single 1 star review.

Aviv Gelman eloquently describes the app as "BS app, remove!!!"

This guy is very serious about his review. You can tell by the number of exclamation points. Also, by the fact that he feels that Google should remove the app. Oddly, using This is Why I'm Right, I find that BS apps have more fun per download than serious apps.

So, since I'm obviously right, I'm more interested in Aviv's experience.

First off, the term "BS app" is pretty ambiguous. What does that even mean? The app does exactly what it claims it does, so it's not BS in the deceptive sense. It doesn't steal your data or crash your phone or do sneaky things, so it's not BS in the criminal sense. Since he was complaining about the free version, he can't even argue that it wasn't worth the price he paid.

The only conclusion I can come to is that the app hurt Aviv's feelings. It was inevitable, really, that some people's feelings would be hurt. When you don't get a joke, often your feelings are hurt. And sometimes when a person has hurt feelings she/he lashes out violently, with things like 1 star ratings.

I'm sorry that I hurt your feelings, Aviv. Whatever you do, please don't download any animal simulators ...