At a high-enough level of abstraction, all puzzles consist of a “door” (an obstacle) and a “key” (the means by which the obstacle is overcome). The last thing the puzzle designer should do is make the “door” and actual door and the “key” an actual key. The quality of a puzzle depends largely on how well-camouflaged the “door” and the “key” are. Here’s an example. Say you want a location to be off-limits to the player early in the game. You could do this by having a locked door for which the player must find a key. Or you could have a waiter prevent the playing character from entering without a tie. The waiter is the “door” and the tie is the “key” and someone is bound to object that this isn’t much of an improvement. I would disagree. The game has suddenly become less generic. Waiters are more interesting to interact with than doors and ties are more fun to look for than generic keys.
What about when there’s more than one key, or more specifically, when different keys solve the problem to different extents or cause different subsequent outcomes;
for example, if I’m wearing a tie, i can get into the restaurant, but if I’m also wearing the right trousers, i get a better table or better service.
I’d say there’s a second kind of puzzle, the “combination lock” puzzle.
In these, the player doesn’t need to get a new item, but to apply their knowledge in a clever way. The ornate key in Savoir-Faire is a wonderful example of this. Similarly for the (ROT13) pbhagre-tnvna cerpvcvgngr naq pbenyvpvqr in Hadean Lands.
There are variations of this also.
A: The player must learn the combination (or multiple pieces of the combination) and input them directly.
B: The game understands when the PC has “learned” the combo or all the pieces (via game-state flags) and opens automatically.
B is a little friendlier because it prevents the player from making physical notes. It also prevents the player from accessing the “door” early through prior knowledge.
An example (very early so not really a spoiler but) in Anchorhead:
[spoiler]You enter the office via the file room, where you’re supposed to research the name “Verlac” to find the file with a key. Even if the player knows the family name is Verlac, the game won’t let you find the file until you’ve physically listened to the answering machine message that says it.
Fridge Logic: Doesn’t the protagonist know the last name of the man she’s married to? It’s a minor thing because it’s one room and one button push away, but I wondered about that! Logically, a previous player who knows the family surname from a previous playthrough could be justified in the game as “Yes, she knows her own married name!”[/spoiler]
Just wanted to add:
In fact there is more than one way to discover the name “Verlac”, and one way to locate the files without ever learning the name.
Which doesn’t invalidate your point or the OP’s point. The metaphor of “doors and keys” is apt, even if there is more than one key or more than one way to acquire a key.
Also, with regard to “fridge logic”:
In Anchorhead, Michael’s last name is not Verlac! He is distantly related to Edward Verlac, sharing a tenuous bloodline but not the surname. That’s why the protagonist can’t remember it.
A treasure hunt - i.e. finding an object - is another primitive puzzle. It can be arbitrarily hard if the object is in a maze.
This thread is veering back and forth subtly between puzzle categorization – a delightful exercise which has no end – and thinking about the high-level use of puzzle structure in games.
Both are cool topics; just keep an eye on which you mean to do.
I’d call that a key though—in your Anchorhead example, the key is the piece of information the player character doesn’t know.
In the Savoir-Faire and Hadean Lands examples, the player character has everything they need to complete those puzzles, usually well before they run into them. It’s just whether or not the player figures out the actions to perform that will unlock the door.
Is his surname ever mentioned before looking up “Verlac”? Maybe that’s why I was confused.
Right - but I mean that a game can require the player to enter the combination literally, or may know that the PC “knows” this info and let them through. This is part of puzzle design, and one of the things Lucasarts Adventures did really well - giving the player the benefit of the doubt that they know what to do without actually needing to do it. Remember the Monkey Island puzzle which involved using two oars stuck into holes in a tree to climb it? It would have taken forever if they made you do the whole thing, but Guybrush at some point goes “Oh, I get it!” and “opens the door”.
I did it two ways with the vault door in Transparent. There is a combination, but once the player examined the combination, they didn’t need to remember the actual numbers; OPEN VAULT would dial it in for them automatically. In an update, someone explained it made more sense and was much more natural to actually let the player input the combination.
The reason I did it the first way initially is figuring out how to implement a “right left right” combination dial was the least of my worries in the crunch before the deadline when I could just Guybrush the player through it!
(Sorry if this is a sideline to the topic. I’m back in the line, Zarf. Back in the line. )
I’m not looking for a typology. As I already stated, all puzzles are fundamentally of the same type. I’m picturing it more like this. Imagine a bunch of “doors” and “keys” having a masquerade ball. Some come in couples, others in groups: a “door” with two or more “keys”, or a “key” with two or more “doors”. The interesting question is what costumes are they wearing? We already have a “door” pretending to be a waiter and a “key” pretending to be a tie. I’m looking for real life situations, real life costumes. I’m not looking for “doors” dressed as trolls and “keys” dressed as riddles.
Marie, I think this is really interesting. I recently read someone who said that parser games are like magicians, using the same tricks just with different patter. I was playing Spellbreaker last week and I noticed that a ton of their puzzles were blatantly lock-and-key (find a spell to pass obstacle A to get a cube to open up obstacles B and C). Like the giant snake filling the hallway, or the copyright protection question (which functions as a real life lock and key, too), or the lava fragment, or even the infamous outcrppping.
But I couldn’t help but love the game as I played it; it’s tied for my number one favorite game, because the ‘patter’ and the dressing up were so good. Casting powerful spells is fun.
So I think you have a good point, and I’m glad that you pointed it out. (I know you said real-life situations, but it made me think of Spellbreaker anyway. For real-life situations i think of Gourmet)
Although this is not specifically IF - The original Secret of Monkey Island has the “Three Trials” puzzle.
In order to become a pirate, Guybrush is ordered to complete three tasks by a row of pirates at a table (the door) to access the wider world in the game. This functions as a limited hub, and each of the quest “keys” are rather extended puzzles that can be tackled in any order, and I believe they all somewhat inform each other. By the time the player has solved all three trials, they are very familiar with the game and puzzle style and are ready to continue the adventure outside the starting area on Melee’ Island™.
Puzzles need not be isolated, and may not be limited to a “door” and a “key”. There may even be multiple (conjunctive or disjunctive), or the “key” for one may be a “door” for another, or you may have a “anti-door” or “anti-key” sometimes, or some method of solving one puzzle may result in another being impossible to do, etc.
Do not isolate all puzzles individiually; there is no individual, just the entire game. (I suppose that is how you make up “holistic puzzlement”?)
That’s a structural/logical approach to puzzle design. It’s interesting in its own right, but it’s not what I’m focusing on. My approach is semantic/aesthetic. The two approaches are not mutually exclusive. In fact, they complement each other. The structural/logical approach looks at the chain of puzzles, while the semantic/aesthetic approach looks at the individual links. It looks at the “doors” and “keys” masquerading as other things and asks, why are some costumes better than others?
Say you’re playing a game where you have to find seven keys to unlock seven doors with a matching colour scheme. Here the author hasn’t even bothered to provide costumes for his “doors” and “keys”. To avoid disambiguation issues, he has had to resort to an artificial colour scheme. Compare this to the waiter and tie puzzle. You immediately recognise the waiter as a “door” and the tie as a “key”, and yet the puzzle seems more attractive, which brings us back to the question of why some costumes are better than others.
If you zoom out far enough, the game becomes the “door” and player the “key”. But what I’m focusing on is not the chain, but the individual links. I’m looking at the puzzle morpheme, the smallest unit of puzzley meaning.
The reason, I think, why it’s so hard to come up with real-life puzzles is because in real life when a door is locked and you don’t have the key, it’s because you’re not supposed to.
I think you’re getting at the chain (tree) of goal prerequisites which make up the game structure. You need object X to reach object Y, and object Y to reach object Z, so X is a “key” which unlocks the “door” that leads to Y. And so on.
This is a useful abstraction. When I’m designing a game, I sometimes jot a note “need something in room R to reach room S, fill in details later.”
However, it’s not always a perfect abstraction. If you describe a game in this way, you are leaving out details which are not mere window dressing.
Consider this: a combination lock with a (fixed) combination which is written down elsewhere in the game. That’s a key/door situation, but the “key” is pure information. The player could find it in a walkthrough, or guess it by brute force, and skip a large chunk of the game. (Famously, the fireplace code in Myst.) We have various strategies to avoid this problem – if you think it’s a problem. But to understand the situation at all, you have to dig into the abstraction and consider the details of how the “key” unlocks the “door”.
I disagree with this. From the player’s point of view, the key/door model describes their goal in solving the puzzle, not the puzzle itself! “Getting through the iron gate” is a goal; “finding the iron key” or “finding someone to teach you lockpicking” or “figuring out that the rezrov spell works on the door” is a puzzle. They are rather different puzzles.
The quality of the puzzle is (of course) subjective and has many subtleties. You can abstract them away, but then you’re not addressing puzzle quality any more.