Designer Diary 7 - Interaction

As with any design project, things get cut. From early brainstorm to final game, maybe about two thirds of the original puzzle ideas make it in. In most cases, they were just not quite right to have inside the game, either because they deviated too far from the way the rest of the game worked, or got in the way of a smoother gameflow. Some of them just didn’t want to be what I wanted them to be… so I decided to allow them to be something else. That came about from playtesting and seeing how users interact with my design.


I wrote about having in-person playtests in an earlier post and was happy to be able to do a fair amount for The Emerald Flame. As I was sitting in on playtests I would hear people speculate about what to do, saying things like, “Does it want us to cut it?” or “Is it asking me to find X?” I realized they were personifying the puzzle they were working on, and, as I realized I do this a lot myself, I began to think about why.

The puzzle is an entity you’re interacting with.

It may not be a conscious entity, but it is a task that was designed to be solved. A human being put it together in order to try and communicate something. Sometimes when you see a puzzle, it feels like it is asking you to solve it, in the same way that a slice of cake is inviting you to eat it. But how do we draw people in and make things look appealing to interact with? What makes that spark inside us light up when we gravitate towards something? What even makes something look like a puzzle, or look like it can be manipulated in some way? From watching other people play games and trying to figure out what draws me in as a player, I’ve observed the following as being effective beckoners:

  • Display points of potential interaction. (We like to do things that affect other things. It’s always fun to push buttons, toggle switches, etc.)

  • Imply assembly or disassembly. (You’re taking one thing and making it into another. Transformation is pleasing.)

  • Make it pretty. (If you’re going to be looking at it for a while, it might as well look nice.)

  • Create mystery. (What are these weird symbols? Where could this path lead? Is there something hiding in there?)

  • Repeated imagery. (Seeing repeated elements across different areas might begin to make you wonder how they all connect.)

In the end, curiosity is everything, and sparking it is what invites players to interact.


Don’t kill the curiosity.

Sometimes difficulty can kill curiosity, and a huge part of that is signposting. The less signposting, the more “difficult” a puzzle becomes, but signposting also ties in to the idea of player engagement. When you look at an item, something has to grab you right off the bat, but it also needs to have some breadcrumbs for you to follow. If you’re aiming for a smooth player experience, you want to give puzzles some sort of entry point, or an onramp. This might mean a simple clue, an explanation of certain rules, an example showing what needs to be done, or even just some kind of recognizable symbol. (For example, a scissor icon? I probably need to cut this.) If there are no strings to grab onto, the less determined player might be left frustrated and abandon the puzzle. It is so sad to watch people walk away from a puzzle.


In the puzzle below your goal is to extract some letters, and some are already given as an example. If there were fewer example letters, or none, the puzzle would still be solvable, but a whole lot more people might walk away from it saying "I don't know what to do." With these examples you can begin to discern a pattern and connection between the items and letters. How do you decide how much to give away though? That depends on your purpose. Who will be solving the puzzle and why? How challenging do they expect (or want) it to be? Since this puzzle was created for a casual online audience, it became clear that it would benefit from a couple extra clues, which might not have been the case if it was made as part of a puzzle hunt for enthusiasts, for instance.

Am I doing this right?

Solving a puzzle feels like a victory, and you want to know it when it happens, because ambiguity is kind of a buzzkill when you think you won something. So what are ways to reduce ambiguity about a process or solution of a puzzle?

  1. Tell the player what they’re looking for. Is it a place, a number, a name? Having a goal helps you find your way to it.

  2. Have a self-confirming answer such as a word or phrase. Numbers can get tricky because there’s often no way to know if it’s right without checking. Try to avoid gibberish answers (like CGFNBKSHJF) unless it’s clear they still need to be deciphered, though I think double decoding is also to be avoided.

  3. If it’s a multi-layered puzzle, it helps to have self-confirming steps as well. It’s like positive reinforcement to continue.

  4. Avoid long dependency chains, especially with numbers. If there are too many variables it becomes hard to know where you made a mistake.

  5. Avoid red herrings and leave smaller margins for error. If too many people are going down the wrong path, you might need to close that gate.


When the intention is being communicated clearly, players will have less moments of questioning and more reassuring moments of “this looks right!” Then, when you finally solve something, it is like your mind and the mind of the designer have aligned, creating a feeling of harmony and satisfaction; of understanding and sharing an idea, even if just in the abstract.


Freedom to interact.

I wrote a previous post about linear vs non-linear gameplay and playtesting The Emerald Flame only reinforced my tendency toward the non-linear. Within a chapter nearly all the puzzles can be solved simultaneously, and it was interesting to watch people pick up the components and choose what puzzles to work on first. The fact that everyone was making different choices was a positive sign - it indicated that the variety and the open format were working. However, there was one exception.


There was a puzzle (puzzle B) in the third chapter that couldn’t be solved until another puzzle was completed (puzzle A), and it was surprising how much it ended up stalling the game. During one test, the players hit a bottleneck. One was working on puzzle A, and the other got stuck on puzzle C and said, “I wish there was another puzzle to do.” They had already solved everything except for puzzle B and C, and I thought, “Why should puzzle B be sitting there while this player has nothing to do?” I want people to stay occupied and engaged.

On top of that, this test was only a group of 2, so what would have happened with 4? Or if the game was entirely linear? I think the level of frustration would have gone up exponentially and many more thumbs would have been twiddling. In the end, puzzle A was entirely too difficult and didn’t fit within the rest of the gameplay, so it changed completely. I also removed the dependency between puzzle A and B so that B could be solved separately, keeping consistent with the non-linearity of the rest of the game. Doing both of those things required some late changes and compromises, but dramatically improved the interactions and player feedback in the final chapter of the game. Just goes to show that sometimes it’s up to the players to show the designer what a puzzle does (or doesn’t) want to be.


What are your thoughts on improving user interaction?


Stay in touch!
  • PostCurious Facebook
  • PostCurious Instagram
  • PostCurious Twitter
  • PostCurious Tumblr

© 2019 PostCurious LLC