The Quest for Quests - Part Three (The Map)

You may want to start this series with part one and part two.

The traditional approach to quests in games is hand written design, followed by scripted implementation. This is not to disparage hand-written design: the map for Shadow Complex is a beautiful, complex document, which was used to prototype the game in Adobe Illustrator and proved robust enough to virtually be identical in design to the final implementation. Scripting for quests is a natural approach, because the process of completing a quest appears procedural. First you do this, then you do this, then you do this. And scripting gives you the flexibility to have a wide variety of start and end conditions for a quest: because scripting languages allow you to set up complex logic to verify that these conditions have been met.

But it is these start and end conditions that make scripting problematic because every script requires that these pre and post conditions be correctly met. I've deliberately changed to calling these pre and post conditions, because the terminology is also used in programming to define the inputs and outputs of a function. And as should be clear from Unangband, the risk of taking a programmatic design to systems introduces the potential for bugs. This raises the bar for quest design, because every quest requires programmer-level understanding of game, which limits the total pool of people who can contribute quests to your game (or requires that you check every quest yourself). So the advantage of scripting quests: allowing complex pre and post quest logic, is the same as the disadvantage of quests. Scripting paradoxically limits your ability to use it to good effect.

That is not to say that a data driven design allows you to avoid pre and post conditions, but these are implemented once, in the programming section of the code, where exceptions can be rigorously handled in a single segment of code, as opposed to required for every script. You could equally argue that you can encapsulate the complex logic for pre and post conditions for scripts in functions to the same effect. But at that point, your scripts are not going to look dissimilar from data structures - just without the advantages that a data driven design gives you.

To see those advantages, I'm going to start with the strongest example of data driven quest design that I can find. Or, more correctly, I already have. That example is Shadow Complex, inspired by the Metroid series of the games, and the quest data structure used is the map.

In the Metroid series of games, the limits to your playing space are not scripted. They are instead limited by the current powers that you have - doors require rockets or ice beams to open, lava requires upgrades to your armour, small spaces require you can transform into the Morph ball in order to fit through them. This is a straight forward lock and key design, where the keys can be re-used. What is most important about this design: it is much more robust than a scripted approach. As can be seen in Metroid speed runs, it is possible to break the individual locks, without necessarily breaking your ability to continue playing the game. In a traditional scripted approach, if you somehow bypass a section of the map and do quests out of order, the designer must have explicitly considered this in the pre and post conditions of individual scripts. With the map-as-quest, you can do sections out of order without anyone having considered the ramifications of doing so. It is still possible to end up stuck if you skip multiple power ups, and end up falling into a section of the map which requires these power ups to traverse out of. But falling is the most general case of one-way movement which otherwise only rarely occurs in map design.

And the map as quest allows us to use a mature game design tool set where we are able to prove important attributes about the map, such as connectivity, in a way that we cannot necessarily prove with scripts. We can also take advantage of procedural generation to create sophisticated maps which are more complex in one sense than any script could be.

You may feel at this point I've performed a sophisticated three-card monte to prove data driven design superior to scripting. Every game has a map, and the important thing is the scripted triggers embedded in these maps, and not the maps themselves. In a sense you are correct because it is entirely dependent on whether you have made the map interesting to traverse. In other words, is it about the quest or about the questus interruptus?

Walking to Mordor

If your map degenerates to a series of nodes, interconnected by a graph of edges, then there is no point trying to represent the map as anything more sophisticated. Puzzle Quest is refreshingly honest in this approach, and it's how I've represented the Unangband wilderness. I don't necessarily think it's the most successful map design - it is another great example of data driven quest design though - but it is much more successful than games where you get a quest, then solely use the minimap in the top right corner of the screen to get there. In simple to traverse maps, the push component of the narrative that I talked about in part two is the most important, because there is nothing sophisticated required by the pull component of the narrative. Once you know where you have to go, there is no compelling puzzle stopping you getting there.

If on the other hand, the map is non-trivial to traverse, then pull narrative can become more important. In the idealized pull narrative, you already know the destination, and there is a compelling puzzle blocking you from reaching that destination. For Far Cry 2, this is the checkpoints between you and the destination, both those marked on the map and hidden, and the area around the destination, which you have been given the opportunity to explore previously. Metroid goes one step further, and just shows you compelling puzzles, with the implicit promise of a destination, or reveal, behind the puzzle. This has the effect of both a push and pull, but without the explicit quest narrative pushing you or a destination being shown pulling you.

We should really revisit our theory of how quests and narrative interact at this point. We've found at least two examples which fall outside the bounds of the push and pull based narrative structure velocity I described in part two. The first is a single, compelling push and pull at the start of the game, which is constantly interrupted as you move towards the destination (the Lord of the Rings model). The second is no push or pull at all, but puzzles in multiple directions without destinations (the Metroid model). Both appear to be about interruptions of some kind, one built from the top down, and the other from the bottom up, which allows me to segue to my own interruption until part four.