Tuesday, 19 July 2011

Where did I start and How To Fix Lunar Lander

Buzz Aldrin removing the passive seismometer f...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);
// <-- 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 {

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 {
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:


Then change to:


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

mWinsInARow = 0;
mX = mLanderWidth;
mY = mLanderHeight * 2;
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.)


Enhanced by Zemanta

Monday, 18 July 2011

Bouncy Key Bottleneck

PenImage via Wikipedia
I can't write with a pen. No, that's not right. I can write perfectly well with a pen, I just don't 'like' to write with a pen. Never have.

Why? I always thought they were too darn slow. Handwritten essays were little more than torture via the medium of tediousness. I even try to avoid handwriting letters as I've usually lost interest by the end of the first paragraph. Actually, over the years I've come to a conclusion: it's not the pen's fault - my brain works too fast.

By the time my hand has etched the first line of symbols across the page, my brain has thought about six other ways of phrasing the sentence, edited it, corrected the spelling and has moved on to a different subject altogether.

You would think this would make it easier to write? Wrong.

With my mind bouncing around like Magic Roundabout's Zebedee I would have to constantly read what I had just written to remind myself what I was writing about. This, as you could imagine, slowed the whole process down further.

Typing is slightly better. The words flow out at a higher velocity and my typing speed is certainly above average, however even this has its own speed limitations.

To some extent the problem has grown over time. As experience persitently crept into my cranium and my development skills...erm...developed, it allowed me to instantly visualise a great deal more constructs, modules, classes and code that need to be on the screen. Getting all of this information from my neural synapses into the current choice of IDE by bouncing fingertips on worn lettered keys takes time.

I am sooooo looking forward to advances in neural input sciences!

Anyone else have the same issue? Or is it just freakishly me?


Enhanced by Zemanta

Friday, 15 July 2011

Sidetracked 00001

No left turnImage via Wikipedia
I highly suspect this will be the first of many deviations from the development path.

Saying that, the path is a purely abstract concept, in this instance. The question is - where would a deviation from an abstract leave me? Further abstracted? Surreal? Insane? Who knows?

Anyhoo. Having set up for a lengthy coding session I accidentally fired up my HTC Wildfire virtual machine (240x320 QVGA) as opposed to my normal form factor HTC Desire(480 X 800 WVGA). As the initial launch takes an age I thought I may as well test the Livestock Vs The Undead Lite code on it to see how it ran. Let me tell you folks, it wasn't pretty. Picasso may have been proud, but it was pretty useless as a game.

As my newly revised graphics engine code was still fresh in my mind it seemed like a good time to make the thing scalable at least.

The conclusion to this tale is that Android seems quite happy to scale images for you by default - but it does a pretty lame job of it. So I turned off all the auto-scaling from my resource fetching code and ran it all through my new routines and voila - a working and scalable version of the game.

This is all well and good. But it doesn't actually add any extra goodies. I shall have to be more restrained and get on with it in the next sessions - ie back onto the menu revisions. Those of you who didn't like the game starting from scratch on each load are going to love the new sections.

Enhanced by Zemanta

Thursday, 14 July 2011

Broke it to fix it

CodingImage by ronny-andre via Flickr
Warning : Spoilers

On Livestock Vs The Undead Lite v1.1b (the 'b' was due to a couple of quick releases to eradicate some memory issues) I was at a stage to really start ploughing in some new functionality. (I apologise at this point if you've been waiting for the new release - below explains why there has been a delay.) This was going well at first. The persistent levels code was working well. I had added another creep along with extra chomping animations and sounds. A dozen or so tweaks around the system were holding their own.

That's when my old enemy, the Out-Of-Memory monster reared its ugly head. I was stuck, nowhere to turn, banging my head on my keyboard (getting dfghjk in reverse on my forehead). Then it dawned on me.

The code I was using loaded all of the game's 100+ sprites individually, resizing them on the fly. It was this that was chomping through the memory at a rate of knots. Even though the combined size of all the sprites was less than 1.6Mb - the processing just overwhelmed the device and all came crashing down. So the bright idea I had was that of consolidating all of the sprites into one .png file.

I started adjusting the code to handle the process. Unfortunately I realised quite quickly that this wasn't going to work either. The memory error had disappeared, but the Out-Of-Memory monster's poor second cousin, the Logistical-Nightmare monster, popped up.

You see, my sprites are all different shapes and sizes. This meant that the consolidated spritemap was all over the place. And given that you are always working with relative positions due the device rescaling, mapping where everything was, it turned out to be like playing darts in a tornado.

Not one to give up without a fight I decided to find the middle ground. This ended up being several sprite sheets with like-sized sprites. This meant that simple division worked effectively to work out sprite positions and that fewer picture files kept OOM away. Yay, success!

So, I currently am basically back to square one in terms of how the game plays, but now I can make some quick progress getting the more interesting stuff in for v1.2 (which I am hoping to have out of the door in a couple of weeks time).

I'm currently working on the menus at the moment - trying to give them a slicker feel.

Enhanced by Zemanta

Kicking Back To The Community

Android robot logo.Image via Wikipedia
Using quality of products as a reflection of how good a community actually is then the Android platform is destined for fabulous times ahead.

Being an avid follower of many great 'tinterweb forums, my hat is doffed to the many great minds that regularly impart their almost limitless wisdom.

As a sign of appreciation to the wondrousness that is the android development community, I have vowed to release the source code of any of my projects as and when they reach 250,000 installs. (As the more established android games are hitting around 10 million then I thought this a reasonable figure.)

'So you're not giving us anything until then?' you cry in dismay.

Of course I will. Over the course of this blog I will be releasing concepts, techniques and snippets of code to help anyone who is facing the same problems I had and have found a work around.

Enhanced by Zemanta

public blog AndGamesDevBlog extends humour

Diagram Android DevelopersImage via Wikipedia
Today, I've decided, is the day I am going to start something bloglike.
Hardly a new concept by any stretch of the most limited of imaginations, although this blog is going to be unique.

'How can it be unique', I hear you scream in disbelief? It is going to be my thoughts, anguishes and (hopefully) accomplishments on the road to (again hopefully) write a successful android game.

'How is that unique?' you ask with incredulous suspicion. Well, as there is only one of me with my thoughts - that'll make it unique!

After some thought you irrelevantly retort, 'But, why is the world flat?' Which I shall ignore and explain that I'm doing this with the hope that it may help others setting off down a similar path, and secondly because my memory is not a good as it ever was and it'd be good to keep a record.

First off, the blog title. A cunning acronym for :

ANDroid GAMES DEVelopment BLOGgeroonie

I currently have a couple of fledgling projects released tentatively onto the android market under the developer name of 'Strangemoo'. (Please check them out, score them with five stars and rave about them in the comments section ;) ) It is these projects that I'll begin writing about as it's where 'I is at' with regards to java/android experience.

If you have any querys, concerns or quibbles that are approximately relevant to the blog then by all means, please ask.

Enhanced by Zemanta