% $Header: c:/tads/doc/RCS/tadsbeg.tex 1.1 92/11/13 16:45:52 mroberts Exp $
%
% TADS documentation:  Basic TADS Game Writing
%
% Copyright (c) 1989 by Michael J. Roberts.  All Rights Reserved.
%

\chapterheader{Chapter Six}{Getting Started with TADS}{6}

The previous chapters have covered a lot of ground:  the language,
the parser interface, and even the general principles of object-oriented
programming.  Because TADS provides such a rich set of options, it's
often difficult when you're first getting started with TADS to figure
out the best way to do something.

This chapter is intended to help you through the process of writing
a game with TADS.  We'll assume that you have a basic idea of how the
TADS language works.\bull


\chapterbody

\majorsection{Designing and Implementing}

^^{game design}
^^{designing a game}
Your author has been involved in the design and implementation of
several text adventure games.  The game development process presented
here reflects the experience gained from those projects.

The first step is designing the game.  Using a system like TADS, which
makes it very easy to get started with a game, you may be tempted to
jump right in and start programming your game, but you should instead turn
off your computer and get out a pad of paper.

We did not follow this advice with {\it Deep Space Drifter}.  After
formulating the basic plot of the game, and mapping out the portion
that takes place on the space station (roughly the first half of the
game), we started implementation.  We had a basic idea of the second
half of the game, but it wasn't even mapped.

Implementation went well for a while, but as we got further along,
we started to run into details in the first half of the game that
were dependent upon details from the undesigned second half.  We
improvised some details, and left others for later.  As we did
this, a strange thing happened:  we started to realize that there
were holes in the plot, and weird little inconsistencies that hadn't
occurred to us until we needed to think about details.  As a result,
we started to change our basic ideas about the second half, which
led to even more inconsistencies and plot holes.  It was like
digging in sand, and before long we decided to throw out the entire
original plan for the second half and start over.

However, we had so much time and effort invested in the space station
that we didn't want to throw it away.  Instead, we tried to design
a new second half that fit in with the existing first half.  From
this point on, the battle was lost.  We went through a series of
essentially unrelated plots for the game, trying to fit each new
plot to an even larger set of existing implementation.  We'd
plan a little, implement it, then discover that the plan wasn't
working and would have to go---but the programming work we did
would have to stay.  The swamp,
the cave maze, and the shuttle represented so much work that we couldn't
contemplate throwing them away, so whatever we came up with had to
include them somehow; for a brief time, we were actually going to
make the swamp a ``Swamp Simulator'' because it was the only way
we could make it fit.

In the end, we were totally sick of writing {\it Deep Space Drifter},
but refused to let the project die before it was complete for
psychological reasons.  To me, this attitude shows through in
the last half of the game; I think there's a room on the planet
whose description is something like this:  ``This room is very
boring; you can leave to the north.''  In fact, I think the entire
game reflects its history:  the space station is full of things to
do, it has some nice running jokes, and it's stylistically consistent.
The planet, on the other hand, has an empty, barren feel; it's
spread out and there's not much to do.  The only parts that are
interesting are essentially unrelated to each other and to the
story in general, a reflection of having been forced into the
game whether they belonged or not.

I'm not saying that {\it Deep Space Drifter} is a bad game---I like
the space station a lot, and the puzzles on the planet are very
elaborate and elegant.  But the game has some serious flaws, most
of which I attribute to the long, chaotic process of design and
implementation.

{\it Ditch Day Drifter}, on the other hand, went through a much shorter and
smoother design and implementation process, and I think a better game
resulted.  Admittedly, {\it Ditch} is a much smaller game than {\it Deep},
but it's clear to me that the same design process could have been
applied {\it Deep}, and that doing so would have resulted in a much
better game.

Before any programming work started on {\it Ditch}, I had a complete
map of the game and descriptions of all the objects and chracters in
the game, including the key elements of their behavior.  This made
implementation very smooth and easy, because I could simply go through
the lists of rooms and objects and implement each.  I didn't have to
make any design decisions during implementation, which eliminated the
desire to change design decisions that had already been made.  The
game took only a few weeks to implement, and came out fairly well.

If you resist the
temptation to start programming before the design is complete, your
game's implementation will go much faster, the game will turn out
much better, and most importantly, the chances that you complete your
game will be much higher.


\majorsection{Designing a Game}

Before you start implementing your game, you should have a list
of all of the locations, objects, and characters in the game.  For
each location, object, and character in the game (to which we'll
refer collectively as ``game elements'' henceforth), you should
have a description of the item and its key behavior.  Basically,
you should know enough about your game that you can go through
the game and play it completely through, command by command.
You don't need to know {\it all} of the details of the game
at this point, but you should know all of the details along the
``minimal path'' through the game (the series of commands that
a player would type to go through the game from start to finish,
if no mistakes are made and the player never needs to back up).
The remaining details do not affect the plot, so you will be
able to make these up as you go without creating plot holes or
inconsistencies.

The complete ^{map} and object list is the {\it result} of the
design process.  To get there, you will probably go through
many steps, adding detail as you go, until you have a complete
design.  The process detailed here is a good way to design a
game, but you may find other ways that suit you better.

\minorsection{Plot}

Most adventure games have a basic ^{plot} framework that controls the
overall flow of the game.  The plot is a good place to start your
design.

An adventure game's plot isn't usually as elaborate as the plot
of a non-interactive form of fiction, such as a book or a movie,
because you have much less control over the details of the
main character's actions.  This makes plot design much more difficult,
but you should give the player as much control as you can, since
adventure games are always more satisfying when they give players
a greater sense of control.  Adventure game plots, therefore,
should simply be a framework that provides the general direction
of action in the game, and specifies only the important events.


^^{goal (of a game)}
^^{puzzles}
You should start off with a basic background and goal.  Where
does the game take place?  When?  Who is the main character?
What must be accomplished by the time the game is over?

For example, in {\it Ditch Day Drifter}, the location is the Caltech campus
(or perhaps Caltech in some parallel universe, since the game
isn't a strictly accurate simulation of the real Caltech), and the
time is the present, generally, and Ditch Day, in particular.  The
main character is a Caltech underclassman.  The goal is to solve
the Ditch Day ``stack'' that the senior across the hall has created.

You can continue by identifying the major sub-goals that must be reached
in order to reach the overall goal of the game.  In {\it Ditch},
the major sub-goals are to find each treasure listed in the note
that describes the stack.

Filling in the details of the plot can proceed by ``working
backwards'' from the overall goal to the major sub-goals, then
backwards to the smaller goals that must be reached for each
sub-goal, and so on.

I would advise against designing a game with major sub-goals such as
``the player must find the five rings of power.''  When the sub-goals
are abstract like this, they don't suggest anything about what you
might need to do to accomplish them.  On the other hand, if a sub-goal
is something concrete and specific like ``the player must destroy
the radio broadcasting
tower,'' the minor sub-goals come almost automatically:  you need to
break into the compound where the broadcasting tower is located, and
you'll need some sort of explosive, and you may need to turn off
power to the tower to avoid being electrocuted.  But if you can
turn off the power, why do you need to blow it up?  Maybe because
an attendant will come and turn the power back on after a few turns.
Now we have another puzzle:  dealing with the attendant.  Sub-goals
that are abstract, such as finding five rings of power, aren't nearly
as helpful in getting to the next level of detail.  Concrete
sub-goals can often provide a seed that your imagination can
almost automatically expand into a full set of plot elements.


\minorsection{Setting}

^^{setting (of a game)}
The basic plot will provide an overall setting for the game, and
the plot elements will usually suggest a specific set of large-scale
locations.  So, you'll start off with a ``low-resolution'' map
simply by designing the basic plot.

Next, you can start filling in the specific rooms.  At this point,
you'll probably find that you start to fill in the details of the
plot at the same time as you're filling in the details of the setting.
Many locations in the setting will offer natural puzzles:  if you
have a bank, you'll probably have a safe, for which you'll need
to find the combination; maybe you'll need to figure out how to
defeat the alarm system, or perhaps you'll need something to
distract the teller; maybe you'll need to find the key to the safety
deposit box.  If you have an airport, you'll probably need to figure
out how to get past the overly sensitive metal detectors, or you'll
need to know someone's itinerary, or you'll need to find some airline
tickets, or you'll need to find a badge or key or combination to get
into a restricted area.

Whatever type of location you're designing,
the location will often suggest a series of puzzles to be solved.
As you design the solutions to the puzzles, you'll be adding detail
to the plot, which will in turn give you new locations to develop.

As you flesh out the setting, you may be tempted to add enormous
amounts of space to your locations.  For example, if you're building
an airport, you may find yourself putting in dozens of gates, each
pretty much the same as all the others.  While the added space may
make the game setting more like a real airport, it can often harm
the game's playability.  Remember, you're designing a game, not an
airport---the most important thing is making the game fun to play,
not ``real.''

The main problem with adding lots of essentially unused space to
a game is that it tends to make the level of detail throughout the
game less consistent.  You should make an effort to keep the level
of detail as consistent as possible throughout the game, to avoid
annoying and confusing the player.  If you have a few rooms with
a great deal of detail (such as lots of objects that can be
examined and manipulated), the player will come to expect that
level of detail in other rooms.  The dozens of almost identical
airport gates will not have anything interesting to do.

\minorsection{Objects and Characters}

^^{non-player characters}
^^{actors}
^^{characters (non-player)}
You'll probably end up designing most of the game in the course
of mapping out the setting and plot.  As you develop plot elements,
you should make notes of the objects and characters that are involved.
You'll probably find it easiest to note objects and characters
on the map, where they'll be placed.

For each object and character, you should make notes about its
relevance to the game, and what it does.  You should think carefully
about what other objects might be used for the same purpose, and what
other uses an object might have.  For example, if you have a door that
you need to break down, and you intend to provide an axe for this
purpose, you should consider two things:  What else might the axe
reasonably be expected to destory?  And what else might reasonably
be expected to be able to break down the door?

Because a player could reasonably expect an axe to have many uses,
and because many objects should be able to break down a door, you
should be very careful about creating puzzles that
involve brute force and powerful tools of general utility.  Explosives,
flammable liquids, weapons, and heavy tools are all likely to
frustrate the player when they don't remove just about any
physical obstacle.  On
the other hand, it would be very satisfying if you took the trouble
to fully realize the axe and the door by allowing the axe to break
down everything that's reasonable, and allowing the door to be
broken down by other reasonable objects.

\majorsection{Implementation}

Once you have the game fully designed, you're ready to start
implementing.  In this section, we'll show how to implement
the basic types of objects.

Start off by drawing the map, and making annotations on the map
describing the essential details of the plot.  This should include
placement of the major objects in the game, and descriptions of the
important actions the player must perform.

As an example, we'll implement a game that takes place in a small airport.
Our airport will have a terminal area, a concourse, and a gate area.
We'll also have a plane parked at one of the gates.  The terminal area
will have a ticket counter, and a metal detector leading into the concourse.
In the concourse, there will be a snack bar, and a locked door leading off
into a security area.  The gate area will have a couple of gates, plus
a locked maintenance room.  Here's the basic map we'll be implementing.

% go to a new page for the map
\vfill\eject
\null\vskip 4.25in

This map conveniently has a couple of locked areas, which we can use
for puzzles.  In addition, we can probably find some use for the metal
detector, since it will prevent the player from carrying any objects
through it.  The plane can also be a puzzle, since you'd normally need
a ticket to board a plane.  Plus, the cockpit should be restricted to
airline personnel.

Let's make the goal of the airport segment be getting out of the airport.
The player will start off in the main terminal area, but won't be able
to go outside the terminal---we'll make up some excuse, such as heavy
traffic that always pushes the player back into the terminal, to
prevent exiting that way.  (If this were an actual game, we'd probably
have more game outside the airport, so we wouldn't use such an
artificial boundary as having heavy traffic that pushes the player
back in.  For this example, though, we want to keep things fairly
small.)  The only other obvious way to get out of the airport is
to fly out on a plane; so, let's make the goal be to fly the plane.

To take the plane out of the airport, the player will have to get
into the cockpit.  (We'll implement this example up to the point
that the player makes it into the cockpit; in a full game, we'd
go on to let the player fly the plane somewhere else.)  Now, only
the pilot can go into the cockpit---the flight attendant wouldn't
let a passenger into the cockpit.  So, we'll need some way to
get past the flight attendant.  One way would be to create a
diversion that distracts the flight attendant long enough to
slip by; for this example, though, we'll require the player to
find a pilot's uniform.

Where would the pilot's uniform be?  The pilot's lounge would
be a logical place; we'll put a suitcase in the pilot's lounge
that contains a uniform.  Fortunately, the lounge is behind a
locked door, which creates a secondary puzzle.  To get into the
security area that contains the pilot's lounge, the player needs
a magnetic ID card to put into a slot outside the security area.

We'll put the ID card out in the open, on the ticket counter in
the terminal area.  However, we'll make it impossible to carry the
ID card past the metal detector---the card will set off the metal
detector, and the security guard will confiscate it (and place it
back on the counter so that the player can try again).  To get
the card by the metal detector, you'll have to turn off the
power to the metal detector.

The power switch will be in the maintenance room, which is locked
with a key.  We'll leave the key with some other maintenance items
in the plane's bathroom---we'll also leave a pail, sponge, and
garbage bag, so that it's clear by association that the key is
probably for the maintenance room.

To get into the plane's bathroom, you'll need a ticket to board
the plane.  We'll make the ticket fairly simple to find:  we'll
leave it hidden inside a newspaper in the snack bar.  As soon
as you pick up the newspaper, the ticket will fall out.

So, that's about the whole game:  you go to the snack bar, pick
up the newspaper, and find the ticket.  You take the ticket and
board the plane, then go to the plane's bathroom and get the
key.  Take the key to the maintenance room, unlock the door,
enter, and turn off the power to the metal detector.  Go back
to the ticket counter, pick up the ID card, go to the security
door, put the magnetic card in the slot, and enter the security
area.  Go to the pilot's lounge, get the pilot's uniform out of
the suitcase, and wear it.  Go to the plane, and stroll right
past the flight attendant and into the cockpit.

We should draw a new map now, which includes annotations for
the main objects and actions that make up the game.

\vfill\eject\null\vskip 4.5in

\minorsection{Implementing the Map}

The first step is to convert the skeleton of your map into the
beginnings of your game program.  At this point, don't worry about
entering all of the detailed behavior of your map, but just build
the basic rooms and connections between rooms.  This will allow
you to get a prototype of the game running quickly, so you can
walk around it and see how it feels.

Start off by creating a source file
for your game, and including the base definition files:

{\example
\#include <adv.t>
\#include <std.t>
}

^^{rooms}
Now, for each room in your game, make an entry that gives the room's
name ({\tt sdesc}, or short description) and long description ({\tt ldesc}),
and the other rooms that are connected to this room.  Here's how to
implement the first few rooms from the sample map above.  For the
time being, we won't worry too much about making the long descriptions
complete; we can always flesh those out later.

{\example
\object{terminal: room}
sdesc = "Terminal"
ldesc = "You are in the airport's main terminal.  To the east,
you see some ticket counters; to the north is the main concourse."
east = ticketCounter
north = securityGate
\endobj

\object{ticketCounter: room}
sdesc = "Ticket Counter"
ldesc = "You are in the ticket counter area.  Ticket counters
line the north wall; so many people are waiting in line that
you're sure you'll never manage to get to an agent.  The main
terminal is back to the west."
west = terminal
\endobj

\object{securityGate: room}
sdesc = "Security Gate"
ldesc = "You are at the security gate leading into the main
concourse and boarding gate areas.  The concourse lies
to the north, through a metal detector.  The terminal is
back to the south."
north = concourse
south = terminal
\endobj

\object{concourse: room}
    sdesc = "Concourse"
    ldesc = "You are in a long hallway connecting the terminal
    buliding (which lies to the south) to the boarding gates (which
    are to the north).  To the east is a snack bar, and a door leads
    west.  Next to the door on the west in a small slot that looks
    like it accepts magnetic ID cards to operate the door lock."
    north = gateArea
    south = securityGate
    east = snackBar
    west = securityArea
\endobj
}

The other rooms are implemented in the same manner.  For now,
we're not worrying about the items contained in the rooms, or
the other people around, or even the locked doors.  We'll just
implement all the rooms so we can walk through the map and
try it out.

\minorsection{Implementing the items}

The next step is to implement the basic objects that make up the
game.  As with the rooms, don't worry about the complex behavior
of some of the objects at this point; just go through and write
basic object definitions for the main items in the game.

^^{items}
Items have different properties than rooms.  The basic properties
of an item are its name ({\tt sdesc}), long description ({\tt ldesc}),
vocabulary words ({\tt noun} and possibly {\tt adjective}), and
container ({\tt location}, which may be either a room or another
item).  If the item can be carried by the player, the object will
be of class {\tt item}; if not, it will be of class {\tt fixeditem}.
Some items may be of different classes; for example, if you want
to make an object that can contain other objects (such as the pail),
make it a {\tt container}.  If you want to be able to put objects
on top of another object, use a {\tt surface} object.
You can make something both a {\tt container} or {\tt surface} and
a {\tt fixeditem} if you want.

Here are some of the basic object definitions for our sample game.

{\example
\object{counter: fixeditem, surface}
    location = ticketCounter
    noun = 'counter'
    adjective = 'ticket'
    sdesc = "ticket counter"
\endobj

\object{IDcard: item}
    location = counter
    noun = 'card'
    adjective = 'id' 'identification'
    sdesc = "ID card"
    adesc = "an ID card"
\endobj

\object{newspaper: readable}
    location = snackBar
    noun = 'newspaper' 'paper'
    adjective = 'news'
    sdesc = "newspaper"
    ldesc = "It's today's copy of USA YESTERDAY."
    readdesc = "You read a few articles, and promptly become
    depressed.  The federal deficit just went up by another
    twenty billion dollars, but it's all \char`\\"off budget,\char`\\"
    so it doesn't really count.  There's another White House scandal
    involving illegal arms sales, money laundering through Italian banks,
    Congressional Pages; several high-ranking federal arts critics have
    already resigned in disgrace.  The economy had yet another downturn,
    but the President says he's confident that the recovery is \char`\\"just
    around the corner and picking up steam.\char`\\""
\endobj

\object{cardslot: fixeditem}
    location = concourse
    noun = 'slot'
    adjective = 'card'
    sdesc = "card slot"
    ldesc = "The slot appears to accept special ID cards with
    magnetic encoding.  If you had an appropriate ID card, you could
    put it in the slot to open the door."
\endobj

\object{suitcase: openable}
    isopen = nil
    location = pilotsLounge
    noun = 'suitcase'
    sdesc = "suitcase"
\endobj

\object{uniform: clothingItem}
    location = suitcase
    noun = 'uniform'
    adjective = 'pilot' 'pilot\char`\\'s'
    sdesc = "pilot's uniform"
    ldesc = "It's a uniform for an Untied Airlines pilot.  It's
    a little large for you, but you could probably wear it."
\endobj
}

The rest of the objects are implemented in much the same way.  In
implementing the basic objects, the main properties you need to
fill in are {\tt location}, so the object appears somewhere in
the game; {\tt noun}, so the player can refer to the object; and
{\tt sdesc}, so the system knows what to call the object when it
mentions the object in messages.  It's also important to choose
the appropriate class for each item, so that you can get the
correct basic behavior of the object without any additional work.
At some point, you should go through {\tt adv.t} and familiarize
yourself with the classes defined there, so you know what you
can get from {\tt adv.t} classes without any work.  See Appendix A
for full details on {\tt adv.t}.

\minorsection{Implementing Special Behavior}

The next step is to implement all of the special behavior that
really makes the game work.  For example, let's implement the
simple mechanism that lets the player find the airline ticket
upon picking up the newspaper.  To do this, all we need to do
is add a {\tt doTake} method to the {\tt newspaper} object (we'll
just show the new {\tt doTake} method below; the rest of the
object is the same as shown above):

{\example
doTake(actor) =
\lb
    if (not self.foundTicket)
    \lb
        "As you pick up the paper, an airline ticket that was
        inside falls to the floor.";
        ticket.moveInto(actor.location);
        self.foundTicket := true;
    \rb
    pass doTake;
\rb
}

This method runs whenever the player takes the newspaper.  The
first thing we do is check to make sure that the airline ticket
hasn't already been found; if not, we display a message that it's
been found, move the ticket into the game, and note that it's been
found.  Finally, we continue with the default {\tt doTake} action
that the {\tt newspaper} object inherited from its superclass
(in this case, {\tt readable}) by using the {\tt pass} statement.

Note that the airline ticket itself should be defined with no
location, because it's not anywhere at all when the game first
starts:

{\example
\object{ticket: item}
    noun = 'ticket'
    adjective = 'airline'
    sdesc = "airline ticket"
    ldesc = "It's a one-way ticket to New York, in class C
    (the \char`\\"C\char`\\" probably stands for \char`\\"Cattle\char`\\")."
\endobj
}

As another example, let's implement the
puzzle the keeps the player out of the security area until the ID
card is used to unlock the door.  First, we must prevent movement
from the concourse into the security area.  For this, we'll change
the concourse room definition, and add a door object.

{\example
\object{concourse: room}
    sdesc = "Concourse"
    ldesc = "You are in a long hallway connecting the terminal
    building (which lies to the south) to the boarding gates (which
    are to the north).  To the east is a snack bar, and a door leads
    west.  Next to the door on the west is a small slot that looks
    like it accepts magnetic ID cards to operate the door lock."
    north = gateArea
    south = securityGate
    east = snackBar
    west =
    \lb
        if (securityDoor.isopen) return(securityArea);
        else
        \lb
            "The door is closed and locked.";
            return(nil);
        \rb
    \rb
\endobj

\object{securityDoor: fixeditem}
    location = concourse
    noun = 'door'
    sdesc = "door"
    isopen = nil
    ldesc =
    \lb
        "The door has a label reading SECURITY AREA--AUTHORIZED
        PERSONNEL ONLY. ";
        if (self.isopen) "The door is open, which isn't very secure.";
        else "The door is securely closed.";
    \rb
    verDoOpen(actor) =
    \lb
        "The door is securely locked.";
    \rb
    verDoUnlock(actor) =
    \lb
        "You should examine the slot if you want to unlock the door.";
    \rb
\endobj
}

The door is really just a decoration item; the various methods we
implement are just to inform the user that the door can't be operated
directly.  The real work is done by the card slot; we'll add some
new behavior to that object now.

{\example
\object{cardslot: fixeditem}
    location = concourse
    noun = 'slot'
    adjective = 'card'
    sdesc = "card slot"
    ldesc = "The slot appears to accept special ID cards with
    magnetic encoding.  If you had an appropriate ID card, you could
    put it in the slot to open the door."
    verIoPutIn(actor) =
    \lb
    \rb
    ioPutIn(actor, dobj) =
    \lb
        if (dobj = IDcard)
        \lb
            if (securityDoor.isopen)
            \invislb
                "You put the card in the slot; nothing happens,
                so you remove it.";
            \invisrb
            else
            \lb
            	"You put the card in the slot.  There's a click, and
                the security door pops open!  You remove the card.";
                securityDoor.isopen := true;
            \rb
        \rb
        else
        \invislb
            "That doesn't seem to fit in the slot.";
        \invisrb
    \rb
\endobj
}

The new behavior is that the player can put the ID card in the slot.
When this is done, the {\tt ioPutIn} method runs, with the ID card
as the direct object (the {\tt dobj} parameter).  This method opens
the door, if it's not already open.

Most of the remaining puzzles in this sample game are implemented
in a similar fashion.  You'll need to implement a couple of actors:
one for the flight attendant, and one for the guard at the metal
detector.  In addition, you'll need a few more locked doors and
special items.

We won't go any further into the other puzzles,
because the next chapter describes in much greater detail how
to implement these and much more.

\majorsection{Where to go from here}

Before expanding this sample game by adding more areas, you could
flesh out the game by adding lots of detail to what we've
implemented so far.  Most of the added material would probably be
irrelevant to the plot, but it could make the game more interesting and
more fun to play.  Keep in mind that you're writing a game, not
a real-world simulator; try to concentrate on things that make the game
more fun to play.

Some items that would enhance the airport:  Add lots of incredibly
overpriced and extremely dubious snack items at the snack bar.  Generate
random messages over the public address system once in a while, asking
various people to pick up the white courtesy telephone and warning
travellers not to park in the red zone.  Implement other effects for
other power switches in the maintenance room:  what happens when you
turn off power to the snack bar, or the ticket counter, or the PA
system, or the automatic doors?  Add lots of strange people milling
about in the airport; make some of them actively bother the player,
such as various fringe religious and political groups trying to hand
out literature (you'll want to write some wacky literature for them
to distribute).

Alternatively, you could expand this game by providing some place to
fly to.  The player could go on to crash the plane into a remote
mountain or desert island, and explore that.  Or, you could take
the plane to several other cities and explore.

Of course, you'll probably have the most fun if you start with
your own ideas and write a whole new game.  The hard part is always
finding the right idea; once you have the premise for your game, you
will probably be surprised at how quickly you can build a map and
start implementing.  Refer to the examples in this chapter to help
you get started.  As your game starts to take shape, and you want
to add more ambitious features, the examples of advanced TADS
programming techniques shown in the next chapter should be helpful.

\endchapter

In creating, the only hard thing's to begin; a grass-blade's
no easier to make than an oak.
\author JAMES RUSSELL LOWELL, {\sl A Fable for Critics\/} (1848)

\eject

