# Locational Puzzle Theory

30 views

### Roger Carbol

Oct 2, 2001, 12:40:04 PM10/2/01
to
Locational Puzzle Theory
--Roger Carbol
--Version: 2 Oct 2001

Synopsis: Almost every puzzle in IF deals exclusively with
only the location of objects, either corporeal or memetic.
The remainder deal with miscellaneous properties of these
objects.

Goal: To gain a better understanding of what a puzzle is,
how to construct puzzles, and hopefully, what distinguishes
a good puzzle from a bad puzzle.

What is a puzzle? This is the question put forward.

The answer depends on what you consider to be a game.

I define a game is defined as a collection of objects, in
the object-oriented programming sense. In this sense,
objects are collections of properties.

I define two sorts of objects: corporeal, and memetic.

Corporeal objects are easy, and probably what you already
think of when I say object. They're the locked doors,
the glowing swords, the small stones. Implemented right
in the program as objects. For my purposes, simply keep
this in mind: a corporeal object may only ever have one
location.
(Yes, there are some weird things like really long
ropes that might have one end tied up in one location and
the other end tied up in some other location. But
we'd probably logically code that up as two seperate
end objects, each with their own location, or in any
case we *could*, so humour me on this.)

Memetic objects are trickier. By this I mean pieces of
information. For example, the combination to the
(corporeal) safe. The phone number of the killer. The
information contained on a photograph, but not the actual,
physical, corporeal photograph itself.

There are two trickeries here. The first is that a
memetic object can exist in any number of locations.
If you give a phone number to a friend, now you
*both* have it. If you show a drawing to a friend, he
now has the memetic content of it, but not the actual
physical drawing, although he could try to make his own.

Secondly, memetic objects exist beyond the game itself.
Beyond the game exists the player, who interacts with
the game, and who, in many ways, can himself be considered
merely a collection of corporeal and memetic objects.

If the player of a particular game walks through the
big steel door and gets killed, he is now in the possession
of a new piece of information, a new memetic object: walking
through the big steel door results in death. The player
character, or PC -- the entity that the player controls
in the game -- is also in possession of this object,
shortly before his death. If the player discovers the
killer's phone number, both he and the PC possess that
memetic object, though the PC may subsequently die. It
is also possible for the PC to own memetic objects that
he won't share with the player, although this is usually
rare.

This loss of synchronicity between the memetic object
inventory of the player and the PC tends to lead to

(A sidenote on 'location': You may have noticed me using
the concepts of location and possession interchangably.
Most IF languages consider the player as a 'container'
of sorts, and objects that he is holding are, in some
logical sense, *in* him, in the same way they'd be in
a room if they were sitting there. In that sense, I use
location and possession interchangeably.)

Playing the game, then, consists of the player changing
the state of the game, which is to say, the state of the
game objects, which is to say, the state of the properties
of the game objects.

But there's a difference between *playing* a game and
just fiddling with it, so let us add to that concept
that playing a game is the player changing the state
of the game in an effort to achieve a particular game
state.

There's a subtle, underlying symmetry in this: why
is the player engaged in this effort? To be entertained,
to become more happy; in short, he is trying to
achieve a particular object state *within himself.*
We can therefore say that as the player tries to
achieve a particular game state, the game is also trying
to achieve a particular player state.

To get back to our original question: what is a puzzle?

A puzzle is defined as something which hinders the
player in achieving his desired game state.

As an aside, we can also now define a problem:

A problem is defined as something which hinders the
game in achieving the desired player state.

A clever NPC might be a puzzle. Poor use of English
by the game's author might be a problem. A tedious
maze might be both a puzzle and a problem.

One will note that one of the chief distinctions between
a puzzle and a problem is that, although the game's
author creates both of them, the player *can only
solve puzzles.* The player cannot solve problems, although
he may learn to live with them. This may be the
chief reason why problems are annoying.

Puzzles of Location

In the grand scheme of all possible corporeal and memetic
objects, there are between them an immeasurable number of
properties. However, there is exactly one property which
they all must share in order to exist as objects.

This property is location. Every object which exists in
the game must have a location to exist in; otherwise, it
does not exist. For the purposes of this discussion,
objects which have a location of null still exist within
the game; they're just not anywhere where the PC can get
to them.

The vast majority of puzzles involve changing the
location property of objects.

This is a bold statement, I know. Hear me out.

Among the most basic (and, unfortunately, the most tedious)
puzzles is that of the maze. What is a maze? Merely changing
the location of the PC until he is in a location the player
likes. In this process, numerous pieces of information
describing the maze, mimetic objects, are moved into the player.
Even outside of mazes, we can consider moving the PC around
the game map to be the fundamental, if usually easy, puzzle
of most games.

Many other puzzles involve moving physical objects. Picking
up treasures and putting them into trophy cases. Taking the
dollar from under the bed and giving it to the cheese merchant.
Carrying the piano up the five flights of stairs.

Recalling that null, which is to say, nowhere, is also a valid
location, all puzzles involving the destruction or creation of
physical objects are also puzzles of this type. Pushing a button
on a photcopying machine so that it creates a brand new copy is
changing that copy's location from null to the machine. Inserting
the copy into an incinerator and pushing its button is changing
that copy's location from the incinerator to null. Stabbing the
troll with a sword so that he dissolves into mist is the same
class of puzzle.

If we conjoin destruction and creation, we get transmutation: the
conversion of one object into a different object. The old object
is destroyed, the new object is created. We burn a newspaper and
get a pile of ashes. We shoot a werewolf with a silver bullet
and we get a corpse.

Closely related to transmutation is exchange, or mediated
transmutation. We give a gold coin to the old dwarf and get a
shiny sword. The transmutation still occurs, although there's
usually less of a sense of the old object *physically* transforming
into the new object. The old object is *usually* effectively
destroyed in the process, but not always.

Of course, there's a fine line between altering the properties of
an object, and creating a brand new object out of the old object.
In some sense, it is an artificial distinction, though a useful one.

Typically, the line between alteration and transmutation
involves one or the other of the following (and sometimes
both):

1. Irreversibility: the new object cannot be reverted into
the old object.

2. Mass change of properties: the new object has radically
different properties than the old object, and usually has more
differences than simularities.

Notably absent is a sense of physical continuity. In real life,
we tend to consider, for example, a living person and his inanimate
corpse to be the same object with different properties. In IF,
it's often profitable to see these as two different objects, the

Up until now, I've been speaking of corporeal objects.
But the same sentiments apply to memetic objects.

The fundamental act of discovery, perhaps the keystone of this
class of games, consists of transferring memetic objects to
the player. There's a wide range of puzzles which depend on
conveying a memetic object to an NPC, usually by TELLing him
or SHOWing him the information. And the inverse case, in which
the puzzle is preventing the NPC from getting the information,
often through hiding, either the PC or an object in his inventory.

The exchange of memetic objects between NPCs and PCs is very
common -- the entire conversation system exists for only this
purpose. A puzzle might be to give the NPC a memetic object in
exchange for a physical object -- for example, telling an NPC a
password so that he gives you a pistol. Or visa versa.

It shouldn't be surprising that this form of puzzle is so common
in IF -- after all, much of real life consists of this sort
of "puzzle". Learning information. Building things. Receiving
money. Talking to people. Birth. Death.

Puzzles of this sort are also relatively easy to invent. At their
simplest, you only need place an object somewhere other than where
it's needed. However, most authors embellish them a bit more
these days.

Popular complications include:

1: The object's location can be moved, but not into the
player -- he can't take possession of it. It is too heavy,
or too distant, or otherwise unable to join his inventory.
If inanimate, he may need to push it around. If animate, he
might command or coerce it to follow him. Or an animate object
might carry an inanimate object for him.

2: It is not obvious how to destroy, create, transmute,
or exhange the object.

3: In transmutation, removing the old object was useful, but
the new object is dangerous. Or the new object is useful, but
the lack of the old object is dangerous. As an additional
trickery, the values of the objects are sometimes contrary to
the player's expectations -- he thinks that removing the ice
blocking the air duct is the valuable side, when in fact it's
the residual water which is actually useful. Or both results
may be useful.

4: The player does not know where the object is, or where the
object needs to be. Canonically, it is better to find a door
that needs a key before finding the key that needs a door. Often
seen with memetic objects -- the player doesn't know what the
NPC knows, or what the NPC needs to hear.

5: It is not obvious the object CAN be taken. This usually
falls into the player-irritating problem category.

Locked Door Puzzles

The function of a locked door (or a locked box) is to
prevent a particular change of location properties. They
prevent movement. As such, they are intimately connected
with location puzzles, and very popular.

One usually requires one or more keys, which might be
corporeal or memetic objects (like a combination, for example.)

The inverse case, which is more unusual, is for the player to
require a key to lock an open door, usually to prevent the
movement of an NPC.

Possible complications include:

1. An unusual verb or sequence of actions used to enable the
key. This can be seen as an memetic key which must be possessed
by the player.

2. The key is fragmented into individual parts. The corporeal
object may be shattered, or more than two corporeal objects may
be required, or the memetic key may be revealed in pieces
(for example, a three-digit combination might have each digit
scattered in the game.)

3. An object may need to be exchanged or transmuted for a key
that will work. A memetic key may need to be decrypted.

4. It may not be obvious that this particular key opens this
particular door. This tends to be a player-irritating problem,
and can often result in the player brute-forcing every object
with every door in an attempt to open them.

Darkness puzzles

It's not unusual for player characters to find themselves in
the dark. The primary impediment here is that there is no
transference of memetic objects to the player character (even
though the player himself may be fully aware of the contents of
the location.) Incidentally, most games prevent a PC from moving
around in the dark.

This sort of problem is almost always solved by bringing a light
source to the location. It is sometimes solved by changing the
'illuminated' property of a room, such as remotely turning on a
light or restoring power, or stimulating a bioluminescent
creature within the room, etc.

An interesting solution is to change the properties of the player
character such that he can see in the dark -- this is essentially
a redefinition of 'dark', and relatively clever.

Miscelleanous Changes in Properties

Other than location, which virtually every object has, and
lumination, which virtually every location has, individual
items will have differing properties. Manipulation of these
remaining properties will form the bulk of remaining puzzles.
Often, however, they will interlock with the aforementioned
classes of puzzles. For example, you may need to chop a tree into
some firewood, then move the firewood into a boiler (both
location puzzles.) This will raise the temperature of the room
containing the boiler (miscellaneous property) which will melt
a block of ice into a puddle of water, revealing a diamond ring
frozen within (transmutation as a key to opening) that you can
show to an anxious groom (transferrance of an information object.)

Puzzles of this sort may be generated by the following
algorithm:

1. What are the properties of this object?
2. What would be required to change the properties of
this object?
3. What would be the result?

For example, consider glass. One of glass's most notable
properties is its transparency. One could make it opaque
through a variety of processes, mostly involving covering
it with a thin layer of some substance: frost, oil, soot,
or paint. The result would be an opaque glass object. Since
transparency is most often related to the transferrance of
information objects, it may very well be used to hide an object
within an otherwise transparent container.

Most "new" puzzles are of this sort.

In conclusion, I've tried to define puzzles, and bring a sort
of taxonomy to them. In doing so, I hope you are better able
to invent puzzles for your own IF masterpieces.

-- Roger Carbol

### Andrew Plotkin

Oct 2, 2001, 1:06:29 PM10/2/01
to
Roger Carbol <rca...@home.com> wrote:

> Synopsis: Almost every puzzle in IF deals exclusively with
> only the location of objects, either corporeal or memetic.
> The remainder deal with miscellaneous properties of these
> objects.

But all properties are merely locations in an abstract phase space.
Right?

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*

Oct 2, 2001, 1:17:51 PM10/2/01
to
In article <9pcs6l\$fan\$1...@news.panix.com>,

Andrew Plotkin <erky...@eblong.com> wrote:
>Roger Carbol <rca...@home.com> wrote:
>> Synopsis: Almost every puzzle in IF deals exclusively with
>> only the location of objects, either corporeal or memetic.
>> The remainder deal with miscellaneous properties of these
>> objects.
>But all properties are merely locations in an abstract phase space.
>Right?

Well, yeah. That's my basic problem with the model. The categories are
so broad that there's no interaction--whether game-related or not--that
can't be put into it, and therefore it loses most of its practical
application.

Or, put another way, at a sufficiently general level of abstraction, all

### Sean T Barrett

Oct 2, 2001, 10:43:10 PM10/2/01
to
>Well, yeah. That's my basic problem with the model. The categories are
>so broad that there's no interaction--whether game-related or not--that
>can't be put into it, and therefore it loses most of its practical
>application.

I think there's something to be said for the claim "most adventure
game puzzles involve locations" being a non-trivial claim; I would
(and have) argued that object location is the only deep simulation
in most adventure games; all objects have it, any number of "core"
commands with highly predictable non-vacuous behaviors are defined
for it (go nw, get, drop, put in, empty, empty into), and a fairly
complex text-generation system (for contents lists) is used (but I
suppose the complexity is more due to the difficulty of generating
English output than the complexity of the simulation).

Most other systems have a quite simple simulation: open or closed,
locked or unlocked, worn or not worn, lit or not lit; and the more
complex of those (e.g. both open/closed & locked/unlocked) in fact
do tend to be rather commonly used in puzzles (or at least were in
the puzzle-game heydays, perhaps less so now).

A figure-out-able puzzle needs sufficient context for participants
to find the solution. Systems with deep simulation generally offer
many more opportunities for providing exceptions to the simulation
and for finding ways in which to get emergent behaviors out of the
simulation than something with less simulation which sets up fewer
expectations that can be built on.

Hmmm. A figure-out-able puzzle needs the player to be able to gain
knowledge of the expected behaviors of actions--if you can't predict
that your solution will work, you're just guessing [to a first
approximation, with lots of exceptions]). This suggests to me
three broad classes of ways to expect behavior: based on game-external
knowledge (real-world knowledge), based on hard-coded text output
by the game, and based on behaviors of simulated actions. The
distinction I'm making with the last two is that the hard-coded
stuff tends to be exceptional--each thing with a different behavior.
If things behave "consistently", that tends to be a sim (or it
*could* be a sim, anyway).

So something like Photopia makes its actions draw a lot from
real-world knowledge; your expectation that a given command is
going to work comes from your knowledge of the real world and
some guidance from the author pointing you in the right direction.
Something like Spider & Web's gadgets are a new custom simulation.
An example of the middle (game-text-driven) escapes me right now--
perhaps the pool scene in Photopia goes in that direction, actually--
but I'm pretty sure it's common in the more linear story games.

All of this said from the strongly-biased POV of a simulationist.

SeanB

### Roger Carbol

Oct 3, 2001, 6:04:26 PM10/3/01
to
Sean T Barrett wrote:

> I think there's something to be said for the claim "most adventure
> game puzzles involve locations" being a non-trivial claim; I would
> (and have) argued that object location is the only deep simulation
> in most adventure games; all objects have it, any number of "core"
> commands with highly predictable non-vacuous behaviors are defined
> for it (go nw, get, drop, put in, empty, empty into), and a fairly
> complex text-generation system (for contents lists) is used (but I
> suppose the complexity is more due to the difficulty of generating
> English output than the complexity of the simulation).

Thanks, Sean -- that was the point I was essentially trying to
drive at. (The bit about memetic objects may be a case of my
reach exceeding my grasp.)

One will also note that some of the most irritating problems
in IF arise from mangling the PC's ability to manipulate the
locations of objects:

1. The 'Time-Spent-Walking' problem we see in graphical IF,
in the sense that the player is trying to change the PC's
location; and

2. The restriction on weight or bulk that the PC can carry
(often fair, yes, but still often more irritating than one
might expect).

Let me suppose this: for the majority of mainsteam IF, if one
were to consider the walkthrough for the game, the majority
of commands (I'd guess even as high as %90) involve nothing more
than changing the location of objects in the game.

And let it never be said that my wild-eyed theories do not
yield verifiable suppositions, at least some of the time.

.. Roger Carbol .. rca...@home.com

### Jon Ingold

Oct 4, 2001, 8:24:57 AM10/4/01
to
Vague Mulldoon spoilers.

As a data point - most of the puzzles in Mulldoon conform to the same
pattern: the aim is to combine object X and Y in location B. Y is already
there, X is in location A as separated by obstacle K. The trick to the
puzzle, is not how to get X from A to B across K, but rather to take Y back
across K, combine them in A, and then cart the whole lot over again. The
puzzle I always thought of as a "switchback" design, and it requires the
player to take one step away from the problem they are faced with (how to
get X to B) and see the whole set-up more clearly. The beauty of that is
that they can do it equally well by the keyboard as at the bus-stop. My
definition of a good puzzle has always been "one that can be solved at the
bus-stop". I make no allowances for handheld computers.

Jon