Skip to content
HAMMERSTEIN LIU
Writing

Let Players Play by Instinct — A Murloc's Handbook of Quest and Narrative Design, Part IV

Games are a simulation through which humans respond to unfamiliar environments by instinct.

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

Dreams and narrative

Before we discuss this theory, I’d like you to imagine a situation with me.

Think back to the last time you dreamed. A good dream, a nightmare, either will do. If you still remember any fragments, try putting them into words.

You’ll notice something: you’re instinctively describing the dream in a “sequence.” But usually, all you can describe is a fragment, or several fragments. You may not even be sure how they relate to one another in time or space. Still, you tend to think, OK, these fragments appeared in some kind of order. At the very least, they changed as the night went on: what you dreamed just after falling asleep, halfway through, and just before waking.

You tend to wake at some turn that goes beyond your imagination. Perhaps it doesn’t feel real. Perhaps the dream suddenly seems about to break character, or you’re about to experience something “you’ve never experienced before.”

Dream joke: when you see a toilet in a dream, it is a trap.

Of course… it could also be this. “When you see a toilet in a dream: IT’S A TRAP!”

Thanks to the way we were trained at school, we naturally describe a dream fragment as a sequence, until we reach a “break”—the bit that suddenly pulls you out.

But have you ever considered this: what is the experience like for the you inside that dream fragment?

At first, you might feel disoriented. You don’t know this place. Then you quickly begin to work it out. Where am I? A room? Outside? A city? Why am I here? What am I wearing, what am I holding, what’s around me? What should I do? You try taking your first step in the dream, build an understanding, gather information, and eventually reach a conclusion: OK, let’s try doing something.

Broadly speaking, the cycle is this: recognize the environment, understand the current state, identify the objective, act.

Notice anything? Doesn’t this sound a lot like playing a game?

So dreams and games have a few things in common:

  • Both put you in a situation.
  • Both require you to actively learn about your surroundings and build an understanding of them.
  • Both establish an objective for you. You may have come up with it yourself, or the game may have given it to you through explicit guidance.
  • Both wait for the player to “take action.”
  • Both advance your experience through a linear or nonlinear sequence.

No wonder a good game can leave you still playing it in your dreams. Ha.

The best gameplay experiences are already there in human instinct

Let’s revisit a classic piece of quest flow: “We Don’t Go to Ravenholm…” in Half-Life 2.

First, let’s briefly summarize its story and what the design needs to accomplish.

Ravenholm entrance with Dario Casali's commentary; the Chinese subtitles are translated below.

The screenshot shows developer commentary by Dario Casali. Translated from its Chinese subtitles:

When we finished Ravenholm, we felt the transition from Eli’s lab wasn’t working. A corridor led directly from the lab to the town, emerging at the start of the area you’re in now. We had just had the residents of Eli’s lab tell the player, “We don’t go to Ravenholm,” and we liked that setup. But on arriving, the player immediately met enemies face to face. There was no space to build tension. So we designed this eerie corridor of zombies to solve the problem in a way we were happy with. We slowed the pacing, relied on the art and lighting, and prepared you to experience why we don’t go to Ravenholm anymore.

Story:

After escaping the Combine attack on Eli’s lab, the player must pass through Ravenholm to reach the Resistance. Father Grigori helps you make your way through the town.

Design requirements:

A combat level where the player fights most of the monsters encountered earlier.

  • It needs a degree of tension.
  • Teach combat uses of the Gravity Gun.
  • Teach traps and mechanisms.
  • Expand on the setting: Combine air raids on residential areas.

If we designed from that information alone, we might produce something like this:

Hypothetical Ravenholm sequence: escape, prepare a church defense, repel attacks, reach the Resistance.

Escape Eli’s lab and enter Ravenholm → meet Father Grigori and help him set up traps to defend the church → repel attacks by the Combine and zombies → leave Ravenholm, cross the mine, and find the Resistance.

Strictly speaking, there’s nothing terribly wrong with that sequence.

You could arrange one or two ambushes as the player enters Ravenholm. Father Grigori brings people to rescue you from being surrounded. Then, in the church area, you use the Gravity Gun to help set up traps. The climax is holding off wave after wave of Combine headcrabs and zombies. Finally, outnumbered, you’re sent into the abandoned mine by Father Grigori. You cross it and reach the Resistance.

But after playing, the player will notice something: hang on, why does it feel as though the story is pushing me along?

So how does the actual Ravenholm level present its sequence?

Let’s take its most famous opening moment: the little saw-blade tutorial.

First, the player enters Ravenholm with an initial situation:

“You’ve just escaped Eli’s lab. Now you need to cross Ravenholm. The wrecked town bears out Alyx’s warning: better not go to Ravenholm.”

The player enters Ravenholm holding the Gravity Gun, with side routes closed off.

The player arrives with roughly this set of abilities and information:

  • I have some weapons, acquired earlier in the game.
  • I know I can carry things.
  • The Gravity Gun can pull in and launch certain objects.
  • I can use the interact button on certain things.

But at this point, the player doesn’t know their objective in Ravenholm. All they may know is to keep walking. After all, the surrounding paths are closed off; there’s nowhere else to explore. So they try moving forward. That’s their first decision based on the environment. They continue until they see the wooden shack, the barrels beside it, and the dead zombie inside.

Fuel barrels and a mutilated body outside a boarded wooden shack in Ravenholm.

Having abilities, the player naturally tries applying them to the environment. Perhaps they use the Gravity Gun to launch a fuel barrel and blast the door open. Perhaps they smash its boards with the crowbar. Either way, they need to get inside.

Interior of the shack, with tables, saw blades and a dead zombie.

Once they’re in, the game rewards that decision with what looks like a way forward. There’s just a table across the doorway.

So the player will probably do one of two things: pick up the table, or jump onto it. Then they find a few saw blades blocking the way.

Saw blades obstruct the doorway as the player aims the Gravity Gun.

Of course, this bit of Ravenholm is so famous that we all know what happens next. You take out the Gravity Gun to move a saw blade. A zombie spawns and startles you. Instinctively, you fire the blade, cutting it in half. And suddenly, you have new information: with the Gravity Gun, saw blades can kill zombies. You leave the room, discover a rotating-blade mechanism, and begin the next lesson.

In fact, the whole of Ravenholm is designed around a cycle:

Four-stage player-driven model: create a situation, understand the current state, establish an objective, act or encounter change.

Create a situation

  • Give the player information about the current situation.
  • Establish and verify the abilities they have.
  • Build their understanding of the environment.

Understand the current state

  • Design events around the player’s basic abilities.
  • As the player uses those abilities to respond to events, guide them toward a new ability, or a new understanding of what’s happening.

Establish an objective

  • Build a new objective around the new ability.
  • That objective may grow out of the confidence a new ability gives the player in dealing with the situation. Or it may be a strategy for responding to the environment, formed from new information.

Act / encounter change

  • Design new events or situations around the objective.
  • Let players use the abilities they’ve acquired to explore a new situation, refine those abilities, or encounter a new change within that situation.

You’ll notice that this model is driven by the player. Players judge their surroundings from experience. Through contact with the environment, they acquire new information or abilities. Those abilities and that information motivate them to form objectives, then help them respond to a new environment.

This is, in fact, how humans instinctively deal with things. Whether you’re learning, playing a game, or getting to know someone, you use this model.

Then why do we still feel “pushed along”?

Over the past few years, I’ve often heard the same argument: “Games aren’t as fun as they used to be.”

It sounds like the usual nostalgia for the good old days. But in games, I do notice some very concrete things.

For instance, people now talk about “episodic-anime-style games.” Usually, they mean content-focused live-service games.

You might also notice that games now practically abuse cutscenes. A character’s story needs a cutscene. A character’s big combat moment needs a cutscene. And how does a project prove it has money? Well: loads of cutscenes, plus real-time Timeline / Dialogue Show sequences made to look very much like cutscenes.

Black-and-white Absolute Cinema meme.

The annoying thing is that this isn’t exclusively a Chinese problem. People abroad make “Absolute Cinema” memes too—though those aren’t necessarily derogatory—or discuss why there are more and more cutscenes. You can even see people watching game streams complain, “Why does this game have so much dialogue?”

We keep saying that games are an art of interaction. Compared with other forms of entertainment, games have an unmistakably interactive quality. Whether you switch on your PC or console, attend an event where the host announces that it’s time for a game, or get kidnapped by old man Jigsaw because you’ve done too many terrible things and he tells you he wants to “play a game”… at heart, it’s a challenge that requires you to take part and interact. Calling it an “episodic anime experience” really does put the cart before the horse.

Of course… a large part of the reason is… there really are a lot of people now who “play” by watching someone else. They don’t take part in the interaction.

Within the industry, the conclusion tends to be: the sequence we’ve designed isn’t appealing enough. But the explanations are all over the place. Some think their cinematics aren’t realistic enough. Some think their script isn’t good enough. Others think they haven’t stuffed in enough minigames.

That leads to some strange behavior. The graphics arms race that’s been going on for years, for example. Everyone starts piling on cutscenes and real-time motion capture. Those who lack the capacity, or whose project’s foundations are a pile of shit, start agonizing over “static character blocking and static camera composition.”

And indirectly, that means… many players now barely register the gameplay. They’re mainly there to watch a story. Sometimes they don’t even watch the story, just its big emotional moments, and get a little teary when one manages to stir them.

Anyone who’s read my quest-design articles here knows that I like to emphasize one term: quest pacing.

I used to think I’d explained it quite clearly: arranging the current quest’s story beats and gameplay challenges.

But if you can quickly recall the worst tutorial you’ve ever played, you can immediately jump up and object. That game had gameplay challenges. It had a story sequence. Why was the experience still such a pain in the ass?

So let me fill in what was missing from that theory.

At its core, designing quest pacing means arranging multiple cycles of the player-driven model I described above.

We can turn that model into a set of questions to check our work against:

Design review questions for each stage of the player-driven cycle; translated below.

Create a situation

  • What information do I need to give the player?
  • What can the player infer from it?
  • How should that information be conveyed: through the environment, dialogue, a challenge, a scripted sequence, or a cinematic?

Understand the current state

  • Based on that information, what will the player expect of the next beat?
  • Does this beat test or teach an ability, or reinforce information already provided?
  • What might interfere with the player’s understanding of the current state?

Establish an objective

  • I need to guide the player’s objective through the current state, built from the information already given.
  • The player must be able to achieve my objective by applying their abilities. At least, it must look that way.
  • I need to build the player’s confidence in their information or abilities.
  • Does my objective match the expectations the player has formed from the preceding situation and their current state?

Act / encounter change

  • Should the player validate their abilities or information, or should I break their existing understanding and create a new situation?
  • Is this a reward for completing the cycle, or a challenge?
  • If it’s a challenge, where should the pressure come from?

In this diagram, what really drives changes in pacing is the distinction between different kinds of situation and current state, and the way one situation builds on or overturns another.

For example:

BT-7274 under attack during the Titanfall 2 capture sequence.

You and BT-7274 have been captured by the Apex Predators. To protect you, BT finally hands over the Ark. He wants you to take the Pilot’s emergency kit and get out.

This is the player’s current situation. As the information supplied at the start of the sequence, it quickly makes clear what’s happened and what the current objective is.

The player holds the Pilot emergency kit taken from BT.

You open the emergency kit and find BT’s data core and a Smart Pistol. You need to use these to reach the Militia. The game gives you an appropriate objective: Survive. Evade. Resist. Escape.

This is the current state as it develops from the situation. Within it, the player acquires an ability: a Smart Pistol. It will be the handiest tool they have. The game then establishes an objective that matches the player’s expectations: fight your way out with BT’s core.

Smart Pistol and objective prompt: Survive. Evade. Resist. Escape.

The screen displays that four-part objective. The Smart Pistol’s description says it automatically locks onto nearby targets and guarantees a hit; the environmental warning reads “External temperature: high.”

Then you send a signal with your knife and fight your way out with the pistol. As you move through the level, you hear the Militia urgently trying to contact you. Commander Sarah Briggs calls your name on an open channel. It isn’t over, she tells you. She’s coming with a new Titan. You just have to fight your way out, and you can still put things right. She guides you along. You’re in luck: every route with enemies you can kill is the right route. Quite naturally, you escape.

The player acts on the current objective, and throughout those actions, the game keeps reinforcing it. The voice performances, the enemies along the way, the layout of this section, and every audio cue guiding you forward all reinforce your desire—and your emotional drive—to achieve it.

BT-7274 restored in a new Titan chassis, with dialogue choices about his return.

The dialogue choices shown are, translated from the Chinese subtitles: “Glad to see you back alive, BT,” and “New chassis, same Titan?”

Finally, you and the game achieve that objective together and enter a new situation. Your Titan is here. You install BT-7274’s core. Now it’s time to save everything.

Honestly, Titanfall 2 has it coming: of course so many players are going to remember that story for the rest of their lives.

That feeling of being pushed along by the story usually arises when a situation doesn’t provide enough information, when the abilities or information the player acquires have too little connection to the situation, or when the objective that tests them doesn’t match the player’s instinctive expectations of the situation and current state. The player’s understanding of the environment differs from the creator’s. Before they can even respond, the story pushes them onward. That’s why they feel “pushed along.”

Over time, fewer and fewer moments fit the player’s thinking or understanding. The story drifts further from what they imagine. They go from directly controlling events to being the story’s progress bar. They begin to resent the parts that require input, and become “readers” of the story instead.

Eventually, they either remember only its big moments, or remember nothing at all. They stop caring about the story and start hitting Skip.

Here’s a deliberately sweeping claim: many games that really are “interactive films” design their experiences better than some games with “gameplay.” They use interactions that fit the player’s intuition, allowing the player to understand the situation, use new abilities, and respond to the environment through them.

The very genre you’d expect to “push the player along” instead designs around how players form their understanding of situations and objectives. As a result, it can feel highly interactive. It becomes an “interactive game.”

Humans are born knowing how to play

Gcores work library highlighting the author's chain-reaction article, handbook series and Zen article.

A view of my Gcores work, highlighting “Creating a ‘Chain Reaction’,” the Murloc quest-design handbook series, and “Zen and Game Narrative Design.”

Looking across these quest-design theories I’ve written about, you can build a model like this.

From the story side, your design needs to revolve around events, create different situations, and establish the characters’ behavior and motivations within them.

From the pacing side, think about how to build a model driven by the player. How will players understand a situation? What information or abilities will they acquire from it? How will they test those? How do you establish an objective, a shared understanding, that matches what the player currently imagines? And how will the next situation validate or overturn that understanding?

From the side of narrative technique, consider the density and intensity of information. Which information or ability needs which form of expression? What can the player learn instinctively? What needs a tutorial or dialogue? What should the environment convey, and what needs a voice performance or cutscene?

As you design, fix a target in your mind. Which players do you want to elicit which responses from? What will each kind of player do? What have you prepared to meet those expectations?

The theory of quest design really is that simple. What matters is continually trying things and testing them to establish the pacing that fits your current situation.

Yes. Quest design itself is a game.

Start with an expectation and try something. Fill out the design with techniques and ideas. Then put it into a playtest. Watch whether “that kind” of tester responds as you expected, and make adjustments accordingly.

Humans are born knowing how to play, because games are themselves a simulation of how humans confront their real surroundings. Through that simulation, we learn to respond to environments, build mental models, develop strategies, and understand how the environment might affect us.

A dream is, at heart, a fragmented gameplay experience. Your moment-to-moment intentions determine what you do and what you’re about to experience. The dream responds to your actions with reactions of its own. If it contradicts your understanding, you wake up.

Just like being forced out of an immersive experience by a game with bad quest design.