By “adventure game”, I really mean any story-based game.
This is post is mainly just a dump of useful links regarding puzzle design, so I can have them all in one place. There won’t be anything terribly elucidating here, just links to useful articles.
- Application of Puzzle Theory – Classifications of all the different types of puzzles in narrative-driven games.
- Adventure Game Design Patterns – Another breakdown of different puzzle types, using some examples from Monkey Island
- Adventure game puzzles: unlocking the secrets of puzzle design
- Puzzle dependency charts, by Ron Gilbert.
- Puzzle dependency graph primer, Joshua Weinberg
- Puzzle dependency charts, tentacles and you – Joshua Weinberg’s GDC 2016 slides
- The Arcane Art of Puzzle Dependency Diagrams – from the GDC Vault
- Someone’s Gamasutra post related to puzzle dependency charts
- Puzzle Tree – from three hundred mechanics
- Ocarina of Time puzzle structure
- Designing the puzzle – from GDC ’97
- Why Adventure Games Suck, Ron Gilbert
- Making Better Puzzles in adventure games
- Another Gamasutra post about puzzle design, not specific to adventure games
- Thesis about Puzzle Design in Adventure Games – I actually haven’t looked over this one yet
I think there are some more, but I’ve lost them.
Right now I’m trying to apply this kind of puzzle theory more rigorously to Cascade Quest. Many puzzles in their current form in the game are woefully unsatisfactory, as has been demonstrated by some playtesting.
Right now I’m trying to polish up the puzzles in the first zone of the game. One thing I’m struggling with is trying to make the puzzle tree more “bushy”. What that boils down to (if you read some of the articles listed above), is trying to give the player several things to do at any particular time. A strictly linear puzzle progression can lead to player frustration if they can’t solve the current puzzle they’re working on, and have nothing else to do.
I’ve managed to make many of the puzzles have multiple independent conditions that need to be met. However, I’m running into problems informing the player of the necessary conditions. Usually there is one obvious thing the player needs to do to solve a puzzle. When they accomplish that, they may only then find that they need something additional. The end result is that the player will probably still progress linearly through the game (and possibly get blocked).
This is more of a narrative problem, I suppose. The puzzle dependency graph may be “bushy”, but the in-game narrative still drives the player through a linear discovery. I haven’t seen much discussion of this in any of the articles I linked, but it’s become a problem with nearly every puzzle to which I’ve added multiple pre-conditions.
One good example of this kind of being glossed over are the GDC slides I linked above. One example they give for “bushifying” the puzzle tree involves opening a chest. You need a key to do so. To add an additional pre-condition, we can say that the chest has rusty hinges, and so you also need a can of oil. The player now has two things to do to occupy their time.
However, how do you deliver that narrative? The player won’t realize the chest has rusty stuck hinges unless they already have the key and have tried to open the chest. So this attempt at parallelizing the puzzle tree risks becoming simply a longer linear chain in the tree.
So these are the kinds of things I’m thinking about right now.