Creating a Language for Complex Puzzle Design
One of the important design tenents that I am sticking to in order to set Lost in Transit apart is that I want to avoid the “samey” feel of puzzle design that many current games out there that I have played tend to employ. (How many times have we seen the “move blocks on switches” puzzle since the original Zelda on the NES now?) While sketching out level design ideas, I hit a brick wall early on when it came to creating complex puzzles. Initially, I would get several steps into sketching a more complicated puzzle idea and suddenly realize that I had not accounted for the possibility of players getting “locked” into a state that would cause the puzzle to be unsolvable if they made the wrong choices. The only recourse at this point is to completely throw out everything up to the point where the players can get themselves permanently stuck and fix it. As such, I became wary of exploring greater levels of complexity in a puzzle idea unless I made sure to circumvent the possibility of a progression blocker. Unfortunately, this precaution trapped me in “2-basic-action” puzzle territory, which is probably best illustrated by the “find hidden block and move it on switch” puzzles in Zelda. The conclusion I came to at this point was that I needed to create a puzzle language that could get me past the complexity roadblock, and with Adam’s assistance, we came up with our own 2-tiered process, the first of which I will delve into below.
The first step is to focus only on the amount of possible actions in a puzzle and charting the series of actions that represent the solution. The important thing at this point is to completely ignore what any of those actions might be in the game. To arrive at our method we first charted what we described as a 1-level puzzle, which appears as follows:
An easy way to visualize how this would manifest itself, an every example hereafter, is to imagine that an action is a button press. However, this could be anything from knocking out a support beam to pulling on a rope, to pushing a block to a new location. Regardless, imagine that the above example is a giant button in a room that, when pressed, opens a door. This can barely even be defined as a puzzle (if at all), and is EXTREMELY easy to solve.
In a 2-level puzzle, or in other words a puzzle that requires two actions to complete, its complexity immediately jumps when charting it out, despite the fact that these are still very easy for players to solve. Take this for example:
To continue the simple “actions as buttons” analogy, this chart conveys the following: Initially, there are two buttons to press. If the player hits button B, a “wrong answer” buzzer will sound and the button will go back to its default state and the player can press it again (which will always result in the same “wrong answer” response. The “X” written after the B in the above chart is extremely important, as that represents an available incorrect option that must not block player progress if chosen. The 1 states how many steps in the chart the puzzle reverts if the X action is chosen, which in this case simply bring it back one step to the initial state of the puzzle. If the player presses A in the initial state, then the A button must return to the exact same “pressable “ state because it is also listed as a subsequent available option. If the player then chooses B, the game tells the player “wrong answer” as before, but sends back the player two steps to the initial state. If the player hits button A twice, the player solves the puzzle.
This is a 2-level puzzle because if you follow I to S, there are two steps. However, added complexity was added by the fact that after committing action A once it is available a second time. Thus, as a second method of quantifying the difficulty of the above puzzle, we count the amount of Xs, which makes the above a 2-2 level puzzle.
Now lets try and chart out a 3-level puzzle:
The solution path is as follows: The player does A (which causes C to appear, then B (which results in B disappearing), and then does A to solve the puzzle. Since there are four Xs, we can then rank this level as a 3-4 level puzzle.
The ranking system has three main benefits. One, it will allow us to chart them in a difficulty curve in an effort keep the pacing smooth. Second, through user-testing especially, we will be able to find a sweet spot for how many “wrong action,” or X, options there are in a given puzzle–none being way too easy, too many being too frustrating. Third, it will allow me as a designer to set out to make a difficult puzzle by choosing how many steps to the solution there are, and charting it out from there. Of course, translating these flow charts into a realized puzzle with defined actions on in-game assets is still a daunting task, but using a “blueprint” so to speak makes the process of designing a complex puzzle much easier.
Although untested at higher levels of our imposed ranking method, I will be sure to report back on how the above method works out in helping me to create complex puzzles from concept to implementation.
