Game Design in General.
Jim Newland
>I did some hasty scratching on my plot diagram,
Could someone provide an example of one of these plot diagrams? I've
seen a rather brief example from Graham Nelson somewhere, but it wasn't
enough to spark my understanding (then again, a bolt of lightning might
not be enough for that...).
Thanks much,
Jim Newland
76461...@compuserve.com
Julian Arnold
> Could someone provide an example of one of these plot diagrams? I've
> seen a rather brief example from Graham Nelson somewhere, but it wasn't
> enough to spark my understanding (then again, a bolt of lightning might
> not be enough for that...).
A plot diagram (aka puzzle lattice, aka goal synopsis, aka puzzle structure
chart, and probably a hundred other names!) is basically a flow chart showing
how the plot of a game will develop. It's a visual thing so an example will
serve better than a description:
[A very simple, totally fictitious example]
START
|
Bash astronaut with heavy magnetic boot
_____________|______________
| |
Steal shuttle keys from Enter
unconcious spaceman armoury
| |
Enter __________ Get
shuttle | Gun
| Find Oxygen |
Takeoff Tank |
| / |
Fly to planet X / |
| / /
Land and _____/ /
go outside /
| /
Meet alien /
\ /
\ /
\ /
\________________/
|
Kill peaceful alien
|
Claim planet for humankind
|
Screw everything up
|
END
Actually, the goal synopsis approach (from Whizzard's guide) is slightly
different, allows more detail, and is more compact, so the above example
might look like:
1. Render astronaut unconcious...
a. GET MAGNETIC BOOT
b. HIT ASTRONAUT WITH BOOT
2. Steal shuttle keys...
a. SEARCH ASTRONAUT
b. GET KEYS
3. Get gun...
a. EAST (past unconcious astronaut)
b. EXAMINE WEAPONRY
c. GET GUN
4. Etc...
If my example isn't of a high enough voltage have a look at Whizzard's guide
(update #2 I think) or C E Forman's article on IF design in XYZZY #4 (using
ENCHANTER as an example).
--
Jools Arnold jo...@arnod.demon.co.uk
Andrew C. Plotkin
General. Julian Arn...@arnod.demo (2906)
> > Could someone provide an example of one of these plot diagrams? I've
> > seen a rather brief example from Graham Nelson somewhere, but it wasn't
> > enough to spark my understanding (then again, a bolt of lightning might
> > not be enough for that...).
> A plot diagram (aka puzzle lattice, aka goal synopsis, aka puzzle structure
> chart, and probably a hundred other names!) is basically a flow chart showing
how the plot of a game will develop.
[diagram deleted]
Except that that sort of diagram doesn't cover the sorts of variations
which I use in "A Change in the Weather", for example. Where things have
more than one use, some of which are incompossible (what a great word!),
and order of use is critical.
I have not invented any way of representing that sort of thing in a
diagram. The "plot diagram" for Weather was actually just a straight
list of commands, with some notes about what timed events occur where in
the sequence. That only works because Weather is a very short game --
and even then, the "diagram" doesn't include any of the wrong ways to do
things. That is, it doesn't prove there are no shortcuts. I had to try
to think of every possible sequence the player might do things, and I
wasn't really certain the plot was hole-less until it had been heavily
tested by other people.
If I come up with a way to diagram the kind of games I like to write,
I'll post. Nasty problem.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
David Baggett
Andrew C. Plotkin <erky...@CMU.EDU> wrote:
>Except that that sort of diagram doesn't cover the sorts of variations
>which I use in "A Change in the Weather", for example. Where things have
>more than one use, some of which are incompossible (what a great word!),
>and order of use is critical.
I assume that by "that sort of diagram" you're referring to a directed
acyclic graph. I don't understand why you can't capture your constraints
with a DAG. Can you give a specific example?
Capturing order of use (and mutually exclusive goals) doesn't seem hard. A
simple approach to drawing DAGs with lots of these constraints on paper is
to have two adjacent nodes for each event --- on for "event occurred" and
one for "event didn't occur". Is the problem simply that you need an OR
operator in addition to the assumed AND? (I.e., that all edges leading
into a node in the DAG must be satisified --- AND --- as opposed to *any*
edge leading into a node needing to be satisifed --- OR)
Since no one has mentioned it in this thread, I'll also point out that
plot/puzzle DAG's aren't just useful design tools --- an IF work itself can
consult (or even construct) an internal represetation of its own plot. The
obvious use for this is in giving hints; e.g., the author wants the game to
dispense a useful hint, where useful means:
1) the hint is for a puzzle that hasn't been solved yet,
2) the hint is for a puzzle that can be solved now (i.e., one
for which all prerequisites have been satisfied).
There is TADS code implementing this sort of thing on the IF archive. (I
think the filename is adhint.t)
>That is, it doesn't prove there are no shortcuts. I had to try to think of
>every possible sequence the player might do things, and I wasn't really
>certain the plot was hole-less until it had been heavily tested by other
>people.
This is a tough problem for any IF, but you can certainly identify all the
points in the code that "assign credit" to the player for having met the
goals. The requirements that these bits of code impose tell you which
edges lead into a particular "goal node", and where these edges come from.
I suppose it all depends on how detailed a DAG you're willing to make...
Dave Baggett
__
d...@ai.mit.edu ADVENTIONS: Kuul text adventures! Email for a catalog.
"Mr. Price: Please don't try to make things nice! The wrong notes are *right*."
--- Charles Ives (note to copyist on the autograph score of The Fourth of July)
Andrew C. Plotkin
(was Re.. David Bag...@lf.ai.mit. (2533)
> >Except that that sort of diagram doesn't cover the sorts of variations
> >which I use in "A Change in the Weather", for example. Where things have
> >more than one use, some of which are incompossible (what a great word!),
> >and order of use is critical.
> I assume that by "that sort of diagram" you're referring to a directed
> acyclic graph. I don't understand why you can't capture your constraints
> with a DAG. Can you give a specific example?
Yes, but not today. I've got to drive from Pittsburgh to DC pretty soon... Heh.
> Capturing order of use (and mutually exclusive goals) doesn't seem hard. A
> simple approach to drawing DAGs with lots of these constraints on paper is
> to have two adjacent nodes for each event --- on for "event occurred" and
> one for "event didn't occur". Is the problem simply that you need an OR
> operator in addition to the assumed AND?
I thought of that. But I suspect that as the game gets more complex, the
two adjacent nodes will rapidly become N adjacent nodes, and you'll be
in a situation where adding another element causes the entire graph to
clone itself. This defeats the major advantage of a standard plot DAG
(that information, and thus changes, remain local.)
I'd love to prove that suspicion, but I've got to get on the road. :-)
I'll try to come up with an example while staring at that big beautiful
strip of sky they call the Pennsylvania Turnpike.
Yahoo.
russ...@wanda.pond.com
}Except that that sort of diagram doesn't cover the sorts of variations
}which I use in "A Change in the Weather", for example. Where things have
}more than one use, some of which are incompossible (what a great word!),
}and order of use is critical.
GOOD. Games like that should be unrepresentable and unwriteable :-).
If there's ever need for an example of a reasonable looking but
totally evil game, "A Change in the Weather" fits. If you hadn't
warned your players, we'd probably be forming an angry mob swinging
burning branches with cloth rags wrapped around them (what do you call
them? Torches, yeah, that's it, torches) outside your house.
Some spoilers follow
I mean, first you attempt to trick your players into breaking the
spade prematurely. Then, there's the fox problem, though that's not
all that evil. Then you won't allow the shack to open, arbitrarily.
When you wake up, every move is critical for quite a long time-- if
you miss the flash of light, you fail. Then there's the two
sandbags-- take the wrong one, and you can't win. And the branch,
tantalizingly made into a light source, but unuseable due to timing
constraints where you need it. Oh, and the various places where the
sandbag could be placed, only one of which led to a win. And the
boulder, which could be pushed different directions but when pushed
without directions did the wrong thing. Two different wrong paths
where you miss by one move-- one where you miss the flash of lightning
when going to get the other bag (never mind why you can't find it by
feel or REMEMBER where it was...), the other where you can't do the last
thing in time before the bridge collapses. The useless pile of sand
and cloth rag. And a "win" ending which you can achieve by simply
going west on the first move. Have I missed any evil?
--
Matthew T. Russotto russ...@pond.com russ...@his.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Julian Arnold
> I'd love to prove that suspicion, but I've got to get on the road. :-)
Have a nice time in Washington? Go on, prove that suspicion. You know you
want to.
--
Jools Arnold jo...@arnod.demon.co.uk
Andrew C. Plotkin
> "Andrew C. Plotkin" (erky...@CMU.EDU) wrote:
>
> > I'd love to prove that suspicion, but I've got to get on the road. :-)
>
> Have a nice time in Washington? Go on, prove that suspicion. You know you
> want to.
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.
Dan Shiovitz
sure how acceptable the following is, but it seems to me that some (at least)
of the problems you raise can be fixed by adding game-state requirements
to the DAG. For instance, the bat problem:
room is dark
|
catch bat room is dark light fire
\ | / |
send bat for key |
\ defrost hinges
get key | extinguish fire before T
| | /
unlock door | keep smoke level below X
\ | /
\ | /
open door
|
escape
Now, this is by no means perfect. Like I said, I don't use DAGs so I might
have made some grevious error. But it looks to me to solve most of the
problems you raised.
--
------------------------------------------------+--------------
The Grim Reaper ** scy...@u.washington.edu |
Dan Shiovitz ** sh...@cs.washington.edu | Aude
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Sapere
_Music of the Spheres_ : Coming Nov '95 |
------------------------------------------------+--------------
Mark Clements
follows:
In Hut<----------------------------------\
| |
/--------------O-----------------------\ |
| | |
V V |
Catch Bat /------------------------> Light Fire |
| | / | |
O------/ | (hinges defrost) |
| | | |
V | /----------O-------\ |
Send bat for key | | | | |
| / V | V |
O-------------------------->A | Extinguish |
| | | fire |
V | | | |
Unlock door<--------------------/ | \______/
| |
\------------------>A<-----------------/
| O: Split - Do one or other
V A: Join - Must have done
Open door both.
This seems to cover your original problem, except for the timing
aspect of the smoke. (Although, correct me if I missed something).
This would be easier to add if we knew how long each action took,
but even so would be tricky (esp. in ASCII <G>).
If you add the constraints needed to give the order you said, then
it would also be more difficult to create. (btw - if this isn't
a proper DAG, I apologise, as I don't really know what one is).
However, whilst this may give clarity, it takes a lot longer to
construct than simply thinking it through in your head, and
with the additions would probably make it's difficulty outweigh
it's usefulness.
(All in my opinion, obviously!)
--
(Smile - or at least, if you can't smile, vomit)
___ ,';_,-,__
Writing is just backwards reading. /~_ ,',' |O|,:,\,
Reading is just clever seeing. / /,',' /--|_|-;:;|
Seeing is believing. ( )',_) ) ):;)
To write, you must believe... >\,(__ / /:;;|
:...Mark...//~ /:;:;:\