A Complete Android Game

And here’s the source code:

package com.pdg.android.sandbox;

import java.util.Random;

import android.app.Activity;
import android.os.Bundle;
import android.view.View;
import android.widget.EditText;
import android.widget.TextView;

public class SandboxActivity extends Activity {
    private static final int INITIAL_GUESS_COUNT = 0;
	private static final int NUMBER_MAXIMUM = 100;
	private static final int NUMBER_MINIMUM = 1;
	private int guessCount;
	private Random random = new Random();
	private int number;

	/** Called when the activity is first created. */
    public void onCreate(Bundle savedInstanceState) {

    private void startGame() {

	private void pickNumber() {

	private void setNumber(int theNumber) {
		number = theNumber;

	private int getNumber(){
		return number;

	private void updateGuessStatus() {
    	setGuessStatus(String.format(getString(R.string.guess_count_format), getGuessCount()));

	private void setGuessStatus(String theGuessStatus) {
		TextView tv = (TextView)findViewById(R.id.guessCount);

	private int getGuessCount() {
		return guessCount;

	private void setGuessCount(int theGuessCount) {
		guessCount = theGuessCount;

	private void setPrompt(String thePrompt) {
		TextView tv = (TextView)findViewById(R.id.prompt);

	public void guessButtonPressed(View view){
		EditText et = (EditText)findViewById(R.id.currentGuess);
		int theGuess = Integer.parseInt(et.getText().toString());

Yes, it is the perennial classic “Guess My Number 1 to 100” game that just about everyone has written.

Why did I write this?

Mainly, I’m teaching myself the view based xml ui for android.

This is how I do it.

By writing an entirely too simplistic game.

But now I know how to put resources correctly into xml files, how to grab widgets by id, and how to set text values on TextViews.

Of course, the thing still blows up if you don’t put anything into the edit box and press “Guess!”, but that’s a feature!


Rudimentary Configuration Loading

I have achieved some of the basics for reading in XML configuration files into descriptor objects for HamQuest for the Android.

I put in the ability to specify types. This time around, I am not having the loader automatically trying to determine the type of data it is for the primitive data. The only assumption that it makes is the if there is no type specified, then it must be a string.

Also, since I do not want to shave the yak of introspection, I’m going to wind up with a small number of fixed types that can be loaded in. Really, there won’t be all that many, mainly weighted generators and string sets.

Getting this part done is highly important to the project. Upon this section lies the functionality of the rest of the application. Without it, I cannot even generate a room, nor a room’s contents.


I started playing a game on my phone called “Adventure Ho!”.

It oddly has nothing to do with prostitutes.

It is one of those “whimsical” RPG-ish games. You choose a highly unlikely protagonist, purchase highly unlikely weapons and armors, and fight against highly unlikely antagonists in equally unlikely scenes.

For example, I am a Hamster armed with a leafblower and wearing a denim jacket. I just came through the casino where I fought against people like bouncers and drunks.

Basically, it is a “manage your hitpoints and mana and inventory” game.

You proceed through various locations, each one with a particular number of enemies to fight to get through it.  Each character has his own strengths and weaknesses.

I was starting to think that a similar type of game could be used for a HamQuest type game, meaning the same sort of combat mechanics as HQ, but without actually moving about a room, but instead going between locations. The locations would be towns/shoppes/places to buy stuff, or areas where a particular enemy to fight is, and the paths between places would be a particular number of monsters to fight to get through.

Its a thought, anyway.

I’d likely have to do things like add special abilities (i.e. “spells”) to HQ in order to make this work.

And naturally, the locations would be arrange in a maze of pathways. Can’t get away from mazes that easily, you know…


Android: Assets, not Resources

HamQuest, in its current incarnation as a SilverLight application, is actually rather small-ish, codewise.

The real content consists of images and xml files describing the various objects in the game.

In fact, I made a concerted effort to remove as much from the application itself, and put it into the xml configuration files.

In the move to Android, I found the XML reading facilities to be a bit less than what I was used to in SilverLight.

See last post.

But forging ahead, because (after all) I still like to have all of my configuration in xml rather than having to convert it to something else.

I learned about XmlPullParser.

It reminds me vaguely of TinyXML.

I used to use TinyXML back in my C++/SDL days.

I didn’t like it then.

I don’t like it now.



I spent a lot of time googling things like “reading xml files in android” and the whole gamut of things like that.

Apparently, if a person is not making an XML feed, or reading something from the Android resource files, they aren’t using XML.

So the documentation takes a little while to sort through.

Eventually, you wind up at XmlResourceParser, and recommendations that xml files should go into res/xml.

Which is true, if you aren’t relying on a folder tree of xml files to feed the engine of your game like I am.

But I try it anyway, with many foiled plots to get my data from xml.

Until eventually I come to the conclusion that my XML files are Assets, not Resources.

And so I move them into my assets folder, and even into sub-folders (which res did not let me do), and I can even use capital letters in the name of the file (again a no with the res directory).

Finally, I can open an read my proprietary XML configuration files.

Unfortunately, I have to have a state machine that reads them in.

No, the org.w3c.dom classes would not help here. My code would be just as iterator-iffic.


Now I’m on to phase 2 of this, which may or may not be trickier.

You see, the XML configuration files contain a number of types of data.

Most of them are strings, bools, ints, and floats.

But every once in a while, I needed something else, which lead to a scheme by which reflection is used to load a custom object based on an attribute that holds the name of the class.

Java, it seems, has had reflection capabilities for quite some time.

They call it “introspection”, but I’m not here to quibble over how a language contemplates its navel.


I use SVN.

Use code.google.com to store my stuff.

Yes, that makes it open source.

No, I’m not concerned about people ripping my stuff off.

Have you looked at how much crap is up there?

I’m like the Millenium Falcon adrift in a Star Destroyer’s jettisoned garbage.

Maybe one of these days,  I’ll get some cloud space to store my stuff on.

However, for whatever reason, I’m having troubles getting an eclipse workspace to play nicely with SVN.

It has mostly to do with the generated resource files.


Configuration Files Run Amok!

“Amok” is one of those strange words, but I’ll save that for another time.

HamQuest has 74 different items, which sounds like a lot if you’ve ever played the game, but really it isn’t, once you consider what an “item” in HamQuest really is.

An item is an object in which the player can interact.  It is not a creature, which moves around and can attack you, it is not terrain, which is there no matter what.

The list of items breaks down into the following groups:

  • Doors: 24.
  • Keys: 7.
  • Weapons: 5.
  • Consumables: 3.
  • Armors: 5.
  • Treasures: 11.
  • Chests: 1.
  • Hiddens: 3.
  • Traps: 3.
  • Amulet: 1.
  • Tools: 1.
  • Megaham: 1.
  • Exit: 1.
  • Portal: 1.
  • Light Sources: 3.
  • Shoppes: 4.

Really this isn’t so much, as the various doors exist because there is one for each direction and one for each color, making fully a third of the items.

Also, treasures are really much the same, just giving differing amounts of gold, and so can be considered different subitems of the same item.

Which brought me to the point I found myself: managing a huge xml file with item descriptors, each with numerous xml tags.

At first, this wasn’t so bad, but as the list of items grew, it became more and more difficult to manage.  If I added a new property, I had to add it 74 different places in the file.  It was easy to lose track of what I did or didn’t do.

So I decided to split these off into their own files, and have the items.xml file point to the files they were in, like so:

<item file=”config/items/weapons/dagger.xml”/>
<item file=”config/items/weapons/shortsword.xml”/>
<item file=”config/items/weapons/longsword.xml”/>
<item file=”config/items/weapons/twohandedsword.xml”/>

And this was pretty neat.  I could now more easily manage the items.  Yes, it means that I now need to manage more files, but this is still a good idea.

Then I noticed in similar items that there is a lot of duplication in items that are similar.

I had already made it possible to do direct inheritance, because I recursed provided that the file=”” attribute in the file I loaded was there.

And I planned on using it, except that the first items in the list are the doors.

There are some properties shared by all doors: they don’t show up in inventory; they aren’t randomly placed in rooms; you can’t find one in a chest; and so on.

There are some properties shared by doors going east: they are all placed in a certain location.

There are some properties shared by all red doors: they are unlocked by red keys; they have the same messages when bumped into or opened.

So I decided to make it possible to inherit from multiple files, like so:

<item file=”config/items/doors/templates/all.xml,config/items/doors/templates/east.xml,config/items/doors/templates/red.xml,config/items/doors/red/east.xml”/>
<item file=”config/items/doors/templates/all.xml,config/items/doors/templates/north.xml,config/items/doors/templates/red.xml,config/items/doors/red/north.xml”/>
<item file=”config/items/doors/templates/all.xml,config/items/doors/templates/south.xml,config/items/doors/templates/red.xml,config/items/doors/red/south.xml”/>
<item file=”config/items/doors/templates/all.xml,config/items/doors/templates/west.xml,config/items/doors/templates/red.xml,config/items/doors/red/west.xml”/>

The order can be important.  If a later loaded file has the same property, it replaces the original.

In this way, I have implemented prototype based multiple inheritance.


Best HamQuest Feedback Ever

This is old, but I just discovered it yesterday, so it is new to me:


For those not wishing to click on the link, here’s the content:

HamQuest is a simple Rogue-like based on the rules of the HeroQuest board game.  It strips everything down to just the movement keys and an attack/defend toggle, but updates the graphics from the standard ASCII affair. If Rogue is a 12oz steak with all the trimmings this is a slice of low-fat bacon.

Fans of the genre may find this a bit too simplistic, but if you don’t want to invest a major portion of your life building up a half-elven level 31 wizard only to be struck down by the Balrog with one blow then this maybe more your style.  It’s still being updated with new features, so read your scrolls of teleport, get over to the forum and show some support.

I regard this as a positive review, even though portions of it don’t necessarily read that way.  The reason for doing so is because it reinforced the gameplay aesthetic I was going for: nicer graphics than ascii, but just barely; minimal controls; low complexity.

I especially like that HamQuest is a piece of “low fat bacon” compared to the “12oz steak” of Rogue.  At least it is some sort of pork, as befits a game called  HamQuest.

I’ll be including this review somewhere in the help file for HamQuest, and likely the support pages.

In other news, this evening, for the first time ever, HamQuest items were loaded from a config xml file, and not put together in code.  It is a momentous occasion, as this was one of the bigger items I needed to take care of in the refactor.  Naturally, the work is not done yet, as there are many things yet to be offloaded into the xml file from code, but at least I now get to deal with it on a configuration level rather than at a code level.