PUZZLES
This section explains my full process in creating, documenting and iterating the puzzles in Façade.
Design Intention
The main goal of the puzzles was to use items hidden in plain sight to solve it. Each puzzle would be contained within its own room, and each room had at least one puzzle, and so the players would always be guided to search the room and look for clues to complete the puzzle, and obtain more evidence to piece together the mystery.
STEP 1: CONCEPTUALISING
The level design and puzzles went hand-in-hand, and so each puzzle was kept in mind when the props in each room were created and placed. As a result, each puzzle I made begun with considering what kind of items would be in the room it took place in, and if they had opportunities for gameplay. Using the candle puzzle in the master bedroom as an example, I felt like a chest of drawers, or a table with multiple shelves would be the best place for a puzzle, as there were numerous things the player could interact with, whether the shelves themselves or items on top, and that there could be hidden items not immediately available.
The experience would then be fleshed out, starting from how the evidence could be hidden, then thinking of what action the player would need to perform to find said evidence, before adding hints to the player to help them figure out the solution. The hints would be found within the room itself, and blend into the environment.
STEP 2: DIAGRAMS
With the idea fully fleshed out, I then moved to make a step-by-step diagram, with mockups of all the different elements of the puzzle would look like on a phone screen. At each step, I annotated the diagram, explaining the actions the player would be able to perform during that step in order to solve it. I would do this for each image until the puzzle was solved, and the evidence was obtained. I would then bring this to the rest of the team for discussion.
STEP 3: FEEDBACK AND IMPLEMENTATION
After sending the puzzle to the team, we would have a discussion on the puzzle, to determine its viability and clarity. The main criteria we looked out for were: Is it fun? Is it solveable? Can the player get confused? Does it work for mobile?
The last criteria was a key one, as every puzzle that was made needed to be able to be completed on a mobile device. This meant that clues couldn’t be too small to see on a phone screen, and that actions were not too complex or precise, which would sour the user experience. Once we had made any adjustments, and we deemed the puzzle to be ok, it was handed to the programming team for implementation, and work on the next puzzle would continue.
GALLERY
Screenshots of some of the diagrams of the puzzles used to send to the team, from different iterations and rounds of feedback.
