How to plan out parser puzzles

[pieartsy (Aster F)]

This recent thread about choice-based puzzle design has me feeling I’m very qualified to talk about designing choice-based (or at least Twine-based) puzzles and very ignorant about designing parser-based puzzles.

When I make plans for Twine puzzles, they tend to look like this (a game concept that I never finished):

The limited choices are something I know how to use, I’m familiar with how to map them out and wrap my head around them.

With parsers though, I’m very much ??? about it, which is daunting when I really want to make some parser puzzle games! How can I possibly make a map of the possible options and where they lead when there’s like dozens of verbs you could perform on dozens of objects at any given time?! (I’m not planning on a limited-verb game either!)

@Doug_Egan

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)

They don’t?!

Really, I don’t know resources or best practices or principles of design or how to even start. Throw advice, articles, whatever at me! Bear in mind I know the principles of puzzles in general, I just don’t know how to design parser puzzles.

[inventor200 (Joey (Jess) Tanden)]

I am terrible at thinking of puzzles, so I’m getting my notebook ready.

[SomeOne2 (Max Fog)]

Same! Especially in my new game where I can’t use movement even though there are multiple interconnected rooms, no inventory or ACTUALLY takeable objects (it’s complicated to explain, not to understand), and no use of the dark/light source or physical possibilities to think of.

[severedhand]

I do it pretty instinctively, but I started when I was about eight or nine

I guess because a Twine puzzle can be exhaustively catalogued in nodes, you may feel you need to do this for a parser game, all in advance. But my experience is that you don’t have to.

I find the map and puzzles guide each other in design, so I can think about both at once by the process of doodling the map and noting where obstacles are and where solutions might be.

The puzzles are Important, so their elements will get priority treatment. As an example, if you put in a log, and a saw for sawing it, you don’t need to immediately think about the saw and everything else that could be in the game. If the saw and log are important to you, put them in, then you can build around the saw later.

You may be able to close off most alternative combinations in a single stroke with a ‘I don’t need to saw that!’-type message. And when cases come up where there is a really legitimate alternate player use for the saw, the kind where the player would say, ‘Oh come on, I should be able to saw THIS,’ you can then program it in when you discover it.

You want to design to avoid conflicts with other major puzzle elements (there shouldn’t be a puzzle meant to be solved in a unique way, that could actually be solved with the saw, too) but not with just any old props in the game.

You won’t know about the ‘Oh come on, I should be able to saw THIS’ cases until the game gets a bit populated and you play in it yourself, and others test it.

My idea is that if writing a novel is about finding out what the characters want to do, writing parser puzzles can be about finding out what the players and props want to do, and can do, as well. And you don’t have to plan all that in advance. You’ll find it out by adding, playing, testing, and by other people testing. You can’t anticipate all the combinations.

I attach below my latest puzzle doodle from the other day. The words will be appear to be scratchy nonsense, but the outcome of this thing was I sorted out a whole six rooms worth of (not-too-difficult) puzzles.

Summary

-Wade

[Piergiorgio_d_errico]

In plotting puzzles generally I describe the scheme of the puzzle in a comment box above the related coding.

Useful especially for people whose don’t plan to release the source, because remain an important reference.

Currently my WIP’s main puzzle has ~10 lines of comments for every line of actual code.

Creative Cooking’s source is somewhat of an exception, because has intentionally a didactic nature, teaching not few details, tips and even tricks with Magx.

Best regards from Italy,
dott. Piergiorgio.

[kamineko (Drew Cook)]

It’s a very grounded process for me. I think about the protagonist and their story. What problems might arise? How might the character overcome them?

Then I crosscheck with “what are some cool or interesting things a player might enjoy doing in this space?”

So, in Repeat the Ending. I devised a magic system based on these ideas, and the problems–I wouldn’t necessarily call them puzzles–were built around that. I thought about what the player might enjoy doing or seeing with the protagonist, and everything flowed from there.

They weren’t very hard–I was very generous with cluing–but they would have been fine as more difficult problems. That just wasn’t what I was after. To me, it all has to fit together and make sense as a unified thing.

[mathbrush (Brian Rushton)]

I thought about this a lot when making my WIP Never Gives Up Her Dead. It has 10 main areas and I wanted each of them to be different. So here are some ways to brainstorm puzzles, each themed around one of my areas.

1. You can use ‘traditional’ parser puzzles

I made a haunted house using tradition parser puzzles. These are puzzles that use standard verbs like TAKE, DROP, UNLOCK, GIVE, etc. This basic style of gameplay means that you find something in one area, identify where it belongs, and carry it there, using some obvious verb.

Classic examples include finding a key somewhere and bringing it back, or finding a weapon you use to kill an enemy. Many people that get into parser games do so because they find this sort of ‘medium-sized dry goods’ gameplay enjoyable the same way a wordsearch or crossword is fun.

So in this case, I just created many obstacles, and then created solutions to those obstacles, drawing a map first. That’s one way to brainstorm.

2. You can theme puzzles around mechanics

My second area, I wanted to have a murder mystery with two mechanics: first, you gather clues and link them to get new clues. Second, you can ‘flash back’ into someone else’s experience, changing the writing and tense.

So to brainstorm these puzzles, I had to think, ‘what kind of interesting situations would arise with these mechanics? What kind of clues could be connected, and how will players know?’

3. You can use puzzles from the real world.

My third area is a wax museum escape room. So, what I mostly did here was research what kind of puzzles actual escape rooms use, and think about how to adapt those to IF.

While not from ‘real life’, puzzles from TTRPGs or video games can also be adapted.

4. You can brainstorm puzzles based on an overarching set of themes.

My 4th area was a horror area inspired by the Magnus Archives, which classifies fears into 13 or so categories. I wanted to create one puzzle that would be related to each fear; so, for instance, to evoke the fear of claustrophobia, I had a puzzle navigating a tight crack; to evoke fear of fire, I had a puzzle where you had to set yourself on fire.

Giving yourself thematic constraints like this can make brainstorming easier. For instance, having puzzles based on the stages of depression, or Chinese zodiac, or the four humors.

5. You can base puzzles on interactions with NPCs.

My fifth area was a robot lasertag arena. The whole idea is that you have to command two robots in battle against a bunch of other robots. This involves communicating with your allies, learning about the enemies and their strengths and weaknesses.

Basing puzzles around interactions with NPCs is often easier since our daily lives contain frequent interactions with other humans that amount to a puzzle (TAKE RECEIPT, GRAB PIZZA, EXPLAIN TO COP WHY YOU’RE SPEEDING, etc.). On the other hand, because we interact with people so much, a game with an NPC that’s not implemented well can really stink.

6. You can do ‘tasks’ instead of puzzles.

Complicated tasks that are not puzzles at all in real life can become satisfying puzzles in a game.

I made a cabin in the woods where all you do is restore it. You have to make paint, cut wood to repair stairs, etc. Technically none of it is really a puzzle, but trying to figure out how the author wanted you to do it and then doing it can be a puzzle. I had to include instructions.

Examples of this in other games include microwaving cold food in The Lurking Horror and rowing the boat in The King of Shreds and Patches, or, famously, in Anchorhead, closing the front door.

7. You can have movement-based puzzles

Arthur DiBianca does this a lot. Into the Facility is nothing but movement puzzles.

I made a zoo area with a bunch of different animals. The solution to (almost) every puzzle was to get an animal to walk to another area and interact with the others.

With this type of brainstorming, you can just think of a dense area (a city, a zoo, sewers), put a bunch of stuff in it, and imagine what traversing the area would be like.

8. You can base puzzles on the capabilities of the system you’re using.

When reading the Inform 7 manuals this 7, I discovered that they included the ability to calculate the inverse hyperbolic tangent. I decided to make a puzzle centered on using that number in the game (by providing an in-game calculator).

I made an area full of floating monuments and based other puzzles in this area on Inform examples and capabilities, including having fire spread in a natural way, modelling hot and cold, performing numerical calculations to model the spread of a gas, modeling currency and a cash and change system, etc.

Edit: If I were to do a TADS game, I’d probably try out some of its sensory capabilities (smell, sound, etc.) because from what I’ve seen they’re really well developed.

9. You can use limited parsers or single-room settings

Both of these options can make a parser puzzle more similar to a twine puzzle. So you can borrow a lot of ideas from twine for this.

I made an area with a tool that you can upgrade and various puzzles that were essentially like quizzes. But I found it incredibly difficult, as limited commands and limited map ruled out most of the puzzles I was familiar with.

10. You can eschew puzzles all together and just provide an ‘experience’.

This is like Charm Cochran’s recent Gestures Towards Divinity. There is no puzzle, or even a linear flow; there’s just an exhibit you explore.

Galatea is kind of like that too. In fact, there’s a long tradition of puzzleless exploration, including The Fire Tower by Jacqueline Ashwell, current IFComp leader.

Anyway, thanks for indulging me, I’ve been thinking about this a lot over the last year and a half! I probably should have brainstormed more; for instance, I have 54 buttons in my game, just because they provide easy puzzles.

Edit: Also, mazes do suck. They’re the ‘timed text’ of the parser world. Can you make timed text work? Yes, if used in moderation, and if it fits the game. Same thing with mazes; they can work, but only if used in moderation, and only if it makes sense with the rest of gameplay.

[pinkunz]

Parser design is revealed in its terminology. Every space, inside or out, is still a room. Rooms are filled with all sorts of things, objects, containers, supporters, scenery, NPCs, vehicles, etc. Stuff. Every NPC could become the player with a single line of code, switching perspectives at the whim of the author. You don’t necessarily start with a game, you design a space, a tangible location. Your game lives in this space.

Think about, say, Doom. When a modder makes a new game, they have to design the levels. Rooms, doors, stairs, windows, objects, elevators. None of this IS the game, but it all informs the player, through subtext and genre expectations (which may be intentionally subverted by the author), what they should expect with this level. All before a single enemy is ever added.

Parsers are often the same way. If you build a game premise and then just plop it into any old premade space, without any thought on how the two interact, that’s a recipe for annoyed players.

There’s a constant awareness of the tangible physicality of the world, often just mentioned offhand as the world-model, that is rarely embraced in Choice games. Not never, but rarely. Ask yourself, how often do you find yourself mapping a Choice game? Again, not never, but rarely.

That’s one side of it. The other is anticipation.

The parser often offers too much freedom. You not only have to figure out reasonable responses to the things that shouldn’t work, but your players will invariably try something that, logically, should have worked but wasn’t the solution you had in mind. You then have to either concoct a reason this wouldn’t have worked or allow and implement it as an alternate solution. People will try things that you could never anticipate, and while we joke about the player licking things, the truth is often times an author finds themselves privately admitting their players and testers may have been more clever than they were.

So, a good parser game not only clues the “right” path, if there is such a thing, but also anticipates every other reasonable thing the player may try and offers some sort of acknowledgement of the player’s wit, even if it’s simply a custom failure message showing the author saw it coming.

Building a parser game is almost like playing chess with someone, but your opponent is in the future.

[Warrigal (Garry Francis)]

The thing you are looking for is called a puzzle dependency chart. It is not unlike your Twine example, except that it tends to be object/action-based, rather than room or node based and it will be a closed network, rather than a tree.

You have probably heard the term “happy path”, normally used in the context of happy path testing. This is where you test everything when the user does the right thing and does not make any mistakes. Your puzzle dependency chart shows the happy path for solving your puzzles. It does not show all the extra, non-essential things that you can do along the way.

Your chart shows the dependency between puzzles (you must do A before you can do B), but also shows which things can be done in parallel or in a different order. For example, you need to find a key to unlock a door, so there is a dependency between the key and the door. You also need to find a sword hidden under your bed, so there is a dependency between the sword and the bed. However, you can do these two things in any order, so they will be shown in parallel on your puzzle dependency chart. Later on, you will need the sword to kill the dragon, so there is a dependency between the sword and the dragon, but this is beyond the locked door, so this dependency comes later, after finding the sword and unlocking the door.

Personally, I don’t use puzzle dependency charts except when trying to find the minimum move solution for a game. Use whatever feels comfortable, including lists, truth tables, sketches, mini-maps, partial walkthroughs and notes.

[pieartsy (Aster F)]

@Warrigal

The thing you are looking for is called a puzzle dependency chart.

!!! you were right!!! this is what I was looking for!!! (tho keep the advice coming yall!)

[Warrigal (Garry Francis)]

The link I gave above was to Ron Gilbert’s Grumpy Gamer blog. He was one of the designer’s of the much-loved Monkey Island. He is very opinionated about the design of games (in general) and adventures (in particular). It’s worth browsing some of his other articles, as well. He has an example of an early puzzle dependency chart for Return to Monkey Island.

If you are looking for a tool to create puzzle dependency charts, you might like to consider Puzzlon by Adventuron author, Chris Ainsley. I couldn’t find any documentation, but he has a YouTube tutorial. It’s pretty easy to use. Just press Ctrl+Space for a context-sensitive hint at any point in your code. Use double-click or the mouse wheel to zoom in and Shift+double-click or mouse wheel to zoom out.

[jnelson (Jim Nelson)]

Speaking of Ron Gilbert, his “Rules of Thumb” offer a number of commonsense, but not always obvious, points on how to build an adventure game. (In particular, I like his point about “backwards puzzles.”)

Since the question is about parser games, I’ll simply add this: Much of the joy in them comes from the sense (or illusion) of freedom to explore the environment. For me, this means not gating too much, especially in the midsection of the game. If a puzzle is confounding a player, they should be free to go off and work on another one. And, it’s perfectly acceptable for the solution (or part of a solution) to be located elsewhere on the map.

[rovarsson]

When writing your very first parser puzzle game, it is mandatory to put a bronze key in the bird’s nest up in the birch tree on the opposite side of the map (at least 12 rooms separation) from the red door with the bronze padlock.

No exceptions.

[JTN]

Here’s an example puzzle chart for Counterfeit Monkey – use this direct link to the image for a legible version. (Spoilers, obviously.) The context was originally this article on that work’s puzzle mechanics and design.
(See IFWiki for more author commentary on CM.)

[J_J_Guest]

My parser puzzles all tend to be of the medium-sized-dry-goods variety. I don’t go in for code-breaking, acrostics or pure logic puzzles, partly because my first introduction to parser games was the Scott Adams Adventure series, partly because I can never think of any, and partly because I find those sorts of puzzles harder to integrate seamlessly into the story. And for me that’s the most important aspect of parser puzzle design, that your player is not just solving puzzles for the sake of it, but that the puzzles should serve the story, and have implications not just for the player character but for the other characters in the story too.

A couple of years ago I wrote a post about how I see puzzles relating to story, which I illustrated with an example from P. G. Wodehouse:

Help with writing puzzles

The way I think of the relationship of puzzles to story is best illustrated by an example from Wodehouse. Spoilers for Jeeves and the Yule-tide Spirit follow: The parser game is very good at modelling physical objects, and very bad at modelling things like love and deceit and persuasion, but it’s easy enough to tie one to the other.

Here are some very spoilery examples of how I apply this principle to my own games:

Alias 'The Magpie'

In this game the titular character is out to steal a valuable jewelled scarab from a country house, but in doing so he saves Lord and Lady Hamcester’s marriage, helps Major Hilary Buff-Orpington recover from the tragic death of his best friend / lover, allows Sir Humphry Leghorn to finally beat Lord Hamcester in the annual cucumber growing competition, and permits beleaguered butler Hives to finally take his well-earned retirement.

In a sense this is a reversal of the Wodehouse example, in that the Magpie is motivated purely by wanting to acquire a particular object, but in doing so he completely incidentally makes everyone else’s life better. It’s collateral beneficence, if you like, but it’s also the real reward for the player.

To Hell in a Hamper / To Sea in a Sieve

Both of these games involve throwing out all manner of medium-sized-dry-goods, belonging to your travelling companion, from a sinking vehicle, but the ultimate goal of each is to save yourself (and your companion) from death. In both games (but in To Sea in a Sieve especially) you do so at the cost of your friendship.

And this is why I’m making it a trilogy.

Yak Shaving for Kicks and Giggles!

In this game your objective is no less than to learn the meaning of life, but to do so you have to shave a yak, knit a pair of socks for a yeti and melt a glacier with a hairdryer (among other things). It’s intended as a parody of to-do-this-you-must-first-do-this adventure game puzzles.

Ultimately it turns out that doing these sorts of humdrum(!) everyday tasks is what life is all about, as long as you get some kicks and have some giggles along the way.

“Before enlightenment; chop wood, carry water. After enlightenment; chop wood, carry water.” — Zen Kōan (note the verb / noun construction of “chop wood” and “carry water”!)

Apologies for wittering on about my own games, but I can only really speak about how I see things. And because I work very intuitively I often don’t know how I see things until somebody poses a question and I have to think about it.

[pieartsy (Aster F)]

@J_J_Guest

Apologies for wittering on about my own games, but I can only really speak about how I see things.

have you seen how much I mention my game erstwhile in this forum?? 90% of the mentions are from me. You’re good

[J_J_Guest]

@pieartsy

have you seen how much I mention my game erstwhile in this forum??

It’s a great game!

[Draconis (Daniel Stelzer)]

My puzzle design process tends to revolve around “what if the player character had this particular capability; what would they be able to do with it? what problems would they be able to solve with it?”

For Scroll Thief, that’s all the spells. For Enigma of the Old Manor House, it’s opening and closing doors, something a ghost can’t do. For Stormrider, it’s the ability to hide in specific locations, and manipulate NPCs’ movement. And for Labyrinthine Library, it’s rearranging the map.

For example, the layout of the cargo hold in Stormrider came from a process something like:

• The player can only hide in specific locations, sometimes with a puzzle to make the hiding possible.
• What if there are multiple viable hiding places, but only one of them works with how the NPCs are moving? Then the puzzle becomes, understanding the obstacles well enough to choose the right place.
• I’ve already done a puzzle where an NPC patrols a corridor and you have to get past them. What if this time, going down the corridor is no problem, but getting back, they’ll stop you?
• The NPC can’t just go back and forth, then, or else you could get behind them. If they go in a circle, though, they can be a problem in one direction (when they’re going against your direction) but not the other.
• This means there needs to be a connecting point in the circle that the NPC can use but you can’t. Maybe this could be part of another puzzle later.
• So now we have an NPC circling around, and you need to prepare a hiding place in advance, follow them in the same direction to get the illegal thing, go back in the opposite direction to get the illegal thing back to safety, and hide in the correct hiding place when the NPC goes past.
• The illegal thing also needs to stop being illegal once you get it to safety the first time, to keep this from being an exercise in tedium.
• Oh, shoot, I miscounted the moves and the NPC needs to take one extra turn to go around. I’ll add one extra action to the NPC’s cycle…hey, maybe that could be another puzzle.