During the last year I've had a lot of opportunities to think about what puzzles are and what their role in video games is. I know that I'm not the first to write about this, and that many other experienced game designers have their thoughts on this topic, but I also had my own, personal, trial and I do believe that the lessons my team and I learned will be helpful for any designer that has to face a similar situation.
As a new member of the Tequila Works team, I was specifically hired to be in charge of the "puzzle design" of the studio's first game, Deadlight -- a cinematic platformer set in a post-apocalyptic Vancouver, published on Xbox Live Arcade by Microsoft.
When I came aboard, one year before the estimated ship date, I was told that the team already had a game -- actually a nice one -- running, but that they needed someone to "design the puzzles." After several years designing video games, it was the first time I had to deal directly with this essential part of many video games.
I should probably explain my previous experience as game designer. It will be enough to mention that I worked on the design of some of the levels of NyxQuest: Kindred Spirits and The Fancy Pants Adventures, which are pure 2D platformers. These required from me to create interesting layouts, gameplay situations, and simple switch on/off puzzles for the player to solve.
Top: NyxQuest: Kindred Spirits. Bottom: The Fancy Pants Adventures
The situation I was facing now was different that then most of the gameplay situations I had created or polished -- these were twitch-oriented, skill-based situations in which the player was supposed to react accurately under stressful circumstances (i.e. perform a series of jumps while the floor is falling down). In Deadlight, the puzzle situations would be much more deliberate and slow-paced.
It should be understood that the puzzles were considered key to Deadlight, together with the navigation and the combat, to the initial core game design.
One of the main objectives of the puzzles was to extend the game experience without increasing the size of the levels (which were really expensive to produce).
As you might know, one of the classic problems you find while creating a new platformer is that the player can move forward pretty fast and go over many "screens" if he has nothing to do but navigate. It's simply impossible to fill the world with so many scenarios. Given that, it's important to slow down his progress. Common solutions are to force the player to go back to a location in order to find something, to revisit areas to perform different actions, or to introduce vertical gameplay.
When I began work on the project, Deadlight had only combat situations to slow down the player. But this wasn't enough, as the combat system wasn't designed to sustain hours and hours of gameplay by itself.
Apart from this practical consideration, it was decided that Deadlight should be much more slow-paced than a typical platformer thanks to its theme. We were creating a game about studying the environment as a survivor would: to find useful items and to bring them with you, and to be smart while navigating a devastated world.
Deadlight used to have an inventory system. As in the old graphic adventures, it was possible to keep, use, examine, and even combine items.
Deadlight's inventory system
As a game designer, the first time I heard about this feature, it totally made sense for me. Randall was a survivor in a zombie apocalypse, and survivors need to make the most of the environment in order to maximize their chances of surviving. Looking for useful items in piles of trash, searching rotten bodies, carrying apparently useless items that suddenly are the solution to deadly problems -- these are clichés in the genre.
An inventory completely suited the mood and the concept of the game. Something necessary, a game mechanic that would support the direction of the concept -- perfect!
At the same time, it looked like it would expand our gameplay, providing us with a powerful tool to create hundreds of different variations on puzzles. Everyone in our team had played classic graphic adventures, where the inventory was key for solving the puzzles.
Finding, using, and combining items seemed it would be the solution to our problems. It seemed that it would allow us to increase the length of the game without relying upon the size of the levels.
And so we started to design graphic adventure-like puzzles. I still remember most of them; for example, at one point in the first act, the player needed to find a gas can, fill it with the fuel of an abandoned car, and then use the gas to fill the fuel tank of a fire truck. After doing so, it was possible to move the ladder of the fire truck and continue.
This is where the fire truck was