Dungeon Crawl Stone Soup

I finally crawled back into the world of RougeLikes, I could never bring myself to play any ASCII version consistantly. I've been hooked on 'Dungeon Crawl Stone Soup'. Which has a graphical version (tiles) aswell and is updated quite alot.

The mechanics are similar to D&D rules. You start off as a single guy trying to get to the bottom of a dungeon, steal an orb and get the hell out. Simple as that.... until you play it.

My favourite and the most fustrating part of the game is the immense unknown. The first time you die on the first floor cause you drank a potion of poison will make you scream and laugh all the same. You'll quickly learn how fragile you are and that everything in the game can be a deadly threat. The moment you feel strong you're almost gauranteed to slip up and send your hero to the grave.

Aslong as you can transition to the "take your time" attitude, you'll find the game easy enough but it could take years to actually beat it.

Rough RougeLike

A post or two ago I mentioned a random dungeon generator I was messing around with. I figure it's a great jumping point for trying a small RougeLike project of my own. So I put together a simple prototype, just melee combat.

I've spent a bit of time working out the base structure of the game, the objects and divisions of the program. Hopefully it's just a matter of
coding it all now. The major roadblock I'm trying to decide on first though, turn order and queueing actions. In the prototype, there was only two actions a creature could take, items can't take actions. They either walked, attacked or did nothing. It was pretty easy to queue a simple struct like so;struct ACTION{usertarget;type;}


An actionProcessor object would store all the actions in a vector, then when it came time to process the turn. it would sort
them all by the users speed and process the actions one by one. I plan to use something similar, but I'm also storing creatures, items and all
other objects different then before. Before, the handles to the actors were very loose. The actor could be nonexistant and the handle could
still be used. it would just cause the action processor to disregard the action entirely once one of the actors wasn't found. This wasnt a
bottle neck what so ever in the prototype, but I wouldn't think so with only 15 actors present. I plan on floors with 200+ objects present all
the time, so looking through an entire list of objects everytime I want to find one isn't going to work.

I decided to go with a simple quadTree container that will be used to store the actual objects. Then the controllers and actions will use iterators into the sub containers that hold the objects. The actions take pointers to these iterators as aurguments for the user and targets of an action. This means iterators can't be removed until all actions are processed or so voodoo needs to happen to remove actions with iterators that were removed while it's processing, and that just seems wasteful. Simply checking if either is invalid because of death or out of range or etc seems more logical.

Now that I'll be using more fragile pointers, and quite alot more actions; also with items being and other objects possibly part of a given action
but not all. It makes it a bit more complicated. Hopefully it'll all come clear after I finish my list of every action I want to be possible.

I already am thinking I'll have seperate processors for item type with specific functions for the different actions / effects that can occur because of those items. Equipping as simple as it seems is a perfectly good example of an action.
// basic action infotype = action_equipuser = selftarget = self// equip specificequipment equipment

The action processor can read that its an equip actions which would then pass all the data to equipmentProcessor.actionEquip(....), these could simply be utility functions. I'm thinking of using a base class action that has the basics, user, target, type, but will also have a processor id. This id will simply tell the main action processor which sub processor to pass the action off to. Then that processor will know how to recast it and process the action.

My brain is brimming with ideas now... Happy coding, next time I should have a worth video ;)