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.