Ian Thomas

Procedural Narrative: Better Templates

This is part 3 of a series of occasional articles on procedural narrative — see part 1 for the explanation, but in short, these are some ideas I’ve been throwing about for controlling or generating the player’s narrative experience of a game procedurally. For a given value of narrative, which not everyone might agree with.

Right, I’ve mentioned this a few times so let’s get into it. Procedurally-generated quests, in roguelikes and in RPGs, have never satisfied me. They tend to fit into a few simple templates the developers have come up with e.g. fetch quests (“I need 6 phoenix feathers’), kill quests (“go kill me a dragon in such-and-such area”), escort missions (“escort this stranger from such-and-such a place to such-and-such a place”) and so on. First, it’s blatantly obvious that they’re generated — admittedly that’s a hard thing to avoid — and secondly they’re so terribly predictable. As soon as you see the introductory text, you know the ending.

So, here’re a few thoughts on creating a better templating system that’ll produce more interesting and unpredictable stories, that make you feel more involved with the world. As per usual, they’re my own waffling, and your mileage will undoubtedly vary.

Let’s take as an assumed baseline that we have a world, in which there are NPCs wandering about — probably randomly generated — and you are a player. For simplicity let’s call it a single-player game. And again, for ease of thinking, a medieval fantasy world a la Skyrim or Fable or any one of a dozen others.

Parasitic Stories and Pattern Matching

Terry Pratchett has this theory that stories are living things that act as parasites, forcing the world to conform to their shape. This is actually a great way to think about a quest generation system. Rather than everything being created up front, let’s think about templates as requiring certain things to be true before they can spawn a quest. Certain situations to exist in the world.

As a simple example, say our quest is ‘Person A wants the player to kill person B’. We need the quest generator to pick a suitable person A and a suitable person B, and if it can’t find them, fail to create the quest.

That’s a really simple example, though. To extend it, we might start adding conditions for the quest to make sense. “Person A must dislike person B”, for example. This presupposes some sort of ‘feeling’ data to be generated and tracked for each NPC, but to be honest if we’re going to be dealing with stories — and stories are all about drama and conflict — then we’re going to need something like that in place. We won’t specify too deeply, but at least let’s start with the idea that NPCs can like or dislike each other and the player.

With that system in place, then ‘Person A must not dislike the player’ is also possible thing to tack on to our simple quest template. After all, it’s not that likely you’d pick someone you hated to do your dirty work. (Okay, okay, lots of counter-examples, but let’s run with it for now.)

So, our template becomes:

‘Person A wants the player to kill person B. Requirement 1: Person A dislikes Person B. Requirement 2: Person A does not dislike the player.’

And then our quest generation engine picks up this template and picks some random As and Bs and tries them out in the world. If it can’t find suitable As and Bs, this quest is put back into limbo for now, and a different one is picked.

Fetch Quests and Items

Let’s divert slightly sideways to talk about the fetch quest. ‘I need 6 phoenix feathers’ isn’t a particularly riveting narrative. But clearly the quest-writer thinks focusing on items should be interesting — after all, items crop up all the time in stories, don’t they? Arthur’s sword, Indiana Jones’s Holy Grail, Jack’s magic beans. So surely our templating system should support items?

But if you look at them, most stories about the acquisition of items have less to do with what the item is than what the item represents. It’s normally the focus of or resolution to some sort of conflict between people. And that’s what makes it interesting. There’s an obvious bit of low-hanging fruit there – a simple instruction to quest-writers to say ‘only put in an item if it’s the focus of a dramatic conflict’, but let’s take a step back and look at what I’m really saying here: interesting stories are about people, not about things.

So why do we keep tripping over fetch quests?

Let’s throw out the fetch quest and the item system entirely, then, for story purposes and come back to it later. The important thing to note is that our preferred template generation system should probably care about people, not about things.

But which people?

Faces In The Crowd

Well… we’re assuming a big world with a cast of NPCs that could be limitless. They’re generated using some sort of algorithm; it’s unlikely someone has sat down and designed them all.

So, if we assume our quest template is something like ‘person A needs the player to kill person B’, then for A and B we just pick random people, right, so long as they fulfil the requirements about liking and disliking and all that?

Well… no. We’re not trying to recreate an entire world with people who have wants and needs. We’re trying to give the player an experience. So we need to pick someone who the player can encounter. So just pick the closest, then, right?

In the absence of any other information, sure. But we can gather lots of information. And as the player plays through the game, we can gather lots more – where they go, how they play, and critically, who they’ve interacted with and in many cases how they’ve treated them.

So to my mind, if we’re choosing a random person in the world to fit into our quest template, we should prefer people who the player already knows. Someone they’ve interacted with before, if possible, because it’s the player’s relationships with the other characters in the world that matters.

Sure, to start with we won’t have that info. But as the game progresses, it becomes easier and easier to work that out. We do need to leave a little wiggle room, or the player will never interact with new people. But that should take care of itself to a certain extent, as hopefully our quest’s requirements are varied enough to spread the net.

So looking back at our template:

‘Person A wants the player to kill person B. Requirement 1: Person A dislikes Person B. Requirement 2: Person A does not dislike the player.’

If our quest system hunts through the world for an A and a B that fulfil the requirements, it should be weighted to pick either an A or a B (or both) whom the player has already encountered. This makes our stories revolve around people who, as the game progresses, start to matter to the player, and becomes a much more personal story.

Creating Extras

‘Person A wants the player to kill Person B’ is a pretty dull and motivationless bit of story. But then, most of that is up to the quest-writer. If it became ‘Person A wants the player to kill Person B because Person B married Person C, who used to be Person A’s lover’ with requirements ‘Person A hates Person B, Person A loves Person C, Person C is married to Person B’ then it’d be much more interesting, but harder to pattern match. It also adds a requirement of tracking ‘spouses’ to our game, but mapping character relationships is kinda important, so worth adding.

But there’s a limit to adding complexity, as your most complex stories will never find matches. It’s worth, at that point, considering allowing the quest generator to generate new characters that are in some way related to existing characters. After all, it works for soap operas!

Reciprocal Quests

So we know we’ve fulfilled our requirements above and the quest engine has found a suitable A and B to fit. Might it not spawn other quests, though, possibly diametrically opposed? Consider this:

Requirements: Person A dislikes Person B. Person A does not like the player.

Quest 1: Person A wants the player to kill Person B.

Quest 2: Person B has found out that Person A wants to kill him, and wants the player to kill Person A first.

It makes sense for those two to get added into the world at the same time, doesn’t it? And starts to give the player choices about who to side with. Hell, it could get a lot more complex: ‘Person C knows A wants to kill B, and wants the player to tell B, at which point B asks the player to kill A’ etc.

The important thing here is once we’ve successfully matched on requirements, we could spawn a bunch of related quests off the back of them, not just one.


The other way to add interest and complexity to a quest is to consider splitting it into a series of sub quests, each of which might have its own pattern-matching element.

As an example:

Step 1. Person A wants the player to get information on person B. This leads to the discovery that person B is sleeping with Person C.

Step 2. Person A wants player A to kill player B.

Now, we could have a whole bunch of different templates for the ‘get information on person B’ step. For example, ‘follow person B and see who they meet’, or ‘break into B’s house and go through their letters’ or ‘beat up person D, B’s confidante, and extract information from them’.

Similarly, we could have a whole bunch of different templates for the second step — perhaps A specifies the death must happen in a certain way, for example in public, or provides a specific poison.

So if we randomly select all the people involved, and the specific version of each subquest, then we open up a whole load of different stories. We don’t even need to pick the exact details for step 2 until step 1 is complete, so it’ll be up to date with what’s happened to the world.

And than can expand upwards and upwards. What if the major arc of the whole game is one long plot with lots of randomised sub quests, and those sub quests have their own sub quests, and so on and so forth…?

Right, let’s wrap it up there. As usual, I hope someone finds something useful in all this!

Comments are closed.