Wednesday, 21 May 2008

Progress Report #4

Not that much has happened in the last few days on Kharne, progress wise, I've been busy doing other things in that strange place called Real Life. Most of the time that I've actually spent on Kharne I've spent refactoring some of the data handling routines to finish their conversion from flat-text storage to reading from the SQLite Database instead, but I'd like to present a little feature that I thought worked really well all the way back in TKAngband, and is pretty much an essential part of MMOs, and which I'm reproducing in Kharne. Ladies and Gentlemen, I present to you:

The minimap.
. Unlike the console version of Crawl*, for example, where you can't display the map and the dungeon view at the same time,

Kharne's minimap is in a separate window that can be displayed and hidden at will, dragged around the screen, and auto-updates as the player moves around the dungeon (always being centered on the player). I think its quite a cool feature, and I'm surprised more windowed-roguelikes don't implement it.

* Yes, I know Crawl's map offers additional functionality like traveling, but traveling is unlikely to be a feature of Kharne for some time. Incidentally, the tile version of Crawl does indeed have a minimap.

Monday, 19 May 2008

Metaplots and Dungeons

All Roguelikes have metaplots, even if its only to give a thin veneer of reason as to why our little '@' hacks his (or her) way through dungeons. In Angband, the goal is obstensibly to defeat Morgoth. In Crawl, its to recover the Orb of Zot. In Nethack, its to recover and ascend with the Amulet of Yendor. Larn has an unusual plot device - the goal is for the player to traverse a dungeon in search of a potion that will cure his ailing daughter of 'dianthroritis'.

I haven't decided what the metaplot for Kharne will be yet, although I'm very interested in exploring different aspects of Roguelike gameplay during the different phases of the game. To this end, like Crawl, I'm going to implemente themed dungeon branches. Unlike Crawl however, I want all the different dungeon branches to be theoretically accessible from the town level (with one exception I'll come to later).

Each dungeon branch will consist of 10 levels, of increasing difficulty. There are 9 branches, therefore there are a maximum possible 90 levels to delve through.

Before describing each dungeon branch, there are a few important things I'd like to note about the intended gameplay:
  1. The challenge to the player should increase as he/she delves deeper. This isn't just a matter of throwing bigger and tougher monsters at the player (although this will happen), rather, I'd like to throw the player into progressively tougher and tougher situations. I have a few idea for implementing this other than some of the standard Roguelike fare, e.g. Vaults, Mutations and increased Monster AI.

  2. I want to avoid Angband-style grinding (e.g. the so-called "Stat-Gain" phase). It won't be necessary to visit every single dungeon or indeed every single dungeon branch - in fact doing so will increase the chances of a death since levels will be dangerous. Dungeons are semi-persistent - whilst within a dungeon branch, levels are persistent, but as soon as you leave the branch and return to town, they will disappear, Angband-style.

  3. I want to allow multiple paths through most of the game, to increase replayability. This would be as well as the standard roguelike randomness replayability. To achieve this end, all dungeons with the exception of the final ones are completely optional.

Player start out in the town level, called the Nexus:

The two introductory dungeons (suitable for levels 1 to 5), are The Wilderlands and The Fortress.

The Wilderlands is built using the cave-generation algorithm whereas the Keep uses the rooms-and-tunnels approach. The Wilderlands will be very much themed upon an outdoor feeling, with animal-themed foes, whereas the Fortress will have a martial setting and will be filled with goblinoids. It is intended that the player uses these two dungeons to learn the basics of Kharne's gameplay and to start the gearing-up process.

Beyond that, there are two intermediate dungeons (suitable for levels 6 to 10) - The Mausoleum and The Keep:

Both use the Rooms-and-Tunnels approach, and the Mausoleum is an undead-themed dungeon whereas the Keep is filled with magical artifacts and creatures. At the moment, I'm intending to have the first vaults appear in the later levels of these dungeons (although vaults aren't implemented at the moment), and the purpose of these are to equip the character with items that are necessary to venture further in a safe manner.

The Advanced Dungeons are suitable for levels 11 to 15 and are basically the Elemental Planes - the Planes of Air, Fire, Water and Earth:

At the end of each dungeon, on the bottom level, is a heavily guarded Elemental Key. This serves two purposes - one of these must be collected to allow the player to enter the final Dungeon (it doesn't matter which elemental plane it comes from), and also one will allow the player to resurrect once, with some....far-reaching consequences (I'll discuss this in more detail in a later post).

And then we have the endgame dungeon, suitable for levels 16 to 20, and the final part of the game. At the moment, its called the Abyss, and its filled with demons and devils and other similar creatures. There will be a macguffin at the bottom of this dungeon, the obtainment of which will be the game's victory condition.

Although the majority of foes in each dungeon will be specific to that dungeon and themed to fit in with that dungeon's theme, there will be a set of common foes across all non-Abyssal dungeons. Some of these will be in the form of demonic and elemental "invasions", with creatures scaled appropriately to the current dungeon difficultly (effectively these will operate as moving and non-permanent vaults). Other will be in the form of rival adventurers and adventuring parties. I'm especially looking forward immensely implementing these, as I remember fondly in Baldur's Gate the first time I came across a rival adventuring party.

Oh, and there will be one other special dungeon...which is specifically tied to player ressurection. I'm still working out the details, but to give you a bit of a hint, this is one of my favourite tabletop-RPGs of all time.

Sunday, 18 May 2008

Language Wars

These last few days, I've been using some some C and C++ code from other Roguelikes as a source of inspiration for Kharne. Years ago, I used to work professionally in both C and C++, and to say I didn't miss them at all would not be inaccurate. However, looking at the Angband source code, I am experiencing not a small degree of deja-vu, and surprisingly, not all of it is bad.

Thers is no doubt that certainly C is still the most popular language for Roguelike development, and nowadays I would contend this is due to two main reasons: the strong cross-platform possibilities that it offers, and also the established momentum that such an exiting large codebase of already written (and finished!) Roguelikes can offer.

There's no doubt that C does have somethings right - I had forgotten how the increment operator was such a thing of beauty. Let's take this amusingly commented extract from the Angband source, specifically in generate.c:

/* Mega-Hack -- Paranoia -- prevent infinite loops */
if (main_loop_count++ > 2000) break;

The Object Pascal equivalent of this is much more laborious:

/* Mega-Hack -- Paranoia -- prevent infinite loops */
inc(loop_count); if (loop_count > 2000) then break;

Double the code, and nowhere near as elegant.

Parameter passing into subroutines is also not as elegant in Object Pascal as it as in C. There is a function used in tunnel building in Angband to find the correct direction between two points. It is defined and used as:

void correct_dir(int *rdir, int *cdir, int y1, int x1, int y2, int x2)

correct_dir(&row_dir, &col_dir, row1, col1, row2, col2);

Now consider the Object Pascal equivalent:

procedure correct_dir(var rdir: Integer; var cdir: Integer; y1, x1, y2, x2: Integer); begin ... end; correct_dir(row_dir, col_dir, row1, col1, row2, col2);

In Object Pascal, I really miss the fact that you know straight away from the calling line which parameters are modifiable or not.

Even the use of { and } seems to be suddenly a lot less irritating than begin and end are.

This is not to say that I've become a sudden convert to Brian W. Kernighan's famous criticisms of Pascal or that I wish to rewrite Kharne from scratch in C/C++. Far from it. There are many things in C and C++ that are simply atrocious, and anyone proposing those features for a modern day language would be, and ought to be, shot. The oft-quoted string handling, for example. The ridiculous fragility of operations involving memory. And, dare I say it, pointers. And pretty much all of Kernighan's criticisms of Pascal are no longer valid when it comes to Object Pascal (though it is, I guess, slightly unfair of me to compare an effectively ancient language like C to a comparatively modern one like Object Pascal). For example, Object Pascal supports casting using the as operator, as whilst you cant quite turn apples into oranges as it sometimes seems you can do with C, as is functional enough.

Now, I think that I perhaps unfairly dissed C and C++ in the past, and with the incorporation of the standard template libary, C++ is certainly a fine development language, but I am still of the opinion that Object Pascal is better. As for C however, would argue that it is unsuitable for modern development - unless there are compelling reasons to do so - it lacks features that modern languages have by default (even C++ has some of these) - exception handling, many useful data types, function overloading and so on. But my biggest complaint about C is that it lets you shoot yourself in the foot too easily.

There are two caveats to this opinion though. The first one is that often opinions on programming languages are a function of familiarity. The second is that what is important with a programming language is how you use it to get things done. This may seem an ironic statement considering I've not released anything yet, but I find the combination of Object Pascal and Delphi allows me to implement things extremely quickly. If you're developing a roguelike, you may yourself have a different method of getting things done, but for me, I'll be sticking with Object Pascal and Delphi, although giving a richly deserved nod to C++ at least.

In other news, I've implemented a simple cave algorithm, with the following results:

Although the levels it generates are somewhat annoying to traverse, they do induce the claustrophobic and careful game play I want the Elemental Planes levels to feature (well, they will do when I add monsters!). All three types of dungeon mentioned in my last post are now implemented, although there's still a lot of refactoring to be done with the code.

Friday, 16 May 2008

Progress Report '#3

I have a dilemma.

Currently Kharne could best be described as an interactive demo. I've posted screenshots and videos but it is currently not a game. Nowwhere near in fact. There are no victory/loss conditions and there is no element of danger or competition.

Things are progressing however, in the next couple of weeks, I plan to:
  • Do all the spadework necessary for implementing magic.
  • Design the frameworks for monster storage and monster AI (again, thanks to Andrew Doull for some inspiring articles on Monster AI).
  • Finish the new Angband-style Dungeon Generation algoritms.
  • Convert and implement the Cave-Generation algorithm Jakub Debski posted recently to r.g.r.d (assuming Jakub gives permission).

Beyond this, serialisation is the next obvious step, and then its the implemention of magic and monsters. After this, Kharne could be resonably described (in the loosest possible terms though) as playable.

However, I'd like to release something as soon as I can. Even if it is only to showcase what I've done so far. And to get feedback, of course. There's a horrible cliche floating about in the business world: Feedback is the food of champions, but it is (at times uncomfortably) true.

Most of all though, I want to avoid Kharne ending up as the coding equivalent of The Longest Suicide Note in History. And I think even an interactive demo would help in this respect. The smallest course corrections at this point could have a massive effect on the finished game.

What do you think? Should I be aiming for my first demo release in a couple of weeks, or hold off for a proper Alpha version?

Tuesday, 13 May 2008

a new Level Generation algorithm

I've mentioned Level Generation before, and I make no secret of the fact that I'm pretty dissatisfied with the current methods I use in Kharne. They're fine for certain types of levels, but there's really too many dead ends for them to be used for anything other than labyrinthine "twisty-turny"-themed levels:

So, as light relief from studying for my part-time Astrophysics Degree*, I've been messing about with a new level-generation system for "room and corridor" type of levels, based upon the one in Angband. I've been thinking along the same lines as Andrew Doull as to how to improve that algorithm, but those improvements will have to wait for now (a thousand thanks, Andrew, by the way, for some fantastic articles).

Here's an example of my version of the Angband algorithm in action, with a simple generated mini-level, using four rooms in fixed positions (yellow represents corridors, and red and blue are soft and hard room walls respectively):

Here's another. A bit messier, but still not too bad:

But it occasionally throws up weird levels:

My first explanation for this occasional weird behaviour was a bug I must have introduced during the rewrite from C to Object Pascal, but then I started up a fresh game of Vanilla Angband and noticed pretty much the same behaviour:

Pretty gross, eh? So I think I might have to introduce a directional weighting factor in the tunneling algorithm to stop the excess of tunneling. But for now, I'll get a basic version (without much of the metadata present in the Unangband versions

* The reason I mention this is that I'm intending to enter the next 7DRL challenge with a small Roguelike with a Quantum Mechanical theme (with a twist). Quantum Physics is actually rather fun, once you get your head around it. A bit like programming, in fact.

Monday, 12 May 2008

Crafting and Economics

One of the most oft-praised things about Dungeon Crawl is the fact that you can't sell things you have found in your travels in the dungeons, and as a result cash is hoarded and treated like a precious resource where every gold coin counts, and where misbuying even a simple scroll is cringeworthy. This is in contrast to the typical 'band where, with the effective availability of unlimited dungeons, the modus-operandi in the early game (well, my early games at least) seems to involve repeated scum-delving carrying back armfuls of loot to the surface to built up funds in an inflationary fashion. This differing behaviour is an example of the differing economic models that have been implemented, and which affect gameplay to a large degree.

So which type of economy do I want in Kharne? My first instinct (and one my tabletop DnD players will definitely attest to) is to be parsimonius. In my opinion 'bands are the equivalent of a Monty Haul campaign - whilst it works for them and initially is enjoyable, after a while, money loses its value and becomes more of an annoyance, not an integral part of the gameplay. However, unlike Crawl, Kharne will have a town level (actually more of a root level where all the various different dungeon branches in the game can be accessed), and whilst I think the no-selling works for Crawl, I do not want to copy Crawl's economics wholesale.

I have come up with a third approach, one I don't think I've seen implemented much in Roguelikes, although it is de rigeur in most MMORPGs. Firstly, much like Crawl, I will have no shops that buy items from players. Players can spend their hard-earned gold on buying items, but over the course of a player's lifetime, I want the sums of gold they can get their hands on to be measured in the hundreds or thousands, not the tens of thousands you find in most 'bands. But there is an alternative method of item acquirement, and it involves one of my main long term aims of Kharne:

to introduce an item crafting system as an alternative method of facilitating character advancement

If anyone has played World of Warcraft (especially post-Level 60), they will know exactly what I mean (think of the Kharne system as a combination of Enchanting and Blacksmithing). My initial thoughts on how this could be implemented are as follows:

  • Items can be disenchanted into various ingredients.
  • New Items can be constructed from these ingredients, and other drops from the dungeons.
  • These items can be made at forges randomly located throughout the dungeons and in the town level.
  • Power levels of items constructed depend both on the ingredients used and the location of the forge that was used to build the item (for example, in the town you could only make less powerful items, to make the really powerful items would require a forge in the depths of the dungeon).
  • Some of these constructed magical items could be convenant items - they grow in power with the user in some fashion.
  • Recipes for magical item creation are available randomly in the dungeon and (for a few basic items) from the town level.
  • These recipes are randomised in some fashion so that each new game does not involve grinding repetatively for the same magical items.

What I want to ensure, however I implement this is that Magical Item Creation should never be obligatory, but rather is an alternative method of character advancement - it should be seen as another way of giving a character an additional edge.

Your thoughts on this are most welcome.

UPDATE: Just after I wrore this post, I found a very interesting (And extremely extensive) thread on r.g.r.d. from a while back discussing crafting systems and the following post by R. Dan Henry in that thread gets to the gist of what I'm trying to achieve (and avoid!):

This [item creation] can be balanced if the character that can make an uber-item has some weakness that makes up for it.

Maybe you are decked out in the finest gear Central-Earth has ever seen, but still have poorer odds of actually hitting with your Awesomeness War-Blade of Universal-Slaying than a fighter would with his simple Strong Long-Axe of Human-Hacking, not to mention hit points only the most specialized mages would consider respectable.

Or maybe you have to sacrifice for every uber-item you make. Your Horn of Artifactness may be able to shatter an ordinary dungeon level when you blow it and deflect spells of darkness 90% of the time, but your maximum character level is 29 instead of 30 and your (non-inflatable brawn and smarts stats are each one lower than you rolled.

If there is a hard clock to the game, the cost in creating items could just be in time and materials.

Saturday, 10 May 2008

A first attempt at Skills

The last few days I've been adding and refining skills and their effect upon creatures (of which a player is the prime example):

The skill model I've chosen is a bastardization of D&D, Angband and Dungeon Crawl, whilst influenced heavily by World of Warcraft and a sprinkling of Everquest 2 on top. Of course, since this is the first draft (and is completely different from the original Kharne), this may turn out to be horribly flawed and may need changing.

Characters have six primarily attributes: Strength, Agility, Endurance, Intelligence, Resolve and Charisma. These operate in a similar fashion to the D&D versions. Then characters have skills. These can be broken down into Fighting, Defense, Subterfuge and Magic categories. From a character's attributes and skills, all other abilities are derived (most of these in a non-linear fashion). The combat related ones are:

Evasion: Like in Crawl, Evasion is probably one of the two most important abilities. It operates in the same fashion as in Crawl, allowing a character to dodge a blow completely, but the derivation is polynomial, and it is affected by a combination of Dexterity, Defense, Armour Skill, Type of Armour Worn, and other factors (yes, I have an unhealthy fetish for Excel):

Armour: This is the character's capacity to absorb damage if he or she gets hit. This is a function of both the Armour Class of individual items and his or her skill with those types of armour.

Speed: Currently a simple linear relationship between the amount a character carries and how fast he/she can move.

Accuracy: In the old D&D days, this would be known as a "to-hit bonus" and it operates in a similar fashion. Is a function of Weapon Skill and Agility.

Damage: Bonus Damage - does exactly what it says on the tin.

Blocking: This is the chance to block the blow completely. This is different from Armour in that even if the blow's damage is so high, it cannot be absorbed, there is still a small chance it can be blocked.

Deflection: I want Kharne to have critical hits. Like the Defense skill in World of Warcraft, Deflection affects the chance of being crit.

There are two other derived stats: HP and MP, which are Health Points and Mana Points. These are a function of Race, Class, Endurance and Intelligence/Magic respectively.

All of these abilities and attributes can be modified by items (both positively and adversely in the case of cursed items). Here's a sample of some of the modifiers items can have:

The resolution mechanic is the good old D20:

Random Dice Roll + Positive Modifiers - Negative Modifiers = Some Target Number.

So there you have it, the first attempt at a rssolution/skill system. It is horribly derivative, but I think it will work adequately, with enough nuance to provide an additional element of gameplay.

Of course, I fully expect this all to completely change before Kharne is released!

Wednesday, 7 May 2008

Progress Report #2

Here are some screen shots showing progress so far (click on each for a larger view).

Normal Dungeon View with Coloured ASCII

Normal Dungeon View with Monochrone ASCII

Character Information

Character Inventory


I'm reasonably happy with my current dungeon creation algorithm - for certain types of dungeon. Its good at mausoleum-type levels, filled with rooms and twisty passages. The typical corridor length, room size, probability of a door being placed at the end of or mid-corridor, and even whether rooms can overlap are all configurable. What the algorithm isn't good at (actually, quite hopeless at), are wilderness and cave-type levels. I will probably rewrite the algorithm to generate those properly at some point in the future.

However, I'd also like to add vaults and other interesting features to the dungeon. The most popular way of generating vaults is to use a predefined map stored in a text file. For example, Dungeon Crawl Stone Soup stores the defintion of its (mini) vaults in /dat/mini.des. The current version of Unangband stores its vaults in lib/edit/vault.txt

Here is a sample Dungeon Crawl vault definition (which also contains a large amount of metadata):

# Another Ice Statue vault
NAME: ice2_lemuel
DEPTH: D:12-27, Lair, Swamp, Coc
TAGS: no_pool_fixup no_monster_gen
SUBST: W = w:20 W .:5
MONS: ice statue
MONS: ice devil w:5/blue devil w:5/ice dragon/freezing wraith/nothing w:30
MONS: white imp/ice beast w:30/polar bear/nothing w:50
MONS: white imp/ice beast w:30/polar bear/nothing w:50
KFEAT: 2 = >
KFEAT: 4 = >

Here's one from Unangband:

D: %%%%%%%%%%%%%%
D: %%.##########.%%
D: %%..#..,,,,..#..%%
D: %%..#..,,,,..#..%%
D: %%.##########.%%
D: %%%%%%%%%%%%%%

I don 't intend to go into detail on how exactly these files are used. If you want more information, the source code for both roguelikes is suprisingly (for C++) reasonable. What I would like to do is use Vaults in the same way other Roguelikes. But, what I have noticed is that each individual roguelike varies how it stores its vault definition, and how much information is stored in each defintion, obviously as per the demand of the roguelike in question. So shouldn't there be a common storage format for vaults amongst roguelikes? A common Vault API, for want of a better name. After all, a vault (no matter its size, orientation and contents) is just a hardcoded subsection of the dungeon, with/without added metadata (which is particularily visible on the Crawl example above).

Further to this, should Kharne (licenses permitting and assuming the vault authors give permission, of course) be capable of reading in and using vault definitions of other roguelikes? Is this even ethical? If or if not, in any case, what would you like to see in terms of vaults in Kharne anyway? How can I make Kharne's vaults somewhere to be dangerous, alluring and rewarding all at the same time? What are the most common drawbacks of vaults you've encountered and how can I avoid them?

UPDATE: A scheme for common vault definitions was proposed on r.g.r.d back in 2003 but it appears nothing ever came of it.

Saturday, 3 May 2008

Recursive Shadowcasting FOV

Although strictly speaking, I should have left it until a move advanced stage of development, a combined case of insomnia and ever-increasing irritation with the old Field-of-View system (increased by metaphorically washing its dirty laundry in public) means last night/this morning I've implemented Recursive Shadowcasting (which works beautifully for any light radius.) Plugging in Henri Haki's implementation into Delphi (from Free Pascal) was quite simple (it almost compiled without making any changes), although the co-ordinate system he uses is different from mine - I use an origin(0,0) at the bottom left (in Cartesian fashion) whereas he follows the standard VCL/LCL convention and has the origin at the top left. This video shows it in action:

The main interface has changed to what I consider to be a more slicker and less intrusive one. I'll probably change my mind again over these elements time and time again before final release.

Friday, 2 May 2008

Oh what a lovely view we've got...

FOV Algorithms. Fun, aren't they?

Here's an example of the current Kharne FOV algorithm (which was lifted almost entirely from the old code), using tiles for clarity of display:

This has a light radius of 4 tiles (which the light radius of the original Kharne always was. Its...okay. However, last night, I played about with changing the light radius. Here is a radius of 5 tiles:

Whoops. The current FOV system is a crude ray-casting system using variations on Bresenham lines, and it looks atrocious when you change the light-radius. To any light-radius other than 4. I'm eventually going to have to change this. But for now, the light radius stays at 4 and any plans for dynamic light sources be damned.

A quick search of the web revealed many different FOV algorithms. The most promising one appears to be Björn Bergström's Recursive Shadowcasting methods. My C++ is extremely rusty, but there are a couple of FreePascal implementations out there that should^H^H^H^H^H^Hwill be easily portable to Delphi.

Should be a lot of fun when I get round to recoding the FOV.

Thursday, 1 May 2008

What the RNG giveth, the RNG taketh away...

Not a direct Kharne-related post, but what follows is one of the reasons I love roguelikes so much, and hopefully someday, Kharne will have the same kind of atmosphere.

I started a new Crawl game the other night, and unusually for me for Crawl, I chose a non-Troll (I have an aversion to the Crawl hunger system born of too many deaths by starvation). I went with a Mountain Dwarf Fighter and almost immediately found a +0 gold dragon armour on the very first dungeon level. Now dragon armour gives an obscene AC for starting characters (at the cost of ruining your EV) along with lots of resistances.

Wearing it, I quickly found I was pretty much indestructible. Ogres and orc warriors were being two-shotted, and couldn't damage me. I stomped my way down to D10, and blatted the top levels of both the Orc Mines and the Lair (with enchanting the armour repeatedly, my AC was 30+).

I spotted an entrance to the Elven Halls. Now, historically, I've stayed out of this place because the amount of firepower those little 'e's can put out is obscene (and has bitten me severly before), but overconfidence got the better of me. So I went down, stomped about a bit, came back up and rested, and then went back down and then bamm!! - you know what happens next:

"Cast into the Abyss (deep elf mage)"

Oops. I panicked for a bit (I've not been to the Abyss for a long time, and have never been ported there), and then encountered an Executioner. Result, one dead mountain dwarf.

Obviously the karma of me getting an overpowered armour on D1 resulted in my death. Roguelikes, don't you just love 'em?
Anyway, here's part of the Morgue file:

Dungeon Crawl Stone Soup version 0.3.4 (crawl-ref) character file.

11855 Blorg the Cleaver (level 11, -4/90 HPs)

Began as a Mountain Dwarf Fighter on Apr 30, 2008.

Was a High Priest of Okawaru.

Slain by an Executioner (13 damage)

... in The Abyss on May 1, 2008.

The game lasted 01:36:17 (16959 turns).

Blorg the Cleaver (11855 points)

Race : Mountain Dwarf Res.Fire : + . . See Invis. : .
Class : Fighter Res.Cold : + + + Warding : .
Worship : Okawaru***** Life Prot.: . . . Conserve : .
Level : 11 Res.Poison: + Res.Corr. : .
Exp : 15335 Res.Elec. : . Saprovore : . . .
Next Level : 20084
Exp Needed : 4749 Sust.Abil.: + Rnd.Telep. : .
Spls.Left : 10 Res.Mut. : . Ctrl.Telep.: .
Gold : 1121 Res.Slow : . Levitation : .
Clarity : . Ctrl.Flight: .
HP : -4/90
MP : 7 Weapon : +4,+3 dwarven hand axe of chopping
Str : 22 Armour : +4 gold dragon armour
Int : 7 Shield : +0 dwarven shield
Dex : 12 Helmet : +2 helmet
AC : 32 Cloak :
Evasion : 2 Gloves : +3 pair of gloves "Ygimeoj"
Shield : 7 Boots :
Amulet :
Play time : 01:36:29 Ring : ring of protection from magic
Turns : 16959 Ring : ring of sustain abilities

You were in the Abyss.
You worshipped Okawaru.
Okawaru was exalted by your worship.
You were not hungry.

You visited 5 branches of the dungeon, and saw 20 of its levels.
You visited the Abyss 1 time.

Hand weapons
a - a +4,+3 dwarven hand axe of chopping (weapon)
n - a +1,+2 dwarven vampiric hand axe
J - a +3,+1 hand axe
h - 12 +0 darts of ice
c - a +0 dwarven shield (worn)
g - the +3 leather armour of Clicank
(You found it on level 4 of the Dungeon)
It greatly protects you from fire.
It lets you teleport.

i - a +2 helmet (worn)
k - a +4 gold dragon armour (worn)
r - a +0 dwarven spiked helmet
s - the +3 pair of gloves "Ygimeoj" (worn)
(You found it on level 4 of the Dungeon)
It greatly protects you from cold.

Magical devices
t - a wand of flame (8)
y - a wand of confusion (3)
E - a wand of polymorph other (7)
O - a wand of confusion (4)
Q - a wand of slowing (7)
R - a wand of frost (8)
d - 4 bread rations
b - a scroll of torment
j - a scroll of detect curse
q - 7 scrolls of remove curse
I - a scroll of enchant weapon III
U - a scroll of paper
f - a ring of sustain abilities (left hand)
l - a ring of protection from magic (right hand)
o - an uncursed ring of ice
z - an uncursed ring of poison resistance
B - an uncursed ring of protection from fire
T - an uncursed ring of magical power
m - a potion of slowing
u - 2 potions of levitation
v - a potion of cure mutation
w - a potion of speed
p - a book of Frost
A - a book of Hinderance
G - a book of Power
Magical staves
F - a staff of summoning

You had 1 experience left.

+ Level 9 Fighting
+ Level 14 Axes
+ Level 1 Throwing
+ Level 8 Armour
+ Level 11 Shields

You had 10 spell levels left.
You didn't know any spells.

Overview of the Dungeon


Temple: D:5 Orc : D:6 Elf : Orc:4 Lair : D:8
Swamp : Lair:2


Okawaru: D:7, Orc:4
The Shining One: D:10
Beogh: Orc:3, Orc:4


D:5: ? D:6: = Orc:3: *

Innate Abilities, Weirdness & Mutations

You have tough skin (AC +1).

Message History

The Executioner hits you but doesn't do any damage.

You hit the Executioner.

The Executioner is lightly wounded.

The ynoxinul hits you.


The Executioner hits you!

You die...


# .#

. . #

. .#.

. . #.#




...#.#. ...##..

. . .{ ...#

. .. ....

# ... #...#

##{ .#.#

.# ..#


Grand Total: 466 creatures vanquished

Turn Place Note
0 D:1 Blorg, the Mountain Dwarf Fighter, began the quest for the Orb.
0 D:1 Reached XP level 1. HP: 16/16 MP: 0/0
230 D:1 Reached XP level 2. HP: 21/23 MP: 1/1
1005 D:2 Reached XP level 3. HP: 29/29 MP: 1/1
1851 D:3 Reached XP level 4. HP: 32/37 MP: 2/2
2174 D:3 Reached XP level 5. HP: 36/42 MP: 3/3
2822 D:3 Defeated Garg's ghost
2822 D:3 Reached XP level 6. HP: 31/50 MP: 3/3
3012 D:4 Noticed Jessica
3018 D:4 Defeated Jessica
3207 D:5 Entered Level 5 of the Dungeon
3321 D:4 Defeated Monsty's ghost
3741 D:4 Reached XP level 7. HP: 56/57 MP: 4/4
3845 D:4 Noticed Ijyb
3861 D:4 Defeated Ijyb
3941 D:4 Identified the +3 pair of gloves "Ygimeoj" (You found it on level 4 of the Dungeon)
4280 D:5 Noticed Edmund
4308 D:5 Defeated Edmund
4436 D:5 Reached XP level 8. HP: 40/63 MP: 5/5
4817 D:5 Identified the +3 leather armour of Clicank (You found it on level 4 of the Dungeon)
4909 Temple Entered the Ecumenical Temple
4966 Temple Became a worshipper of Warmaster Okawaru
5202 Orc:1 Entered Level 1 of the Orcish Mines
5910 Orc:3 Acquired Okawaru's first power
6199 Orc:4 Entered Level 4 of the Orcish Mines
6531 D:7 Reached XP level 9. HP: 61/69 MP: 5/5
7527 Lair:1 Entered Level 1 of the Lair of Beasts
7557 D:8 Noticed Blork the orc
7567 D:8 Defeated Blork the orc
9406 Lair:1 Reached XP level 10. HP: 67/79 MP: 6/6
11998 D:10 Entered Level 10 of the Dungeon
12762 D:11 Defeated Brag's ghost
12965 D:11 Reached XP level 11. HP: 83/88 MP: 7/7
14995 Orc:4 Gained mutation: You have tough skin (AC +1).
15399 Elf:1 Entered Level 1 of the Elven Halls
15722 Orc:3 Acquired Okawaru's second power
16790 Elf:1 Cast into the Abyss (deep elf mage)
16790 Abyss Entered The Abyss
16959 Abyss Slain by an Executioner

Progress Report #1

Its finally time for a progress update. Inspired by the categorisation given in How to Write a Roguelike in 15 Steps, I've broken down the coding of Kharne into a number of discrete areas. The current areas of the rewrite either completed or in a reasonable playable state are:

Game Mechanics
I have a complete document that specifices the game mechanics I'm using. The original Kharne used AD&D, but the rewrite is using a system influenced by both Angband and Crawl. These may need tweaking during playtesting since according to the old saying, "no plan ever survives contact with the enem^H^H^H^Hplayers."

Data Storage
Read-only config and item information is currently stored in an SQLite database. For any modifiable data, e.g. savedata, compressed text files will be used.

Character Creation
This has been hived off into a seperate DLL to avoid bloating the main code too much. This is, bar any tweaking to the game mechanics, finished and complete.

Level Generation/Navigation
The dungeon algorithm I'm using is a heavily modified version of the one used in the original Tyrant by Mike Anderson. I've extensively modified it and parameterised it to enable the production of a much wider variety of levels than it was originally capable of. I will add in additional algorithms for different level times eventually.

I'm using plain old GDI with Double Buffering. The basic viewport is running, in tiled mode, at well over 100 fps on an old P4 2.8 Ghz PC. The framerate for ASCII mode is off the scale. Incidentally, Kharne doesn't use any sort of text handling for ASCII mode - the characters are blitted graphically to the screen. I hope to eventually use this to enable smooth real-time rotation and zooming of the play area, which, to use a technical term, "cool".

Item Generation
I can generate a wide variety of magical and non-magical items, either random, or of a specified quality and type. I have also written an external program that uses the same item code to produce vast numbers of items for future analysis and statistical purposes.

Inventory and Item Handling
The '@' can pick up, wield and remove a wide variety of items. The effects these items have on player statistics isn't completely implemented, however.

Things yet to do, in approximate order, are (deep breath, this is still quite a big list):

Morgue/Death Handling
Time Handling
Monster AI
Victory/End Game Handling

The current roadmap from here is to try and finish what is remaining on inventory handling and then make a start on the remaining items mentioned above. Unfortunately, a playable release will be a few weeks off yet.