A few Quest-ions

I'm working through implementing quests in Unangband at the moment. The core of the idea has been hanging around in the code for a while, but there's no time like the present to get them up and running.

I've gone with a data-centric as opposed to a script-centric design for quests. This may initially appear an unusual choice, because quests are implemented using scripts in so many games, but the data centric approach is common for Angband variants, and a natural fit for the way I design systems in Unangband - by building examples of the data I'm trying to model, then build a data structure, and then wrap code around it.

A quest consists of a number of stages which the player must pass through, and an event for each stage - which is a record of in-game actions required to complete the quest stage. An event is a subtle concept because it could be 'killed 7 goblins', but forms a natural accumulator as well, in that this could equally consist of 7 events of 'killed 1 goblin'. There are actually two ways that events accumulate:

a) if the game object is removed as a part of the event, we add 1 to the number of game objects counted in a separate stage which monitors the player actions contributing towards completing the quest. If this equals or exceeds the number of objects whose state we are required to modify, we complete the event for this stage.

b) if the game object is not removed, but instead has a state modified, we count the total number of objects in the game with this state modification. If this equals or exceeds the number of objects whose state we are required to modify, we complete the event for this stage.

This second type of accumulator is intended for quests where we have to 'terrify 7 goblins' instead of 'kill 7 goblins'. I can also combine the two, to allow the player to 'kill or terrify 7 goblins' by subtracting the number of type a accumulated from the number of type b required.

There are a number of problems with this approach. In particular, I have to make sure that if I've terrified a goblin, it never stops being terrified, otherwise the player will have to terrify it again. I could use this to form a natural timer for the quest, by making this a player requirement that they have to have all monsters terrified simultaneously, but it'll probably be easier just to prevent quest monsters from exiting the state required for the quest. Doing it this way ensures that the player knows which quest monsters they've already terrified, because the Afraid state is shown in the monster name and in its in-game behaviour. The alternative is to have a separate 'you've terrified this monster before' flag, which is a much harder UI problem.

But the real problem is I'm starting to recognise a particular code pattern, which I've implemented previously and has caused no end of debugging problems.

The pattern is one where I have to fire off a series of actions after modifying a variable, in every instance where that variable is modified. In this example, it's every time that a monster gets scared - I've got to check whether or not the player terrified it, and whether there's an active quest that needs to be updated as a result.

This is, of course, a classic problem of encapsulation. Instead of directly referring the variable, I should have been using an function to update the variable indirectly, which I can then use to also to check the player quest status. In order to correct this, I'll have to refactor the code to add the function in.

But even if I had anticipated this requirement in advance, I'd still face this refactorisation process. This is because I could not have correctly anticipated what information is important when updating the variable - in this instance, the fact that the player was responsible for what ever action caused the monster to be afraid. I could equally specify circumstances that are completely independent of the player and the monster: such as the fact that the Oracle might have to be at Delphi, in order for the monster terrify action to count as a quest action being completed.

The previous instance where this has caused me no end of problems is the player learning about the effects of equipment that they use, and inferring information from that. This allows for example, the player to get poisoned by a spider, put on an unknown ring, and then not get poisoned by the spider, to determine that the ring supplies poison resistance. The variable I needed to encapsulate in this instance was whether the player resists poison.

In the poisoning example, this is actually a case of premature optimisation causing me problems. In Angband, to avoid the overhead of having to test whether a player resists poison every time, we check whether the player equipment changes, and if so, update the state of 'resisting poison'. I'd still have to check whether the player equipment changes, even without this optimisation because I'd also need to update the state of 'the player knowing about what equipment they are using'.

What I really want is a generic way of specifying variable dependencies: that is, information I also have to update if a specific variable changes. I can't think of any specific programming paradigm that conveys this idea well. It's not a particularly functional or object oriented idea: because in the examples I've given, you'd have to pass the entire global environment into the function or object in order to not have to go through a refactorisation process if you needed additional information.

Does anyone have a good example of a programming language that conveys this concept well?