HamQuest Returns

So, my website playdeez.com has been defunct for almost a year. Its still there, and its a long story that I might tell some day other than today.

For now, I share most stuff on the Dropbox, and I have thus far uploaded most of the flash games I wrote (they are on the right side of the blog, under links).

Today, I finally add HamQuest to that list.

I may even work on this version (a little… I backed myself into some pretty severe corners architecturally, so more effort will be on the Java version *WITHOUT* the convoluted organic architecture)>

So enjoy.

A Subtle Change Makes for Not So Subtle Possibilities

Off and on, I work on HamQuest.

I decided to keep going with the SilverLight version, and to heck with android.

I’ve been tinkering with a great many of the parts of the game.

Mostly, it deal with offloading things into classes that get loaded into descriptors using reflection.

A recent example of this is that I added properties to the player that allow the handling of command keys.

Before that, there were only six in-game commands:

Arrow keys: move

Tab: switch fight modes

Y: invoke the Amulet of Yendor

I wanted to add a “rest” feature.

Pressing the space bar would have some effects:

1. Healing (health++)
2. Use up a full turn of the player (light source duration –)
3. Increment the wandering monster check for a wandering monster in the room (it should not be without risk to rest in a dungeon)

And naturally, there is a limitation on when a player can rest. The room must have no creatures lurking within it.

Since I already had the one-off “Y” command, I figured I’d put it into the same area, when I realized I should offload it to a class that gets loaded as a part of the configuration.

So, now the configuration has the following added to it:

<key-handlers type=”TagSet”>
<tag>amulet-of-yendor-key-handler</tag>
<tag>rest-key-handler</tag>
</key-handlers>
<amulet-of-yendor-key-handler type=”AmuletOfYendorKeyHandler”/>
<rest-key-handler type=”PlayerRestKeyHandler”/>

I have two parts to this. One, a “TagSet” (i.e. a HashSet<string>) that specifies all of the actual key handlers, and two, the individual key handlers, which use reflection to load into the descriptor.

After putting this in, I realized something…

I have basically made magic spells and special commands to use items possible and infinitely expandable.

And that is when the full realization hit me.

I’m not making a casual roguelike exploring a maze game anymore.

I’m making a casual roguelike exploring a maze game kit.

And I’ve been doing this for some time.

If I wanted to, I could make the “E” key eat ham, the “D” key drink a potion, and all the other roguelike baggage.

Which I do not wish to do for hamquest itself, because the roots of the game are simple controls.

I could add a macguffin item, like mushrooms, to use a “spell components” that power scrolls that do things like banish monsters.

And I could do this WITHOUT recompiling the engine.

Or at least, I’m close to doing so.

 

Desktop Dungeons

Okay. I live not exactly under a rock, but in the shade of the very rock in which the underrockdwellers live. So I don’t hear about a lot of things, mainly because I’m not paying a lot of attention.

Yesterday, through the very small filter I have, I discovered Desktop Dungeons.  I first downloaded the free alpha version to my pc, and was playing it, and infected my coworkers with it. I am the ebola monkey who also introduced them to MineCraft. I have also attempted to infect them with Terraria.

When I first played Desktop Dungeons, I said to myself “Well, I guess I can stop developing HamQuest now”.

This is not actually true. HamQuest, while sharing a genre with Desktop Dungeons, and similarly sharing the design style of minimalism, is quite different in some fundamental ways, and so work will continue.

For E3, the DD folks allowed everybody to check out the DD demo online.

I realized this after I had already been playing the alpha version (and liking it an awful lot) for a few hours.

So I checked out the online version.

Instantly hated it.

Apparently something is wrong with me.

Maybe so, but if it is, then the same thing is wrong with people like Viridian Games.

I guess I’m just a part of a cross section of humanity that wants to risk being eaten by a grue.

And I’m okay with that.

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…

Ear Bleeding Java Generics

In my previous post, I blather on about my adjustment to Java from C#.

Now that I’ve had a little while, I’ve been adjusting a bit better.

I am realizing that a simplistic “port” is not what I am doing.

I am doing a “translation”.

I do not let curly braces fool me.

Just because both are present in C# and Java does not mean that I can express the same concepts in the same way.

Sometimes I cannot even express a concept in a similar way.

I started with my C# classes that deal with boards and mazes.

In C#, these are highly genericized.

So, I set out to write them in Java in a highly genericized manner.

Doing this was a mistake.

Why?

Three reasons.

One, I think my original solution may have been a bit on the “clever” side. The one true thing about all clever code is that it will come back to bite you later. I use generic types for the contents of a board cell, the contents of a maze cell (which is actually a subclass of board cell), the contents of a portal between maze cells. Relying on the language feature in C# that enables me to instantiate these classes, I used them mercilessly. In Java I needed to switch over to interfaces and factory classes, because the templates started to get really confusing.

Two, there was a significant design flaw in my C# code. This is common with organically grown code like this. I have a number of static (read “global”) objects for dealing with things like the item and creature lists. Recently, I decided that this was not the best way to go about things.  I also don’t have one large “game” object, which I normally do in cases like these, to contain all of the subordinate game objects and state. I decided to restructure so that the static classes were no longer static, and that the various tables would be put together into a single tableset, and this tableset object would be given to the various other classes that need them.

When translating to Java, I noticed that things would be a lot easier if everything knew what its parent was, and could talk up and down the hierarchy. There should be the big Game object, which is the parent of the tableset and the maze (which is the chief other object in the game), and so I attempted to do this with typed generics in Java, with a nifty interface (also generic) that allows specification of a type of parent. I was going along quite well until I got to a class that would need five template parameters, at which point I decided to ditch generics entirely, and use interfaces and the “Object” class for the parent.

Don’t get me wrong. I’m fine with generics, but my limit is type parameters. After that, my ears start to bleed.

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.

Anyway.

—-

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.

Extension Methods. I Like Them.

Yes, I’m about three years late to this party, but so it goes.

The tool used to write HamQuest is Microsoft Visual Web Developer 2010 Express.

It has been since I moved to this tool last year.

Originally HamQuest was a WinForms application in Microsoft Visual C# 2005 Express, later moved to 2008, then switched to Silvelight, and finally moved into 2010.

Which means that much of the HamQuest codebase is the 2005 flavor of C#, and while certain areas of the codebase have had to morph as it migrated from one tool to another, most notably the change from XmlNodes to XElements in the move to Silverlight, a lot of code remained in the older style.

Now, a lot has changed in HamQuest itself.

For instance, the representation of the items, creatures, and terrain moved from hard coded arrays into xml configuration files, and in fact became very sophisticated with the user of reflection as time went on.

Unfortunately, the added flexibility of XML made for some painfully awful constructs in order to get information as simple as hitpoints.

For example:

CreatureTable.GetCreatureDescriptor(CreatureIdentifier).GetProperty<IStatisticHolder>(GameConstants.Properties.Health).Value

For context, CreatureTable is a static class, with a static member function GetCreatureDescriptor, which naturally retrieves a descriptor for a creature based on the string CreatureIdentifier.  From there, I use the generic method GetProperty to retrieve the GameConstants.Properties.Health(a const string containing “health”) into a type called IStatisticHolder, from which I can finally retrieve the value.

Ugly and long.

However, it would be so much nicer to do:

CreatureTable.GetCreatureDescriptor(CreatureIdentifier).GetHealth()

The problem is that the Descriptor class doesn’t know anything about the properties it holds. It just loads them from an XML file.

In fact, I don’t actually WANT the Descriptor class to know anything about the properties it holds, because the same Descriptor class is used for Creatures, Terrain, and Items.

And this is where extension methods come in.

I have a class called DescriptorExtenders (a static class), and to it I add the following static function:

        public static int GetHealth(this Descriptor theDescriptor)
{
if(theDescriptor==null) return 0;
IStatisticHolder holder = theDescriptor.GetProperty<IStatisticHolder>(GameConstants.Properties.Health);
if (holder == null) return 0;
return holder.Value;
}

And blammo. I have my nifty GetHealth function, which I can use elsewhere in the code.

In addition, my extension method can do things like check for null, and return “safe” values if I want.

Some of the properties got really strange, especially for things like the Health example above.

The reason is that an enemy creature on the map needed to look the same as the player avatar.

Student Status, Windows Phone 7, and HamQuest Improvements

Over the last couple of days, I learned a few things.

One, that my status of “student” is far more valuable that I first realized:

1. I was able to verify my status for DreamSpark, and there are a number of tools I now get to make use of for free, namely Visual Studio NON-Express.
2. I was able to get a free developer account for the windows mobile marketplace.

Two, I improved my XAML skills, mostly as a result of using Visual Studio 2010 for Windows Phone. Considering that I’ve been making HamQuest in Silverlight, the fact that I can also use Silverlight for the phone appeals. Also the fact that the resolution of the phone screen is 480×800 means that my 480×480 map area actually fits, which means I don’t actually have to change the size of the map, I just have to rearrange the screen somewhat in order to get HQ onto it.

But before that, I decided to whip up a copy of “Feed the Fish” for the phone. Unlike the couple of times I attempted to get into iPhone development, I’m not going to do excessive Yak Shaving.  A game of feed the fish is fine. A game of click the yellow rhombus is also fine. A game of jetlag is fine. Pipes. Hammurabi. Hunt the Wumpus. Even a port of HamQuest, since it is for all intents and purposes a complete game that I’m simply adding features to.  I’m *NOT* going to start some big project specifically for the platform. Forget it.

Plus, I think I’ve made peace with my artistic aesthetic: ugly, cheesy games that are fun.

New Features in HamQuest

The version on the site is updated.   Click here to play.

I’ve actually added a few new features, and a couple of modifications.

The most noticeable change is the new tutorial mode, which is a feature a la Gauntlet.  The first time the player encounters a particular item or monster or whatever, a little pop-up message comes up.  Currently, I just have popups for ham, potions, and treasures.  The rest is a matter of putting the appropriate content into the messages xml file.

Another change is in the functionality of free-standing portals (the ones that don’t move and teleport you annoyingly).  Instead of remaining static, they are now single use portals. You use one, and it is gone.

The tutorial mode can be quickly turned off, as after the first time, it really loses its charm.  I also currently don’t have a key to press that will dismiss it.  You actually have to click the close button.  I do, however, have some functionality that forces the tutorial window to show up, no matter the state of the tutorial mode.  This will allow me to always pop up information when a bizarre items like the Amulet of Yendor it picked up, or the player is killed by a monster.

Finally, the Amulet of Yendor actually does something!  The Amulet is being held by the Necromancer (the dude who summons skeletons and whatnot).  Once you have it, there are a number of effects that apply to the character.

1. Portal monsters cannot teleport you, making them extremely easy pickin’s. (Which means that I’ll need to make them smart enough to run away from you at some point).
2. You cannot use free-standing portals.
3. You cannot use the exit.
4. If you press “Y” you invoke the amulet, which leaves it wherever you were, and then teleports you as a portal normally would.  After this, you no longer have the amulet in inventory, and so are again affected by portals and portal monsters.

The Amulet of Yendor is now the most complex item in the game. It added a whole other key command, making it the first item that you have to specifically make use of. It is also the first item that can be dropped.

Generally speaking, the tutorial mode makes it almost unnecessary to do detailed documentation.  This is not to say that I won’t do any, but the documentation can now be more of a summary of items and such rather than an explanation of how things work.

Something still necessary in the documentation, however, is some maxims on how the game is to be played.  Here are a few of them:

1. Early in the game, the main focus is a mad dash for potions and better weapons and armor.
2. Don’t open any door until all other rooms are cleared out.  The monsters in locked rooms are tougher.
3. Torch shoppes are for chumps. The light radius has absolutely no impact on game-play, and going into a shoppe causes wandering monsters to be spawned.  The benefits of buying torches and lanterns is greatly outweighed by the negatives of entering the shoppe.
4. Get the Amulet of Yendor as soon as you can.  Teleport monsters are annoying.
5. If you are going to go for the Dragon (which isn’t necessary to win), get the Battle axe from the minotaur, and go first to the potion shoppe and armor shop.
6. You can’t have too  many shields. It helps to conserve low durability two handed weaponry by entering into defensive mode.

HamQuest User Interface and Documentation

After my first video journal on HamQuest, I got valuable insight into some things.

First, my continued lack of documentation is appalling. A player new to the game and new to the genre will be completely lost.

Of course, that’s sort of part of the roguelike genre, but I’ve been stapling “casual” on the front, which means that there has to be some manner of guiding a new player gently into the game.

And that means revisiting the tutorial mode.

But!

I’m also considering a change to the UI.

Currently the game plays in a 640px x 560px window.

I’m thinking of moving it to an 800px x 600px window.

This would lead to a panel on the left similar in width to the panel on the right, the availability of more space for more items, the ability to actually show the pieces of the megaham as they are acquired, the ability to show the statistics as far as how many monsters have been killed, as well as how many hams eaten, potions drunk, etc etc.

But without the player’s ability to know what the little icons on the screen and numbers on them mean, it is all useless.

So, step one: redo the user interface at 800px x 600px, and step two: tutorial mode.

I’ll finally be getting to some “new feature” work, which will be energizing.