La Salle Debain

It's time once again for the 7-day Roguelike challenge. This years attempt is entitled "Casket of Deplorables".

Further updates will be posted here.

It's time once again for the annual 7 Day Roguelike Challenge. I know I said I wasn't going to take part again until I properly finished one of my previous entries but I've thought of an interesting and novel game mechanic that I'm eager to try out so what the hell.

If you are interested in following my progress, I will blog about it here starting from Monday and (hopefully successfully) finishing on the following Sunday.

Of course the best part of it is coming up with names. Here are this years choices:

• letsen[terthe]crypt
• Make Narnia Great Again
• Thane of Groans
• I Am The Black Wizards

It's time once again for the Seven Day Roguelike Challenge but I've decided to try and force some discipline on myself and not participate until I actually complete one of my earlier entries into a properly playable game.

I did have some fun thinking of names though.

• Fifty Shades of Grue
• The Intothegroundening
• Game of Spiky Chairs

Each year the 7DRL competion gives me an opportunity to abandon developing a roguelike game part way through. This year I am going to strive mightily to actually complete a playable game though owing to family commitments I have already gotten off to a rocky start which does not bode well.

But enough negativity...

So this year 7DRL coincides with the first ever Procedural Death Jam. This is a similar type of thing except the genre is Procedural Death Labyrinth. Procedural Death Labyrinths are a subset of Roguelikes (or is it the other way round?) If you have taken advantage of the wonderful offer Valve has given to Debian developers, you can find a number of examples of Procedural Death Labyrinths on Steam.

The most important part of any software development project is of course choosing a cool name. My game is called "The Girl Who Played With The Dragons Nest" (Can you guess what I've been reading?) It is written in C++ with the Curses toolkit. It will of course be open source.

I intend to blog my progress here if you care to follow along.

Kanzepharaz of the one thousand and eight spires. Kanzepharaz capital of the Empire of K'thorv and since the succesful end to the war that led to the annihilation of the Pleiadic Oligarchy in K'threl, the richest and most splendid city in the Middle World. Kanzepheraz whose real estate prices have soared e'en beyond the calculation of the rainbow abacus of Thobis Himself.

Anathomelis, a princeling of the Imperial Clan needs a location for his new and expanded orgy dome. Yet the only available—and affordable on a seventh rank civil allowance—place left in the city of one thousand and eight spires is the tomb of Pharaz the First and Subsequent, lich-emperor of the Jerelite dynasty and his eldritch retainers. Before the construction-serfs can move in, the tomb must be cleared of its unshriven and non-rent-paying denizens.

As His Principalities' chief swordbearer it has fallen to you to make the tomb of Pharaz safe for gentrification. Treasures and honors await you if you succeed. Aeons of torment in the Planes of Unlife await you if you fail.

WILL YOU RISE TO THE CHALLENGE?

rec.games.roguelike.development is having another challenge, this time to complete a roguelike game in four days. My previous attempt to write one in seven days was a failure but as I can build upon my previous work, I think I can make it this time.

This time I did not waste lots of time thinking of a name. S.Y.T.Y.C.D...OMG? and The Real Housewives of Mordor were the only ones under serious consideration.

With that crucial task out of the way, I spent the morning ripping code out of A.L.F. wherever possible. In the afternoon, I looked into dungeon generation.

My previous experiments with this sort of thing were pretty convoluted but now I think I have a simpler algorithm which still provides a random yet plausible-looking map. It basically goes like this:

1. Divide the map into a grid of sectors.As the S.Y.T.Y.C.D...OMG? map is 60×80, my sectors are 20×16 giving 3×5 grid.
2. Mark each space on the map as impassable.
3. In each sector, pick a random square as its "center" not too near the edge of the sector.
4. Join each pair of centers first W -> E and then N -> S. with passable spaces. These will be the corridors and doing it this way ensures all sectors will be connected. Last time, my mistake was making rooms first and then corridors which is much more complicated to get right.
5. For each sector, there is a 2/3 chance it contains a room. If there is, randomly a number of spaces to each side of the center square. These will be the dimensions of the room. Make all the spaces in the resulting rectangle passable.
6. Randomly take a quarter chunk out of some rooms making them "L" shaped for a bit of variety. (at some point I can add round, polygonal or other shapes.)
7. Create "walls" by making all the outer boundary spaces of the room impassable again. This also ensures rooms do not touch or overlap.
8. If a wall meets a corridor, turn it into a "door." Doors don't do anything yet but eventually will be locked, trapped etc.
9. Finally, place monsters, treasure, and items in the room.

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.

So I've got combat, I've got basic potions that restore health and I've got items such as weapons or shields which can affect your combat stats. Try as I might, I cannot get ncurses to give me a yellow background for some unfathomable reason. It just comes out brown no matter what. Ironically, in the next Konsole over, I have the alpine ncurses-based mua taunting me with a yellow background. I'll look in its source (yay open source!) to see how its done sometime but for now brown will have to do.

C++ is proving a joy to work with as always. Ok It's probably just me; I use it so infrequently, I keep having to relearn how to do multiple inheritance and abstract base classes each time. I am rather proud of figuring out how to access class members from a signal handler without having to look it up.

Now if I can quickly tie up some loose ends, I can spend the last two days maybe making the dungeon generation more roguelike.

I am still being plagued by the burdens of real life so most development is taking place after the kids ("It should have mermaids! And Spiderman!") have gone to sleep. By the time I finished up yesterday, I was too tired to blog so this is is a combined report on the last two days.

I decided not to bother with Javascript as I want to try a different project for the plasmoid competition. So I'm back to C++ and ncurses. At this point my '@' can move across the dungeon which at the moment a very simplistic 10×10 grid where every space is a 'room'. Rooms are populated with monsters, treasure and items though at the moment only the monsters can do anything and by anything I mean fighting. My combat system is based on Solo Dungeon Bash and pretty challenging I think. Hopefully by tomorrow, A Lively Fisting will be playable though I really need to pick up the pace if I want to finish on time.

I've decided to take part in the 2010 Seven Day Roguelike Challenge

My entry will be written in JavaScript as a KDE4 plasmoid (thus simultaneously allowing me to take part in this competition)

Unfortunately today had to be spent in RL family activities so I'm already behind. however I've done lots of research into Roguelike development and I have accomplished the first step—finding a name. Candidates are:

• Descent into the No-No Area
• Going Rogue
• Battle For Quiznosth
• Tol-in-Gaurhoth

...and the winner is:

• A Lively Fisting

It will be a simple combat heavy coffeebreak game inspired by things such as Solo Dungeon Bash and Pocket Dungeon though as time permits I will add as many more roguelike features as I can.