Livestock Vs The Undead

My story is far from unusual.  I had an android smartphone.  I liked playing tower defence games.  I had a modicum of development talent (Java being the eighteenth programming language I taught myself).  I wondered if I could mash the three together into some sort of Frankensteinian monster of a game. 

Just before I embarked on the slippery slide of android development, I had come across what is termed as a Production on Demand (PoD) site called Zazzle.  We've all had ideas for great T-shirt designs and slogans at some point. Well, this site lets you actually take that idea and slap it on not only T-shirts, but hoodies, ties, caps, cups, bags and a hundred other items.  You can then set up your own site-within-their-site and sell your freshly baked items to friends, family or anyone else you can convince.  It taps into your creativity in a big way and is quite addictive.  Let's just say: I went nuts.

A month later, with help from my wife (who joined in shortly after I did) I had racked up over a staggering 4,000 items!  At that point I came back to my senses and realised that (a) it was gobbling up too much of my time, and (b) the remuneration was relatively pitiful in relation to all the effort you put in (not Zazzle's fault - I just don't have young and/or trendy, fiscally endowed social circles).  Our store, http://www.zazzle.com/strangemoo is still open (with 5,577 items at time of writing), but my attention has now been firmly refocussed.

By abstaining from Zazzle, I found that not only did I have some time on my hands, but I had built up a sizable library of self drawn stock images.  Add some of those images to smartphone/idea/iota of talent and what you have there is a starting point.

Livestock Vs The Undead was born.

The alpha was at the time the best game I had ever played.  Looking back it was embarrasingly bad.  It was little more than chicken hurling bananas (Yes, bananas. What? It was there to use, Ok?) at zombies.  (Same zombie, different colours.)  Don't get me wrong. The coding was sound and most of the code is still beating away in the heart of the latest version.  It was just that it didn't do much and needed a host of stuff throwing at it.

My first piece of advice: Don't release anything onto the market too soon. 

Blinded by enthusiasm and pride of getting something working, I naively signed it off, plugged it and rolled it out onto the android market.  I paid heavily for this by getting some less than constructive criticism on the market that will remain there forever, no matter how many further releases I add.  By jumping the gun, I have branded my poor game a loser.

Realising my mistake and lessons learnt, I am basically treating the current game as a beta. At some point in the (hopefully not too distant) future I'll rename/rebrand and re-release it to start afresh.

The game is significantly better than it was. However I want to take it to a stage where I can look back at it at some point and consider it 'done' or even 'not bad' by my own standards.  If I am going to monetise this thing, I want to give my customers value for money, else I'd consider the project a failure.  It's not even the volume that interests me.  If 20 people buy it and love it, that's success in my books.

Ok, some stats now.  Android Market is both good and bad.  It's good that it allows us lonely developers to reach the masses.  It's bad in that (at the time of writing) the statistics it provides make little to no sense.  Figures go up and down almost at random.  Comments and ratings rarely make it onto the system.  The best I can make out of it is just taking the average from a daily reading.  At this point in time it looks like:

D - Downloads, I - Installs, C - Comments

Not too shoddy for a beta.  It was originally released in May 2011 and has been growing steadily.  (Not anywhere as great as Zombie Pop - but that is another blogpost.)  I've also made it clear (since the initial release fiasco), that it is a beta on the market and it still gets a few downloads per day.  I am convinced that the naff, very early comments are putting a lot of people off.  Google should implement ratings by app version to show a fair differentiation between the qualities of the releases.  


There is a definite spike when a new release is made (not shown on this graph) which I'll hopefully be able to demonstrate when I put v1.4 live.


Paul

Where did I start and How To Fix Lunar Lander

Image via Wikipedia

Ok. So you've got this idea and your target android device in mind, but you've no idea of what to do next?

My primary OS/s are Windows 7 and Linux (Ubuntu's v11.04) so I can only comment on my experience with these.

The first place to check out is Google's own developer's guide. Following the instructions correctly (mostly), I had my IDE set up and me poking around example projects within an hour (including downloads).

The recommended IDE is Eclipse but there are many others out there. As the tutorial was for Eclipse I've stuck with it and kind-a like it. It has contextual prompting and integrated debugging - which does make life that little bit easier. Eclipse does have the advantage of having Windows and Linux versions, allowing me to work on the same project from both my machines.

For my graphics I use Inkscape, a free and versatile vector designer. For audio I use midi files and Audacity, another excellent free app.

Once you have the tools, you need something to play with. Reading a few of the threads on the forums I heard a lot of chatter about the supplied Lunar Lander example, so thought it a good one to check out.

I thought I had hit gold. Animated sprite handling, user control handling, a basic but functional game thread, multi screen handling.

This would have been the perfect shell for Livestock vs The Undead, apart from the fact that it was a heavily flawed example. It didn't handle some of the most fundamental functions that any android application should, ie home/resume.

To cut a long story short it was losing its hook on the thread when the home button was pressed. So when you restarted the app it didn't know what it should be doing and falls over in a big heap. The following code allows the resumed code to pick up a new thread and continue down its merry way.

public void surfaceCreated(SurfaceHolder holder) {
// added fix -->
if(thread.getState()== Thread.State.TERMINATED){
thread = new LunarThread(mHolder, mContext, mHandler);
thread.setRunning(true);
thread.start();
// <-- added fix }else { thread.setRunning(true); thread.start(); } }

Unfortunately, this isn't the whole story. As all of the variables that were held within the thread class have now effectively been wiped you will now only see a black screen. ie:

class LunarView extends SurfaceView implements SurfaceHolder.Callback {
class LunarThread extends Thread {
variables
arrays
etc.
}
}

To remedy this you have move all of the variable declarations from within the thread class into the outer class. As inner classes can access outer class variables, you don't have to alter the variables themselves! Phew.

class LunarView extends SurfaceView implements SurfaceHolder.Callback {
variables
arrays
etc.
class LunarThread extends Thread {
}
}

Great. So now all the variables will stay in tact. But we've moved stuff around and in doing so we've broken the LunarLander.java file. Just look for, if you're using Eclipse it'll no doubt be highlighted:

case MENU_STOP:
mLunarThread.setState(LunarThread.STATE_LOSE,
getText(R.string.message_stopped));

Then change to:

case MENU_STOP:
mLunarThread.setState(LunarView.STATE_LOSE,
getText(R.string.message_stopped));

You'll have to delete this inside the public LunarThread(SurfaceHolder surfaceHolder, Context context, Handler handler)

mWinsInARow = 0;
mX = mLanderWidth;
mY = mLanderHeight * 2;
mFuel = PHYS_FUEL_INIT;
mDX = 0;
mDY = 0;
mHeading = 0;
mEngineFiring = true;

Leaving it in will mean everytime you resume the game it will start the lander in the bottom left with the engine already firing. It was some ill conceived start up code to position the lander in front of the splash screen.

These fixes were put together with the help from here.

A word of warning though. Pressing the home button doesn't actually shut the app down - just hides it, so it will happily chomp on your battery reserves. I would recommend using a clean exit using the finish() function on the button press instead.

Other than this - there is still a silver lining. You can still get the gist of how to structure a game frame, so please read through the code.

Finally: check out those forums, there are answers to just about every question you can think of out there. (Apart from the current one, because that's just silly.)

Cheers,


Paul