Best practices for puzzle design in Choice based IF

Over the last several years I have observed an increase in the number of choice-based (non-parser) games which employ “puzzles” either for their own sake or to help with pacing a more dramatic story. But while there has been 30 years of discussion on best practice for puzzles in parser fiction (players don’t like mazes, I’m told) there has been less discussion about puzzle design in choice games

What makes a good puzzle in a choice based game?
How much world modelling is required and what type?
What style of UI is preferred for presenting choices in a puzzle-driven game?
Any thoughts about what works and what doesn’t work?


I recently wrote an article looking at some commonalities between these kinds of parser-like choice games and limited-parser games, as well as tracing some shared threads to point and click graphic adventures. The last section in particular tries to queue up some angles for thinking through craft approaches for these sub genres. Anyway here’s the link!


I haven’t played much choice-based IF that presented any particular puzzles of note.

The power of parser puzzles is that you really need to think about how you want to accomplish a task and see if the game is accepting of that conclusion. It requires a bit of strategy and analysis in an environment of seemingly endless possibilities. How do we get that “endless possibilities” vibe in a choice-based game?

The one weakness of choice games is that you can progress without much thought. You click on things and reading the prose is even optional, to be completely honest; the possible choices will always be there, waiting for you. With parser games, even simple deductive puzzles (hit nail with hammer) are satisfying as the answer comes completely from your mind without any prompting. Choice games always distract you from critical thinking with constant suggestions (i.e. possible choices).

I’ve thought a bit about how I would like to implement choice-based puzzles if I ever made a choice game.

1.) All choice engines allow for text input. So while it wouldn’t be a parser to navigate the world and explore it, you might come to parts where you need to know the “answer” to continue. What could it possibly be? These kinds of puzzles push your mind to contemplate the context from which question is being asked, given all that you have explored thus far. It could also be a simple riddle (Q: What gets wetter the more it dries? A: A towel.), but that doesn’t tie into a game’s world in a satisfying manner typically. What is the deceased man’s password to his computer? That is way more satisfying to try and answer.

2.) Choice-based games allow you to “drag and drop” (or some pseudo-form of this) and some games allow combinations of symbols, numbers, etc. This would allow either a combination password to exist or even a set of instructions to be carried out. (Programming a robot to perform a task, for example.) Because the combinations would be quite large, it would require some thought and analysis in most cases and won’t allow for brute force. Brute force is something that you don’t want to make appealing/effective at all or players will do it… and they’ll hate the game for it. Stretch the idea further and you could do the sliding image puzzles… or even crazier stuff.

3.) Then there is bringing some of the freedom that parser games afford into the choice-based engine; like the point-and-click command style of Monkey Island.


Except without a graphic scene, you click on the nouns in the room’s description prose. (The nouns would not look clickable though.) There could be variants of this style, but essentially it’s about a parser-like experience without the typing.

4.) Lastly, pure strategy elements as puzzles work well in choice-based IF due to mouse and touch controls. (Tower of Hanoi and other things like that; The 7th Guest comes to mind.) Because choice-based is typically browser-based, images are second nature to work with in choice games.

Puzzles don’t need to look like art either; diagrams are just as effective when it comes to presenting a puzzle and conveying the state of the puzzle. Use PowerPoint to make your graphics, if you want.

When you mentioned that player’s hate mazes in parser games, I believe it translates to players don’t like things that are visually complex in a medium than restricts all visual aids. For example, if you coded a working game of checkers in a parser engine, would you want to play it with text descriptions only? That’s pretty hardcore and asking for a lot of mental energy. So we dumb things down a bit to tic-tac-toe and it’s still challenging to visualize, but not maddening. Parser games need to keep the mazes dumbed down, is all.

Anyway, just my two cents.


Puzzles in a choice-based game? Sounds like a terrible idea! I mean, you just click the choice and puzzle solved right?


Yours came in 7th place, Ben @radiosity . Somebody must like these things. :grinning:


Are you serious or is this sarcasm?
OK context… you made some… Sarcasm is hard to read sometimes on the internet…

There are quite a handful of Twines that are Puzzle based… I’ve made some. Plasmorphosis is another game I can think of.


There’s no accounting for taste right?

And sorry @manonamora yes, I was being gently sarcastic :slight_smile:

I do think it’s a really interesting topic though - and some good thoughts above. I just reject the idea that puzzles are an ill-fit with choice games. There are always different approaches, and the parser approach is just one of them.


There’s no accounting for taste right?

You should try the 13th place game. Absolutely brilliant.


I hope Ben won’t mind if I share publicly some feedback I gave to him while I was beta testing Lunium, a puzzle that was a bit more difficult for me because I’m an American, but which I loved all the more for it. I’ll spoiler blur.

The puzzle was calendar based, requiring the player to enter a date to open a lock, a date which had alreardy required the synthesis of several different pieces of information to discover. I knew I had the correct date, but it wasn’t opening the lock. After thinking about it a bit, I remembered that Americans use month/day format, while Europeans use day/month format. When I switched the numbers, the lock opened.


Not at all, and you gave some great feedback (including a full transcript which was fantastic) - it was you who suggested adding a little extra feedback on the puzzles when the player gets close (right numbers, wrong way around). The funny bit about that bit of the puzzle is that specific part was accidental, I never originally considered it might be played by an international / non UK audience! But um, let’s pretend it was deliberate.

Something I found doing mine (and likely shared with parser games) was the importance of distance - ie. you could make a puzzle easier or harder by moving a clue and its solution further away from each other (in space/play time) or closer together, that became quite an important tool in my game.

One really interesting point raised by both @DeusIrae and @HAL9000 's ideas is where does a text-based game turn into a more traditional video game? I think mine already sails close to the edge of text based IF with its use of images. Do choice based puzzles have to involve greater use of images and interactivity? If so, does the choice of IF ‘engine’ impact / limit this?


As someone whose choice-based puzzler erstwhile won 5th place amongst a bunch of other choice based, high placing puzzlers in ifcomp 2018 (ex: grimnoir - 4th place), gonna have to disagree with you here chief.

your suggestions are ok-ish but they’re thinking inside a box, the box of “how to make choice-based IF more like parser IF?”:

and “failing” that, bringing in graphical/mouse elements for basic stock puzzles like towers of hanoi and sliding puzzles for children.

No you can’t. I don’t know if you’ve heard of the concept of “narrative puzzles” but my narrascope talk, Thematic Puzzle Design, defines them as, essentially, “puzzles which require narrative context to understand how to solve the puzzle”. You’ll see several other game design resources (which I pulled from) which define them similarly. If you don’t pay attention to the narrative, the puzzle does turn into combinatorial explosion brute force, but you are not actually supposed to do that.

Go ahead and try this with Erstwhile and tell me how it goes.

The truth is that choice-based games require different tools, different structures, and different ways of thinking about puzzles than parsers (I’ll elaborate on these in a different post in this thread when I’m on my computer). If you want to make a choice-based game that’s just like a parser, just make a parser. Or play more choice-based puzzles, if you want to contribute to the conversation more productively. Or don’t.


As @pieartsy says, Erstwhile is a great example. For a choice-based game with inventory puzzles, try 16 Ways to Kill a Vampire at McDonalds and try to find all of the 16 ways. It’s challenging!


Gonna bass boost this, you are 100% correct in my experience. I actually made a 15 minute presentation on this that I haven’t shown anywhere (because I don’t know where to show it :sweat_smile:)

The presentation posits that to make a puzzle, you start with two things with a strong connection. Ex: This person was murdered by that person; this key opens this lock.

Then you abstract the connections, turning them into clues that hint at connection rather than explicitly show it. The more abstracted the clues, and the longer the “chain” between them is, the more difficult the puzzle is. The more clues there are pointing to the same thing, the easier it is. Using the key and lock example:

The lock is blue and you find a blue sticky note. The sticky note has a drawing with a heart on it. The key has a heart on the end of it. Lock → same color as → sticky note → same shape as → key

Then you get to the concept of distance or what I call “scattering”, which you describe. There are three ways I found to scatter things, physical distance, distance in time, and events-as-distance.

  • Physical distance: The key, sticky note, and lock are found in separate rooms.
  • Distance in time: The key is found an hour after you find the sticky note, and the lock an hour after that.
  • Events: After you are handed the key, a person appears and talks to you for a minute-long cutscene. This is an interesting one, as it doesn’t take that much playtime but it does take up space in the player’s mind.

Reinforcing connections through repeating motifs (like the colors and shapes in my example) tempers difficulty after that.

You can see the full slides here actually:


Open Sorcery, a puzzle game by the same author is the top rated Twine game on the IFDB!


I know. It’s just like books! You don’t even need to read the words on the page, it’s still going to be flippable when you reach the right bottom corner with your eyes. Really distracts from critical thinking. :wink:


For whatever it’s worth, I think I get what Hal was getting at. I really enjoy Choice works, and while many provide just as much possibility as any parser game, but many also emphatically do not. Bad choice games can alter someone’s perception of choice games in general just as much as badly implemented parser games can do the same to parsers. Someone’s perception of either group is going to hang heavily on the group of titles they have played.


The idea that choice based games should provide just as much possibility as a parser game is the thing I take issue with. I know that’s not entirely what you were saying Pinkz, but I don’t like that mentality in general.


That’s your prerogative, Aster. It’s also your assumption that I believe they should emulate parser games. If you reread where you quoted me, it is a statement of fact, not value. The following sentence stands alone and isn’t dependent on the preceeding sentence. I probably could have constructed that better.


To actually answer the great questions Doug raised:

  1. A lot of different puzzles work, from the inventory/world puzzles in 16WTKAVAM, the combinatorial puzzles in Erstwhile, to the escape room puzzles in Lunuim, and so forth. In my experience, narrative puzzles (as I defined) work best, where the narrative context really really matters. Games that are centered purely on mechanics are less satisfying in choice games-- I will give the point to Hal that “hit the nail with the hammer” puzzles are not satisfying at all in choice games when the only option provided is “hit nail”. As well, puzzles that take advantage of the fact that there is a limited set of options but many different combinations of those options are available tend to be the strongest.

  2. No world modelling is really required, at least not in the same way as parsers think of “world modeling”. I would argue that a cohesive narrative and strong worldbuilding makes a great choice based puzzler. But trying to have a world model where you can do anything with anything because the language itself can parse any set of actions (in theory) is fighting against the point of choice games.

  3. None in particular, I think. My preference in an accessibility sense is that choices you make that actually affect the world should be clearly delineated (either UI wise or explicitly stated) in comparison to “flavor” choices, but that’s by no means a universally agreed upon preference. Erstwhile is 100% text with some color changing decoration, but doesn’t actually need styling at all. Open Sorcery relies more on styling and effects to convey meaning, such as in its riddle puzzles and the colors of elements. Lunium clearly needs images to work at all.

  4. What doesn’t work, again, is trying to treat a choice-based game like a parser. Just make a parser if you want to do that.


To clarify, when I say I don’t like that mentality in general, I mean that I’ve seen this mentality from people, who are not you, repeatedly. And I don’t like it.


Fair enough. :+1: