To Plot or not to Plot? and programming

[David Whitten]

Seeing the large number of posting about plotting, (and the excellent list
of Plot Outlines (when will the rest be posted?) brings to mind the question:

What would a programming system that supported integrating a plot into an
adventure include?

Using the analogy that a plot is kind of like a path thru a terrain, we have
a familiar model already. This is the movement of a character through a map.
Each room has connections to other rooms, some of which are blocked until
some condition comes true.

The main difference with moving around a plot-map and moving around a space
map is that in general you can retrace your steps in the space map, and you
can't really undo your actions in the plot-map.

But of course we are in the non-real world of IF! yeah! so we could (if we
were generous as writers) allow someone to change their mind and go back
to the state they were in before they made some important decision.

so what are these programming elements ?

below is a list of some that I have thought of :

SITUATION
A plotmap equivalent to a LOCATION. You have three kinds of
situations: Start situations, story situations, and final situations.
The start situations are the beginning of the game situation and the
limbo situation where you decide if you want to play the game again
after you have been killed.

DECISION
A plotmap equivalent to an EXIT. Any time the plot is going to
change significantly from a particular SITUATION to another SITUATION
a DECISION is made. Contrary to its name, a DECISION (in current IF)
is rarely actually asked of the player. (Although the Choose-your-path
books include a lot of these.) Usually a DECISION occurs when a
puzzle is solved. In other cases a DECISION occurs when the player
figures out exactly how to phrase a verb-noun combination to tell the
computer what she wants done.

Note that all plot does not 'move forward' based on the actions of the
player. Fuses, NPC characters, Monsters, etc. all can move the plot forward.

I think one of the reasons many int-fiction works are boring is because the
plotmap of the work is extremely simple. They reduce to a START SITUATION,
with the DECISION of SolvePuzzle and then some number of copies of the
SITUATION of FindPuzzle and then a DECISION of SolvePuzzle until you have
no more puzzles, and then you are in the FINAL SITUATION.

Thoughts anyone?

David Whitten : whi...@netcom.com : (214) 437-5255

[Gerry Kevin Wilson]

I enjoyed that post immensely. It sums up my feelings on plot quite nicely.
Too much linear-ity spoils the feeling that the player is in control. Here,
I'll do a little ASCII map:

Key:
| = Decision
# = Situation (I'll lump all three kinds together.)
@ = End Solution

Linear (bad) Not-so-Linear (good)

# (both start with 1 beginning) #
| (The first decision is made) /|\
# (Things should begin to branch) # # #
| (Second decision) /| | |\
# (Note that not all second |'s branch) @ # # # #
| (Here, one collapses into another.) \| | |\
# (This was done to reduce the workload) # # # @
| (On the left could be any of some really /|\| |\
# bad games I've seen. Maybe Trinity on # # # # #
| the right.) /|\|\|/| |
@ (The last decision on the right was a @ @ @ @ @ @
really poor one, or a hard to do good one.)

There are early endings, which represent player death. (There would be
many more than that in an Infocom game.) Some different branches are just
multiple solutions to the same puzzle, so they collapse inward. Others open
up multiple puzzles or cause several things to occur. Finally, the player is
left with a number of different endings depending both on his current and
earlier decisions. You should definitely incorporate earlier decisions into
the endings because it adds a shade of realism to the game. Some will
definitely complain that they have to go back and try things differently, but
my response would be that if there are different solutions to the puzzles, it
will be like playing a new game, since you are not repeating your old actions
like in Infocom. Anyways, that's how I plan to work my games, multiple
solutions to one puzzle, areas accessible only through certain plot-paths,
and multiple endings to the game. Hasta.
--
<~~~~~E~~~G~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~>
< V R I O Software. We bring words to life! | ~~\ >
< T | /~\ | >
<_WATCH for Avalon in early '94!____wh...@uclink.berkeley.edu_|_\__/__>

[David Whitten]

I don't know the Netiquette of following up on our own posting, but I had
some more ideas so I figured I'd keep everything together...

David Whitten (whi...@netcom.com) wrote:

:Seeing the large number of posting about plotting, (and the excellent list

Directly related to the idea of the SITUATION someone is in is the question
of providing help.

It would be nice to provide HELP that is situation dependent, not just
generic to the game as a whole.

There is an analogy that HELP is very similiar to asking for the description
of the current SITUATION. Since many authoring tools have multiple levels
of description of ROOMS, storing the PLOTMAP as a real set of rooms (that
can't be reached from the rest of the MAP) means that writing HELP
degenerates to calling the LOOK verb on the SITUATION (room).

CLUES are OBJECTS in the SITUATION MAP. thus the command HINT ABOUT CAR
is asking about the description of the CLUE shadow of the CAR object in the
current SITUATION (PLOTMAP ROOM).

The essence of the PLOTMAP idea is that for the primary character, you have
a shadow object EGO which is moved around a set of rooms corresponding to
the different SITUATIONs that the player is in. Certain games may have a
set of puzzles that don't have an order of solving required. Thus you
may have more than one shadow EGO object (EGO-1,EGO-2...)

Current programming style includes the idea of a ROOM like NOWHERE to
store objects or actors that have not appeared in the game yet. These
can be stored in the SITUATION room when they become important to the game.

One change to a PLOT might be the SITUATION of UnlockingASafe. Rather than
having a single object BankSafe with an attribute or feature "locked" which
is True/False, and then a lot of code to check the attribute and then decide
what kind of response to give, you could have two objects LockedBankSafe
and UnlockedBankSafe and store the one that currently isn't in the game
in the SITUATION room. The code seems much simpler that way.

As a final note, I was struck by the similarity IF games have to Petri Nets.
Places are ROOMs , Tokens are OBJECTs, and Transitions are the code linking
Places & Time together...