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.

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 ...

Part 5: Dynamic Plots

This is part 5 of a series of posts on procedural generation of content in Idamu Caverns.  You may want to go back and read the earlier posts as well.

The idea of procedurally generated plots seems like the holy grail of computer programming.  Not only could a chunk of code doing this revolutionize the game industry, but it could put a bunch of script writers for TV and movies out of business as well (especially for a lot of mediocre sitcoms on television).

Luckily for those writers, accomplishing this seems to be very difficult.  If you know of anyone doing it, please drop me a line and tell me about it.

While that doesn't mean it's impossible, I expect that it's too difficult for a lonely developer to build on his own.  Of course, that makes me all the more determined to do it!

I'm writing this blog post prior to 99% of the code being written, so most of what I'm about to say is speculative planning.

The key to most programming problems is to break the problem down into pieces and solve each piece independently of the whole problem, while keeping the solution flexible enough to be usable even when unexpected things are discovered about the overall problem.  Abstraction is key (think about the Map interface in java, and how you can easily swap out different implementations based on the specifics of the problem).

That being said, the part that is currently written is to avoid the complexity of each creature in the game having to track their attitude toward you independently.  Instead, each creature belongs to a faction, and reputation and other things are tracked by the faction.  Each creature, then, stores only information about what faction they belong to, and some indication of how closely they follow that faction.  This quickly allows the few factions to remember extensive and detailed information about the player while each creature (of which there are many) only has to remember two small pieces of data.

Organizing things into factions is only the tip of the iceberg.  The complex and interesting part is the code that I haven't even started yet: how do the intelligent creatures react to the player based on faction standing (a large part of this is that I haven't created code for intelligent creatures yet ...)

Like mentioned in earlier parts of this series, completely random information is usually not the best way to do things, and this approach should avoid that.  If the player meets the Spider Queen and she randomly decides whether to be friendly or hostile, that's not very engaging or realistic.  However, if the Spider Queen is hostile because he's been killing and looting every spider he's met since the beginning of the game, that becomes interesting.  Not to mention the fact that it encourages the player to come back and play additional times, perhaps not killing so many spiders the next time through to see what benefits there are to befriending them!

Interactions become more interesting based on this mechanic alone.  If the Cat people and the Dog people are at war, and the player has an excellent reputation with the Cat people, she's not going to like the first encounter she has with the ruler of the Dogs, even if she has avoided fighting them.

But are the Cats and Dogs at war?  This is a place where random generation is interesting.  If each run through the player doesn't know whether there is an uneasy peace or all out war between these two factions, then the replay value of the game goes up quite a bit!

This alone could be considered a procedurally generated plot.  If each faction has a randomly generated attitude toward every other faction, and there are rules and code in place to control how factions behave toward each other depending on whether they're allies, or at war; then we have a state of affairs that the player has to contend with that changes with each play through.

Many other behaviors can be the result of faction reputation: Do faction members attack on sight?  What kind of prices do merchants offer?  What quests are available?

Writing this got me to thinking.  Each of the monsters in the game has a hardcoded reaction to the player at this time.  Spiders always hate you.  Rats ignore you.  But what if this were based on faction, and the faction attitude was random?  One time you pay the rats hate you, the next time they ignore you.  Depending on the other attributes of the factions, this could change up the game quite a bit.

The key to making this work programmatically, is good programming interfaces between the code that handles behaviors and the code that manages creature-specific attributes.  Doing that well is a completely different discussion.

This is the last post in this series for now, but I may come back to the topic another time.  If you've enjoyed these posts, please share, and consider downloading Idamu Caverns and becoming a Patron.

Part 4: Quests

I'm writing this blog post as I create the initial code.  This is Part 4 of a series of posts on procedural generation in games.

I've been thinking about quests in Idamu Caverns for quite some time.  Now that it's time to start implementing the code for the next feature release, I've been thinking about them a lot more.  Quests form an integral part of many game genres, and previously I'd thought it would be poor form to have them generated programatically.

However, the last few days, as I plan out my actual strategy for the code, I'm realizing that quests aren't that different from a lot of other game aspects that can be generated.  For one thing, most quests fall into one of a few categories with aspects that are easily randomized.  At it's core, a quest contains the following elements:

1. Someone/something to communicate with about the quest
2. A thing to do for the quest
3. A reward for the quest

Number 3 is the easiest to generate: pick a valuable item that the player doesn't have and offer it as a reward, possibly in addition to points added to the score, or an achievement if the game supports that mechanic.

Number 2 is only slightly more complex.  Wikipedia has a list that breaks quests down into categories, which basically handles everything I need to say about this.

Number one is where things get interesting.  On the surface it seems simple, spawn an NPC and put it somewhere the player will find, then use that NPC to manage the issuing and rewarding of the quest.  If it were that easy, though, you could just have a book of quests that the player can read from any time she wants.  One of the important reasons for creating an NPC to begin with is to create some sense of realism to the game.  Sure, I could simply place a Creature that says "Bring me $number $items and I will reward you with $treasure." and having a simple generator like that would be better than no quest at all, but it lacks the emotional power that many gamers crave.  Many gamers want the game to give them an emotional reward in combination with an in-game reward.  Something like, "thanks to you, my wife's spirit can finally rest in peace."  I don't know if I can generate that sort of thing with code.

From a programming perspective, all quest code has a fixed way in which it needs to interact with the rest of the game code:

1. There needs to be a way to communicate the desired difficulty to the quest generator
2. The quest generator needs to ensure that all the game objects required for the quest are populated
3. The NPC has to communicate the quest to the player
4. The NPC has to recognize when the quest is complete and reward the player
5. If it's possible to fail the quest, the NPC has to recognize and react to that as well

There are other things that could be added.  For example, the player's reputation with the NPC might determine how good the reward is, or whether the quest is available at all.  There are also non-critical nuances, such as what happens when the player has received the quest but has not yet completed it, then talks to the NPC again.  In the end, however, the above five are pretty much the minimum for getting a quest engine running.

For the first round of quests in Idamu Caverns, I've decided to create a quest manager that can select from multiple types of quest generators when the time comes to make a quest.  That will allow me to gradually implement different quest types and have the quest manager be a central place to enable them when they're ready.

The early quests will be fairly generic in nature, and thus not have much emotional value to the player.  However, once the code is in place, it will allow me to easily write specific quests and interleave them with the generated ones, the overall goal being to quickly provide a wide array of shallow quests to make the game feel broad, then add quests with depth over time, to strengthen the game.

If you join the Idamu Caverns community on Google+, you'll see updates as they happen and will know when this new code is released.  If you're enjoying reading about the development of Idamu Caverns, or enjoying the game itself, please consider becoming a Patron to ensure I can continue developing it.

The next post in this series discusses dynamic plots.

Part 3: The Director

This is the third post in a series about procedural generation in Idamu Caverns.

Anything generated on the fly presents a challenge in maintaining game balance.  If levels are designed by humans, those designers will ensure that the levels are appropriately challenging, and pre-release testing will ensure that the level designers have done their job in creating levels that are challenging but not impossible.  When generating levels dynamically at run time, this testing isn't available.  Furthermore, since there's no linear flow to Idamu Caverns, a player could easily take any one of multiple routes, thus arriving at a point with different equipment and buffs accumulated.

It seemed logical to me that there needed to be an explicit section of code for maintaining this balance -- a game Director, similar to what was designed for Left 4 Dead.  The purpose of the Director code is twofold:

1. Keep the game as challenging as the player requested.
2. Keep the game fun and interesting.

When you start the game, you are asked to select a difficulty level.  This selection is stored as part of the game state, and the Director attempts to maintain that difficulty level throughout the game, adjusting for how well (or poorly) you play.

The code is called primarily at level generation time.  Once the map generation code has finished, the map contains rooms, hallways, stairs, and spawn points.

For each spawn point, the director is consulted at multiple times during the population process.

First, the Director is consulted to see if the spawn point should spawn a treasure.  Here the director is fufilling the role of keeping the game at the requested challenge level.  To determine this the Director keeps track of how many treasures have already been populated on the current map, and compares that number to a number derived from the requested difficulty, factoring in a small random element to keep things from being too predictable.  A higher difficulty setting results in treasure spawning less often, while a lower difficulty setting means more often.

When it's time to populate a treasure, the director is consulted again to determine what type of treasure to populate.  Here the primary goal is to keep the game fun.  The code has already determined to present you with something helpful at this point, so the goal is to ensure that it's populating something useful.  The Director essentially rifles through your inventory to see what you're currently carrying, and tries to present you with something that you need.  This is why you won't see backpacks spawning once you already have a backpack (because there's no value to having multiple backpacks).  The code here is still imperfect, so you will occasionally find items that you have no need of, but it does fair job for the most part.

Next the Director determines whether to spawn a monster.  The chance of a monster spawning is always 100% if no treasure was spawned, but a factor of the difficulty level otherwise.  While it seems odd to have unguarded treasure lying around, it's a matter of keeping the game interesting, as there aren't enough items yet in the game to have every monster drop something.  This is code that will have to be adjusted as the catalog of game items increases.

Selecting which monster to spawn brings up another factor in the Director's operation.  Each creature in the game (of which the player is one) has a challenge rating that can be computed at any time.  It takes into account every factor that makes the creature dangerous, such as damage resistance, maximum health, and potential damage dealt; and returns it as a single number.

The player's challenge rating is calculated, and the requested difficulty is added.  This results in the desired challenge rating of the monster to be populated.  To mix things up a bit, a random element (based on the requested difficulty) may increase the target challenge rating, resulting in a monster that's a bit more challenging than would be expected on that level.  The list of possible monsters is searched to find the one closest to the target challenge rating, and that monster is placed at the spawn point.

The Director does a good job of keeping the game on track as far as being fun and challenging, but it's too random.  Monsters and items are spread completely at random across each level, which removes any sense of coherency from levels.  I have plans to improve on this in the future.  Another challenge is that every new element added to the game upsets the balance of the Director's equations and requires some tuning.  This is a problem only because Idamu Caverns is being developed incrementally, and ensuring that each version is playable requires careful testing to ensure the Director is still doing it's job properly.

You should download Idamu Caverns and try playing at different difficulty levels to see how all this translates into a game.  Please also consider becoming a Patron to help ensure I can keep making games and giving them away for free.

The next post in this series discusses generated quests.