Busy Life Makes For Development Stand-Still

I got exactly zero time in on HamQuest over the last week.

On the assembla space, I currently have six tickets in order to reach the first milestone, which I tentatively put at the end of September.  This is me trying to establish a time specific goal.

Only six tickets, but that is deceptively simplistic. I know full well that two of the tickets, which are the refactoring of the main two classes involved in the game itself, will be quite involved and take quite a few times and more than a couple of tries in order to get it right. The others are more trivial, even the “save and load” functionality that I ripped out of the old version but have to put in new.

Also, one of the things I need to think about with saving/loading is the Rogue-like tradition of permadeath. It is against tradition to allow “save scumming” so common to other RPG type games. I’m not entirely certain I want to go with permadeath, but that decision is still a ways off. First I need to finish the rest of the refactor, because only at that time will I know the best way to save and load the game.  I don’t think I want to go back to the original xml file that I had before. I never even bothered trying to make it difficult to hack.  Of course, wading through the gigantic XML file was the price a cheater would have to pay in order to cheat, but so what?

Of course, a new issue with saving and loading is that the contents of the creature list and item list and terrain list are now configurable externally, which means that a player could conceivably save his game, go and modify the item, creature, or terrain lists, then load the game.  It is entirely possible for the configuration to not even make sense with the save game.  For this reason, I’m going to have to save and load the states of these tables.

But that’s a problem for later. Right now it is an issue of finding time to inch towards the goal line.

Untangling the Knot

First, HamQuest is now in an assembla space:

http://www.assembla.com/spaces/hamquest

Second, there has been a lot of refactoring in the HamQuest code base.

I’m finally tackling the “get the creatures into xml” task, and it is proving to be very challenging, and the reason it is challenging is because of the corner I painted myself into with how the creature that represents the player is represented in code.

Slowly but surely I’m starting to unravel the issue, but not without pain, and I’m surprised the thing still actually works after what I just did.

A creature on a map is represented in code by a Creature object.

A Creature object holds the state of the creature (mostly the wounded state), and an index into a creature table.

The creature table consists of two types of object: CreatureDescriptor and a PlayerDescriptor, which derives from CreatureDescriptor.

A CreatureDescriptor is just that: a description of the general type of creature.

A PlayerDescriptor is more than that: it also contains the current state of the player.

The intent was noble: make players and creatures use the same rules for the most part, and only differ when they actually differ in behavior.

In a CreatureDescriptor, the attack value is static. A goblin always has an attack value of 2 no matter what, and nothing will change it ever.

In the PlayerDescriptor, the attack value depends on the weapon equipped by the player.

Now that I’m moving both types of descriptor into the “property bag” model that I put the Items into, I’m using a generic function to grab out the values, but the property bag knows nothing of the values it holds… it just holds them.

So, I “cleverly” wrapped a value into a new “StatisticHolder” class, so that the same looking call can get both the CreatureDescriptor attack value in its own static way, and will get the dynamic value from PlayerDescriptor.

So now CreatureDescriptor is completely empty, and ready for moving to XML, and PlayerDescriptor is not.

Of course, I’m not entirely sure that there is a need to put the player descriptor into xml as a whole.  It may be good enough to put some sort of “base statistics” for the player, and have the player descriptor copy from them, and simply add the PlayerDescriptor to the end of the Creature List, but load the others from xml as originally planned.

In any case, one step closer to the goal, along with the change of almost all enums into static classes with const strings, which may seem crazy and untypesafe (and it is!) but with the mind I have for extensibility of the project, it’ll make sense in the end.

In any case, you can check out the code at assembla, if you want.  Try not to point and laugh.

Text Based MMORPGs

I have spent some time over the last week playing the various “Text Based MMORPGs” on the iPod Touch.

Invariably, they are variations on Dope Wars, and remind me more than a little bit of Kingdom of Loathing.

I found three companies that make them for the app store, and the basic designs are practically identical, but the implementations vary in the smoothness of the user interface.

I would put storm8 above the others, then playmesh, then godfather games.  All games are about the same. The business models are identical. Storm8 is better because of presentation and clean user interface, and they get some points for actually trying to make their reskinned games a little different than the others.

Deep down, these games are simply Hamurabi on crack, with the ability to “attack” other players and take their resources.

Oddly enough, there are elements of these in my two game concepts Island Interloper and Midieval Micromanager, as well as the branch of Dungeon Delver games entitled “Text Quest Lite”.   My original Dungeon Delver spun off into HamQuest, and will live its life as a roguelike.

Resource Micro-Management Games

Yesterday I posted about PlayMesh games.

I’ve taken a more intense look at the games they put out.

Originally, I thought the idea of taking exactly the same game, reskinning it, and attempting to foist it off as something new was stupid.

And yet I downloaded every version and played them.

I admit I did so mainly to find out what the equivalent of buying land in the vampire game was, or what the equivalent of the Godfather was in the robot wars game.

So, obviously Playmesh is not an innovator. It is a company like Blizzard, which takes a solid game concept and refines it to an enormously polished game.  There is another company, Storm 8, doing the same thing and with the same business model.

It is the business model that is absolutely brilliant. The game is a relatively fluffy abstract game of limited resource management. The limited resource is “energy” (or mana, or fuel, or whatever), which is spent to perform money making activities which can then be used to upgrade equipment or purchase income generating properties.  The reason that energy is the limiting factor is because when it is depleted it takes a certain amount of time to recharge.

Which shows once again that the only real commodity ever is time.

So, the business model is this: sell exactly the same game. Have a free version that gets you a very few cheat points, or a more expensive game that gives you a lot of cheat points.

If you buy cheat points, you don’t have to spend time doing the mundane tasks early on in the game, and you can do more advanced mundane tasks.  In essence, you trade “real” money for time, and you got the “real” money in the first place because you spent time in real life doing something to earn it.

So,  a very smart business model, although from what I’ve seen in their reviews is that they are rather polarized. Lots of people think the games are stupid, and lots really like them.

However, if they are going to go with themes, then they should really go further.  The most “disturbing” one was Vampire, but culture has made Vampires completely campy long ago.  Same thing for Mafia.

Be bolder, I say.  Be edgy. Make an evil cult theme. Make a porn star them.  Make a serial killer/rapist theme. Make a corrupt politician theme.  Make a drug addict theme.  Make a homeless person theme.

Even better, make a “freedom fighter” theme, and release it along side the “terrorist” theme.

Procedural Rhetoric of PlayMesh Games

So, I was using my iPod Touch today, and decided to take a peek at whatever new free games were available.

I find a Wizard themed game from PlayMesh.  I download it.  I go through the tutorial.  It is something like a Harry Potter-esque themed push button RPG, the like of which I’ve seen plenty of times before.

So I then download PlayMesh’s pirate game.

It is exactly the same game, with different graphics and different labels on the statistics and the character classes.  Except this time it is a Pirates of the Carribean theme.

And I downloaded the super hero theme.  Same game again.

And a mafia game.

And a robot war game.

I’ll be doing a more in-depth critical analysis of this game (I will refer to it as one game with many masks) another time.

Apparently the procedural rhetoric of PlayMesh is that your fantasies of being a wizard, a super hero, a pirate, a ninja, and a wild west outlaw can all be accomplished in precisely the same manner.

A Knead For HamQuest

Coming back to code that is “aged” to any extent (HamQuest is about a year old as a code-base), it is easy to spot the flaws and quick decisions that painted the code into a corner.

Normally I think “This code sucks! I totally need to re-write it!”

But then I asked myself a very simple question: “You have written games a hundred times. You have rewritten those games another hundred.  Since when has that ever actually helped you finish any of them?”

So I’ve been slowly going over the code.  In many way, software development is more like making bread.  We add stuff, we remove stuff, we mix stuff around.

What started out as a single executable has turned into an executable and two dlls.  Originally I had just split out a single dll for the game itself, but once I had done that, I could see that there were a number of classes that were generic (something of a pun as most of the classes are generics) enough that they didn’t have anything to do with the game specifically.  There is now a dll called PDGBoardGames, which includes things like a Board class and a Maze class, both of which generic enough that they can be reused whenever I need a board or maze provided I remain in .Net land.

As I keep pulling stuff out of code and into XML files, more and more of the existing classes become unnecessary.  Item management has had the most work done, and there is not a single mention within the ItemTable class about any specific item.  Everything is either in the XML file, or derivable from the data in the xml file.

So, my usual thoughts about a codebase like HamQuest is “If I had done it right in the first place, it wouldn’t be like this.”  But I don’t think that way this time.  As far as codebases go, HamQuest isn’t all that bad or convoluted, which I attribute to my having worked on code for a long time, so a number of good habits have formed along the way.

However, I have spent the last few weeks working over the code and making it do exactly the same thing it did before, just a little more flexibly.  Thankfully, I haven’t had any performance hits.

Looking Into The Mirror (Using Reflection)

In the switch to making items load from XML, most properties of most items were easy to deal with, as they consist of strings, ints, and bools.

One of the outlying cases was speed multiplier of armor, which was a float.  I had to change the XML slightly in some cases, because the values would parse as either int or float, and I wanted floats.  So I changed a few 1s to 1.0s.

The last remaining “strange” one was the inventory list for shops.  I wound up having to specify the type within the xml, and using reflection to find a static method that I could call in order to load them properly.  This solution works nicely, and gives me the ability to deal with some more of these “1-off” properties in the future.

It also scratches at the door of making the game extensible, meaning that with a little more work (and by a little more work, I mean a lot more work),  a person who is modding the game would be able to supply their own assembly to add behavior to the game, all without me having to hand out my source code (even though half an hour with ildasm will tell you everything you want to know).

In other development news, I’ve been considering  rather heavily the feature creep issue and HamQuest as a game.  There are a number of new features that I will be adding for certain(some new items, changing how the player interacts with shops, continued refactor for loading from xml), and those that I definitely won’t be adding(an XNA client, a Silverlight client – these will be separate projects)

Still other features I’m on the fence about.  There are four of these:

• The Dragon’s Fire Breath:  I’m leaning towards cutting this, as it would be the only ranged weapon in the entire games, and the dragon is pretty much too hard to kill already.
• The Amulet: The amulet, if I include it, would repel undead.  I was thinking of putting it in as a response to the ghoul and the necromancer.  However, considering that half of the creatures in the game are undead, does this item give the player too much of an advantage?
• The Escape Portal: This would be a portal that the player can carry with him and use when he wants to escape to a random other room.  Most of the functionality is already in the game. My main issue with it is that it would require a new control for the player in order to use it.
• Monster summoning portals: This would be a portal that, when the player walks onto it, will grab some other creature in some room and bring it into the player current room.  It would look just like any normal portal.  There are also ideas for a portal monster that teleports you when it hits.

So, in any case, we’ll see how it all goes.

Procedural Rhetoric and Ergodic Interactions

So, I’m enrolled in online school, and taking my first couple of classes.

One of my first classes is basically a “How to go to college” class, which covers some diverse topics as time and stress management, academic writing, reading strategies, and most recently – critical thinking.

As part of the assignment for critical thinking, I am tasked with reading some academic articles (of my choosing) and writing about them.  Since I am in an IT program, it is recommended that the articles have something to do with IT.

So, I found: http://meaningfulplay.msu.edu/proceedings2008/mp2008_paper_66.pdf

I picked an article on games…. go figure.

For a while, when initially reading this article, I felt like I was talking to Ron Penton.

I had to read it several times, as well as look up terms like “ergodic” and “procedural rhetoric”.

So far, I’ve about half-digested what the four page paper is saying (I think!).  A lot of it looks like someone used a thesaurus bazooka on it.

In the end, I think I’m starting to get a bit of a bead on something that I didn’t really have before.

Previously, I had no appreciation for academia.  I am an applied sort of guy.

I am starting to see how it is a very different world view, which has value in its own way.

I recently had a similar realization about the world view of manager-types.

So, in any case, I’m starting to be less of a “world view bigot”. Managers and adacemic folks are people too, it seems.

Best HamQuest Feedback Ever

This is old, but I just discovered it yesterday, so it is new to me:

http://feedproxy.google.com/~r/RetroRemakes/~3/iXfY21evtzs/

For those not wishing to click on the link, here’s the content:

HamQuest is a simple Rogue-like based on the rules of the HeroQuest board game.  It strips everything down to just the movement keys and an attack/defend toggle, but updates the graphics from the standard ASCII affair. If Rogue is a 12oz steak with all the trimmings this is a slice of low-fat bacon.

Fans of the genre may find this a bit too simplistic, but if you don’t want to invest a major portion of your life building up a half-elven level 31 wizard only to be struck down by the Balrog with one blow then this maybe more your style.  It’s still being updated with new features, so read your scrolls of teleport, get over to the forum and show some support.

I regard this as a positive review, even though portions of it don’t necessarily read that way.  The reason for doing so is because it reinforced the gameplay aesthetic I was going for: nicer graphics than ascii, but just barely; minimal controls; low complexity.

I especially like that HamQuest is a piece of “low fat bacon” compared to the “12oz steak” of Rogue.  At least it is some sort of pork, as befits a game called  HamQuest.

I’ll be including this review somewhere in the help file for HamQuest, and likely the support pages.

In other news, this evening, for the first time ever, HamQuest items were loaded from a config xml file, and not put together in code.  It is a momentous occasion, as this was one of the bigger items I needed to take care of in the refactor.  Naturally, the work is not done yet, as there are many things yet to be offloaded into the xml file from code, but at least I now get to deal with it on a configuration level rather than at a code level.

How To “Finish” HamQuest

I’ll be the first to admit it.  I don’t finish my games.  I get them into a playable state.  I get them to “good enough”, but I don’t get them to “finished”.

Answering “why?” is easy: building a rapid prototype is easy and fun.  Finishing a game completely is difficult and tedious and, yes, exceedingly dull in parts.

I’d like to actually finish HamQuest, realizing that in games in general, and a roguelike especially, “done” is a completely relative and arbitrary term.

So let’s define “finished”.  Finished means feature complete, content complete, documentation complete, and media complete.

I have to scale back my todo list, in this case, because two of the items on the TODO are a)port to silverlight and b)port to XNA. Technically, these should be separate projects.  I have recently split out the game into the game mechanics back end and a rendering front end (with a little bit of bleed from front end into back end still, but that’s also on the TODO).  So really my product has two pieces: back end and front end.

Mostly I’m concentrating on the engine part.  The front end cannot possibly be finished until the back end is complete anyway.

So, back end and front end are still muddied up, and that is my highest priority because doing anything else just causes more mud.

After that, the next thing to do is to disentangle the content from the back end.  Currently the item list, creature list, terrain list, and so on are all hard-coded in the back end. This is meant to be configurable, so this part will be crucial to the finishing of the back end.  Naturally, some of this work is being done during the splitting of front and back ends.  I’ve gotten through about 75% of the item types.  They are now in a much better spot for moving them into xml files, but I don’t want to do so until the rest of the item types are also dealt with.

After all content is out of the back end, then content changes are simply configuration, which means the back end moves one step closer to done.

Then it’ll be time to finish up the features yet to be implemented (a few item types, a few other “effects” on the character) of the game itself.

Then on to content and media completion, then on to front end completion, then on to documentation completion.

And finally, after all of that, I want to be able to have the game automagically update itself like other .NET apps do, so I need to start learning how to do that using the publishing mechanism in VC# 2008 Express(after, of course, I actually move the application to 2008 from 2005, and maybe 2010 by the time I get there, who knows?).

---

So… why this drive for completion?

Quite frankly, I’m tired of not completing things. Look at my game portfolio on PlayDeez.com. They are (completely playable) game prototypes, not complete games.

I can do better than that. I can make a fully professionally done and polished game.

I’m also realizing that, at this point in my life, I don’t get a whole lot of time to work on these games, so constantly distracting myself with other projects that are fun prototypes to almost make really gets in the way of actually accomplishing something that I can take seriously.