GAME DESIGN AT THE DRAWING BOARD - part 2

                       By C.E. Forman

Concluded from issue 80

Transcript

Anyone familiar with Infocom will likely understand what I mean by
a transcript. Basically, it's an example of what the game will
look like when it's being played. Transcripts include not only
what the game will print on the screen, but also the player's
commands that cause the various responses.

I only write a transcript when I'm having trouble getting the
story started, or if I need to visualize how a complex puzzle
should work. Like object and item specs, anything you write into a
transcript will mean less time spent coding later.


Puzzle Structure Chart

This is my own personal favorite design tool, but unfortunately
it's also the most difficult for me to describe in words. A puzzle
structure chart is much like a hierarchy diagram which lists the
necessary puzzles in an adventure game, from beginning to end, and
indicates what must be done before each puzzle can be solved.
Confused?  Maybe it'll become clearer if you look at the example
provided.  This is the complete puzzle structure chart for
Infocom's "Enchanter" (and just in case you overlooked the first
warning, the following diagram contains some really big-time
spoilers):

*** See the map in the screenshots section - Sue

Okay, let's start at the top of the chart and work downwards. At
the start of "Enchanter," there are really only three significant
tasks for the player to accomplish--opening the oven to find the
bread, filling the jug with water, and getting the REZROV spell.
The three separate paths leading off from "START" reflect this.

Note also that only one of these paths, finding the REZROV spell,
really opens the doorway to further adventure. Eating and drinking
are merely necessary to keep the player alive long enough to reach
the end. So the game starts out almost purely linear, requiring
players to find the spell, use it to enter the castle, and use the
FROTZ spell to create a light, before anything else can be
accomplished. Once the player gets past these first few minor
obstacles, however, the scope of the puzzles reaches its widest
point. The game is now quite non-linear, with seven distinct paths
that players are able to follow.

As an example, let's assume that the player's first task is to
open the jewelled egg and obtain the shredded ZIFMIA scroll
inside. Let us assume that the player then proceeds to cast the
REZROV spell on the castle's rusted north gate in order to gain
access to the forest beyond, where the scroll inscribed with the
KREBF spell is located. The player now has the KREBF spell and the
shredded ZIFMIA scroll itself, both of which are necessary in
order for the shredded scroll to be fixed. So the two initially
separate paths merge into one, and the KREBF spell can now be used
to obtain the ZIFMIA spell, which in turn can be used to summon
the wandering adventurer.

In a puzzle structure chart of this nature, when a path splits
into two or more separate pathways, this indicates that there is
more than one puzzle for the player to solve at that particular
point in the game. When two (or more) paths merge into one,
however, it indicates that both paths must be completely traversed
before the player can continue. You couldn't obtain the ZIFMIA
spell without the KREBF spell, nor could you get ZIFMIA if you
didn't have the shredded scroll on which it is written in the
first place. The puzzles leading up to the acquisition of both
items must be solved before the two items can be used together to
solve a third puzzle.

And what about optional puzzles, and puzzles with more than one
solution? Well, to keep the above example less cluttered, I didn't
include the CLEESH spell, since it isn't essential to victory. I
did make a note that it could be used in place of VAXUM when
confronting the shape in the endgame. The discovery of the CLEESH
spell could have been inserted on a separate path branching off of
the path in which the player enters the forest and finds the KREBF
scroll, and later tied into the endgame.

With a puzzle structure chart, however, neither of these are
absolutely necessary. A puzzle structure chart allows the designer
to explore a game's linearity, to determine if it's too rigid or
too vast and overwhelming. It lets a designer see if changes in
the arrangement of the game's puzzles need to be made, and if so,
where.  Puzzle structure charts also eliminate circular logic in
puzzles, that is, puzzle A needing an item that can only be
obtained by solving puzzle B, which in turn can only be solved
with an item from puzzle A.  If such a situation exists, it will
reveal itself in a puzzle structure chart.

The last important step involves deciding which techniques to use
in combination with each other. It's really up to your own
personal preference. I prefer puzzle structure charts, combined
with a concise scoring list, when I'm designing on paper. As the
game begins to take shape, I like to sit down and type out
specifications for objects, items, and characters. And, of course,
a good map is always put to use.
















                              - o -