Archive for July, 2009

HQ1.0.0.7

July 26, 2009

I had been going through a large code overhaul, but some negative reactions to some of the features I put into 1.0.0.6 have caused me to change some things around a little.

Mainly, folks did not care too much about the thieve’s ability to steal megaham.  It was compounded by the fact that, if there is a creature in a room, the room indicator is red, whether or not there are any items in the room.  This was by design in the original version, where monsters didn’t respawn and once a room was empty of creatures, the player could take items unmolested.

I haven’t completely abandoned the thief taking megaham… I have simply made it less likely.  There is now a 10% chance that a thief will take your megaham.  Usually he will just steal gold.

I have also added new minimap indicators so that rooms with items and creatures can more easily be picked out.

This will be the first version where the gameplay iteself takes place inside a DLL consumed by the UI applications.  Basically there is zero impact that I can detect.

Knotty Umbilical Cord

July 19, 2009

(^ That title should cause some interesting search results.)

Realizing that my added features to hamquest were only making the codebase worse, I decided to do some cleanup.

Also, because of my desire to make the game easily ported to XNA and Silverlight, I decided to split out the rendering code from the game mechanics code.

For the most part, this was easily done. Having written a number of board games, I typically try not to muddy rendering code and game code together.

There were only two classes that rip the veil between rendering and game logic.  One was shops, and I felt it at the time I was doing it. This one will take some ironing out, likely with some sort of “shop proxy” object shared between the game code and the display dialog.

The other one is in my message queue, and I’m not entirely certain what I want to do to straighten it out, if anything.  Ideally, I just want to remove System.Drawing as a reference from the class library.  In fact, all I actually need it for is Color, of all things.  Likely I’ll replace it with an int or something, and put a color array on the rendering side.

Of course, the whole message system needs revisiting anyway, but that’s a much lower priority than the stuff like moving the item descriptors to XM, for which the pre-work is progressing apace.

Also, as I’m progressing with the shape that the game code is in, I am thinking more and more about opening it up, a la sourceforge or assembla.  In my faith walk, I’ve had to come to terms with games as stewardship of time, and whether or not making games is a worthwhile pastime, spiritually speaking.

I realized the following thing:  activities that foster community where faith and community can be shared are good.  Activities that foster isolation where no faith or community can be shared are bad.  Basically if a game brings people together, then ok.  If a game serves to separate people, no good.

Which leaves hamquest in a rough spot, because it is a solo activity, and also would not lend itself well to multiplayer.

However, as I’ve been going along with the remodel, it has been slowly shaping itself in a more “moddable” direction.

Which is the answer to community. There exists a pretty large roguelike community, with folks of lots of skill levels.  By and large, HamQuest is, code wise, a lot closer to “beginner” code than most roguelikes.  Plus the fact that I’m working to make it customizable WITHOUT changing the code through XML files means better opportunity for those who wish to dabble and toy with it art wise, code wise, or simply modifying the xml creature and item descriptors.

So that’s sort of the direction I’m wanting to head with HamQuest.

Why I Don’t Post Much On Forums and Such

July 19, 2009

I used to post rather prolifically on message boards/forums/etc.  I don’t any more.

I also don’t do much with Facebook, and nothing with Twitter.

I finally discovered why.

First, that sort of communication is no longer ingrained in my life the way it used to be.  This I knew already.  Years ago I had many more “online” friends than people I associated with in person.  My life changed.  I am no longer on a computer 18 hours a day at home.  At work it is frowned upon to carry on an online presense all day, and I have a wife, a home, a lawn, a garden, a dog, in-laws, online school, and everything else.  There are many things I like to do on computers: play games, make games, go to chat rooms, post on forums, and so on.  Since I am limitedin my time, I have to prioritize what I do.  Often I fail at prioritizing, and so I waste my “precious” time on the computer.  My favorite thing to do is make games, so I try to focus on that.

Second, I actually *DO* attempt posting on forums. In the last week, I gave up and closed out four postings on GameDev.net.  They were starting to get long, like into article sized posts, and I simply did not have time to put in what I wanted to say, so I decided to say nothing, and cancel the post.  I used to write article type things, and books and such, but they are time consuming, and I don’t want to (again) spend my limited time writing an article in response to a thread that few people will read and fewer will care about.

I like this blog format, though.  If I get stuck for time, I can always save a draft, which is not as possible on forums. Of course, remembering that I have a draft waiting to be completed is another thing entirely.

Also, about a week ago, I suddenly clammed up about HamQuest.  The reason is the cavalcade of other things in life.  I had a yardsale yesterday, and people were dropping stuff off and we were organizing stuff all week.  HamQuest got no love.  Also, we are going on vacation this week, and I’ve got online school to complete for the week prior to leaving, so no love for HamQuest.

And my time is up!

“Summoned” Creatures and Experience Points

July 13, 2009

Had to come up with a fix today in HamQuest regarding monsters and experience points.  In particular wandering monsters and creatures summoned by a necromancer or summoner (both of which were implemented today as well).

The fix is that no experience will be awarded for killing summoned or wandering creatures.  The reason for this is that the player can exploit summoned and wandering monsters to farm experience points (a sufficiently outfitted character can whomp on the lesser creatures  for quite some time, and rack up experience points while doing so).

So, a player could (and I did)  run away from a summoner, who will happily keep sending more goblins after you. I was pretty well armored and armed, and was able to pick off lots of goblins, orcs, and fimir before I finally got tired of it and killed the summoner. I likely could have gained two experience levels in this way had I continued.

A similar situation occurs with wandering monsters.  Currently the mechanism I use does a check for wandering monsters each time a room is entered (and the algorithm used guarantees no wandering monster the first time the room is visited).  A player can just stand in a doorway and blip back and fotth between two rooms, eventually generating an infinite number of creatures.

Now that they are no longer worth experience points, they are completely a nuisance to the player, especially the thief and ghoul, who are now a part of the wandering monster brigade.

Of the creatures now added, I would have to put the Dragon as the deadliest (I tried to fight one… I burned through 15 potions and hardly scratched him) and the thief as the most annoying…. easy to kill but he steals megaham pieces!

I’m now in a refactor of the code as well.  One of the things that will make further development easier is the ability to put the item descriptors into xml file, which means I need to make the classes representing items more into property bags, so make the xml easier to work with.  Actually, this is part of a more overall “configure the game with xml” effort, which will pay off in the long run.

Also, I have found HamQuest to be a new kind of game development experience for me.  Usually, I will come up with a little game, make it “done enough” and never touch it again. If the game is simple enough, I’ll port it to every platform/api/language I can find, but it doean’t really progress from the state I leave it in.

HamQuest has begun a life of its own.  I may set it down periodically, but I don’t think I’ll be able to set it aside completely.

Corpse Looting (I wonder what sort of spam comments I’ll get with the word ‘corpse’ in the subject line?)

July 10, 2009

HamQuestSS_LootCorpse

Yep. It officially happened.  I got killed by a skeleton, and then the thief looted my corpse!

It reminds me that I need to fix up the messages.  The whole “a thief missed you” just makes me want to say “awww. i missed you too, thief!”

HQ1.0.0.5

July 9, 2009

Link to page

Link to game

A lot of developments between the last couple of versions.  For one thing, the game is a lot harder right now as a result of being unbalanced.

I have rudimentary shops now (called Shoppes, as any good tongue in cheek wannabe roguelike would have), and likely there are about a dozen or so bugs that I haven’t found in the game.

My “help screens” are out of date now, but as they are going to continue to get more and more out of date and I don’t want to be spending half of my time updating them, I’m going to wisely leave them for later in the process.  It still has enough information for the end user to play.

I have been playing a lot, and in playing I think one thing that is good is the starting condition of the player.  He is equipped with a dagger, a torch, and some ham. Also, all of the creatures that aren’t behind a locked door are on the weaker side now, so provided he doesn’t find himself surrounded, the player typically has a reasonable chance of succeeding through a few rooms.

However, the dagger will be done after killing several creatures, the ham will undoubtedly run out if the player doesn’t find some armor, more ham, or more potions, and that torch is practically going out already.

So this is good, as always, because having the player immediately in a crisis will get the player to engage with the game.

Also, I think the bosses and monster spawning is going to really help the end game (currently, the game is hard, and I haven’t played a full game to success in over a week).  I have now made the mistake of walking into a room with not even a torch or a single potion, only to have the dragon waltz over and kill me.

The move from traps that are always visible to ones that you have to detect by walking next to them is fantastic.  It completely changes the way a pleyer navigtes a room.

Anyway, I am quite excited with the new stuff.  I think I need to open it up on gamedev’s help wanted section to get some playtesters putting some time in on it.  Thats always a mixed bag, because there will be a lot of feature requests, but thats what happens when you roll the dice.

HQ1.0.0.3 Self-Check

July 6, 2009

HQ is updated and uploaded as of this weekend at version 1.0.0.3.  I actually have even more content in the game, but I wanted to get the monster respawning stuff out quickly.

http://www.playdeez.com/gamesfordownload/HamQuestInstall.rar

This version does also have durability based items, no longer random percentage breaking.  I also have adverse effects of armor on speed, so that’s something interesting to see how it affects balance.

I also yanked out the “how much light duration is left” statistic, and replaced it with the same sort of visible mechanism for determining how close an item is to breaking (yellow and pink highlights — stole it from diablo!).

I know already that I made the dagger too un-durable in this version.  10 hits and it breaks.

I have yet to play through a full game with the new fixes/adds.

One of the things I’ve noticed, though, is that the start of game phase (the dash away from danger and looking for weapons and potions) is still there, but the urgency for weapons is slightly less.

I’ve also found that throughout the course of the game, ham doesn’t stay in inventory very much.

Features “Completed”, Revealing Features Needed

July 3, 2009

Today I was able to polish off a few enhancements and fixes for HamQuest.

One, I have “finished” the trap spawning upon acquiring megaham feature.  Naturally, the spawning frequency of the various types of monsters will need tweaking, but the feature is in, and waiting for the right settings to be determined.

Two, I switched the weapon and armor breakage rules from random percentage with each hit to a durability system.  Now items are worn through use until they break.

Three, I fixed a glaring omission in the rules regarding armor. Previously, armor had absolutely no effect on movement.  Now it does.  Chain and plate armor have a speed roll multiplier (technically, so do shields and helmets, but they are both 1.0) which is multiplied into every speed roll.

However, these three new pieces lead to more ideas and decisions.

First, now that armor adversely effects the speed, shouldn’t there be another item that counteracts that effect?  I’m thinking magic boots.

Second, now that there is item durability, I’m thinking that I need some way of communicating that to the player visually, so I’m thinking of putting colored highlights behind the currently equipped items.  I’m also thinking about replacing the light duration timer for the currently in use light source to a similar thing.  Likely the colors will be yellow when durability is less than 50% and red when less than 25%.

Third, now that items are affecting the speed of the character, the fight mode becomes more complex.  Right now, the characters equipment is optimized for attack or defense, but not for speed.  Speed is ignored completely because before it was never modified.  Now the three need to be prioritized when certain combinations of items are carried.

As a side note, I was pleasantly surprised with how easily I was able to switch from a percentage breakage system to a durability system.  I was concerned that it was going to take a complete architectural overhaul.  It did not.

I think after I’ve wrapped up one more feature (wandering monsters) I’ll be ready to release revision 1.0.0.3 of hamquest.

The Quest For Ham Continues…

July 1, 2009

I’ve roughly put in the first of the new features into HamQuest, namely respawning of monsters when a megaham piece is acquired.  After a few minor snags, it works.  For the moment, I only have it add goblins, but that’s simply because I haven’t made my generator table for the various monster types.  That’s next to be implemented.

I decided to only replace traps with monsters, and not chests also. I felt that getting rid of chests was unfair to the player.  Besides, when I’m playing I tend to open all of the chests in the room anyway, whereas I avoid the traps.

I also have found that I tend to open chests last, after collecting all of the known goodies. Mainly, this is because a chest might contain a teleport.  In any case, this is what I expect my players to do as well.

I haven’t really worked on the code base for HamQuest in months.  I remember that it had its quirks and issues. I also have been coding for long enough to know that I should not fix them and refactor them into my vision of what the code should look like.  I do not get graded on the perfection of my code.  I get graded on how fun the game is.  My code has warts, and while I don’t always like it, I learn to live with it.

I will, however, be doing something of a refactor for some of the code as a result of the new features.  One of the new features is to finally switch from the percentage of breakage model for items(which I quickly learned to hate) and substituting a durability system whereby the weapons and armor get slowly eroded and destroyed because of use.  Naturally, this will throw the game balance out of whack again, but so be it… adding the other features throws it out of whack anyway.

I’m also really looking forward to adding persistent tenacious monsters.  Currently my thought is to include the wizard, who will use magic to conjure monsters and teleport himself around the maze, and the thief, who does what thieves do, and take your stuff, only to hide it elsewhere.