How We Make Puzzles
/Hello again! Nick here.
In Valley of Shadow, we just passed the 70 mark for puzzles made. Our design process has evolved a lot over the years, and I’d like to share our current process with others in the hopes that it can help, and also potentially expose some weaknesses in our process via feedback! So let’s just dive in.
Game Outline
First, a quick outline of the game’s design, for those unfamiliar with it.
Valley of Shadow is a puzzle game about spells, and each spell has a Vault tied to it. Each Vault has 4 floors, with a new mechanic introduced on every floor. A good example is the Vault of Light, which is what our demo focuses on - so if you’ve played that you’re already familiar with the spell. Floor 1 uses Light, Floor 2 adds Crystals (a second Light), Floor 3 adds Shadows, Floor 4 adds Pillars (to create your own shadows). This layout was arrived at organically for the first Vault, and it’s a useful confine so we’ve carried it forward into the other Vaults.
Level Design
It all starts with Anthony’s level design. He does a rough layout of the 4 Vault floors in Miro, complete with room shapes. The reason for this is simple: left to my own devices, I simply create square room after square room. I’m a lot more focused on the puzzle design than the level design, and as a result the latter suffers. Anth’s early layouts help to combat this.
Puzzle Design
Once the level is laid out, it’s time for me to come through and populate the rooms with puzzles.
Prior to this point, I’ve implemented the spell in a sandbox and played around with it. This lets me explore the spell, see how it interacts with the other spells, and determine what’s most interesting or surprising about the interactions. This is a lesson I learned from The Man Himself, Jon Blow. In his Indiecade talk, he stated that (my words, not his) a puzzle designer’s job is to explore a mechanic, find the most interesting aspects of that mechanic, and then present that to the player, cutting out the boring stuff in between. Thus, because I’ve already implemented the spell and played around with it, I am generally prepared to take the player on a puzzle journey.
I like to ensure that each of my puzzles does 1 of 3 things: Teach, Remind, or Challenge.
A Teaching Puzzle should be as simple as possible. There should only be a single element in the room that the player hasn’t previously mastered. This allows them to focus on learning and exploring the mechanic at their own pace. These puzzles are often tutorial-like, but they are also most often the greatest “Ah-ha” puzzles in the game. This is because they can teach something that’s been right in front of the player’s face the whole time, they just didn’t realize it.
A Reminder Puzzle should be a bit more complex, and should not teach the player anything new. It should contain only mechanics the player has already encountered. The purpose is to ingrain a mechanic into the player, because they’ll need to use it later. More often than not, these are created after playtesting, when it’s obvious what a player forgets along the way.
A Challenging Puzzle can be as complex as necessary. For these puzzles, the player should fully understand the mechanics, and just has to figure out how they interact in order to solve the puzzle. Ideally, these aren’t needlessly complex; they should be as simple as possible while still creating the challenge.
I’ve found these categories surprisingly helpful. They are useful during playtesting; because when a player is stuck, I know exactly what purpose the room they’re stuck in serves, and can tweak it accordingly. Is the player stuck on a Teaching puzzle? There’s probably too much complexity in the room, remove some elements. Are they stuck on a Challenge puzzle? Maybe we need some more Reminders earlier on, or maybe the room is just too challenging and some minor tweaks are in order.
Additionally, they are helpful for laying out the levels. For each Floor, I know I’ll need a couple Teaching puzzles up front, maybe a Reminder or 2, and then end with some Challenges. On the most recent Vault, for the Fireball spell, the entire 1st floor is all Teaching puzzles with a single Challenge at the end. In contrast, the 4th floor is 100% Challenge puzzles.
Whiteboxing
The Level and Puzzle Designs have been done entirely in Miro up until this point. We’re making a 3D first-person game, though, so it never translates 1:1 into the engine. Therefore, after every floor, it’s crucial that I whitebox the entire floor in Unity before moving on to the next one. “Whitebox” is a level design term for laying out the level in the editor. The layout is often done with generic, untextured cubes, which is where the name comes from.
Whiteboxing lets me figure out spacing and, more importantly, see how all of the puzzles actually work in the game. It’s one thing to think a design through, it’s another to actually implement it and see how it feels. I like to do this after every floor is designed, so I can take any lessons learned into the next floor. It would suck to design all of the floors in Miro, only to whitebox the very first room and realize I had some flaw in my thinking that requires all of the floor designs to be redone.
Testing & Refinement
Once everything is whiteboxed and functional, I try to get people testing it as soon as possible. There will be bugs, and no polish at all, but that doesn’t matter. I need to see what the player understands, where their focus is, what the difficulty curve is, etc. ASAP. There’s no sense in toiling over a puzzle if it ends up not fitting and just gets removed altogether. A few things that I keep in mind while watching playtesters:
What is the puzzle’s purpose? If it’s a Teaching puzzle, the player shouldn’t get frustrated. If it’s a Challenge, some level of frustration is okay, so long as they eventually solve it.
Priorities! There’s no end to our backlog, and watching playtesters lets me know what is crucial to work on next, and what players don’t even notice.
Avoid thinking “they’re not our target audience”. It may be true, but something can be learned from every person who plays the game, even if they aren’t our ideal player. I’ve made this mistake in the past, and written off valuable feedback under the guise of a game “not being for them.”
So there it is, a fairly in-depth analysis of my approach to designing puzzles. It has evolved over time, and I would love to hear what others think of it, whether you think it’s cool or see an area where it can be improved. Please let me know, either on here, reddit, or in our Discord!