Creating Puzzles: Objective-based vs. Solution-based Puzzle Design

Most puzzles in IF are essentially either doors or chests: some combination of actions and/or items is required to “unlock” an obstacle that provides us with something new. For “doors”, this is access new section of the map; for “chests” this either a treasure or a new tool to use in further puzzles.

Today I’m wondering about how different authors create puzzles from a blank slate. Is your puzzle design objective-based or solution-based? That is to say, do you start with an objective or obstacle in mind and work backwards to devise a means to achieve or surpass it? Or do you have an idea for something the player must do, a fun solution for a puzzle, and create an objective with an obstacle necessitating that solution?

I’ll use Violet as an example to illustrate what I mean.

Objective-based puzzle design: the story calls for the PC to need a pen, and you decide to impede access to it by lodging it in a sprinkler that is too high to reach. With this as your starting point, you work backwards to create a solution wherein the player has to create a makeshift slingshot to knock it down.

Solution-based puzzle design: you have an idea for a puzzle solution where the player has to create a makeshift slingshot using household items. With this as your starting point, you give the player an objective where they require a pen that is lodged stuck in the ceiling.

I’m sure everyone’s answer will be different, but I’m curious which of these methods people tend to use more.


I tend to favor solution-based puzzle design.

When I was writing a game called Absence of Law, I knew I wanted to have a tiny robot that moves around a desk, and a giant robot with a flamethrower, so I had to think of puzzles that those robots could solve.

In my current game, I had a bunch of animals in a petting zoo, and I wanted them to be able to follow you to solve different problems, so I had to come up with problems for them to solve.

In fact, pretty much every game I’ve ever done has been about this, coming up with a solution (or mechanics, more generally) and wondering what problems they can solve (mechanics like ‘3d-movement in an open world’, or ‘fighting-game style attack combos’).


Both! It’s much easier to create a puzzle if you come up with a solution first. In fact, if you’ve got the solution, you’ve got the whole puzzle, and it’s just a matter of finding the right place in your game to deploy it. It’s a lot harder to work the other way, and it normally only becomes necessary when you need to “gate” off a particular course of action. I don’t want the player to have such-and-such an object yet, so I need to create a puzzle to prevent them getting hold of it until the right time. It can take a long time to come up with a puzzle like that which doesn’t feel contrived. One of my games, Yak Shaving for Kicks and Giggles!, sat around for an entire year because I couldn’t think of the right obstacle to obtaining the safety razor. When the idea finally did come to me, it involved reusing an object the player already had, but in a different way, and making use of pre-existing scenery object that I’d put in just for atmosphere. It was perfect, because it didn’t involved creating anything new, and it remains one of my favourite puzzles, but boy, was it a struggle to come up with!


This topic comes up from time to time. Might want to skim this thread: Writing IF: mechanics first, writing second or both at the same time?


Thank you all for these thoughts! I agree that it’s generally more effective to develop mechanics and then work them into the progression of the game.

I think one of the troubles I’m encountering is that my writing process generally begins with developing the setting - an abandoned madrasa, a haunted mall, etc. - and working backwards from there to develop a plot and structure. It’s something I love doing, as I think a sense of place is the single most important aspect of game design, but sometimes it leads to difficulties coming up with mechanics and puzzles post facto, so to speak.