Episode 3: What playtesting changed

Development Journal for Where the Arc Falls

In the previous post I wrote quite a lot about how I approach puzzle design.

Near the end I mentioned that the first chapter was getting close to playtesting, and that I expected actual players to expose things I had missed. That happened fairly quickly.

For the last weeks I have spent much less time adding things to the game. Most of the work has been watching people play, fixing problems, and then seeing what happens with the next player.

Some of the feedback was reassuring. People were interested in the story and wanted to continue. The puzzles generally made sense once players understood how interaction worked. The more useful feedback was about the places where they didn't.

I know every solution, which objects matter, why a line of dialogue is there and what it will become relevant to later.

That makes me quite bad at seeing some problems.

A player coming to the game for the first time sees something very different.

The tutorial

I originally had a fairly explicit tutorial at the beginning of the game.

It explained the basic interactions: examining things, using inventory objects, combining them and so on.

This seemed reasonable. Even people familiar with point-and-click games still need to learn the particular interaction system of a new game.

In practice, the tutorial became another thing the player had to understand.

The game started, and instead of immediately exploring the room, the player started following instructions.

I tried making the tutorial shorter and less intrusive, but I kept running into the same problem. As soon as I tell the player to select an object and use it somewhere, attention moves from the room to the interface.

So I started moving most of that learning into the first room itself.

The room already contains several different kinds of interaction.

Some objects can only be examined.

Some open into a close-up interaction.

One requires using an object Elia already has.

Another leads to combining two inventory items.

Eventually those interactions feed into the first puzzle.

The player learns the controls while trying to understand the room.

Playtesting also exposed smaller things I had never considered. Selecting an inventory object was clear enough for most players. Releasing a selected object was less clear.

I never noticed that while testing because I already knew what clicking again would do.

When the player no longer has the clue

Hints caused a different problem.

Adventure games rely heavily on information the player picked up earlier.

Sometimes that information is an inventory item. That is easy. The object stays there.

Sometimes it is a sentence somebody said twenty minutes ago.

That is much less reliable.

I had several cases where a player reached a puzzle and clearly had no idea what to do, even though the information needed to solve it had already appeared.

In one case the original source of the information was in an earlier section of the game that the player could no longer access.

From my perspective, the clue had already been given.

For the player, it had effectively disappeared.

That made me look again at how important information is presented and how it can reappear later.

Sometimes Elia can comment on something once it becomes relevant.

Sometimes another character can mention the same fact from a different angle.

Sometimes an object can still be examined later.

The part I am still trying to work out is how much repetition is useful.

If every important clue appears again immediately before the puzzle, there is very little for the player to remember or connect.

On the other hand, one sentence from half an hour ago should probably not be the only thing standing between the player and progress.

I have also started experimenting with contextual hints.

The game knows quite a lot about what the player has done. It can see how long they have been in a particular state, which interactions they have tried and whether they keep returning to the same place.

That can provide some indication that the player is stuck.

The response can stay fairly small. Elia might make a more useful observation after several failed attempts, or one of those attempts might reveal another piece of information.

I still need more testing here. A hint that comes too early is worse than one that comes late.

Wrong interactions

Another thing playtesting exposed was how little time I spend trying incorrect solutions.

When I test a puzzle, I generally pick up the correct object, go to the correct place and use it.

Players try many other things first.

This becomes especially visible when they are stuck.

They may use one object on several different hotspots. They may return to the same character and ask the same questions again. They may inspect something several times because they suspect they missed a detail.

That made some responses sound much worse than they had sounded while I was writing them.

A generic response might be perfectly acceptable once.

After hearing it five times in a few minutes, it becomes irritating.

I have therefore been going back through a lot of failed interactions.

Some need several responses instead of one.

Some need a more specific explanation.

Some are good places for humour.

In a few cases the failed interaction itself can help the player understand the puzzle.

For example, if Elia explains why an object is useless in that situation, the player can eliminate one idea and move on.

A generic “that won’t work” leaves them with almost exactly the same information they had before.

This has also led to another pass over the dialogue in general. Repeated conversations expose lines that sound fine on paper and quite unnatural when someone actually plays through them several times.

Moving around Merrow

Travel time also became much more noticeable during testing.

The first chapter covers a reasonably large part of Merrow.

Initially, walking between locations helps establish how the city fits together. The player learns where the market is, where the towers are, how the streets connect and where they can return later.

Once those places are familiar, the same movement starts serving a different purpose.

A player thinks an object might work somewhere across town.

They go there.

It fails.

They go back and try something else.

Then they remember another location.

After a while, a lot of the play session can consist of moving between attempts.

I had already written in the previous post that I want puzzle difficulty to come mainly from reasoning rather than from the amount of work required.

This was a good example of the distinction.

The repeated walking added time between ideas.

It also made experimentation more expensive. Trying an unlikely object somewhere feels reasonable when it takes a few seconds. The same experiment is much less appealing after several screens of travel.

So I added faster navigation between locations the player has already visited.

I also went back and looked at how other adventure games handle this. Maps, shortcuts and skipping repeated movement are all fairly common approaches.

I am still adjusting the exact implementation, but the basic idea seems right. The first journey establishes the place. Later journeys can be quicker.

What I learned from people playing differently

A lot of the useful feedback came from players doing things I would never do myself.

They missed things I thought were visible.

They interpreted dialogue differently from what I intended.

They tried combinations I had never tried.

They revisited characters much more often than I expected.

They also sometimes solved things much faster than I expected.

When somebody gets stuck, I now try to look at what happened before that point.

Did the clue appear too early?

Did it sound like ordinary dialogue?

Could they still access it?

Did something else accidentally suggest a different solution?

Was the intended interaction clear?

Did the failed attempts give them any useful information?

Those questions have been much more useful than simply deciding whether the puzzle technically contained enough clues.

They have also made the design principles from the previous post more concrete.

If a player spends most of their time reasoning about several pieces of information, that is generally what I want.

If they spend most of their time walking around and trying every inventory item, something probably needs attention.

What I am working on now

Most of the current work is refinement.

The interaction problems found during the first testing round have largely been addressed.

I am going through the dialogue again, especially repeated interactions and places where characters sound too much like they are delivering game information.

Some lines are being cut. Some are being made more natural. Some places could use more humour.

The voice work is also getting another pass, together with the dialogue changes.

Animation still needs a considerable amount of work. For this stage I have been prioritizing interaction, dialogue and pacing.

It makes more sense to solve those problems while they are still cheap to change.

Once this pass is finished, I want another testing round with people further away from the project.

The first testers were mostly people I already knew.

That was useful for finding the first set of problems.

The next group should have much less context.

I expect them to find different ones.

Discussion question

For people who play adventure games: when you get stuck, what usually caused it?

Was there a clue you missed or forgot? An interaction you did not realize was possible? Or did you simply reach a point where you had run out of ideas?

I am particularly interested in hints that helped you continue while still leaving the actual solution for you to figure out.