Uncategorized

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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s