I live in Washington, actually. (For those who are still confused, I
moved here in April from Pittsburgh, where I went to school and later
worked. This is why 1) I still have an account at CMU, and 2) why I
like to go there to visit.)
Anyway, here's the result of a few hours' thought and typing,
distributed over the past week. In between everything else I've done
for you ungrateful louses. Lice.
-----------------------------------------------------------------
Not Actually an Article #1:
Why Plot Diagrams Don't Butter My Biscuit
(If you don't know what plot diagrams are, see the article in XYZZY
#4.)
The problem, see, is that plot diagrams represent a very abstract form
of a plot. They assume that the plot consists of a bunch of goals,
each of which depends on previous goals. Once a goal is complete, it
stays complete, and you can complete a goal if and only if all its
previous goals are complete.
For a straightforward game, this may be an accurate representation.
But for more complicated games, a plot diagram misses out rather a
lot of information.
A simple extension to the system (which I by no means invented) allows
you to do much more. I will use the notation that two actions joined
by a line and a cross will mean that the actions are mutually
exclusive:
|
get food
/ \
/ \
eat feed
it --X-- it to
| cat
| |
(My first thought was to have a single line coming from "get food",
which splits at a cross. But this notation is more general; it
covers situations where two mutually exclusive events don't share a
previous action.)
Lines joining at a circle will mean that either of the actions is
sufficient to allow the action below the circle:
| |
buy catch
herring trout
\ /
\ /
\ /
\ /
O
|
feed cat
|
I leave it as an exercise to extend the _Enchanter_ plot
diagram in XYZZY #4 to include information about the various red
herrings, such as the alternate (mutually exclusive) uses of the
"Dispel Magic" scroll.
So this sounds good. It's still missing a couple of things, though:
* Timing information (situations where you can only do so many
things before a given event)
* Goals that can be cancelled after they're satisfied, and possibly
satisfied again, etc.
You can hack some of this with mutual exclusion. Complicated
situations can spawn exponential numbers of little lines and crosses,
however. Consider a situation where you have 15 minutes to act, and
you can perform action A (6 minutes long), B (9 minutes), C (4
minutes), D (10 minutes), E (5 minutes), or F (5 minutes.) That gives
ten possible combinations of actions within the time limit, which I
don't feel like listing. You could represent this as ten action
bubbles, all mutually exclusive. A later action which requires, say,
action C would be joined to several of the combinations (any one
being sufficient.) Not entirely wieldy. And that assumes that you
*want* to perform as many of those actions as possible; if some of
them have negative consequences, the number of combinations worth
listing goes up to, I think, 18.
So, fine, you think; eighteen bubbles isn't so bad for such a
complicated timing puzzle. Okay; consider the following scenario...
The player finds himself in cold, dark room. Wood is laid in the
fireplace, but it is not lit. The door is locked and the hinges
frosted up. The key is on a ledge, out of reach, and there's a bat
nearby.
(Contrived is my middle name, yes.)
The sequence of actions that I, the author, have in mind, is this:
- player catches the bat (this can only be done when it's dark)
- player lights the firewood with his trusty Zippy-Spark
- the fire begins emitting lots of noxious smoke; the player begins
choking, and will survive just long enough to complete the sequence.
- the heat from the fire defrosts the door
- player extinguishes the fire (the smoke stops getting thicker, but
doesn't clear away.)
- player orders the bat to fetch the key (this can also only be done
when it's dark)
- the player unlocks the door and escapes, just in time to avoid death
by smoke inhalation.
Note in particular that it takes some time to catch the bat; if you
spend that time *after* lighting the fire, you won't have time to get
the key before you expire. Also, if you don't extinguish the fire,
the smoke gets worse and kills you before you can get out.
How does this diagram out? First attempt:
| |
catch bat light fire
| / \
| / \
send bat door extinguish
after key defrosts fire
\ / /
\ / /
\ / /
open door /
\ /
\ /
escape
|
Not very satisfactory. This diagram says nothing about the fact that
bats are nocturnal. It also wrongly implies that you must light and
extinguish the fire to escape. If there was another way to defrost
the door (say, a nice warm fuzzy cat), and thus an alternate path
into the "open door" bubble, the whole fireplace thing would be
irrelevant; but this diagram doesn't show that fact.
The latter omission can be fixed as follows, using mutual exclusion
and alternatives:
| / \
catch bat light fire ---X-- don't
| / \ light
| / \ fire
send bat door extinguish /
after key defrosts fire /
\ / / /
\ / / /
\ / / /
open door O----------
\ /
\ /
escape
|
What about the bat? My ASCII-art abilities fail here, but imagine
adding an additional requirement leading into the "send bat after
key" bubble. This line splits back to three alternatives: "don't
light fire", "extinguish fire", and the node just before "light
fire". Those are, after all, the three conditions when it's dark.
Except, oops, you can only *catch* the bat when it's dark, so add a
similar set of three lines leading into the "catch bat" bubble. You
can see that this approach would rapidly disintegrate as elements are
added. If the fire can be lit and extinguished a second time, there
are about twice as many conditions when it's dark (including the ones
where the fire is only lit once); that's about twelve lines snaking
across the diagram, instead of six. If there's something that can
only be done in the light, jack it up to sixteen or eighteen. At this
point it's easier to throw away the diagram and go back to the
old-fashioned method of pacing around and mumbling neurotically to
oneself.
Oh, and we still haven't accounted for the timing requirement. You can
work out a diagram which describes what's possible and what isn't --
we've done most of that already -- but it's ad hoc. Change the timing
slightly, and you have to go back and rebuild the diagram from
scratch. Again, this defeats the purpose.
Consider this: there's a design problem in my scenario. The player can
send the bat to fetch the key *before* lighting the fire, and thus
save a lot of time afterwards. (Did you notice?) Of course, you might
be willing to allow this as a legal solution to the scenario, but then
again you might not:
* You might want the dramatic impact of barely making it out of the
room alive.
* You might have a heart-rending scene planned where the bat struggles
up through the smoke, grabs the key, and returns it to you with its
dying gasp, leaving not a dry eye in the house -- or maybe that's
just the smoke in your eyes.
* You might have some other red herring in the room -- something that
the player really would like to get (or do) -- but there absolutely
isn't time to get it and also escape alive. That is, it is essential
to the plot that the player not get it at this point.
The point is, the diagrams shown above do not distinguish the case of
getting the key before you light the fire, and the case of doing it
afterward. On the other hand, once you see the problem, it's not hard
to fix: you might say that the key is also buried in frost, which only
melts when the fire is lit, and make "light fire" a requirement for
"send bat after key". But this is again ad hoc. The diagram is
supposed to display plot flaws and make it clear what changes will fix
them.
Whew. Much typing. Someone else's turn.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."