Spirit Island Development Update: For my third Unity prototype, I designed a difficult puzzle for a touchscreen device that required three steps of logic and relied mainly on audio clues. The goal was to for the player to experience a moment of joyous surprise and a great sense of accomplishment after completing the puzzle.
Part 1: Research and Concepting
A well-designed puzzle inhabits that ideal gameplay state that we aim for as developers: challenging enough to give players a sense of satisfaction, but not too difficult to cause frustration. Games don’t necessarily need them - first person shooters don’t, for example - but some genres do. The last time I played through a point-and-click adventure game without good puzzles was the last time I quit a game only partially through; it’s just no fun.
As a point-and-click adventure game designer, I want (need) to learn how to make good puzzles. For this prototype, I didn’t just want the puzzle to be good, I wanted it to be difficult. I wanted to find the sweet spot where most players were challenged sufficiently enough to have a monster smile on their face the second they completed it.
What’s more, it had to be surprising. I want to give players the joy of discovery. So - two smiles, one playthrough.
That’s what I’m going for: difficulty and surprise.
I am prototyping this puzzle to live in the universe of my larger game project Spirit Island. I know that the general style is a point-and-click adventure game, but where do I go from there?
I began by considering a question posed by Jolie Menzel in her 2016 GDC talk “Solving Puzzle Design”: will my puzzle be homogenous “systems-based” or heterogenous “context-based”? As in, will my players have a set of tools that they carry around that they need to interact with this puzzle? Or will the tools arise differently in each situation?
As a story-based game, I immediately chose the latter option. This puzzle would be about exploring new interactions during the obstacle. Discovering how to manipulate the puzzle itself, and not the tool, was the goal.
In another great GDC talk by Noah Falstein, he says: “Stuck on a story point, work on game, or vice versa.”
I turned to one of the most poignant moments that I currently know from the plot of Spirit Island. In this moment, Emma is alone in her father’s house, and she is searching through it to find clues that might point to his whereabouts. She has just uncovered a section of a rug and found a combination lock in a hidden hatch. When she enters the hatch, it will set in motion a major turning point in the narrative. For now, she just has to get in it.
That was enough of a hook to get me going. I continued to develop the story around that. I determined that the combination of the lock changed at whim, and so there was no chance of her finding it written (correctly) anywhere. The house was the magical entity that changed the code itself, but it always found a way to communicate the new combination to the person to whom it wanted to grant entry.
I looked around my own office for inspiration. I asked myself: "If I were to hide information in this room, where might I put it?" In the lining of a framed photograph? (Boring!) In a strange arrangement of the chairs around a table, whose shapes might make something out at a certain angle? (Might be interesting). My gaze fell on my record player. Now that would be a cool place to hide information! Spirit Island was going to rely heavily on audio cues so - BOOM! Record puzzle.
Setting the Difficulty
Menzel has a simple breakdown for what she calls a “difficulty dial”. According to her, there are three things to consider when determining how difficult a puzzle is:
How many steps does it take to solve the puzzle, and how often is the player getting communicated to by the game that they’re on the right track or not?
Does the player have to use a new mechanic or a new type of information to solve the puzzle?
If the type of information or mechanics is the same, is the way they use that mechanic or information new?
In my current puzzle prototype, the player has to:
… complete three steps, each its own miniature puzzle within itself.
… continue with no communication that they’re on the right track,.
… process audio and written information.
… figure out the mechanics of a record player interface.
… discern the relevant information from lots of “noise” and red herrings.
In other words, my puzzle is hard. I am happy with this.
Learning from Other Games
I played through a few touchscreen adventure/puzzle games to prepare for designing this prototype. My greatest takeaway was this: Respect your players. Don’t hold them by the hand. I was playing a strange game called Rusty Lake Paradise when I came across this screen:
There were zero instructions. Now what would you do in this situation? For me, I had no idea. It turns out that it was a simple matching puzzle: match the exact blobs of frog eggs until they all disappear. It’s a very easy puzzle, but it wasn’t within the context of the game.
This puzzle had two parts: the first was just figuring out what it was!
It required that players first observed and tested the world before even beginning the “main” objective. This is something I want to try out myself.