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.

Click the Yellow Rhombus in Silverlight

You can play it here.

First question: Why?

CTYR is about as good of a sandbox project as JetLag is.

Actually, it’s a little better because it requires mouse clicks and a slightly more refined UI, whereas JetLag only need text and blocks of color.

Also, since I made the video journal today about CTYR, it was on my mind, and I happened to have a few hours.

Its about 200 lines of code, many of them blank or containing only a { or a }.

In fact, if you really want, you can look at the source at http://code.google.com/p/pdg-hamquest-silverlight/source/browse/#svn/trunk/ClickTheYellowRhombus. (Yes, it is currently in the HamQuest repository until I find a better home).


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.


HamQuest Hiatus Halting? Island Interloper Interruption Initiating?

The topic of this post reminds me of the 60’s Batman narrator.

HamQuest and I have a rocky relationship.

Periodically, I look back at the code base, and see a number of areas in which I can improve things.

I get inspired to do so.

After a while, the things that I want to do to make the game more configurable or better organized or generally more engineered pile up into a insurmountable list of issues to resolve.

Inspiration wanes.

Eventually I abandon working on it for a while, and move on to other things.

I imagine the curve plotted by my desire to work on HamQuest (or really, any long range project) might look something like a graph of cos(x).

Since there are endless cycles of this, the graph is really cos(x+k*2*pi), where 0<=x<=2*pi. And k is the number of cycles that have taken place already.

So, I appear to be heading for x=2*pi, which means the cycle will reset, and I will do some work on HamQuest.

Which is actually a good thing, because my “x” value for Island Interloper is rapidly reaching “pi”, or the minima in interest level.

Is it possible to have a few projects that hit peaks and valleys in interest level in such a fashion that I simply need to switch between them?


So, why a decrease in interest in Island Interloper?

A couple of things.

1) There is a reason that HamQuest is not written in JavaScript(I tried… believe me!).  What does this have to do with Island Interloper? The problem with writing something in a scripting language is that it isn’t compiled.  This is also its strength, as long as it remains at a small enough scale.  Island Interloper has achieved a scale where it has become difficult to deal with.

2) I also don’t really want to invest the time needed to learn one of the many debuggers available for JavaScript.  Generally speaking, my “debugging” of JavaScript involves the heavy use of “alert”, and the FireFox error console, and that’s about it.

3) If the end goal of Island Interloper is to operate online in a multi-player scenario, a JavaScript single player game isn’t going to cut it except for prototyping how the game should be laid out.

4) I think that the “correct” client to use is SilverLight, with a swappable back end that can either be used to store data to isolated storage or through the web, and this layer would be abstracted so that I could use the iso storage one during development, and the web one in deployment.  Plus, C# has a real debugger.


$_SESSION Looks like a winner!

So, I’ve been looking into $_SESSION as the way of perpetuation data across web pages, now that I’ve got the site into PHP.  Very likely there will be session data flying around when moving between pages on PlayDeez.com.

Of course, there will be no content associated with having a session. Its the plumbing for future expansion, and I think a reasonable first target is the Silverlight Jetlag, since it is a smallish code base, and it is relatively easy to get my PHP session data into the object via a <PARAM>.

I’ve also been reading into getting a Silverlight application to call another webpage silently. After reading the documentation on it, I must say that it is a whole lot easier doing this from Flash or even simply JavaScript.

I also need to start investigating getting information from a FlashVars param into Haxe. I’m going with a lower flash version(7) because I want compatibility with the Wii browser and potentially other flash lite devices.

The first Haxe target is CTYR. I’m going to take the art assets from the Yahoo! Widget I made of this game.


Baby Steps Towards Facebook, and an Elusive Bug!

The rudiments of HQ on FB is here:


There is no integration of any kind, I just wanted to start getting it onto facebook. Still a lot of stuff to do on that end, but as time goes along, it’ll be much easier to distribute on FB than elsewhere.

Also, be on the lookout for a very strange and elusive bug. It seems that the down arrow (and only the down arrow) stops working. It makes no sense. If anyone sees what the trigger is, let me know so that I can take care of this issue once and for all.