Congratulations to Angband.

A hearty congratuations to the Angband folks. The new version (v3.1.0) is now officially GPL, thus ending a saga over licensing that has dragged on for literally years. Whilst I'm not entirely a fan of the GPL (its a bit too viral for my tastes; yes, I am aware of the counterarguments that this may not the case), I do support the principle of open-source software where feasible (and there are many reasons why in some circumstances a closed-source/propriety-based route for software is preferable).

Hence Kharne, if it ever gets released will probably be LGPL at most. It cannot be GPL since it uses 3rd party VCL components which themselves are not-GPL compatible (for the record, the license terms of said components allow embedding and distribution in free software).

Getting back to Angband, a couple of change in the new version have caught my programmer's eye. Firstly,

"Set up an event system for UI display updates, where the game communicates with the UI by sending messages saying that something's changed that the UI might be interested in, rather than deciding that specific things should be redraw. The main screen updates all use this system now. Amongst other things, this system should help things like the borg and graphical frontends, because they can hook right into changes in state. (#348) "

Obviously Angband is at heart (and still is) a console application, but it is interesting to note they appear to have finally moved to a paradigm that window-based GUIs have had since almost the year dot. Its a heck of a lot easier for the UI to be in charge of updating the screen than it is for screen updates to be scattered willy-nilly about the rest of the code. As I'm not familiar with the Angband codebase to any extent beyond being "inspired" by its dungeon generation algorithm, I don't know the exact reasons for the switch now, but being a professional software engineer in my non-Roguelike existance, I'd put money on two things: 1) refactoring the UI code was most likely a massive job and they had to wait until they had a sucker^H^H^H^H^H^Hvolunteer lined up to do it, and 2) the previous code was getting really really REALLY unmaintainable.

The second change of note ties somewhat into this recent thread on r.g.r.d:

"Monster HP is now specified as an average value around which to randomise, instead of using a "12d5"-type calculation. Uniques always have the number of HPs specified in the monster.txt file, like before."

At first glance, this sounds like an attempt to blunt the fangs of that fearsome elite mob, the RNG. Is this such a good thing? I'm not sure. For standard monsters, isn't part of the "fun" finding one that goes down like a sack of potatoes, or one that is hard as nails? Or is the fact that one orc may have six times as many hit points as his brother simply random-masochism or the sake of it?

Programming Wars (not)

Sometimes miracles do happen. A recent thread on r.g.r.d. asked for advice on programming languages to use for developing roguelikes. And the corresponding thread didn't descend into a language war. Is the roguelike community finally growing up?

Bad Dungeon Design

Apologies for the lack of updates recently, this has gotten in the way.

There has been a bit of a hooplah recently over a new Dungeon Generation algorithm released into the public domain over on r.g.r.d. and touched tangentially upon over at ASCII Dreams. Here is a sample of its output:


I'm of the opinion that this is sub-optimal for roguelikes, primarily because of one main factor: geometrically, it is too deadly for any reasonable player. Leaving aside the obvious irony of this statement since roguelikes are a genre where one mistake in game-play could kill you forever, a map such as this tilts the balance of the game too far away from the RNG towards a style of game-play where the presence of even one OOD monster with extended following abilities means the level (and almost certainly) the character is a certain and complete and unavoidable write-off. A map such as this, lacking any in-level escape options, would almost inevitably lead to an overwhelming sense of frustration quite quickly, and would shortly result in whatever game used this dungeon design being deleted off the players' hard drive.

So what could be done to make this map more suitable? Not that hard actually (though I may be underestimating the difficulty due to not being familiar with the original algorithm). Each "branch" needs to be connected up with another (not just through the centre) to allow at least one alternative escape option for a player:


If this is done, I feel this could be another interesting dungeon design, one of many that roguelike authors could use.

Hiatus

Development of Kharne is in hiatus at the moment, despite my exams being over and life conditions ideal for coding. This is mainly due to a mistake of my own volition. I opened up Delphi recently to do some coding and was greeted by the following screen:

All standard and custom VCL components are missing and all settings have been reset back to not just default, but a pretty much empty configuration that is no good for anything except console apps. The packages (both standard and custom) are all gone as well and are unreinstallable. In short, my installation is totally corrupt. I think I caused this by partially uninstalling Delphi by accident whilst doing a major clean-up on the hard disc a while back. I’ve tried reinstalling Delphi but despite hacking about in the registry I can’t get any custom components reinstalled.

There’s an old urban myth going about that the Chinese word for “crisis” is a conglomeration of the symbols for “danger” and “opportunity”. So I think I’m going to take this opportunity, when funds permit, to upgrade my development environment to Delphi 2009:

Once I do that, development will restart at full throttle. In the meantime, I hope to be more active than recently on various aspects of roguelike programming.

Delays and Delays and Delays...

Yes, I'm aware I was meant to have released a version of Kharne by now. Unfortunately, real life has intervened quite dramatically over the last weeks/months. I have exams coming up in early October and once those are over, I hope to get back finally to development, Wrath of the Lich King not withstanding. I'll also release what I have coded so far at that point (although many things will still be incomplete of course, but such apparently is the life of a Roguelike).

In other RL news, its good to see Lords of Dark Hall is now back in active development. And a new (even harder, I suppose) version of Crawl (I'm still playing and dying in 0.3.4). And I also notice that LambdaRogue which only recently achieved the magical 1.0 status, is currently being rewritten. From personal experience, I can tell you that this rewriting business is a dangerous two-edged sword. As I recounted before, when I tried this for the original version of Kharne, it depressed me so much it stopped me writing any code for about five years.

And of course, where would roguelike development be without a flamewar (surprisingly not on r.g.r.d. this time). wouldn't be the same place without a major flamewar. On rec.games.roguelike.misc this time. Over permadeath, inevitably. Years and years ago, I would probably have agreed with the posters who (rudely) advocated not using permadeath. But now, let's just keep things, and especially Crawl, the way it is, ok? That's what makes it Crawl.

Design Decisions and their Consequences

Back in the days of 8-bit computing, a popular genre of computer game was the text adventure. My formative years in computing was based around them, and to this day, one of my favourite computer games of all time is Heroes of Karn:

Despite the limited (and often downright annoying) parser, to this day, this game has an atomphere and an ambiance that is unsurpassed.

But one of the ironic things about this game is that in one particular area, this 1983 game is more advanced than Kharne is, some 25 years later. And its because of a design decision I made a long time ago, back when I first was programming Kharne.

I'm talking about the ability to have multiple items in the same location:

In Kharne, I have discovered I cannot do this, without extensive modification of the code, because the Dungeon object represents items currently located on in the Dungeon (e.g. on the floor) by a single 2D array of integers:

Objects: array [1..DUNGEONSIZEX, 1..DUNGEONSIZEY] of integer;

Of course, representing objects in the dungeon this way has advantages - it is dirt simple to program and is extremely quick - but it disallows more than one item per square (it still allows a single stack of items, such as 19 arrows for example, as stacked items in Kharne are merely an instance of a single item with a "count" attribute).

Now, it wouldn't be horrendously hard to refactor item code to allow multiple items per square - indeed the Roguelike Dev FAQ at Roguebasin mentions the standard method of doing this:

"...For the list of items, use a linked list. This allows many items to exist on the same tile. Store a pointer to the beginning of the list. The pointer takes up 4 bytes of memory...."

Leaving aside the gratuitous Unix/C-ism ("the pointer takes up 4 bytes of memory...") . implementing a linked list would probably be trivial.

So why am I holding off from doing this? Why do I think that, for now, I'm better off with only one item per square?

There are four reasons I can quite quickly think of:

Firstly, consistency. Now, yes, roguelikes aren't noted for consistency - for example, dragons ("D") take up the same amount of space in game as a rat ("r"), and arguments for and against consistency on r.g.r.d. are notorious for producing much more heat than light. But there is something especially jarring about having a rat take up the same space as three swords, four maces, two sets of armour, four goblin corpses, and a kitchen sink.

Secondly, at the moment, Kharne levels are not persistent. They will be eventually (to a limited degree), but when you do not have persistent levels, then there is no point in stashing. Stashing is a powerful argument for multi-item storage.

Thirdly, its something else to worry about - another obstacle to getting the game out. Already, this rewrite of Kharne has turned into something much more extensive than I'd ever imagined - but its more of a marathon (in the sense of a journey) than a sprint.

Fourthly: how often in a RL (leaving aside stashing, obviously) do you actually need to stack items? When does it become tactically necessary, nay, critical to do so?

Your thoughts are welcome on this.

Incidentally, if you try and pick up the money, the Barrowight prevents you. The solution to the this dilemma is to "ATTACK BARROWIGHT WITH CROSS":

Obviously the cross is a thinly-disguised Mace of Disruption. Handy that. Much too powerful to put into a roguelike, obviously.

Here we go again....

Well, after the little break I've had due to RL issues, I've restarted serious coding on Kharne again. Look out for more information soon. Rather embarrassingly, I've just realised that there was no Drop Item functionality in the Inventory screen, so I'm currently implementing that. Data entry and framework coding for Monsters is on hold until I get the Drop functionality finished.

On a slightly different note, there's a new thread on r.g.r.d. entitled 'Is "identify" really good for the game?', which does as it says on the tin. I'm sure this has been discussed in the history of Roguelikes many times, and I think I'm in the camp that says, overall, that the ID-minigame is indeed good for the game as a whole. It is however, a real bitch to code, when you're working with non-primitive item data structures, as I am.

In other Roguelike news, Mario Donick has released v1.0 of his roguelike, Lambda Rogue. Its a rather splendid game, and even more splendidly, is written in Free Pascal, which is fairly compatible with Delphi. Mario and I both use the Recursive Shadowcasting Algorithm to generate FOVs, and I think I speak for us both when we say we're very happy with it. Congratulations on your achievement, Mario!