Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

New Thread: Designing Puzzles.

20 views
Skip to first unread message

Gerry Kevin Wilson

unread,
Mar 9, 1995, 6:03:58 AM3/9/95
to

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 | /~\ | >
<_______________________...@uclink.berkeley.edu__|_\__/__>

Derek Jones

unread,
Mar 9, 1995, 4:16:19 PM3/9/95
to
whiz...@uclink.berkeley.edu (Gerry Kevin Wilson) writes:

> 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.

I LOVE adventures with those kinds of dead ends or failure! That's
what makes IF worth playing, in my opinion. Besides being more logical,
and thereby not annoying the player, there is an automatic reaction
from the "narrator character", the "little guy" whom you control with
your typed-in imperative sentences.

Some of the posts in this group talk about the future of IF, more multimedia,
more senses involved, moving toward a Star Trek holodeck-style adventure.
Obviously it makes sense to make the player feel like they, themselves,
are playing the game.

But this is, I think, the wrong goal for a TEXT adventure. No senses of
any kind are involved. (You can't say "sense of sight" because, for a
pure text adventure, there aren't any accompanying pictures.) Instead,
it's like you're kibitzing a novel. Really good novels get deep into
the main character's head, and his/her thoughts are often unlike your
own, since they're a different person than you.

So, in summary, one thing I like in IF is a "narrator" who has their own
reactions to things, helping the writer conceal what are
actually dead ends behind this "narrator's" personality. Most of the
IF I've played (not an exhaustive list) has this "narrator" trying to
be invisible, sort of a pantographic extension of the player. If you're
going to go this way, it seems to me, you should be complete about it:
in the "hot lasagna" puzzle above, the player should be able to force
the "narrator" to shove the blazing hot lasagna down his throat, with
the accompanying tissue damage, or messages like "you are feeling extreme
pain". This could, of course, get quite morbid, and is more like controlling
a zombie.

Is there any IF out there, for example, which requires that the player help
the narrator overcome some "personal" phobia before being able to undertake
some activity? Like trying to overcome a fear of heights?

What do you the rest of you think? Does that make IF more or less fun?

--Derek Jones
d...@primenet.com

--
-------------------------------------------------------------------------------
Derek Jones
d...@primenet.com
-------------------------------------------------------------------------------

SueLong

unread,
Mar 10, 1995, 9:42:25 AM3/10/95
to
Derek,
I think you have a great idea here. Seriously. I find IF much more
meaningful when it helps me learn something, including something about
myself. As a non-risk-taker in ordinary life I never put myself in the
position of climbing mountains or racing fast cars. IF simulations would
be a very good way to experience this "safely". With all due respect to
people who like to solve puzzles (and with great respect to people who
write clever games), I get enough hot lasagna in my everyday life.

Sue Long

Carl Muckenhoupt

unread,
Mar 11, 1995, 1:47:04 AM3/11/95
to
Interesting. It goes to show that everyone's different, I guess - my own
project-in-the-works is growing in exactly the opposite way. It started
out as an idea for a puzzle, which led to other puzzle ideas that would
"fit in" with it, by reusing either items or game mechanics. The plot has
developed largely as a means of explaining the necessity of solving the
puzzles and the presence of the objects used to do so. How this will
affect the end result remains to be seen.

--
Carl Muckenhoupt | Is it true that Kibo habitually autogreps all of Usenet
b...@tiac.net | for his name? If so: Hi, Kibo. Like the sig?

0 new messages