Episode 2: Adventure Game Puzzles Shouldn't Feel Like Escape Rooms

Development Journal for Where the Arc Falls

The puzzle has to belong there

I grew up with classic point-and-click adventure games, and puzzles are obviously a large part of why I still like the genre.

But there is a particular kind of puzzle that has always bothered me.

The story is moving, I am interested in the characters and trying to understand what is happening, and suddenly I encounter something that feels as though it was placed there specifically to provide fifteen minutes of gameplay. Maybe I need to collect several unrelated objects. Maybe there is an elaborate lock on something that could have had an ordinary key. Maybe I am presented with an abstract mechanism whose main purpose seems to be announcing: Puzzle starts here.

At that point I become aware of the designer.

I start trying to work out what the person who made the game expects me to do, rather than thinking about what the character standing in that world would do.

That is the feeling I have been trying to avoid while designing Where the Arc Falls.

The question I keep coming back to is fairly simple:

Why does this problem exist here?

And closely related to that:

Why should the player solve it rather than simply watch the character solve it?

That second question turned out to be more important than I initially expected.

The Shippey Test: adapted for games

There is an idea usually referred to as the Shippey Test, after Tolkien scholar Tom Shippey.

It comes from thinking about adaptation between different media. A simplified version asks two questions about a change made when adapting a story:

Was the change necessary because of the new medium?
Did the change improve the story in that medium?

I find that surprisingly useful when thinking about adventure games.

A game is an interactive medium. Moving a story into a game means the player needs to participate in it somehow. In an adventure game, a large part of that participation comes through solving problems.

So I have started using my own version of the Shippey Test:

The first question is mostly about worldbuilding. The second is about interactivity.

A perfectly logical puzzle can still fail the second question. If the player spends ten minutes solving something and learns nothing, feels nothing and understands nothing differently afterwards, I have to ask what the interaction contributed.

A relatively simple puzzle can work very well if solving it makes the player notice something important about the world.

That is the kind of puzzle I am trying to build.

Problems before puzzles

One practical result of this is that I try to start with the situation rather than the puzzle mechanic.

Suppose the protagonist needs to get somewhere in town.

I could begin by thinking:

I need a puzzle here.

That immediately sends me toward locks, combinations, missing objects and mechanisms.

Instead, I try to think about the place itself.

Who normally uses this route? Why would access be restricted? How was this part of the city built? Has its original purpose changed over time? Who might know something about it? What tools would realistically exist nearby?

Once those questions have answers, possible interactions tend to appear naturally.

This approach also helps with clues. If the solution depends on information the player could reasonably encounter while exploring the same world, the puzzle feels much less arbitrary.

The player is learning how the place works rather than decoding my intentions.

Three kinds of puzzles

While working on the first chapter, I found that most of the puzzles I was designing fell into three loose categories.

They overlap quite a bit, but the distinction is useful when I am trying to understand what kind of reasoning I am asking from the player.

1. Environmental puzzles

These are probably the most familiar adventure-game puzzles.

You explore, notice things, pick up objects and eventually work out that something you found earlier can help with a problem somewhere else.

There is nothing particularly new about that structure.

What I find difficult is making the objects feel natural once I know what the puzzle requires.

In practice, I rarely invent the world and all its objects first and then discover that some of them happen to form a puzzle. That would be nice, but it is not how I normally design.

Usually the story creates a problem first.

A character needs to get past someone, repair something, reach an inaccessible place or create a distraction. Once I understand the problem, I start thinking about possible solutions. Those solutions suggest objects, information or other resources the player might need.

The next step is where much of the design work happens.

If the solution requires a particular object, I need to find a convincing place for that object in the world. Why is it there? Who owns it? What was it normally used for? Could the player have noticed it before knowing they needed it?

I don't think there is anything wrong with designing backwards from a problem. The player just shouldn't be able to see the scaffolding.

An object can exist because I needed it for a puzzle. It still needs to feel as though it existed before the protagonist arrived.

That also affects where I place things. Putting the exact tool next to the exact problem usually makes the design obvious. Introducing it earlier, giving it some context, or letting it serve another purpose can make the eventual connection much more satisfying.

So my environmental puzzle process is usually:

The design may happen backwards but the player's experience shouldn't feel that way.

2. Dialogue puzzles

These have become some of my favorite parts of the game.

Dialogue in adventure games often behaves like a menu. You go through the available options until the character eventually tells you everything you need to know.

I would rather have conversations behave more like investigation.

A character might make a claim. Somewhere else, the player learns another fact that changes how that claim should be understood. Two people may describe the same event differently. Someone may know only part of what happened, or may have a reason to leave something out.

The puzzle comes from comparing these pieces of information and deciding what they mean.

In that sense, facts can work almost like inventory items. The player collects them in different conversations and situations, then uses the right piece of knowledge when it becomes relevant.

So the basic structure is usually something like this:

The important part is that the player has to make the connection.

If every dialogue option can simply be exhausted until the correct response appears, then the player does not really need to understand anything. The conversation may look interactive, but mechanically it is still a script.

I have already run into this while developing the first chapter. Some dialogue sequences worked exactly like that: keep clicking, keep asking, and eventually the solution arrives.

Those needed rewriting.

A dialogue puzzle works much better for me when something learned earlier changes what the player can ask, challenge or suggest later. Paying attention then becomes part of the gameplay.

3. Mechanical puzzles

Mechanical puzzles are the easiest ones to recognize.

There is a machine, interface or physical system and the player manipulates it until something happens.

These are also the puzzles where I am most cautious about the escape-room feeling.

Adventure games can get away with almost anything once an ancient mechanism appears on screen. Symbols light up, pieces rotate, switches have mysterious rules, and because the object looks old or strange we tend to accept it.

For Where the Arc Falls, I try to work out what the mechanism originally did before deciding how its puzzle works.

Who built it?

Who used it?

What would its controls communicate to that person?

What has changed since then?

A machine can become puzzling because knowledge has been lost, parts are missing, instructions are misunderstood, or the people using it today believe it has a completely different purpose.

That gives me much more to work with than simply making the mechanism complicated.

It is particularly appropriate for the world of the game, where old systems have survived long enough for their original purpose to become unclear.

Ideally, operating one of these systems tells the player something about the people who built it.

I am deliberately avoiding showing the actual solution logic of one of the larger mechanical puzzles here. Figuring that out should remain part of playing the game.

A useful failure test

The Shippey questions also give me a fairly good way to identify puzzles that should be cut.

Imagine a puzzle where the player spends several minutes manipulating something, succeeds, and a door opens.

Sometimes that is enough. Games are allowed to have obstacles.

But I still want to know what happened during those several minutes.

Did the player discover something?

Did they make an interesting deduction?

Did they use knowledge they had gathered elsewhere?

Did they learn how some part of the world functions?

Did the interaction create tension, humour or character development?

If all that happened was that the player delayed reaching the next room, the puzzle probably needs more work.

This has been one of the more unexpected parts of development for me. I usually have more puzzle ideas than I can use, so a lot of the work is deciding which ones are actually worth keeping.

A puzzle can be clever in isolation and still be wrong for the game.

Difficulty is a separate question

There is another distinction I have found useful.

Whether a puzzle belongs in the world and whether it is difficult enough are two separate design problems.

It is tempting to make a puzzle more complicated when playtesting shows that players solve it too quickly. Add another object. Add another stage. Hide one of the clues further away.

Sometimes that works.

Sometimes it simply makes a good idea longer.

I am trying to treat difficulty as something that comes from the amount of reasoning required, rather than the amount of work required.

If the player understands exactly what needs to happen but must walk back and forth between four locations collecting things, that is usually not difficulty.

If they have several pieces of information and need to make a connection between them, that is much closer to what I want.

Of course, whether I am succeeding at this is something playtesting will tell me much more reliably than my own design notes.

Reusable systems

There is also a practical engineering side to puzzle design.

Until recently I was working on the game alone, so I had to be careful about how much custom code each new puzzle required. That pushed me toward reusable systems.

Mechanical puzzles can share the same underlying framework while using different visuals, rules, clues and completion conditions. Dialogue puzzles can use common logic for information the player has learned, available topics and changing responses. Inventory and environmental interactions can rely on the same basic systems for hotspots, items and game state.

This makes iteration much easier.

If changing a puzzle means rewriting a large amount of code, I am less likely to change it. If most of the puzzle is defined as data and configuration, I can simplify it, move a clue, change the logic or replace the idea without rebuilding everything around it.

Playtesting often changes a puzzle. I may need to move a clue, simplify a sequence or change the logic, and reusable systems make that easier to do.

Puzzle dependency charts

Another tool I have found very useful comes from Ron Gilbert's article on Puzzle Dependency Charts.

A dependency chart is different from a walkthrough or a normal flowchart. It describes what each puzzle depends on. If opening a door requires both finding a key and fixing the hinges, those are separate branches that can be worked on independently before they meet again.

This makes the overall structure of an adventure game much easier to inspect. You can see where several puzzles are available at the same time, where they converge, and where the design has accidentally collapsed into a single linear path.

Ron Gilbert explains the idea in detail here: Puzzle Dependency Charts.

For puzzle design, I still come back to the same two questions:

Would this problem reasonably exist here?
Is the story better experienced because the player has to solve it?

What comes next

The first chapter of Where the Arc Falls is now getting close to broader playtesting, which means I will soon find out how much of this survives contact with actual players.

That is the part I am particularly interested in.

A puzzle that seems completely clear after designing and implementing it for several weeks may be incomprehensible to someone seeing it for the first time. And something I expect players to struggle with may be solved immediately.

I am also starting to collect gameplay analytics alongside direct feedback so I can see where people spend time, where they stop progressing and which clues they actually use.

There is a lot I expect to change.

That is probably a good subject for a later post.

Discussion question

What adventure-game puzzle do you still remember years later?

I am less interested in whether it was difficult than in why it stayed with you.

Was it the deduction itself? The way it used the environment? A character interaction? A joke? Or did solving it make you understand something about the game that you hadn't understood before?