Anyone else have trouble coming up with puzzles, or scope creep?

I’m working on a big Inform game, and there’s a section where I’ve been doing ‘one room, one NPC that has a request’.

But it’s really hard to come up with puzzles. I even wanted this section to be ‘just simple traditional puzzles’. I’ve brought up pages from old games like Adventure or thought about people’s games who write trad-puzzles (like Garry Francis), but a lot of times I just sit and stare at the computer.

And when I do think of something, it always ends up being something overly elaborate like a machine or a conversational puzzle that is hard to program.

How do you guys come up with puzzles, especially in larger games? Especially, how do you come up with puzzles that aren’t a huge pain to code?


I’m by no means an expert on this, I find it’s super helpful to have a non-IF source to riff on. Like, for Eleusinian Miseries, I read about what we know about the elements of the real-life Eleusinian Mysteries, and though about how I could turn them into puzzles – there was a sacred drink, a joke contest, a vigil, and a call-and-response section, all of which sparked ideas. Then since the game was also riffing on P.G. Wodehouse, I also brainstormed a bunch of Wodehovian set-pieces, and picked out the ones that seemed to lead to fun puzzles. The game also has a number of puzzles that didn’t come out of those processes, but they’re the ones that I think are less inspired and more typical IF fare (well, except for the pig – the puzzles involving him didn’t come from anyplace in particular, but I still like them, proving that you can never go wrong with a comedy pig).


The Infocom folks kept puzzle books and issues of Games magazine around the office for inspiration. I’m pretty sure Games is still around, and they probably are still good for ideas!

In my own game—which may be bad, so you might be better off ignoring this—I’ve taken a narrative-centered approach. i.e., after I had the story I asked, “what kinds of things would get in the way of this character doing these things?” I sought complications to the plot and then turned them into problems for the player to solve.

Admittedly, that process is going to favor some types of puzzles over others. There’s nothing like the babel fish puzzle in my game, as much as I love it.


I don’t have as much to contribute here, but I do have a quick thought. Have you considered mining mysteries for puzzle ideas? The protagonist solving the greater mystery is basically the PC solving a series of puzzles. Surely, between thousands of mystery novelists and endless hours of serial TV whodunits, there must be some useful material or ideas for puzzles. I imagine you could get ideas just from watching reruns of Scooby-Doo or Monk.


I like to draw a puzzle chart / puzzle diagram way before I start coding the game. It is basically a large chart of connected boxes, what puzzle is required by what other puzzle. I find that drawing it out makes it easier to trace the way from beginning to end. Musing over the chart is a great way to improve the game and come up with new puzzles or new solutions to existing puzzles.

It also makes it easier to expand a puzzle.

Say I have an arrow going from A to B. (A might be “find something” and B might be “open something”, meaning A is like a key and B is like a barrier). If I now want to expand the game, I can come up with something like, maybe the key is composed of multiple parts. So now I add C and D beside A, and all three point to B, meaning it requires all three. Now I also need to incorporate where C and D are found / how to get them, which leads to even more puzzles.

Sometimes I also chop off nodes from my chart if I do not really like it or find that it is not needed for the game.

My puzzle chart will need to be in a good working order before I start on the game actually. But it does not mean it is complete. It will change during development and even during testing when I find out that something works or does not work. Or sometimes something requires too much coding or is too complicated, and it gets axed or replaced. But having the puzzle chart at all times makes these changes a breeze to do. I really struggled with my games before I started using charts.

Back to your initial question: just looking at the chart is also a great way for me to get ideas what to do next. Inserting puzzles here and there, then reading through gives new ideas more easily.

But I do get stuck sometimes myself. I find it best to just leave my chart in peace for a little while. If I am still in the design phase, I might work on another project. If I am already coding the game, I can work on something else, and come back to it later. Forcefully trying to come up with something usually does not work.

(In fact, I am stuck in making a puzzle work in my next game I am designing, have been stuck for a few weeks now. But I am letting it stew in my thoughts, I am sure something will present itself sooner or later).


So I’m not exactly the expert on making large puzzle games, but I notice that many of the most successful ones build around puzzle mechanics. So Savoir-faire has a combination of food recipes and it’s own particular magic system; Hadean Lands is built around alchemical recipes; Scroll Thief is all about using a collection of spells; and Arthur DiBianca’s games also tend to be perfect examples of this approach.

Alternatively, there are the games that lean heavily on integrating puzzles with story. So there the puzzle ideas come from the fact that, first, you need Harry to give you the dirt on Frank, but of course he would never give it to you as long as he thinks Frank is his best mate, so you now have to uncover evidence that Frank is cheating on Harry with his wife, but in order to do that…

I think you make things very hard for yourself by trying to come up with puzzles in a vacuum! Of course you can always add in some simple ‘use A with B’ puzzles – the locked bronze door for which you need the bronze key, the hungry NPC who must be given the delicious taco – but they probably won’t feel as satisfying to you as puzzles that are either mechanically or narratively integrated with the rest of the game. :slight_smile:


I’m with you on this, Brian - I think integrated puzzles are (for me) the hardest part of writing parser based puzzly IF. Specifically, coming up with puzzles that are fully integrated in the world. the locale, and the story and aren’t just a puzzle for the sake of there being a puzzle - you know, the old saws: the fox, chicken, seed, Towers of Hanoi - that sort of thing.

For me, when I 'm writing a puzzly game, I try and class each puzzle into the type first, which specifically revolves around what I’m trying to achieve as the author - What do I need to enhance the player’s game experience.

For me, there are four main overarching types of puzzle and puzzle rationale which directly impact this:

  1. A gateway puzzle. The way/an area is blocked until the player does X. In this case, I am trying to frame the game to get the player’s focus on a specific area before I allow them to move on.

  2. A narrative puzzle. The plot will not move forward unless a player does X. I need the player to talk to NPC’s A and B so the plot makes sense and the player has experienced all the bits of plot I need them to experience.

  3. A Puzzle System - As Victor mentions above, my game, or an aspect of my game revolves around getting puzzle system into a specific state before the player succeeds.

  4. Score a Point. The player has a score command. They need to do X to score.

Once I have made this determination, which is directly aligned with my story, I look at the locales themselves and the world I am building. So I have multiple areas - the puzzles musty be aligned to what is presented to the player. I have a laboratory? Pop a complicated machine in there. A kitchen? Cook something. An NPC? They’re sad. Why are they sad? How can the player make them happy? A dungeon? Oh, I don’t know - something to do with locked doors and/or the timed movement of guards.

Once I have these three basic things : Here’s why I’m doing the puzzle, here’s what the player achieves by doing it, and here’s the type of thing it needs to be based on my world-building, it usually flows from there.

I’m going to link back to the white whale thread here. Of all the things I think have stopped me in my tracks when writing parser IF - it’s the realization that the world/narrative I’m creating simply isn’t conducive to puzzles - that I genuinely can’t think of anything sensible within the above framework. Re-write required!

This sort of framework helps me, personally - it may not others. Puzzle creation and integrating those puzzles into a world is an art.



Just an aside, but when I saw the title of your post I thought of a hypothetical game about a stalker spying on his victim from afar with magnifying glasses.

It would be titled Scope Creep.

Probably just the aftereffects of EctoComp…


The sequel is called Scope Creep and the Combinatorial Explosion.


I don’t think there is an easy answer to this. I use a lot of different techniques to come up with puzzles. Once I have a basic storyline and map, I start to populate it with potential NPCs and objects and find that things fall into place. Imagine that I have a stable. What would I find in a stable? Maybe a horse, horse manure, horse shoes, bridle, hay. Think like MacGyver. How can I use these objects either here or somewhere else?

I like to use ordinary objects in unusual ways. I use a lot of chained puzzles where you need to do A in order to do B in order to do C. Mind you, you won’t know what the sequence is until you’ve discovered all the relevant objects and tried a few things and received some hints along the way. How do I make things more difficult? Hide things? Make them visible, but inaccessible?

I also use a lot of branching so that you can do various things in a different order. I rarely use a puzzle dependency chart. Perhaps because of this, I sometimes have trouble working out the optimum sequence to solve my own puzzles. But that’s a good sign, right?

When working out the puzzle mechanics, I use little charts and sketches and truth tables and lists and goodness knows what else. I also write little transcripts. All these methods lead to different ideas and “what if” scenarios.

I keep a folder of “adventure ideas”. Some of these are storylines, some are ideas for puzzles, some are mini walkthroughs. I draw on lots of resources, such as puzzles in books or newspapers. However, you have to be careful of puzzles for puzzles’ sake. If I have an idea for a puzzle that I want to use, I make sure that it is integrated into the story and fits into the environment.

I also do a lot of research. This often leads to puzzle ideas. For example, when was the safety match invented? If it didn’t exist in the pirate era, then you’re going to have to use a different means of lighting fires. This leads to new objects and new puzzle ideas.

I never thought of my puzzles as being “traditional puzzles”, but I know what you mean. I think most of my games have at least one idea that has never been used before, but puzzley parser-based games will always have a lot of things that aren’t entirely new. There’s nothing wrong with that, as it gives the player a comfortable feeling of familiarity.

If you’re short of ideas, put it aside for a while and something will spring to mind when you least expect it. Or work on a different part of the game.

I’ve never had any trouble with scope creep. On the contrary. I get to a point where I can’t think of what else to add. That’s when I know it’s done, at least from the puzzles point of view.


In parser games, there’s always an environment or three. So if I had to super-summarise my approach, the story determines the nature of the environments and then the environments’ natures determine the puzzles.

If I can’t come up with enough motivated puzzles to suit an environment, I need to shrink or change the environment. Or more drastically, the story so that the environment is more conducive.

I probably don’t suffer much scope creep at a microscopic level, because I implement so heavily, by the time I’ve fully built just a few ideas from a list into part of the game, they have become so much business that I don’t need to add more from the list. My brain says ‘That’s enough.’

I can’t speak on the topic of gigantic devices and such as I’ve rarely built any. I don’t think I’m great at them as a player. As an author, I’m afraid I will bore people describing such things at length. It’s enough work to just describe everything in a location, let alone the ten dials and levers on one machine in that room in such a way that won’t confuse anybody!



Just a little bit of practice, and you too will be able to write:


I am terrible at writing puzzles, but I love solving them. I read @McTavish 's list with interest, because I always categorize puzzles quite differently. I think puzzles fall under 3 broad categories:

1.) Puzzles that are there to be puzzles. There’s no sensible reason why you have to play a game of chess to unlock a door, or figure out the 10 levers to operate the machine that inexplicably makes a key to the door, but they’re there for puzzle-lovers to solve.

2.) Puzzles that grow organically out of the story. These tend to be fetch-quests or convince-people tasks or figure-out-what-the-NPC-wants puzzles.

3.) Overarching mechanism puzzles, where you have to figure out variations on one central idea for the entire game. Think Hadean Lands or Counterfeit Monkey.

I love and play games with all these approaches. #1 is the hardest, I think, since you have to make up a bunch of zippy puzzles and then fit your story around them. But luckily, since #1 doesn’t have to make sense, you can just do what you like and the player will happily learn a series of dance moves that lower the rope from the ceiling.


@VictorGijsbers : I LOLed in RL.

@mathbrush : I guess you know all about my puzzles, which are usually easy and plain. Anyway: I tend to imagine rooms, places, environments and—above all—to tell a story. This means that puzzles come up by themselves (I usually don’t waste too much time creating them–>and it shows!) and they are just a medium to a larger environment/story. The few times (like in my very first effort, Awakening) I really wanted to “create” a puzzle, it came up obnoxious and detached (the soap-for-a-key comes to mind).

So, my advice, and YMMV depending on how your brain works: you either invent a “system” and use and expand it everywhere, or—eventually, in story-driven stories—you just go there relaxed and let the story create them for yourself.


I’m not sure I 100% agree! I think a huge part of the art of IF is working out, as an author, why there’s a reason to play chess to unlock a door and how that can be represented in a way that makes narrative sense to the player.


I tend to be pretty hard on puzzles that don’t make narrative sense, even when it comes to “classics” like Zork III’s Royal Puzzle. As a player, it’s important to me that they feel like… intuitively sensible parts of the world.


Ideally. But there are many, many games that don’t make any attempt at all to work such puzzles into the narrative. There’s probably more pressure on IF authors to try and make the puzzles make sense, since IF is supposed to be narrative-driven, but in the point-and-click puzzle game world, many of my favorite developers don’t even try. It’s just a series of puzzles. I’m totally fine with that. Sometimes I don’t want to unravel a big complex story-- I just want the comfort food of laser puzzles and sliding tile puzzles, etc.

Take The Room series of games. They make an extremely weak attempt at a plot line, but you don’t need to follow it at all. You’re just futzing around with opening mysterious boxes and tinkering with complex machinery, and it’s incredibly fun, and those games were extremely successful. I recommend them all the time.

** Edit-- Thinking about it more, I can think of a dozen great puzzly IF games off the top of my head where the author made only a hand-waving attempt to rationalize the obstacles. Either you’re OK with this kind of thing, or not, but there’s a definite audience for them.


Play Finding Martin, if you haven’t already.

Seriously. Play it.


I’m not an expert either, and my experience is limited.

Ron Gilbert’s rules of thumbs is useful to keep in mind, especially “Backwards puzzles” and “Puzzles should advance the story.” If you’re working on a multi-stage puzzle, “Incremental reward” is another design choice to consider. (I love it when a game allows me to get part way through a puzzle, go off and work in a different part of the map, and then return later.)

Recently I was cleaning up some IFWiki links and found Bob Bates’ “Designing the Puzzle.” It might be useful to review as well. He categorizes different kinds, and offers suggestions about good ways and not-so-good ways to implement them.

When looking for an easy win, I look for ways to utilize pre-coded components in the TADS library (I’m sure Inform has them too). If I have to code a new verb (that’s not a synonym for an existing one), I also consider that to be a bigger bite than a built-in verb.

In other words, “easy” puzzles that require pushing buttons or pulling levers or setting a dial to a number are attractive, because it’s less code to crank out. Of course, these are stock library objects because they’re stock elements of IF. That’s the trade-off.


Totally agree. The Room is one of my absolutely favorite game series. Also “House of Da Vinci II” in that same vein. I do think it’s easier to make an attractive puzzle in a video-oriented game. The video tricks your subconscious into thinking, “Well, it’s real and it’s there, that’s all.” Doing the identical puzzle in a text environment might be a lot less satisfying.