N.R. and I are branching out and doing some little development while working on "Mythicum Goetia".

I've started making a little mini-game for the Android operating system.  It's been a lot of fun programming in Java again.  Most of my first games were in Java, so it's great to get to use those skills again.

The Android allows multiple applications to run.  Because phones may have limited memory, there is a "lifecycle" component to applications.  The documentation has a section on how it works, including graphics like the following:

This shows the flow of function calls that may happen when you get a phone call or the user wants to start using another application.  There are other functions that are called on the lines between the boxes, too.  The documentation describes this whole flow in excellent detail.

Pretty cool, right?  Wrong!  For the incredible amount of detail that went into this, including describing the exact order that functions will be called, it's not true!  I've got proof in the form of trace logs and now forum posts.  What's even better is that I based my application off of an example game that Google provides.  When I checked it out, it crashed during the lifecycle testing I ran on it!

Thanks, Google, for wasting half of my week!  I guess the best thing to take from this is that Google is not perfect.  And to never assume that documentation is true.

A lot of programmers (and non-technical friends) wonder how I start a game.  For me, it usually starts with a few hand-drawn pictures of how I imagine the game looking.  Next, I play the game in my head.  I imagine pieces moving and the buttons I have to click.

The first important step, though, is the "feature prototype".  I pick a feature in the game and code as quickly as I can to get to that point.  In Mythicum Goetia, that was movement and combat.

I took a detour getting there, though.  I went ahead and built a lobby system and a way to add artificial players.  To the new coders out there, DON'T DO THIS!  I shouldn't have done this, but I trust that detours won't prevent me from finishing the game.

So what would I have done without A.I. players?  I would have made the game temporarily a hot-seat game.  You can play for everybody while testing the first few features.

N.R. made 3D dice for the game.  I had some bouncy-ball code for another project and I adapted it for dice bouncing against each other.  It's mostly convincing and it adds a lot to the board-game aspects.  Feature #1: Implemented and worth the time!

The next feature was to test combat.  This is a really rough prototype.  It even requires that you use a little imagination because we have none of the weapons/spells available right now.  Using your imagination is okay.  In fact, seeing 75% of your idea implemented helps to motivate you and focuses your efforts on what will be more fun.  Feature #2: Almost there and looks to be fun!  It might need some tweaking, but it's better to know after a few weeks of coding then after months of writing the game.

Next is a more practical feature... loading and saving.  We want players to be able to re-start a board game as though you left it on the table.  There will be a few issues: connecting a player to his character's slot and having A.I.s take over for people who can't continue.  I'll talk about this once I've got some progress.

Later!

With the release of "Hackers of 2073", I've been bemoaning the lack of responses from game portal sites.  Not rejections, mind you, but a complete void.  Not even an autoreply.

I waited 2 weeks at first.  I then sent a "follow-up" letter.  After another 2 weeks, I created version 1.1 of the software and sent another letter, this time with a lot more jazz.

I would much prefer a "Thank you for your submission.  The current wait time is 6 months.  Please hold."  Or even a "Thank you for your submission, but we find your game without any redeeming value, and playing it was a torture we'd not wish on our enemies."

And this brings me to my main point:  Software development requires an enormous time/money commitment that can't be recuperated until the software is complete.  A couple of failed ventures, and you could be looking at a significant loss or even bankruptcy.  And in the casual market, you are completely at the whim of large companies.

I wish I could come away from these thoughts with a lesson.  We've done almost everything possible (demos, ads, videos, website, self-publishing, requests for reviews/distribution).  Unfortunately, until we get feedback, ANY feedback, there's not much that I'm learning.