La Salle Debain

Open Source @ Consolidated Braincells Inc.

Search for:

Show past days of news

About La Salle Debain

This is a weblog I'm keeping about my work on Debian and any other useful Debian related info I come across. It is not meant to compete with other news sources like Debian Weekly News or Debian Planet. Mostly it is just a way for me to classify and remember all the random bits of information that I have floating around me. I thought maybe by using a blog it could be of some use to others too. Btw. "I" refers to Jaldhar H. Vyas, Debian developer for over 8 years. If you want to know more about me, my home page is here.

The name? Debain is a very common misspelling of Debian and la salle de bains means bathroom in French.

If you have a comment to make on something you read here, feel free to write to me at jaldhar@debian.org.

You can get an rss 0.91 feed of the blog here.

Monday, March 15 2010

7DRL Challenge - Final days

I'm afraid that in the end I failed the challenge. As the last minutes of Saturday night ticked down, I was still mired in the minutiae of C++ Run-Time Type Identification (RTTI.) Sunday was my 12th wedding anniversary and I know from past experience that this is one day when it is advisable to step away from the computer. So I have to concede defeat for now. But I only actually spent about 48 hours on this project this week so if you really think about it, I still have 120 hours available. That's what I choose to believe anyway.

The galling thing is in theory I know how this is supposed to work. A.L.F.s model (in the model-view-controller design pattern) is a class called World. World has an array of Rooms which represent rooms in the dungeon. In my original almost working version of a few days back, this Room class had all manner of verious members for different objects in the dungeon but I decided to redesign it the right way by consolidating all the redundant bits into an abstract base class called Item which would have concrete subclasses: Potion, Treasure, Monster etc. Room now only has to hold a pointer to the Item associated with that room. (Later on I will consider allowing multiple items per room but for now there can only be one.) A factory function creates Items and assigns them to each Room (or leaves them empty) It returns a pointer to an object of the appropriate class but we can access that object through the Item* because they are derived from Item.

So far so good. The fun part happens when we want to know what the Item* really is. For example, combat makes sense for Monsters but not for Treasure. I only want to activate combat if the Item* is a Monster*. It's easy in theory:



if(dynamic_cast<Monster*>(contents))
    return FIGHT;
                            

...but it didn't work. Problem number 1. C++ RTTI only works on polymorphous classes. (Ones that contain atleast one virtual member.) So a little redesign of my classes was necessary. Problem #2, once you start slinging pointers around, segfaults soon follow. I had to go back and make absolutely sure I wasn't double-deleting objects and things of that nature. As I write this, I think I have finally got it all sorted out. So I am going to persevere and finish this game, its just going to take a bit longer than 7 days.


posted at: 02:13:47 | #