Housekeeping

So much of what I find myself doing these days with Unangband amounts to house keeping (I've called it refactoring previously - apparently incorrectly). That's a good sign, because it means the game is mostly working.

That's not to say there are still not significant changes going to happen between now and the version 1 release. The two most significant changes yet to come are persistent dungeons, and quests, with item creation code a short step behind.

Recently, I've been working on the region code, but the total impact on the player will be some additional druidic spells and more interesting traps. It won't fundamentally impact the game play but it has been months of code development (I don't have much spare time at the moment).

And I've been holding off adding some additional timed effects, such as timed feather fall, because I wanted to move across to Angband's new timed effect code (by timed effects, I'm talking about effects that apply persistently to the player). I did the jump yesterday - thinking it'd be a small change.

Six hours and what feels like thousands of LOC later, I've implemented this. The actual change wasn't that complex. But it turns out that timed effects are used throughout the code base. And the cascade effect was that it was often easier to rewrite other parts of the code at the same time than to manually go through and change that code as well. I've partially moved skills at the same time to the Angband skill implementation. I could have changed the code displaying timed effects on the screen at the same time - but I'm waiting on Angband to prove its new interface model before I do. I've still yet to update the self knowledge code to include the timed effects - simply because I was worried about making mistakes (most common coding errors seem to occur towards the end of a large coding period because I tire and lose focus).

One advantage that has come out of this development work is a game design error I've made can soon be removed from the code.

Some time ago, I added the ability for spells that the player cast to appear as objects in equipment slots. These objects would temporarily replace any existing equipment in that inventory slot - essentially allowing the caster some zero weight swap kit, at the cost of giving up an existing piece of equipment.

Unfortunately, it turns out the cost of sacrificing the use of existing equipment is always too high. Angband - as I've said many times - is a game of inventory management. And the spell ideas that I can come up with are always too weak or ill-matched with the players remaining equipment, and are almost always useless for most of the game.

This is even worse for shape change spells. When the player changes shape, in Unangband, one or more of their equipment slots has a spell item created in it, to reflect the shape of the monster that the player becomes. As a result, it's almost never worthwhile changing shape.

Both ideas are great concepts that just fail in practise. I should have known - because so much of the code is devoted to inventory management that these quick hacks would prove useless. I'll be amending the shape change code so that it doesn't create objects, and removing the timed equipment creation spells.

But both these features will be back - in particular it turns out the timed spells as objects has mileage.

I mentioned above that timed effects are used throughout the code base. It turns out that a large part of this is because Unangband often has checks of the form:

if (player_has_equipment_with_this_flag || player_has_timed_effect)
{
/* Do something */
}
else
{
/* Do something else */
}

I could simplify this considerably if I change this to (player_has_flag) where that flag is set by either equipment or a timed effect. And one way of representing this is by allowing time effects to be specified like other objects, but allow an infinite number of them to be applied.

There are a number of complications. The main two are:

a) Angband has a tradition of allowing one flag from equipment to accumulate with one temporary effect, but no further. For instance, temporary resist acid is cumulative with permanent resist acid, but permanent resist acid from multiple pieces of equipment don't stack. I'd like to continue some of this tradition in Unangband (where resist acid on equpment stacks, but temporary resist acid behaves differently - by not protecting the player's kit, providing better protection against environmental effects and so on)

b) Unangband tracks which equipment could be providing a particular flag. Having temporary effects that could provide the same flag complicates this tracking. But I have to deal with this complication at the moment, and so a more general solution would help considerably.

Again, I had a long hard think about whether I should have included this in the original code changes - but it would have complicated and extended the implementation even further.