IF Roundtable: The Art of the Puzzle

One subject that crops up perennially on the interactive-fiction newsgroups is puzzle design. Just how do I come up with these nefarious beasties? is a frequent cry. In the interests of furthering humankind's understanding of the lowly puzzle, we've gathered together three accomplished IF authors -- Adam Cadre, Lucian Smith, and Andrew "Zarf" Plotkin -- along with XYZZYnews contributing editor Neil deMause, in the IF MUD's Specious Loby [sic] to hammer out The Art of The Puzzle.

NEIL: How about we start by introducing ourselves for posterity?

ADAM: Greetings, posterity. I'm Adam Cadre. I wrote I-0, and, even more impressively, Lost Anaheim Hills. I'm currently at work on Pantheon, which I'm targeting for late '98.

LUCIAN: I'm Lucian Smith. I found IF again by randomly searching the net for "XYZZY" a couple years ago, and found XYZZYnews. I wrote some invisiclue-like hints for So Far, and just entered this year's competition with The Edifice.

ZARF: Hi. I'm Zarf. You may remember me from such transcripts as "Zarf eats the XYZZYnews awards alive" and "Zarf says 'Yo.'" I'm currently working on something but it's not done yet.

NEIL: And as for me, I'm Neil deMause, author of Lost New York (LNY). So the reason we're here is because there's been a fair amount of talk on the newsgroup about puzzle design. One, how to make the puzzles seem natural to the game play. And two, how to make puzzles that are both fair and challenging. Let's start with the first one.

ADAM: Well, to immediately start talking about myself, most of the puzzles in I-0 didn't have an independent genesis. I'd create a location -- either on paper or in code -- and then think, okay, what would logically be in such a location? From there, I'd make puzzles out of the materials at hand. I don't think I ever thought, "Hey, I've got a great puzzle idea!" and then struggled to figure out how to fit it in.

LUCIAN: For my game, the plot *was* the puzzle. For example, for the second level of the Edifice, I thought, "OK, in this scenario, the player will have to learn someone else's language." The rest of the details fell in around that. The sick boy was a way of creating a more personal motivation for the player to solve the puzzle.

ZARF: Even more so, for me. Since So Far is pretty much pure surrealism, I didn't *have* a plot in mind originally. I had a theme, and was co-inventing puzzles and scenes and events all at the same time. Plus, of course, part of the theme is that the player doesn't quite understand how it all fits together.

ADAM: I suppose that leaves LNY, which featured both intricate puzzles (goats and gumballs) and a strong sense of place. Which came first?

NEIL: Well, LNY is a weird hybrid. I started out with the assumption that IF games were based around puzzles, so I wrote a whole bunch of puzzles around a time travel theme. But what I was really interested in doing was telling a story about the history of New York and forces of change and "progress," I suppose. I mean, I'm looking to move more towards less puzzle-centric games myself. But then I look at people like Zarf, and they have no problem creating puzzle-centric games that don't seem contrived. What's your secret? You just smarter than everyone else? (And I include Lucian in that, too.)

ZARF: I never thought of I-0 as being *less* puzzle-based than So Far. I think maybe I do better at turning the normal plot-incidents of a story into "puzzles" -- that is, things that stand out in the player's attention. At one point, I posted "A puzzle is a mechanism for focusing the player's attention." Start with that. But they already were plot elements where the player has to act. Where the *protagonist* acts. I try to invest that into the player.

ADAM: Yeah, it does sound like we're talking about different types of animal here. An all-encompassing thought exercise like the language puzzle in The Edifice seems quite different from a lock-and-key eureka-type puzzle, like how to survive the scorpion in I-0.

ZARF: Oh, no, they're the same thing.

ADAM: Are they? Hmm.

NEIL: Yeah. Just levels of complexity, no?

ZARF: Levels of complexity, importance in the overall plot, importance in the overall thematic effect.

NEIL: Lemme focus for a sec on a slightly different issue: What *purpose* does a puzzle serve? For example: One of the things I like most about playing IF is the thrill of discovering new regions. I've sometimes compared it to the tricks that Frederick Law Olmsted used in park design: make an artificial bend in the path, or a tunnel to pass through, and then once you're past it -- bang! a seemingly endless vista! It's not endless, of course, but you can use trickery to make it look endless, at first.

The problem, then, is how to keep the player from rushing through the entire park at once. The solution: puzzles. You'll notice that virtually all the puzzles in LNY involve finding the next plaque to the next time period. Each one you solve gets you the payoff of a new vista to explore. But I guess I'm wondering if that's the only way to structure a work of IF...

ADAM: I'm not so sure you necessarily need lock-and-key-type obstacles for that, though. Here's an alternative model... Think of a map of North America. Say that to see all there is to see, the player needs to visit, say, the 40 largest cities on the map. The obstacle there may be no less than the fact that travelling from Houston to New York means you're traveling away from Los Angeles.

So converting that back to IF terms, we're dealing with plot branches.

ZARF: OK, I think you're wrapped up in a subset of possible IF stories -- those which are travel stories. If the player's motivation is to see over the next hill, the anticipation and struggle are getting to the top of the hill.

Most generally, the goal is the *next thing* -- that's next in the static fiction sense. In a book, pacing is controlled by both simple page count and the nature of the writing (intensity, complexity of action in a scene, etc.). I have much less control over that, but I can make the climactic scene come sooner or later by making the player do more or less to get there.

NEIL: But isn't that what we were just saying? Puzzles serve to slow the player down by making them do more, thus controlling the pacing? The only other alternative is daunting amounts of text to read, no?

ZARF nods.

ADAM: What types of motivations could a player have? There's the thrill of seeing new places and things. That of solving a problem...

ZARF: Rescue the princess, find a good book, eat lunch...

NEIL: Motivations for the player, or the PC?

LUCIAN: I think the two are intertwined. It can be very hard to separate them. For The Edifice, the overall motivation is simply human nature. And, in a story about the beginnings of man, this is not inappropriate. I make a very light reference to that in that the only way to get an "extremely content" rating from the game is to walk away from the Edifice at the beginning.

ADAM: On the other hand, I do think that PC motivation and player motivation can be separated. The player always chooses to subject herself to the frustrations a game inevitably provides, but the PC may well be happier just going home, or just playing volleyball.

NEIL: But, Adam, I could say the opposite: the PC only has the game goal to live for, whereas I may very well decide to go watch TV instead. Motivating the PC is worthless if you don't motivate the player, too.

LUCIAN: And I think one of the main purposes of a puzzle is to involve the player in the story more. I remember Gareth Rees talking about his Christminster. He said that the purpose of his 'darkness' puzzle was essentially to give the player something to do while Wilderspin told his story. This is along the right lines, I think, although for better integration, solving the puzzle should advance the plot on its own.

NEIL: Well, maybe I'm unusual, but I don't solve puzzles because I like solving puzzles. I solve puzzles to get the payoff, whatever that might be.

ADAM: I think we've wandered into the question of where the pleasures of a text lie. In IF, overcoming an obstacle should be rewarding, but also, the obstacles should themselves be somewhat pleasurable, or the player *will* go watch TV. Or just use the walkthrough without even trying the puzzle. Which I often do.

NEIL: I don't even bother to finish games that don't have a clear payoff. This can be either the threat of nuclear holocaust, or characters I care about -- either one will do. But otherwise, the first hard puzzle and I'm out of there. I don't even bother with a walkthrough. I only use walkthroughs for games I like that I get irrevocably stuck in.

ADAM: This may also be a factor in why so much IF has a comedic tone. If a game is funny even while I'm banging my head against the wall, I'll keep playing. If not, I'm probably gone.

ZARF: Well, I like discovering clever puzzles, so there's *some* motivation to finish a game with no clear payoff. On the other hand, I've never seen a game without a clear payoff -- except mine, and I had my own reasons. Any idiot can threaten nuclear holocaust.

LUCIAN: So, I think what we're saying is that there should be two parts to any given puzzle. To use my language puzzle as an example again, since I'm familiar with it, saying that the sick boy was "just a detail" was misleading, before. There's the puzzle itself, and its relation to the story.

ADAM: And yet the Edifice language puzzle is an oh-so-rare example of a case where I found myself addicted to the puzzle just because it was interesting.

NEIL: We seem to be meandering into the second part of the conversation: What's a good/fair puzzle? Maybe we could start with the opposite: What makes a *bad* puzzle?

ZARF: A bad puzzle requires you to be in telepathic communion with the author. We all know that rule. A bad puzzle is one where, when you figure out the answer -- or look it up -- you're annoyed instead of pleased. And a combination lock made of soup cans is a bad puzzle.

ADAM: And I can think of an example of the last of these -- have we all played 'A Good Breakfast'? This is an example of a game that's interesting, that has interesting puzzles -- but the puzzles themselves are really unmotivated. For instance, a combination lock made of rotating gnomes, just to get back in your house.

ZARF: The cute robot toy?

ADAM: You need a spoon. How do you get a spoon? You play Lights-Out with a robot. Who, if you win, unexpectedly gives you a spoon. The puzzles and the stories are tangentially related at best. That's a problem.

NEIL: Deus ex puzzle.

ADAM: Exactly.

ZARF: It's tricky, because I *liked* all those elements. And the author can get away with one of them (any one), because of whimsy.

NEIL: Well, here's the problem with trying to define "good" and "bad" puzzles. As Lucian will attest, when I found out the proper solution to the darkness puzzle in So Far, I just about had a conniption. Yet many other people say it's their favorite puzzle. And I get the same complaints/compliments on my games, too. What some people love, others hate.

LUCIAN: There's a difference between puzzle elements and puzzle solutions.

NEIL: So as an author, how do you judge what's good? Just your own personal reactions?

ZARF: Yes, no, and let me back up. :) The "tangentially related" problem is, I think, a conflict between the focus point of the story and the focus of the player. You-the-player stuck and frustrated and yelling at a bunch of gnome statues that are preventing you from getting in the front door. If that were a short story, going in the front door would rate one sentence. Or, if it were weirdly locked like that, it would be a major part of the story in a way which didn't make it into AGB.

I cheat heavily by setting up stories where a major part is the protagonist wandering around, trying to understand confusing things Many many IF works do the same thing, of course.

You can make IF where you're in control and confident, but you have to structure the puzzles to take that into account.

LUCIAN: There's definitely a difference between 'satisfying' and 'pertinent'. A satisfying puzzle is one that you are pleased with yourself for solving. A pertinent puzzle relates it to the plot as a whole. You might be pleased with yourself for winning "Lights Out," but that doesn't make it pertinent.

ZARF: Unless it's satisfying because you solved it by understanding its relationship to the plot as a whole. Then they're the same thing again.

NEIL: It sounds to me like bad puzzles fall in three categories: the unfair, the unsatisfying, and the, er, impertinent. Am I leaving anything out?

LUCIAN: The too hard, the too easy, and the too weird? Shall we talk about "hard" vs. "easy" puzzles, then?

ZARF: Hard vs. easy is too subjective. We can sometimes agree on fair vs. unfair, but almost never on hard vs. easy.

NEIL: Unfair = requires telepathy, right?

ZARF: Yes.

ADAM: Here's another issue that just occurred to me regarding the fairness issue: what kinds of cognition, for lack of a better word, do IF puzzles incorporate? For instance, how often do we encounter puzzles that require knowledge of the world or culture? (Didn't Graham have a puzzle that requires familiarity with Proust?).

ZARF: About Proust, no, I don't think so. I'm pretty sure he put in clues for the culture-ignorant. You may be thinking of his "deliberate guess-the-verb" puzzle.

NEIL: This is mostly an implementation issue, I think. Or at least partly so. Locked door puzzles are easy because there are libraries for them.

ADAM: Is it really unfair for a puzzle to test your knowledge of baseball, but fair to test your command of logic? Or are these just different kinds of games, and player beware?

LUCIAN: I was able to create an interaction-with-people puzzle (the selfsame language puzzle) only because I was able to limit the playing field--the Stranger had a complete vocabulary of about 21 words. Even with that limitation, that code still took up about a third of the game.

ZARF: Well, yes, they're different types of games. But the level of logic in existing IF is really within the grasp of just about all the literate audience. Whereas I don't know Proust *or* baseball.

NEIL: Define "literate."

ZARF: Capable of reading science fiction. OK, I'm judging by myself. Of course the prevalence of SF and fantasy in IF is not a coincidence -- similar target audiences. Ditto, why there's a lot of puzzle plotting in SF and fantasy.

NEIL: Whereas I know plenty of people who know baseball, but couldn't solve a logic puzzle to save their life.

ZARF: Can't solve which logic puzzles? The formal knight-and-knave puzzles? Those are a minority. Are you talking about people who can't solve Lights Out or the brown-eyed rock puzzle in Spellbreaker?

NEIL: I know a very smart person, for example, who was unable to get past the first puzzle of System's Twilight. The tree thing. It requires a certain kind of thinking -- which is I think what Adam was trying to point out.

ZARF: OK, that's a large class of puzzles that I wouldn't hesitate to put in IF, but which would give people trouble.

NEIL: Basically, anything that's fair game in Games magazine tends to be seen as fair game in IF.

ZARF: Hypothesis: we don't spend enough time inventing *easy* puzzles. Discuss.

NEIL: Easy puzzles are too hard to design! Seriously. It has to be easy enough for anyone to solve, yet hard enough to be satisfying. That's a damn hard line to walk.

LUCIAN: I think we might be able to define a new classification here -- "kind" and "unkind." A kind puzzle will take your attempts at solving it, and push you in the right direction. An unkind puzzle will wait for you to solve the whole thing before it lets on that you're on the right track.

ZARF: Implementation detail.

LUCIAN: Exactly. And that's important!

ADAM: Okay, so what makes a puzzle involving aside from difficulty?

NEIL: It should be fun to do. No setting a hundred levers to different positions.

ZARF: The canonical uninvolving puzzle is "find a key in the living room which unlocks a door in the hall." That's easy, but there's more to it than that.

NEIL: It should have an obvious payoff. Either intrinsic or extrinsic to the puzzle itself. The problem with the "find the key" puzzle is that it's no fun looking for the key, and a door in itself isn't that exciting.

LUCIAN: But if you *made* it fun to look for the key, it would suddenly become OK.

NEIL: Right. Put the key just out of reach, guarded by, er, a tree sloth. And have intriguing noises coming from behind the door. And suddenly it's not so bad a puzzle.

ZARF: No. The noises and the tree sloth make it an interesting *situation*, but the puzzle itself adds nothing. What you've done is added a potentially interesting get-the-key-from-the-sloth puzzle.

LUCIAN: Layers of complexity.

NEIL: Babel fish.

ZARF: If, however, the solution to *that* is to find some sloth chow, then again the players will say "gosh, the sloth chow puzzle." A puzzle can be easy and satisfying, on its own, if it reveals something interesting or makes you think of something in a new way. The harder puzzles don't let you win until you've thought of it; an easier version might show it to you as a side effect of winning."

NEIL: Whereas if it's to learn something about sloths (say, that they're distracted by copies of the National Review), then to tune the TV to a picture of William F. Buckley, it's a more interesting puzzle?

ADAM: That reminds me of the Reagan puzzle in Bureaucracy.

ZARF: How about the slide projector from Curses? The puzzle proper is to put a two-inch picture into a two-inch slot. But the context makes it interesting, even though it's not particularly tricky by itself.

LUCIAN: One trick in conventional fiction is to show the end before you get there. This can be in a flash-forward, or by, say, showing you the murderer in scene 1 and telling you he's the murderer. The interesting bit then becomes 'How will the detective catch the murderer?' You can do the same thing with your puzzles to make them more interesting. If you dangle a gold key just out of reach, and have a gold door somewhere, you become very interested in getting the gold key. If instead, you saw a sloth, got him to move, and suddenly found a key in his lair, it isn't as tantalizing as it could have been.

ZARF: Good. Anticipation is part of it, yes.

NEIL: Having Vogon announcements blaring in your ear, to make you desperate for the fish. If it were just an "every time you solve one puzzle, we'll give you another" thing, it'd be far less engaging. It'd be damn annoying, in fact. The announcements are key; they provide urgency.

LUCIAN: Showing you the fish was essential to that puzzle. If it had been "something flies past you, and you don't see what it is.", it wouldn't have been quite as engaging.

ADAM: Would this be the time to bring up narrowness and width? As in, how does it affect our assessment of a puzzle if it's A Thing To Do as opposed to The Only Thing You Can Do? How do we ameliorate the frustration factor of the latter, and make the former compelling?

NEIL: Provide entertainment.

ZARF: My problem with the Only Thing You Can Do is that it limits the *solutions* to the stuff available, and therefore it can't be interesting to figure out which stuff is relevant.

NEIL: You mean, the player just gets to make a list of objects they have, and try one at a time?

ADAM: Or knows that everything needed is at hand (or lost) and that no further exploration will help.

ZARF: In the worst cases, yes. And if you *solve* something that way, it's not satisfying. Brute force never is.

NEIL: How do you avoid that, though? At some point, every game can devolve into Only One Thing To Do.

ZARF: If there's lots to do, there is the potential to make that connection between apparently unrelated things.

LUCIAN: The Edifice would be a very different game if you had to finish the first level before you could get to the second. Which I considered. And which I rejected as I thought about how much fun it would be to play if I did ;-)

ADAM: The red-herrings issue goes back a bit to the first thing I said: if you create objects to fit the setting rather than just making what the player will need, the herrings take care of themselves. One of the things that bug me in games is encountering, say, a salad shooter, and knowing that the reason it's there is because I will need to come up with some innovative way to use a salad shooter in the future.

LUCIAN: For my game, I tried to make the "herrings" tangentially related to the puzzles. For the most part, they weren't there to solve the puzzles, but they could be used to give the player/PC clues about the correct solution. For example, all you really *needed* to solve the language puzzle was about five words. But all the rest were there to provide a context, and to encourage the player along a path.

ADAM: I'll throw in a random observation here on puzzle genesis. Since my current project is still quite plot-centered, a lot of the opportunities for puzzley-type things has come from my own implementation of them. [At this point, the MUD promptly crashed. Adam, Lucian, and Neil regrouped the next day, with Zarf joining in a bit later.]

ADAM: Okay, here's an example. In my current project, there's a vehicle I have to make. The process of figuring out how to implement it ended up seamlessly transmuting into a puzzle: how will the player make it work? This is another variation on the "found puzzle" phenomenon I mentioned at the top.

NEIL: "Found puzzle" as in puzzles that derive from the story, right?

ADAM: Right.

LUCIAN: I think that good responses to wrong solutions are extremely important. In the stimulus-response that is IF, you, the game author, are providing stimuli to the player, who responds by typing in another command. Every default response or "I don't understand that." response when the player was trying something serious is a mark against you. Every unique response when the player is trying something goofy is a mark in your favor, and encourages further typing.

The animal puzzle in So Far is a good example. Even though there's only one correct way to do things, there are many interesting ways of failing, all of which help your conceptualization of the situation until you finally solve the puzzle. I tried to guide people along this same course in my "invisiclues" -- I told the player to do many wrong actions, hoping that the responses they got would help them enough so that they wouldn't have to come back to the clues again.

Maybe this tells us something else, too -- a good puzzle in IF is a puzzle for which there is more than one potential solution.

NEIL: I have a game in the early stages of design where the whole plot hinges on gaining knowledge about something. Think of it as a whodunnit, even though it isn't. My problem: Short of an ACCUSE verb, or buttons to push indicating what the player knows, how can I tell when the player has figured it out? More generally, my question is: How does one design a knowledge puzzle?

ADAM: So I take it it's not a matter of revelation -- you have to figure out when the player has pieced it together in her head?

LUCIAN: I think that if the plot hinges on this knowledge, there should be some physical way for the player to manifest this knowledge. I think you'll need to figure out what your plot's equivalent of an "accuse" verb is.

NEIL: It's the Clue problem, though. How do I stop the player from ACCUSING salesman, ACCUSING cat... ACCUSE MR. MUSTARD WITH THE CANDLESTICK. No, that's not it. ACCUSE HIM WITH THE LEAD PIPE...

LUCIAN: How to prevent brute force?

NEIL: That's part of it.

LUCIAN: Have too many options?

NEIL: I think the greater problem I'm pointing to is: It's possible to design a puzzle to determine whether the player knows the answer to a question. But not if they understand WHY it's the answer. The final puzzle of LNY, for example, is solvable without understanding it.

LUCIAN: A small number of options with a variety of ways to combine them works. For example (again!) my language puzzle could certainly eventually be solved by brute force. Well, half of it, anyway.

NEIL: You can see how this artificially hamstrings what puzzles are available, though, right? Ultimately this reduces knowledge puzzles to a game of Mastermind.

Let's go back to Clue. Sure, you can make the puzzle more difficult by forcing the player to determine the murderer, murder weapon, location, and time of death, if you so choose.

LUCIAN: That's an example of combinations. Some rooms, some people, some locations, buttons of possible groups of three.

NEIL: But that isn't the same thing as requiring the player to figure out the motive and the M.O.

LUCIAN: But for motive, wouldn't you be saved by the fact that you had tons of options?

NEIL: But how do you let the player explain a motive? It's a parsing problem. Here's another example: Exercise: Translate TO SERVE MAN into IF.

I had enough troubles with GUIDE, TAKE ME TO AUSTRALIA in MacWesleyan. If you think I can code a game to understand WARN LEADERS THAT BOOK IS A COOKBOOK, you're nuts.

ADAM: You want to make sure the player stops the aliens for the right reason And not just because "I know the aliens are bad. Aliens are always bad! Screw the book puzzle!"

LUCIAN: I'd find a way to abstract the knowledge into a concrete form. A written translation of the man pie recipe, for example. Then you can SHOW RECIPE TO PRESIDENT or whatever.

NEIL: There are major guess-the-verb pitfalls here. But I guess that's unavoidable.

ADAM: At some point you'd need the player to be able to enter the word "cookbook" somewhere. You'd just need to find a way to make that as simple as possible.


If you put TELL PREZ ABOUT BOOK, it'd reply, "Yeah, aren't those aliens sweet?"

LUCIAN: Tapestry will have Morningstar react differently if you refer to him by a certain name. If you referred to the book as a "cookbook," that could also work.

ADAM: >TELL PREZ ABOUT COOKBOOK would elicit, "Oh my God! We gotta stop 'em!"

LUCIAN: Well, you'd have to allow for TELL PREZ ABOUT BOOK OF RECIPES, and whatnot. Abstraction is a key, though. Find a way to represent the knowledge in a simple form, and make that form obvious to the player.

ADAM: That brings up something else...the fact that experienced IF players know that there are only about 20 commands that are ever likely to do anything.

NEIL: SHOW PICTURE OF CHEATING WIFE TO HUSBAND. See, Gumshoe tried to do a knowledge puzzle. And it was clunky as all get-out.


NEIL: The more complex or abstract the puzzle, the more different player inputs you're going to have to account for. There's an inherent conflict in player expectations. They expect things to work like they've always worked, and yet they also expect new puzzles that they've never thought of before. There's a fine line between "Ick! Guess-the-verb puzzle!" and "Cool! A game that recognizes a new verb!"

ADAM: Right. Here's what I'm envisioning: Game starts. Before long, the player's up against a puzzle. An experienced player will try three or four "standard solutions," then if those don't work, sit back and think. "Hmm...what am I missing?" A novice player is more likely to try ten things the parser doesn't understand, and get frustrated. How to "pitch" a puzzle to both audiences?

NEIL: All the more reason to have as many working non-solutions as possible.

LUCIAN: Right. For example, I implemented "use" in my game, just because my novice beta testers were trying it.

NEIL: It almost seems like a puzzle's fairness or enjoyability has less to do with how to solve the puzzle, than with how the game lets you *not* solve it.

LUCIAN: Essentially, I told them, "Don't use 'use'. Try other verbs." But at least it was a response. The more I think about it, the more I am convinced that working non-solutions are essential to a fair, kind, and enjoyable puzzle.

ADAM: It's important that players be given an idea of what current IF tech just can't handle. The problem is, most players won't sit through an instruction book. So insinuating it into the game would be a real plus.

LUCIAN: I remember someone's idea on r.a.i.f a while back where if a player got a certain number of "I don't understand" responses in a row, the game would say, "Okay, you seem to be new at IF..." Not the best as it stands, but it's a good start.

ADAM: I've had friends who've never touched a computer game of any kind play I-0, and I found myself having to serve as a second parser, translating what they wanted to do into IF-ese. Otherwise, they'd type things like GO BACK SOUTH. Or GO NORTH AGAIN. Maybe even just making the player conscious that IF-ese exists would be good.

LUCIAN: But now we're talking about kind parsers, and not kind puzzles.

NEIL: I think even leaving out beginners, though, it's a problem to introduce new puzzle-solving methods. Has everyone here played Plundered Hearts at least, oh, three-quarters of the way through? I'm trying to remember now: What's the puzzle with the spices?


NEIL: Right. Is that a nifty extension of the verb set, or an unfair puzzle?

ADAM: Depends. To an experienced IF-er, that's outside the standard set of tools. To a novice, it's no more out there than anything else.

ZARF: My immediate thought is "give the player a fan, too." If the player has made a breeze in the past, it becomes a known tool. And "blow" is a valid alternate solution.

LUCIAN: I think it depends on how the game reacts to the standard verb-set. For example, what happens with the verb THROW?

ADAM: In I-0 there's an avoidable micro-puzzle to which the solution is APOLOGIZE. That's one of Graham's supplied verbs. Still, it's out there.

ZARF: I always turn off most of the sorry, curse, etc., verbs -- precisely to avoid confusing the player.

ADAM: THROW AT comes up with the bizarre response: You miss. In Inform, at least.

NEIL: TADS, too.

LUCIAN: No, I meant in this specific example. What happens if you try THROW SPICES instead of BLOW SPICES?

NEIL: Don't remember. Obviously, it's a good place to put a hint in the right direction. If this is a problem with physical puzzles, the problem is tenfold with knowledge puzzles. What if, instead of BLOW SPICES, the player has to TELL LUKE THAT LEIA IS HIS SISTER? The player starts with TELL LUKE ABOUT LEIA. "What about her?"

LUCIAN: I think that in the Luke/Leia case, you should have a good response to TELL LUKE ABOUT LEIA. Like, "What do you want to tell him about her? A), B), C),...."

NEIL: But multiple choice ruins it, if the player needs to figure it out themselves. TELL LUKE THAT LEIA WAS DISSING HER SISTER. "She is? No way!"

ZARF: If you're going to bring in a keyword system, you're going to have to tell the player and then put in a lot of work to make it playable.

LUCIAN: ...and that's where you need natural language parsing.

NEIL: But still, how's the player to know that they need to use LEIA and SISTER in the same sentence? Especially given that games are usually limited to TELL X ABOUT Y.

ZARF: The only way I can think of is to use the system so heavily that by the time the player gets there, it's obvious.

LUCIAN: Seriously, in order for this to work with present technology, you'd need to have some method of abstracting that knowledge into something concrete. A pendant with their family name. A DNA code analysis. Whatever.

NEIL: That's really clunky. It's back to SHOW PHOTO TO HUSBAND.

LUCIAN: Well, that's what level we're at, as far as I can tell.

ZARF: Nobody cares about clunky. As long as there's a clear solution, people will accept it as "The parser didn't suck."

ADAM: Well, you know my answer. Ask/tell must be burnt down. Or maybe not that extreme, but still.

See, here's a problem. Take TELL LUKE ABOUT SISTER as an example. You sort of have to trust that no player will try that until she knows what it is that a mention of SISTER translates to in the game. And that means that somehow you've got to keep players from trying stuff like TELL LUKE ABOUT BUTTERSCOTCH.

ZARF: "You don't know anything about Luke's sister" -- well-known hack in knowledge puzzles.

LUCIAN: Also, I don't think it's as clunky if, in response to SHOW PHOTO TO HUSBAND, the game responds, "'Sorry, Mike,', you tell him, 'I'm afraid your wife is sleeping around.' Incredulous, he denies it, until you show him the picture,and he can't help but acknowledge it."

ADAM: Y'know, Balance of Power had a notice on the title page: "People who play this game without reading the manual are wasting their time." Include a message of that sort, and in the manual, say TELL doesn't just mean "ramble on about X."

NEIL: Zarf, the problem with your solution is that it requires that the player perform a certain task, flaggable, to find out that Leia is Luke's sister. You can't code the player's brain to trip a flag.

ZARF: Well, that's how I'd set up that kind of plot.

NEIL: How does that differ from FIND KEY TO OPEN DOOR, then?

LUCIAN: It doesn't. But that doesn't make it a bad puzzle.


ZARF: That's not a command, that's a description of some plot events.

NEIL: Sorry. Lower-case it.

ZARF: It becomes a known puzzle, yes, but the content is interesting.

LUCIAN: All games are Space Invaders. But some games are more Space Invaders than others. All puzzles are lock-and-key. But some puzzles are more lock-and-key than others.

ZARF: And more likely the interesting point was the scene where you found out, or got the evidence, or whatever. The evidence itself is just something you grab as a reward.

NEIL: This seems to be directly at odds with Adam's solution. Zarf and LP suggest bringing the puzzle within conventional commands. Adam wants to tear up TELL entirely.

ADAM: Yeah, well, now that I've perfected my conversation interface, Ask and Tell are ashes in my mouth. Or something.

ZARF: Not to drop any spoilers, but the "about" text of my half-done game says "To simplify the problem of dialogue in interactive fiction, the 'tell' and 'ask' commands are not used in this game. Your conversational options are limited to 'yes,' 'no,' and saying nothing at all." Except that *really* that turns out to be... not entirely the case...

ADAM: I think what we're getting at here is: set your own ground rules. It's not that hard. Your game doesn't have to incorporate everything every other game has.

NEIL: But give the player lots of warning what the ground rules are. And lots of tolerance for disobeying them.

ZARF: I certainly don't stick a TELL X ABOUT Y puzzle at the end; that would suck.

NEIL: Well, but also: If you're going to require the use of the verb SIGNIFY in the endgame, you might want to mention it two or three times earlier in the game.

ZARF: Have the player use it casually, early in the game, with lots of cueing.

LUCIAN: I put in a new, necessary verb in Edifice. And no one's complained yet, so I suppose that's good.

ADAM: Er, I did. That was when I had to hit the walkthrough.

LUCIAN: Well, whether it worked or not, I tried both to include as many synonyms as I could, and also imply the verb indirectly as part of the "functional non-solutions."

ADAM: I'm wondering about the prompt now. One of the big arguments in favor of the prompt is that it provides the illusion that you can type anything you want -- not just pick from a menu of 12 verbs. Yet that illusion is so far from the truth...

NEIL: That illusion is what puts bread on our table. So to speak.

ZARF: The truth is *also* far from a menu of verbs. There is a consistent IFese. But I know we've done this on the newsgroup.

NEIL: So what have we determined about puzzles?

ADAM: Puzzles. Burn them down!

ZARF: It's better to find a can without a can opener than a can opener without a can.


LUCIAN: Well, in a whispered conversation with Adam, I remembered that I actually added *two* necessary verbs, one of which he got, and the other of which he didn't. The first one, on the first level, I provided much more context. More synonyms, more implications. The second, on the third level, didn't have nearly as much context, and I agree that the verb was probably harder to come up with.

ZARF: I would have gone off on my rant about "any good puzzle can be done with standard verbs. Except NPC puzzles." Except I liked the Edifice puzzle you're talking about.

ADAM: I'm troubled by the whole notion of 'standard' anything. At least regarding IF.

ZARF: Be troubled; we've got standard IFese.

ADAM: Any game could be someone's first game. You can say that "we've got standard IFese," but "we" who have it are mostly in this room.

ZARF: Many games have the standard intro to IF built in. Even the rest could just say "See the standard intro to IF first."

LUCIAN: A sample transcript should be able to overcome most of the problems with that. I've come up with three things we've said.

  • Use the environment.
  • Provide working non-solutions.
  • Provide ample context and warning.

Any others?

ZARF: Err on the side of easy. (He said, waiting to be struck dead for hypocrisy.)

LUCIAN: Be kind to your players.

ADAM: "Use" the environment? I thought we weren't supposed to use "use." Oops! I used it!

I think the only thing I'd add is this: IF is different things to different people. To write a game I like, emphasis on LP's point one is paramount. But other people won't much care. So the upshot is: to an extent, how you approach your puzzles isn't a matter of "good" or "bad," so much as: what type of game are you writing?

[right arrow] Go to the next page in this issue
[left arrow] Flip back to the previous page
[top arrow] Go to the XYZZYnews home page