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.

I hereby declare HamQuest “done enough to put it out there and see what happens”!

http://www.playdeez.com/HamQuest.html

HamQuest Loading 90% Done

Yes, I’ve reached the “90%” stage of doneness with the loader.  This means, of course, that I’ve gotten nearly all of the tags loading (I’m down to half a dozen, all concerned with the player state, which is much more complex than any other part of the game).

After those are done, I’m on to the SECOND 90%, which is determining why it doesn’t work.  I’ve done enough of things like this to know that there are about 10 different ways that I did this wrong that I’ll have to fix.  8 of them are really simple fixes, and 1 of them will have me scratching my head for days, and the last one will make it out into the field and be reported by a player, require a massive change to the software such that the old savegames will no longer work with the new software.

Viva la 90%!

Loading HamQuest

I’ve pretty much broken down at this point, and decided to make an external loader class for HamQuest savegames.

While the encapsulated “convert me to xml” functions work just fine for saving games, similarly internal “convert xml to data” functions become so bizarrely contrived as to make me cringe whenever I work on it.

It’ll still make me cringe a bit to have an encapsulated ToXml in all of the data classes, but an external FromXml loader class, but I’d like to get this done without rearchitecting it.

In other news, the backend to the playdeez.com highscore/user system is now mysql.  Still ASP accessing it, but it is a step in the correct direction.

New User/High Score System

From the day I first put it into HoneyComb until now, there has been a User/High Score system on playdeez.com.

The back end consists of old style ASP, which talks to an MS Access database through ADO.

Which makes it state of the art … for 1998.

As it turns out, however, my provider gives me a MySQL database as part of my hosting package, which makes it a little more 2008-ish, so after carefully considering that I did not want to completely rewrite my user system, I set about the task of migrating it.

Now this is a “live” system. Live in the sense that zombies are alive, anyway. I do not have any active users at the moment.  However, on the off-chance that somebody stops by and uses the old system, I didn’t want to leave out that persons activity the day I finally throw the switch on the new system.

Plus the fact that the new system will look ABSOLUTELY IDENTICAL to the old system until I can give it some sort of face-lift.  The only difference is the database connection.

Yeah, I wish “only difference” were the right way to put it.  For much of the migration things have gone pretty well. However, little snags have shown up in the old code not quite working right with the mysql odbc provider, requiring me to tweak the ancient vbscript to make it work.

And of course, the fact that the user/high score system was basically duct-taped together compounds the issue.

In this process I’ve had to reverse engineer a lot of my own code, as it has stood there in most cases for years untouched.

One thing I can say… I was *REALLY* SOLID at writing JavaScript about a year ago, a skill level to which I hope to return.  This will be especially important if I am to proceed with my plan, which is to port HamQuest to javascript, and have it playable in the browser.

But first: finish c# HamQuest and move user system into MySQL, then change ASP to PHP, then…

Saving and Loading HamQuest

I finally got a little bit of time again to work on HamQuest, and so I picked up where I left off, namely, the “load game” functionality.

Note to self: stop being so clever with things.

Most of my objects wound up tightly coupled, which is fine in a smallish project like this, but for the saving and loading aspects, this has been disastrous.

For example, I have a class called “CountedCollection”, which is a generic  that requires a type of thing that will be “counted”.  Really, this is just a wrapped up dictionary. It is so that I can count things like how many swords a room or a player has.

The ToXml function was easy.  blah.ToString() to send out the counted type.

The FromXml function… not so easy.  CountedCollection doesn’t necessarily count enumerated types, so the Enum.Parse function cannot be used.  I might instead be counting various string values.

So, I now have to pass a delegate to the FromXml function in order to enable conversion from string. Durp.

Quickly, this code base is turning into a slightly steaming pile of goofy code.

But, if and when there is a HamQuest II, I will avoid some of these mistakes.