A Murloc's Concise Handbook of Quest and Narrative Design, Part I

Or: how to start designing a quest.

Reposted from my article on Gcores, so I have a copy on my own blog.

Mglrmglmglmgl! May the murloc god watch over us.

Last time I talked about narrative design on Gcores, I described a situation in China: the role of “narrative designer” is often closely tied to that of “mission designer.” After thinking about it a little more, I realized that might have been a slightly… one-sided claim. So, to avoid leading people astray—and to have something I can use as spell components for a future team presentation—I’ve decided to write down some of the methods I use in quest and narrative design.

But I’m still… well, my goal has always been “to be a good narrative designer.” If anything I say differs from what you do or study, you’re welcome to discuss it in the comments. Given the state of the profession in China, I think having some readable material on quest design and quest narrative could help people who want to try making this stuff, or even enter game development as narrative or quest designers.

“The serial shitposter is back to farm XP.”

This series will go through three stages in detail: receiving the quest brief → breaking down and designing the quest → implementing it. I’ll try to keep the industry jargon to a minimum. If I do use it, I’ll add a footnote or something. The idea is to explain how to design quests and their narratives in as much detail as I can manage.

Getting started is the hard part

OK. If this is your first attempt at quest design, I strongly recommend finding out what game you’re making the quest for before you even get the brief.

Don’t dismiss that as a statement of the obvious. The root of all evil in many terrible quest beats and quest sequences is usually some combination of “I want to pad this out and meet my quota” and “I’ve never actually clicked the Play button in the project.”

Different genres, different mechanics, even different styles of game can call for very different quest pacing. Here’s a simple example.

The player has special powers: in certain spaces, they can summon “mental entities” to fight enemies. Unfortunately, the character discovers this ability on their first trip to school, after fumbling around on their phone with a delinquent they met only a few hours ago. They don’t yet know where the power comes from, how to enter these special spaces, or who they’re up against. You need to design an introductory quest sequence that teaches the player how combat works in these spaces, what their “mental entities” can do and how to use them, and the various clever tricks built into the levels. Meanwhile, your dear writer has attempted to “bribe” you by slipping an Alipay red-packet QR code into the document, and would like you to fit in a bit of story to establish the world.

If you’ve played Persona 5, that brief probably sounds familiar. Isn’t that just the first trip into Kamoshida’s Castle—“Duck Castle,” to give it the Chinese fan nickname? So my design should start with the player bumping into that blond delinquent, Ryuji; seeing the attractive girl who’ll later join the team get into Mr. Kamoshida’s car; then having Ryuji lead them to open that dodgy navigation app and enter Duck Castle…

Yes, but hold that thought. What if the framework I hand you is an action RPG like Control? Or an FPS like Return to Castle Wolfenstein? Your player might not even come from the real world. They might be some poor adventurer who’s just arrived in Suramar and accidentally picked up your quest.

We usually start by breaking the game down in fairly broad strokes. Is it Japanese or American in style? Does it prioritize the playable experience or telling a story? How demanding are the controls? What style is the script written in? What’s the overall tone?

There’s a basic rule here: your quest experience must fit the game’s framework.

Imagine that our dear model student Joker’s real name is B. J. Blazkowicz. Before school, a package arrives for him at Café Leblanc: a fancy black handgun bought on eBay from someone claiming to be a Federal Bureau of Control janitor who sells them in bulk. And your game’s tone happens to lean toward that youthful, gloriously ridiculous JRPG feel…

You’d better sit down, pick up a pen and paper, and think hard about how you’re going to design this quest.

Of course, if you actually use that framework… your game’s pretty much GG already. Haha.

So, once you’ve received the writer’s story and the requirements or tutorials that other teams want to fit into your quest, do two things first:

• Check whether the story and requirements fit the game’s overall style. List anything that has nothing to do with the game as it stands, or doesn’t belong at this stage. Then go argue it out with the relevant team.
• Set the tone of your quest. What sort of quest should it be? Does its tone need to connect to the preceding quest?

This is usually where I grab a pen and start scribbling. I jot down keywords for the elements in the game’s framework, then keywords for this particular story and its style. Then I start thinking about whether they can work together.

The quest brief, broken down

• Story
  • A school story: ah, youth, bromance, and crushes.
  • Urban supernatural powers: a touch of urban legend. It shouldn’t feel too oppressive—at least not to play.
  • Early in the game: the player’s first encounter with mental spaces and “Stands.” Active exploration, or something they stumble into?
  • How do we present the villain? They need to leave an impression. Check the character brief: megalomaniacal, self-important, arrogant, harsh. Could we add a touch of stuffy rigidity to make the stereotype stick?
• Gameplay
  • There are Stand users, but combat isn’t turn-based. Ask the combat team whether the Stand mechanic is built into the player’s weapons or abilities.
  • Visible enemies or random encounters?
  • Should we add elements linked to the villain—mechanisms or puzzles, perhaps? Talk to level design.
• Assets
  • Do we need special props or environments?
  • Cutscenes?
  • Level Sequences: scripted scenes staged within the level?
• Other systems
  • Any tutorial requirements? Basic combat, the friends system…

I’d especially recommend this stage for indie projects. Indie games often make something with a little in common with existing games, but not all that much. That makes it especially important to consider which mechanics and features take priority, and how to build them into the quest.

Of course, if you’re making Goat Simulator, forget I said anything.

Be difficult, and more difficult

OK. Once that phase of hair loss and flying spittle is over, you can finally start what we’d properly call quest design or quest narrative design.

Before you unleash your Alfred Hitchcock camera language and staging, before you flex your creative muscles and design a quest so profound it could be Hideaki Anno reincarnated—hang on, that doesn’t sound quite right—take your hands away from the project. Yes. Put them down.

“Why can’t I keep these hands under control?”

Turn your attention back to the writer’s revised story outline. It’s time for something very mechanical: breaking it down.

Let’s use the scene in The Three-Body Problem where Wang Miao goes to the radio observatory to watch the universe flicker. I’ll call him Wang “Three Waters”—the Chinese character in his given name is three water characters stacked together. We’ll do a sample breakdown and see what “breaking it down” means in quest design.

Across the whole sequence, Three Waters first visits Ye Wenjie. She tells him the radio observatory can observe cosmic background radiation—that is, the universe flickering. He then goes to the Chinese Academy of Sciences observatory and meets Sha Ruishan. They watch the universe flicker together, after which Three Waters has a breakdown and calls Shen Yufei to ask what lies at the end of the countdown.

Emotionally, we still need to maintain the mystery around Shen Yufei and the countdown. So we may want to cultivate a feeling of “What? The universe flickering? That’s impossible.”

Sketch the structure, and it looks something like this.

Talk to Ye Wenjie → follow her directions to the observatory → meet Sha Ruishan → watch the universe flicker with him → call Shen Yufei and ask what lies at the end of the countdown.

From the observatory visit onward: keep an air of mystery around the ETO.

That’s a basic quest breakdown: take the story’s sequence of events and separate them into quest nodes.

Looking at it now, we can see that the sequence involves two locations. And both of them are very… dialogue-heavy.

If we were being crude about it, two loading screens and two story cutscenes would get the job done. A bit rough for a whole quest, though.

So, as the quest designer, you need to break it down further. Think about how to add a little more to it.

Let’s assume our game is a GTA-like open world, more American in style, where we want some things for the player to actually experience.

With that framework, we can try adding a few “elements.”

The expanded sequence

1. Visit Ye Wenjie’s home.
2. Cutscene: talk to Professor Ye.
3. Dialogue: call Sha Ruishan.
4. Playable activity: drive to the observatory.
5. Talk to Sha Ruishan.
6. Dialogue: follow him on a tour of the observatory.
7. Kill time together: play darts, take him out for a meal, or watch a film.
8. Playable activity: return to the observatory.
9. Playable activity: operate the observatory computer to begin detection.
10. Cutscene: the flickering begins; a report is generated.
11. Minigame: analyze the report.
12. Dialogue: discuss it with Sha Ruishan and work out the countdown.
13. Call Shen Yufei to ask what lies at the end of it.

The green nodes in the original diagram are dialogue; the red nodes are playable activities and minigames. The observatory section still serves the goal of keeping the ETO mysterious.

In this expanded version, I’ve tried to make the observatory section feel more like a game: let the player actually slack off with Sha Ruishan, observe the universe flickering, then call Ye Wenjie.

To convey Sha Ruishan’s attitude that “the universe flickering is simply impossible,” I chose to expand his first meeting with Three Waters. Make the whole “going to the observatory to see it flicker” business feel a bit more casual.

Then, when they finally observe the flickering, I hand some actions that could have gone into a cutscene back to the player. Under Sha Ruishan’s guidance, the player sets up the observatory computer, analyzes the report, and works out the countdown. Letting the player operate things themselves can increase their immersion in the sequence, and make it feel a little more believable.

Of course, you can’t just copy and paste these ways of filling out a sequence into another project. It depends on how well you understand the framework of the game you’re designing for: what gameplay it offers, and which mechanics you can bring into the quest.

Wow, you can really dance!

Sorry to interrupt your reading, but quest design is a free-to—

Kidding, kidding. I know you’re itching to start breaking down a quest, but there’s one more thing I think you really need to know.

First, a story.

Once upon a time, a writer sent me a story outline. They had some awareness of quest design, so the outline included ideas for the quest and some story beats. When I’d finished breaking it down, I realized something: this little rascal had crammed five fights, six cutscenes, and seven puzzles into a quest that was supposed to last less than thirty minutes…

Let me ask you something. What was the worst level you’ve ever played like?

OK, you might say its routes were unclear. It went on too long. Its enemies were too hard or too easy. The sequence was too long, or too short…

Right. You can put all of that under one heading: the level’s pacing was terrible.

Rational Level Design and dynamic design. The slide says that RLD manages game content to help players experience flow; dynamic design is a necessary complement, but cannot replace the relatively static work of RLD. The chart places player skill on the horizontal axis and game challenge and variety on the vertical axis. Anxiety sits above the flow channel; boredom sits below it. Slide © 2017 Clark Jiayang Yang.

I often give Yang Jiayang a hard time because the experience of playing SYNCED is such a mess, but his “Rational Level Design” live session was actually very useful to me.

Put simply, if a level makes the player spend too long doing one thing, or repeat it too many times, they’ll get thoroughly fed up. That’s the anxiety in the chart.

If the level is a cakewalk, on the other hand, or the player enters it and finds practically nothing to do, they’ll be bored.

Manage the player’s experience of flow—damn it, I really don’t like that word—so it stays somewhere between fed up and bored, and they’ll find the level fun.

Quests work the same way, though there are a few complications to consider.

For instance, I personally wouldn’t recommend triggering two dialogue scenes back to back. The player feels like they’re just sitting there, bored, watching people talk. Nor would I recommend a whole quest consisting of two cutscenes with some running in between. It makes the player feel like a tool: Sisyphus, endlessly pushing the story’s progress bar along.

An example planning sheet. Successive sections occupy the columns; rows track design goals, the core experience, the player’s role, story and location, section duration, elapsed time, difficulty and pacing. Further rows track weapons, cover, movement abilities and enemies, including when elements are introduced or practiced. The original excerpt and its credit are retained.

This isn’t a hard rule. Before you start designing a quest, though, I’d suggest making a sheet like this. List everything that could affect its experience: all the available gameplay, including minigames; staging resources, including cutscenes and scripted level sequences; NPC pathfinding used to guide the player; and so on. Give these things an “RLD value.” Estimate how much patience each asks of the player, and how long it will take. Then consider the range of values you want the player to experience over the quest.

Before you do that, remember that running around, watching dialogue, the complexity of triggering a feature, even how many layers a menu has—all of these affect the quest’s RLD value. If the quest is supposed to feel tense and urgent, don’t keep making the player open their inventory, run long distances, or watch unskippable cutscenes.

Strictly speaking, it’s the Gwent problem. I’m a witcher. I’m trying to find the wife and daughter of the most foul-tempered baron in the world, while also searching for my dear Ciri. Otherwise my wife might hang me upside down from an old locust tree and whip me with magic. And somehow, in the middle of all that, I have time to ask the baron, “Fancy a game of Gwent?” Doesn’t exactly fit the situation, does it? Pile too many mechanics like that into a quest, and the result is tedious, interminable, irritating, and constantly breaking the spell.

So think about your quest’s pacing. If it’s a questline, think about the pacing of the whole thing.

After the storm, remember to talk to your old friends

Good. Once you’ve done all that preparation, you should have a reasonably complete quest outline, including its gameplay and a detailed breakdown of the sequence.

Don’t rush to open the project and start configuring things. Honestly, even a Muggle can do that. You don’t need to experience the Muggle part just yet.

Take your outline to other people and talk it through. Let them get a feel for how complicated the quest is.

Or split yourself into twenty-four different personalities, Billy Milligan style—an essential skill for quest and narrative designers—and let all twenty-four mentally play through the sequence. See whether it fits the range of RLD values you’ve set.

Once that’s all good, still don’t open the project. Take the document and organize all your requirements.

The art team usually needs advance notice to make cutscenes. If the sequence needs its own level or some level mechanics, talk to the level designers about how to build them. Prototype what needs prototyping; pass around the Chunghwa cigarettes if that’s what it takes. If you need a special panel to open or some unusual functionality, have a chat with the programmers. Catch up on life. Get those feature requests in amid the laughter.

Once all that’s done: OK. Now you can open the project and start configuring the quest.

When I sit down to write Part II, I’ll probably talk about some more technical things. What should you watch out for while implementing a quest? What states might the player be in? How do you handle players trying to break it? What tools do you need? How do you test a quest? How do you design a quest editor?

And, if possible, in Thrall Part II—pfft, I mean Handbook Part II—I’ll get into a few finer points. How do you use the environment? What clever tricks get a player to stand where you want them? How do you minimize new art requests while making the most of existing art assets to guide the player?

But that’s all for later. At least wait until you’ve started putting the quest together.

So… coo. That’s procrastinator pigeon for “I’ll get around to it.”

Oh, and if you have questions, come chat in the comments~