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.

Silverlight, Looping MP3, Sadness, and Woe

So, I got to the part in JL2011 where I start to put the music and sound effects in.

I have another game where I did this (Object Ouster), so I just grabbed the classes I used to manage multiple sound effects, and went with it.

The sound effects worked flawlessly.

The music….

Not so much. There is an awkward silence while playback loops.

So, I head to the interwebnets, to find a solution.

Because this is JetLag, and if the stupid JetLag song doesn’t play, its just not JetLag.

Updated JetLag2011

You can find it here.

Currently most game states are at least stubbed out, and the game is fully playable, but no high scores just yet.

High scores are going to be local to the machine, at least until I can arrange an online leaderboard.

ASCII Graphics in SilverLight

I have recently begun work on a new version of JetLag called, unimaginitively, JetLag 2011.

The most recent “full” version of JetLag was 2003, and was written in C++ and used SDL and Visual Studio .NET (the 2002 version, so with the rare 7.0 runtime).

I’ve had a number of other quick versions with blocks and sans lucky charms, but this time I wanted to really make a version with all of the bells and whistles, including full ASCII text mode graphics emulation, as well as the same sounds that I used in JetLag1999.

The first major issue that I had with the SilverLight version was the graphics.

SilverLight is meant to make really pretty things. Not emulate an ASCII screen from DOS.

I could not find a way to colorize an image, at least not without a pixel shader.

My needs are simple.

I simply need to take a white graphic and give it a hue in which to shade.

Easy, right?

Not hardly.

Fail.

So, plan B – use 16 image, one of each color, and use a cropping technique to set the visible part.

This works, but it was very slow, and my frame rate was abyssmal.

Not to say that I needed a huge frame rate. I can make do with about 20fps. It’s JetLag, so it doesn’t smoothly scroll.

So I dug a little while longer.

I discovered that ImageBrushes render quickly.

A ha!

Now the entire grid consists of layered rectangles given a Fill of various image brushes.

How many image brushes?

16 for the background rectangles.

4096 for the foreground rectangles. 256 characters each in 16 colors. Each one 16×16 pixels.

It takes quite a while to download the repository, as you might imagine.

Which is what I am doing now on another of my machines.

And I do cache them.  The image brushes do not load the image until needed. It makes starting out a little bit slower(not noticeable on any of my machines, but I haven’t fired up my clunker yet).

The only question left to ask is “why”.

Why ASCII graphics? And in SilverLight, even.

(I also did them on the iPhone, as some may remember).

Really the technique that I found for using ImageBrushes would help with any game where a fixed grid of layered rectangles is needed.

Which is really almost all of my games.

TurtlePop now has themes.

I did a rough implementation of one of the features for TurtlePop.

I implemented themes, and put in four of them.

I plan to dip into IconBuffet for quite a few more, as well as my angband graphics collection.

Some time soon, the game will be renamed “Object Ouster”.

New Quickie Game

Yesterday, my wife was playing a game at pogo.com called Poppit!

She was not satisfied with exploding pies.  She mentioned that I should make a game like is, so behold:

I unleash upon the world another hastily thrown together hopelessly derivative game!

It is called Turtle-Pop, and you can play it here.

The state at this time is “barely functional”.  It does not detect the “no more moves” condition. It does no collapsing animation in the slightest.  It represents all of about three hours worth of work, and more importantly it includes the use of Angband graphics.

At some point, I will re-theme it with the creatures of hamquest, or perhaps the items, depending on what images are most easily differentiated.

In fact, I think all of my games should be re-themed with hamquest graphics.

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.

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.