A New Year, A New Dungeon Delver

This is not the longest haitus I’ve ever taken.

Nor is it likely to be my last.

Previously, I had been working on HamQuest in C# and Silverlight, and toying with moving it to XNA.

A lot of things have happened since then.

One of which that I started making MineCraft plugins.

The reason I made Minecraft plugins was because I was running a MineCraft server, and I was using plugins, and they sucked.

Which means that I started developing with Java.

Which means I started using Eclipse.

Which means I realized that Javas not so bad, and Eclipse is not so bad.

So now I’m making a Dungeon Delver in Java.

And rather than simply porting the C# code (because there are a bunch of things that I sort of backed myself into a corner on) I decided not to make a simple port, but to make an entire new game, applying some of the lessons I learned(or re-learned) while developing HamQuest.




HamQuest II: Porkchop Boogaloo

The title is an allusion (not an illusion) to the movie Breakin’ 2: Electric Boogaloo. I give out this information because I realize not everyone has the exact same pop culture repository that I do.

So, I recently put out HamQuest for PC, and was left with a quandry: what is the next step?

I have a few options:

  1. do a “sequel” to hamquest
  2. do a port of hamquest to another platform or to a platform independent medium
  3. make “island interloper” or “medieval micro-manager”
  4. make something else completely

for the moment, I have decided to go with 2, and so I am making a javascript version of hamquest which will be mostly faithful to the original, but hopefully will address some of the bizarre issues I faced when implementing it originally, namely the saving/loading issues as well as the weird coupling of objects in order to make the player connected to an instance of creature.

JavaScript makes a number of things very easy.  I can duct tape any field or method onto any object I want.  This also makes it easy to get into a great deal of trouble and foolishness if a person gets too clever with it.

The downside of JS is that I’ve had to learn to write it in a particular pidgin that works across browsers. Just the other day, I had to fix Connect! because it had stopped working in Firefox(an odd happening… normally IE gives me the issues).  I then learned that it didn’t work in Chrome (which I had never tried).

So now, my big four(IE, Fox, Opera, Safari) is a big five (+Chrome), and I’m probably going to target Adobe AIR for this version of HamQuest.

But this is not my primary topic today. I am doing some forward thinking, and it brings me great joy to make games like HamQuest, and so I’d like to continue in this line of games. But the current game mechanics are based on the game HeroQuest, which isn’t necessarily a bad thing, as they core of the game is solid, but a complete RPG mechanics system it is not.

So, I have been scouring the web looking at various systems. Thus far, they have fallen into two categories:

  1. Not enough.  A game in the “Not Enough” category is not complete enough to easily adapt it to my purposes.  This can happen because a game is too generic (FUDGE), or because a game is incomplete in some way.  In either case, I basically have to make a homebrew RPG system, which I don’t want to do.
  2. Too much.  A game in the “Too Much” category has more stuff in it than I can use in the game. Most tabletop systems fit into this category. Typically the reason a system gets lumped in here is because of an attribute like “Intellect”, which my game has no use for.  You aren’t going to use a “lore skill” in HamQuest, so the applications for “Intellect” are pretty slim, which basically means I’m cutting a bit of meat out of an established system, which means that the balance is off for the game, and again I have to homebrew it.

In HamQuest, the character has four basic statistics: Attack, Defend, Health, and Speed. Speed changes every once in a while (it is rolled on 2d6, and once that number of steps are made, it is re-rolled.  each step the player makes gives the creatures a proportional number of steps that they can make. it works out so that turns and speed are transparent to the end user).  Attack has a default of 0 with no weapon, and Defend has a value of 2 with no armor. Nothing increases these values ever in HamQuest. Health has a maximum that starts at 5, and increases 1 point per level of experience earned (this is where it departs from HeroQuest).  In Heroquest, all character had a Health and a Mind score, which together would add up to 10. Mind was rarely used in HeroQuest, and I had no use for it, so I ditched it, and gave a reasonable (to me) figure of 5 health for the player.

So, I had an ad hoc advancement system, and a pretty simple combat system.  The main issue is that all level 3 characters with the same equipment are identical. Not really a problem with a hack n slash game like this, but it won’t work larger scale, in a world larger than a dungeon maze.

Also, the game as it stands has four weapons, all of which are swords. What about mace, hammers, flails, staves, bows, arrows, etc?  Should they all be on the same Attack attribute?  Does Defend work the same against a melee weapon and an arrow?

So, at the moment, it looks like I’ll need to homebrew my gaming system.  Unless someone points me to a decent system that mostly deals with combat.