Puzzles in games are great. They are a fantastic way to get players thinking, where they need to pause for a moment and flex their mind. You can build an entire game out of puzzles for more intellectual players looking for a challenge, or you can use puzzles as a break in your action title to give players a rest. Some developers also enjoy weaving together puzzles with their action challenges, creating new genres and great new experiences.
But for a puzzle to be fun, it needs to be properly constructed. So that begs the question: how is a puzzle built? We’re going to cover this in its simplest form, but the rule still holds true for other designs. As many readers of The Game Prodigy already know from other articles, a puzzle can be defined as a circumstance where the player sees a problem and doesn’t yet know the solution. If the player flies through the solution without understanding it, then it’s not a puzzle; it’s just some brief interaction in the game. Or if the player immediately figures out the solution and executes it just as quickly, then it’s not a puzzle either. Or at least not a good one.
In this simple example, the player character, the Jelly, wants to get inside the door. However, the door is locked and needs a key to open. If the game designer just placed the key and the door right next to each other, then the player might not even really understand what’s going on. The puzzle doesn’t stop them and require them to think, so this fails as a good puzzle. They just blow right through it, the designer may as well have not spent the time to make the key in the first place.
Good puzzles present themselves to the player and require the player to stop, understand them, think about them, and then come up with a solution. If the player is never aware of the problem, then the puzzle isn’t a very compelling and the player is robbed of the experience of figuring out something interesting.
So back to our previous example with the Jelly and the door. To be made into a simple puzzle, the door, which is the problem to be solved, needs to present itself to the player. The player should understand that they need to get in the door, but it can’t be opened at the moment. At this point the player starts to think, “Hmm, this is a problem. How do I open this door?” That is when the design has fulfilled its purpose, by getting the player thinking about what they need to do. Then the designer presents the player with the solution.
So when you’re working on puzzles in your own games, rememeber: Present the problem to the player first, make them stop and ask the question, “How do I solve this?” and then allow them to seek out the answer.
Yes, good article if a bit short (not that that’s a problem by any means!) I dislike developers confusing the things that make up modern-day zelda for puzzles.
Developers! (Including me to an extent although Game development’s just a hobby right now (I’m a student.)) Puzzles are not procedurally lighting every unlit torch in a room! They require thinking. Unlike modern day zelda…
There are some really interesting puzzles in The Legend of Zelda: Spirit Tracks. I will say that much.
Do you guys have any videos you can find online of some of your favorite puzzles?
http://www.youtube.com/watch?v=dzyY9y2I570#t=09m40s
That’s the puzzle I was talking about. But overall Spirit Tracks has a lot of brain melting puzzles.
I stumbled across you site. I’m still checking things out.
But I will say that your definition of a puzzle is pretty weak:
“puzzle can be defined as a circumstance where the player sees a problem and doesn’t yet know the solution”
Simply not knowing/seeing the solution has more to do with player experience than puzzle design. For instance, what happens after a player solves a puzzle. Then from that moment on, that player knows the solution. So does that mean the puzzle ceases to be a puzzle? Of course not.
Furthermore, what if I take a simple action based challenge like throwing a bean-bag on a square 10 feet away. You may not know the rules of this game/challenge. So you’ll probably use trial-and-error to test a few ideas out. Does not knowing the solution make this simple action challenge a puzzle? And again,what happens after you figure things out.
It’s simple questions like this that already work against the framework you have here.
I offer my work as an alternative for clarification.
http://critical-gaming.squarespace.com/blog/2010/1/7/puzzle-design-decoder-reading.html
http://critical-gaming.squarespace.com/blog/2010/1/7/puzzle-design-decoder-reading.html
http://critical-gaming.squarespace.com/blog/2010/1/24/elegant-brute-force-solutions.html
http://critical-gaming.squarespace.com/blog/2010/8/18/puzzle-design-reading-failure.html
Hi Richard, thanks for the great comment!
In my experience in the industry, especially in the discipline of design, it’s often too easy to box yourself in and miss out on possibilities. For that reason I often try to keep my definitions as broad as possible to allow for innovation while still catching the core points.
“For instance, what happens after a player solves a puzzle. Then from that moment on, that player knows the solution. So does that mean the puzzle ceases to be a puzzle? Of course not.”
This is getting a little too philosophical for my tastes, but I would say that yes, actually, for that player, it’s not a puzzle anymore. The first time when we were children we couldn’t understand how turning a glass of water sideways into another cup would move the liquid. It made no sense; it was a puzzle. We would watch our parents do it but couldn’t reproduce it ourselves. Now that we’re older we fully understand how it works and don’t give it a single thought; it’s not a puzzle to us anymore, it’s just an action we perform. The puzzle is the actual act of trying to figure out how something works.
“Furthermore, what if I take a simple action based challenge like throwing a bean-bag on a square 10 feet away. You may not know the rules of this game/challenge. So you’ll probably use trial-and-error to test a few ideas out. Does not knowing the solution make this simple action challenge a puzzle?”
If you had some mechanism of telling the player when they succeeded and when they hadn’t then yes, this would be a puzzle. This is actually exactly a common puzzle in many Zelda games. There is a bow and arrow (beanbag) and there is a small switch far away (square). Nothing is telling Link what to do; the player needs to experiment and figure out how the puzzle works. They throw the beanbag/arrow on the square/switch, and the door opens, signalling they’ve figured the puzzle out. This isn’t much of a puzzle to Zelda veterans who have solved this before, but it does take quite a bit of thinking for someone encountering it for the first time.
I looked at a couple of your articles; great stuff, very well thought out. Thanks for the links!