New Thread: Designing Puzzles.


9 Mar 1995 11:03:58 GMT

First of all, let me warn the reader that I'm not just very good at
creating hard puzzles. At least I wasn't at last count, it's been awhile
since the last round of betatesting on Avalon died down. Nonetheless, I
am going to offer what I DO know about puzzle design. No, this isn't a
reprint of Graham Nelson's "Player's Bill of Rights". Rather, this is
advice on the actual process of puzzle creation. And all of it is just
the way I do things, and remember, my puzzles aren't very hard (at last
count).

Puzzles have walked hand in hand with text adventures from the
very beginning. Many games are simply a framework of puzzles over which
a veneer of story is imposed. I'll tell you right now, that is not the
way I do things, but in fact the reverse to a certain extent.
The first thing I did when writing Avalon was to write a story
outline. The first draft only covered the beginning and the end, but I
knew where I was leading at all times. Whenever I got to a new area, I
would write the story for that area, and the background information of
the area, a sort of history if you will. Next, I outlined certain major
goals for the player to accomplish: One major goal unknown at the start,
3 or 4 minor ones given in the introduction. In the course of completing
these, the player discovers the major goal. I then made an outline
listing these goals, which I began to break into subgoals.
At this stage I started thinking "Okay, they want to do this.
Now, what could conceivably go wrong." You will find this sentence makes
a very nice basis for your puzzles, as often several answers will spring
immediately to mind. For example: "Hmm, they need to eat the lasagna."
What can go wrong? The lasagna is too hot, spicy, mild, foul, poisonous...
I'll choose hot. The lasagna is served from a walk-thru restaurant,
dropped scalding hot into the player's hand, outside of which there is a
pile of dropped lasagnas. Obviously the player needs gloves first off,
and then a way to cool off the lasagna.
When solving complications, I generally pick the first thing that
springs to mind, thus, I get easier puzzles, as my answers tend to be
more intuitive. I have since been practicing my puzzle-making skills and
I think the betatesters will find the next few areas not so easy. It is
important to take into account the current setting of the game. I expect
my example puzzle to be different if it is set in the arctic than if it
is set in the tropics. In the arctic, you might well plunge the hot
lasagna into a snowbank to cool it down. If you want to make things a
bit more frustrating, you can add further complications, in the form of
additional steps in solving the puzzle. Look at Trinity's satellite
puzzle. Fairly complex and challenging simply because it has so many
subgoals to its completion.
I must again stress the importance of betatesting. An author can
have no concept of how tough his/her puzzles are unless he tries them out
on some unsuspecting players. It was in this manner I learned that my
puzzles were too simple for most players. More importantly, I picked up
on other gut reactions to the puzzles that told me what dead ends to
implement in my game. So, you might hear from 2 or 3 testers that they
tried to use the squirt bottle of koolaid to cool down the lasagna, and
were rewarded with, "The kool aid mists gently over the steaming
lasagna." They say they found this counter-logical, as cool liquid
should cool the lasagna. So you change the response to "As the kool aid
hits the steaming lasagna, there is a hissing sound, and the quiet scent
of strawberry meat sauce rises into the air. Nauseated, you throw the
now-soggy lasagna as far away as you can manage." This appeals to the
testers, so that problem is solved for the moment.
In fact, you will likely spend more time plastering up dead ends
than implementing new puzzles. Don't worry, this is perfectly normal.
My first area was 25 rooms large. Such a small scale yes? Hahaha!
Foolish mortal! I received over 300 bug reports for that area alone. I
still reach for the Maalox whenever I think of those early days.
Frightening I tell you. I actually had one puzzle that would crash
folks' computers, and that's not easy to do with TADS, mind you. But
then, those were the early days. I would awake in the middle of the
night screaming, fresh from a nightmare that I had just received a bug
report from M. Kinyon that was over 40 pages long. Happily, I never did.
There's an up side to betatesting for the implentor as well
though. It was thanks to my testers that certain jokes have been added
to the game, and I still have a collection of the funniest bugs,
including the Undead Mississippi Squirrel from Hell and this juicy little
thing:

>put joe on grenade
You miss.

Don't worry, if you don't get the joke yet, it'll come to you eventually,
or at least when you play Avalon.

So, a quick recap of what I have written so far:

1. Write your story.
2. Set goals.
3. Break goals into smaller units.
4. Brainstorm complications (These are your puzzles.)
a. Make things intuitive.
b. Take the setting into account.
c. Betatest, betatest, betatest.
5. Add dead ends.

And really, that's all there is to it. Good settings will tend to be
more flexible in what you can do with them, and if you use care in
deciding goals, puzzles will come knocking at your door.

-- 
<~~TREV ERA~~~~~~~~~~~~~SIGHT~UNSEEN~~~~~~~~NO~RELEASE~DATE~YET~~~~~~|~~~~~~~>
<  I      W  In the jungle of the big city, a predator stalks one    |  ~~\  >
<  GO  SOFT  he considers easy prey, a blind student.  Feel the fear | /~\ | >
<______________________________________whizzard@uclink.berkeley.edu__|_\__/__>