Minor spoilers for: Adventure, Zork I, Wishbringer, Christminster
Moderate spoiler for: The Beetmonger's Journal
<P>
[FONT/] means begin fixed pitch font. This is used for pseudo-code.
[/FONT] returns to normal font.
<P>
Giving Your NPC a Life of His Own
by Brent VanFossen
brentvanfossen@hotmail.com
<P>
Pick up any novel and chances are good that it will center around a
character or group of characters, their activities, and what they
do. Stories are about people because people are interesting. Our lives
are full of people and so are our stories. Great characters drive a
story along: Homer's Ulysses and Shakespeare's Hamlet are
unforgettable. Our literature is full of fascinating supporting
characters as well: Defoe's _Robinson Crusoe_ had the good man Friday
to keep the shipwrecked sailor company, and Huckleberry Finn was such
a powerful character in Mark Twain's _Adventures of Tom Sawyer_ that
he later played the leading role in a book of his own. These
characters are memorable because they add something to the stories and
we relate to them in some way, motivating us to turn the page.
<P>
[[The first paragraph has a tendency towards redundancy; the
thesis presented here is obvious and well-recognized, so there
is no need to belabour it.]]
<P>
The IF tradition has been somewhat different. The original _Adventure_
by Crowther and Woods was a digital treasure hunt through the largely
uninhabited tunnels of a real-world cave. The dwarves and other
creatures that populate the game were quite literally an afterthought,
as were the puzzles, which were added later to bring the stark
landscape to life. Likewise _Zork I_, the Infocom classic, offered the
Great Underground Empire for the player to explore, but the troll and
the thief, and later on, the cyclops, are nearly unresponsive to the
player's attempts to converse with them, and they do little on their
own. In the parlance of writers, they are cardboard cutouts: simple
and single-purpose, unengaging, and shallow. They serve a purpose but
don't offer much in the way of depth.
<P>
Creating believable NPCs is hard. The author of a novel can plan and
write a scene that the reader will see once, then turn the page. The
characters come alive because the author has carefully crafted what we
see and hear, showing us the dramatic and essential bits while leaving
out all the extraneous details, until the effect is exactly right and
the characters live on in our imagination.
<P>
[[Should probably be clearer that the intended meaning here is
"Creating believable NPCs in IF is hard."  Characters in static
fiction are not normally referred to as NPCs, but I'd still prefer
some clarification.]]
<P>
In IF, the player is free to move and explore on his own. The very
nature of IF allows the player to return to locations again and again,
much as we do in real life. Unlike in real life where people have
minds of their own, the non-player characters that populate the
interactive landscape can only react the way the author has programmed
them to react. Thus, if an author has created a simple NPC who only
reacts to a single "correct" solution, that NPC will stand in the same
place for hundreds of moves while the player attempts to discover the
key that will advance the game.  The NPC in this case is little more
than a locked door, infinitely patient and equally lifeless, and
ultimately, not very interesting.
<P>
This is not always a bad thing; we encounter "single-purpose" people
every day in real life. The person we meet on the way to the mailbox
who nods at us, the girl chasing pigeons in the park, the gasoline
attendant who asks if he should check the oil in the car, the door
openers and ticket takers and grocery clerks of real life are all
people with their own lives and their own problems.  Their interests
are not known to us and we really only interact with them on the most
basic of levels. Their "How are you today?" is not really a question,
but a social courtesy.
<P>
In the opening scene of _Wishbringer_, the boss, Mr. Crisp, stands
behind the service counter of the Festeron Post Office reading other
people's postcards. As the player enters, Crisp tosses a mysterious
envelope onto the counter and snarls, "We just got this Special
Delivery. I want you to drop it off right away. That means NOW!
Deliver that envelope, chowderbrain! The Magick Shoppe closes at five
o'clock!" We immediately know that we have a task to complete, and so
the game has begun. Any question is met with Mr. Crisp screaming,
"You're here to take orders, not to ask questions!" If we dawdle, he
shoves the envelope into our hands and throws us out, locking the door
behind us. The red-faced Mr. Crisp will play a more significant role
later on, but in the opening scene, he is a simple NPC who serves a
simple purpose: to move us into the game.
<P>
Many NPCs, however, play a more complicated role in the story. Gus,
the harvest hand in _The Beetmonger's Journal_, sits in a rocking
chair on the front porch of the farmhouse, commenting on the weather
and talking to the PC. Later, the player character must return to
visit Gus again, bringing him a particular object, which Gus then uses
to fashion a toy for the PC. This is when Gus comes to life. He
changes from the passive, sit-on-the-porch farmhand into a
wood-whittling toymaker. The player watches with amazement as he
fashions a "whimmy diddle" from a piece of dry wood. No longer does
Gus simply respond to what the player character says or does, rather
he knows what to do and proceeds to make the toy, even if the PC just
stands and watches. The NPC follows the script the programmer/author
has written, and we, the players, forget we're reading words on a
computer screen and become entranced.
<P>
The prologue of _Christminster_ has a number of NPCs, from the old man
who guards the gate of the college, a simple NPC who does little more
than look through the gate and tell the PC that the college is closed
on Sundays, to the more complex busking magician who stands behind a
table on Bridge Street and exhorts passers-by to watch his tricks. The
magician has a full routine that involves asking the audience for a
small article, which he uses as the hidden object in a three-cups
shell game. If no one in the audience offers him an appropriate
object, he continues the trick by providing a marble of his own. His
magic routine is scripted, and he follows the script without prompting
from the player. He interacts with the police constable who patrols
the grounds around the college, responds to a few simple questions,
and is a very realistic and effective NPC. Like a real person, he has
activities he does whether anyone watches or not.
<P>

[[These three paragraphs are a bit rambling; offering examples of
NPCs at this point in the essay doesn't seem to be especially useful.
A clarification of what they are intended to illustrate may be sufficient.]]
<P>

When Should an NPC Have a Script?
<P>
NPCs that occupy a central position in a story, either central to the
plot or centrally located in the landscape of the game, are more
important to the player's experience and are good candidates for a
script. The shopkeeper in a small town's general store can be a
passive NPC if the player will visit only once to make a quick
purchase. If the shopkeeper, however, is known by the locals as the
most opinionated on matters of politics, aware of all the goings on
around town, and if people gather in his shop in the afternoons to
meet for a soda and gossip, then he takes on a special importance to
the game. When a character begins to take on a life of his own, when
his importance to the story demands that he be more than a just a
prop, it is the author's responsibility to assist that NPC by giving
him the freedom and independence to pursue his own goals.
<P>
[[Since 'scripting' has a special meaning as a programming term,
a bit more clarification might be useful.  The first sentence
is particularly clumsy.]]
<P>
This means that as the author, you have to know what those goals
are. Who is this shopkeeper that everyone in town wants to visit in
the afternoons? What is his name? Is he young or old? Is he married?
Maybe he gets his best information from his wife, the quiet little
woman who sits in the back room, says nothing but hears
everything. How long has he been married and how did he meet her?
Maybe his brother is a world-famous guitarist who holds free concerts
and workshops in front of the store whenever he passes through
town. Maybe he himself was a world-famous guitarist until he got tired
of touring, and now he just wants to tend the shop, leaving the life
of glitter behind. Maybe he makes his own ice cream, using fresh cream
and fruit from the local orchards, and it's the best to be had for
miles around. Did he build the shop himself, or did he take it over
from his parents when they died? Did they die of old age, or was it a
terrible accident down by the river? How did the accident affect him?
Does he walk with a limp? Why? What is his education? How is his
speech: meticulously correct or full of slang? Does he speak with a
foreign accent or a southern drawl? Maybe his father was or still is a
local politician, and that's why he likes to argue politics. Maybe he
plans to open a second store in the town 15 miles down the road, and
the county government is opposed because it would threaten the store
already there that is owned by the chairman of the building
committee. Maybe our shopkeeper is afraid of changes in the law that
will affect his business. Does he have a problem with creditors? Does
he extend credit to his customers, even the ones who he knows can't
afford to pay him back? What does he do in the evenings after the shop
is closed? Does he have a hobby?
<P>
[[This paragraph is overly-exhaustive and belaboured.  We get
the idea.]]
<P>
Keep a journal of the background story of your NPC and write the
answers to these questions and more so you can keep the details
consistent throughout the game. Not everything you write will appear
in the game, but you, the author, need to see your characters as real
people if you want your players to believe in them. This information
should never come out as a big narrative infodump. Rather, the
research and preparation will reveal itself slowly during the course
of play.
<P>
Write out a description of a typical "day in the life" of your
NPC. Our shopkeeper's day might include arriving at work in the
morning, putting out his wares, cleaning, leaving for lunch, receiving
new stock, making ice cream, discussing politics with the people in
the store, managing money at the end of the day, and going home for
the evening. Whether any or all of this is interesting or important to
the game will affect how much of it is included.
<P>
[[These two paragraphs would perhaps work better as a bulleted list
of 'ways to develop your NPCs'; writers can get a bit cranky when
these sort of instructions are offered as gospel.]]
<P>
Once you know who your NPC is, you can flesh out the details in your
descriptions and in the NPC's responses to the player's questions. You
also will be ready to begin writing the script that will guide your
NPC through the day.
<P>

Scripting a Life
<P>
Most of the IF languages have the ability to handle daemons, routines
that once turned on, run every turn. Using language-independent
pseudo-code, let's create a hypothetical NPC. The method described
here is the method I used to create Bob in my game, _She's Got a Thing
for a Spring_.
<P>
[[Here he's switched to the programming sense of the term 'script'.
It causes enough confusion that I'm not entirely happy with it.]]
<P>
Begin by dividing the NPC's day into locations and activities. Let's
call our shop owner Merle.  We'll use three activities for the sake of
example:
<P>
   1.  Arriving at the store in the morning and preparing for
          opening (7:30 to 8:00 am).
   2.  Opening and cleaning the shop (8:01 to 9:00 am).  
   3.  Making ice cream on the front porch (9:01 to 10:00 am).
<P>
Merle's script has three sections of code, one section for each
activity. We write each section as a separate subroutine, and we call
the appropriate subroutine from the daemon routine, depending on the
time of day. The time of day is controlled by a counter based on the
player's moves.
<P>
Let's say the game begins at 7:00 am and each turn lasts a minute of
game time. Your model may be much more complex. From 7:00 am until
7:29, the store is closed and Merle is nowhere to be seen. At 7:30
Merle begins his day by stepping out of his front door and walking to
the store. At 8 o'clock sharp, as is his custom, he unlocks the door
of the shop to the public. At 9 o'clock, we move him to the front
porch where we watch him making some of his locally famous ice cream.
<P>
We start by assuming that Merle's daemon is turned on and running when
the game begins.  We'll use the "!" as the comment character, and
anything following the exclamation mark is a comment and not part of
the pseudo-code. The daemon looks like this:
<P>
[FONT/]
NPC Merle
   ...
   counter 0                  ! The is Merle's main script
                              ! counter, which starts from zero.
   daemon [
      Merle.counter=Merle.counter+1     ! Increment each turn
<P>
      switch based on Merle.counter {
         1 to 29:    subroutine Merle0()
         30 to 60:   subroutine Merle1()
         61 to 120:  subroutine Merle2()
         121 to 180: subroutine Merle3()
         ...
      }
   ]
   ...
[/FONT]
<P>
We initially set the counter to zero, then increment it each
turn. Since each turn is assumed to take one minute, the counter value
of 0 corresponds to a time of 7:00 am. A counter value of 61
corresponds to a time of 8:01 am, and so on. We place our code in
Merle's daemon routine, but we keep the details in subroutines so as
not to clutter up the daemon. The counter could be a global variable,
but in this example, we have made it a property of the NPC Merle, so
it is listed as [FONT/] Merle.counter [/FONT] .
<P>
Let's write the subroutines:
<P>
[FONT/]
[  Merle0               ! 7:00 to 7:29 am
   return               ! Nothing happens before 7:30 am
]
<P>
[  Merle1               ! 7:30 to 8:00 am (Arriving at the Shop)
   subroutine Merle_Actions_1()
   subroutine Merle_Messages_1()
   return
]
<P>
[  Merle2               ! 8:01 to 9:00 am (Cleaning the Shop)
   subroutine Merle_Actions_2()
   subroutine Merle_Messages_2()
   return
]
<P>
[  Merle3               ! 9:01 to 10:00 am (Making Ice Cream)
   subroutine Merle_Actions_3()
   subroutine Merle_Messages_3()
   return
]
[/FONT]
<P>
In the first thirty minutes of game play, Merle does nothing. The
[FONT/] Merle0 [/FONT] routine is just a placeholder for anything we
would like to include that the player will see before Merle leaves his
house. This might include turning lights on or off in the house,
letting the dog out into the yard, and so on. For this example,
nothing happens, so the subroutine returns control to the daemon.
<P>
Next, in [FONT/] Merle1 [/FONT], we call two more subroutines. Since
Merle has his own life and is doing things whether the player is
watching or not, we need a way to keep his movements and any objects
that he changes separate from the routine that prints a message for
the player to read. If Merle picks the newspaper up from his sidewalk
on his way to work, the [FONT/] Merle_Actions_1 [/FONT] routine will
move the newspaper to Merle's inventory, and the [FONT/]
Merle_Messages_1 [/FONT] routine will tell the player what
happened. If the player is not present, Merle will still collect the
newspaper, but there will be no message to tell the player.  The only
thing the player will notice is that the next time he sees Merle, the
newspaper will be in his hands and not on the sidewalk in front of the
house. Keeping actions separate from messages will save us a lot of
effort. Let's look at Merle's Actions and Messages routines:
<P>
[FONT/]
[  Merle_Actions_1
   switch based on Merle.counter {
      30: turn off porch light on Merle's house
      31: open Merle's front door
      32: move Merle to porch of house
      33: close Merle's front door
      34: move newspaper to Merle's inventory
      35: move Merle to sidewalk
                                          ! Notice nothing
                                          ! happens here
      40: move Merle to porch of shop
      41: open door of shop
      42: move Merle inside shop
      43: close door of shop
      44: turn on lights in shop
                                          ! or here
      59: put "open" sign in window
      60: unlock shop door
   }
   return
]
<P>
[  Merle_Messages_1
   if (player can't see Merle) return
   switch based on Merle.counter {
      30: print "The porch light goes off."
      31: print "Merle opens the front door of his house."
      32: print "Merle steps out onto the porch."
      33: print "Merle closes the front door."
      34: print "Merle sees the morning newspaper and picks
             it up."
      35: print "Merle steps out onto the sidewalk."
      36: print "Merle walks along the street. You notice
             he favors his left leg."
      37: print "Merle stops walking, as if thinking of
             something."
      38: print "Merle looks backward toward his house."
      39: print "Merle glances at his newspaper, then
             continues walking."
      40: print "Merle steps onto the porch of his shop."
      41: print "Merle opens the door of the shop."
      42: print "Merle enters the general store."
      43: print "You hear a click as the door closes and locks."
      44: print "The lights inside the shop come on."
      ...
                                     ! Merle does something
                                     ! each turn, unless he's
                                     ! out of sight.
      ...
      59: print "The shutters of the shop open, and Merle hangs
             an 'Open - Please Come In' sign in the window."
      60: print "Merle opens the shop door wide, beginning
             the business day."
   }
   return
]
[/FONT]
<P>
The Actions and Messages routines for the other time periods are
similar. Notice that there is no movement in the [FONT/]
Merle_Actions_1 [/FONT] routine when the counter is between 36 and 39,
or between 45 and 58. That's because Merle is neither changing
locations nor moving any game objects. However, in the [FONT/]
Merle_Messages_1 [/FONT] routine, we tell the player something every
turn. You don't have to, of course, but real people are always doing
_something_. It's a good practice when you're scripting to tell the
player something each turn, unless the NPC is out of sight. Also,
notice the first line of the [FONT/] Merle_Messages_1 [/FONT]
routine. If the player is not in a position to see what Merle is
doing, we simply return control to the daemon routine and don't print
anything at all.
<P>
[[I'm a bit hesitant with whole preceeding block.  I suppose there
might be a part of the audience that would find this sort of
pseudo-code useful.  I'm inclined to think, however, that this sort
of coding is trivial to most people and not really within the scope
of a book on Theory.  A short and general summation of maintaining
state in an NPC and generating quasi-random statements would probably
be sufficient.]]
<P>

NPCs with Something Special to Say
<P>
NPCs can help move the player through the game by providing essential
information at the appropriate time. What if Merle has an important
message for the PC? If we put that message in his script, the player
could very easily miss it by being in another location when the
appointed time comes. We could drop hints so the player will ask, but
that kind of force-feeding is a bit awkward, especially when we have
crafted an NPC to pursue his own goals. Far better to write a short
piece of code that interrupts the script when the time is right and
when the PC is present.  The NPC will then seem naturally spontaneous,
and the plot will flow more freely.
<P>
As the owner of the local gathering place, Merle has access to all
kinds of information and gossip. Let's imagine that at some time in
the morning, Merle gets a visit from his good friend, the minister of
the local Methodist church. He has just been asked to publicize the
information that the traveling holy revival is in town and will begin
this Sunday morning; the special guest speaker will be none other than
the well-known and controversial Reverend Brandon Braden from
Mississippi. The revival tent for the expected 400-member congregation
is being pitched this afternoon on the banks of Lake McMurtry, and the
church is looking for volunteers to help with the setup. Maybe the PC
should go and see if there's a way to help out.
<P>
Why is this information important? It tells us that something
significant is about to happen, and that there is a way for the PC to
get involved. It sets the stage for a big public event, which opens
all kinds of possibilities for game and story design. It tells the
player that Rev. Braden is famous and in some way controversial, and
so it arouses our curiosity to find out why. It reinforces the
importance of Merle in the eyes of the player, and gives us a number
of topics we can use in our conversations with him. It is consistent
with the small-town feel of the game, and tells us that the story is
set in the American South. We can probably even conclude that Merle
speaks with a drawl.
<P>
[[All of the above is relatively useful; I'm not sure I see the
value in the following code, though.]]
<P>
To accomplish this, we need to write code to determine when is the
right time to give the player this information. Obviously, we need to
wait until the PC is in Merle's presence. Waiting until a few turns
after the PC arrives is probably more realistic than having Merle
speak immediately, unless, of course, the information is particularly
urgent. That means we'll need a small counter.  Then, instead of
running Merle's normal script, we interrupt it and insert our message
code. In our example, suppose Merle's message can come any time after
9:15 am. Merle will be on the porch making ice cream then, and his
counter will be greater than 135 (remember, that's 7:00 am plus 135
minutes). Merle's routine might look this:
<P>
[FONT/]
NPC Merle
   ...
   counter 0                  ! The is Merle's main script
                              ! counter, which starts from zero.
<P>
   special_message 0          ! This counter will tell the
                              ! daemon if it's time to give
                              ! the player the special message.
                              ! Counting starts from zero.
<P>
   special_message_seen 0     ! Has the player seen the message?
                              ! 0=No. 1=Yes.
   ...
<P>
   daemon [
      if (player can see Merle) and if (Merle.counter>135)
      and if (Merle.special_message_seen=0)
      {  Merle.special_message=Merle.special_message+1
      }                             ! We begin incrementing the
                                    ! special message counter,
                                    ! so Merle will wait a few
                                    ! turns before speaking.
<P>
      else Merle.special_message=0  ! If the player leaves
                                    ! before the counting is
                                    ! completed, we reset the
                                    ! counter to zero. When the
                                    ! player returns, we start
                                    ! counting again.
<P>
      if (Merle.special_message>2)
      {  subroutine Merle_Special_Message()
      }
      else
      {  Merle.counter=Merle.counter+1   ! Increment each turn
         switch based on Merle.counter {
            0 to 29:    subroutine Merle0()
            30 to 60:   subroutine Merle1()
            61 to 120:  subroutine Merle2()
            121 to 180: subroutine Merle3()
            ...
         }
      }
   ]
<P>
[  Merle_Special_Message
   Merle.special_message_seen=1     ! Only see the message once
   print "You know, I heard something just this morning that
      I think you'll find interesting. The holy revival has
      come to town! It's setting up down on the shores of
      Lake McMurtry..."
   return
]
[/FONT]
<P>
Notice that we don't increment Merle's counter during the time of the
special message. This guarantees that afterwards, the script will
continue and Merle won't miss a beat. Also, we have to set the [FONT/]
special_message_seen [/FONT] flag so the message doesn't repeat later
in the game.
<P>

NPCs Who Listen
<P>
The shopkeeper we have created is a great improvement over the passive
NPC who just stands and waits. Interactive fiction is about
interaction, however, and we can further improve our shopkeeper by
allowing him to be influenced by the player. In IF, the most common
ways of interacting with an NPC are fairly simple:
<P>
     Ask NPC about something
     Tell NPC about something
     Show something to NPC
     Give something to NPC
     Talk to NPC
     Do something to an NPC (kiss, attack, throw something at, etc.)
     Do something in the NPC's presence
<P>
There are undoubtably others. All demand that the NPC acknowledge the
player's presence and that he do something appropriate in response.
<P>
In real life, some people are constantly on the move. A perfect
example in my family is how my mother-in-law will begin a sentence in
one room of the house, and finish her thought from somewhere else,
sometimes within earshot, and sometimes not. My grandmother, at the
other extreme, would stop everything and listen whenever I would say
anything to her at all. In IF, we need to make allowances for such
traits and characteristics as we breathe life into our NPC's
code. That means that if our character is a listener, we need to be
able to make him stop and pay attention when the PC is trying to
interact with him.
<P>
Let's say Merle is a listener; this fits the way we have described
him, and for him to just give a quick response and then walk from a
room would be out of character. We have to find a way to interrupt the
script whenever the PC is trying to interact so that Merle can pay
full attention.
<P>
We define a new property called "listening", which is normally zero,
meaning that Merle is going about his business and following his
script. When the player interacts with Merle by _talking to_ Merle or
_showing something_ to him, for example, the routine that handles
these interactions sets [FONT/] Merle.listening [/FONT] to some
non-zero value. Then, at the beginning of Merle's daemon, the
interpreter checks the property. If it is zero, we continue with the
script as we did before. Otherwise, we skip the code that runs the
script. Merle doesn't do anything at all, effectively giving 100
percent of his attention to the player. Improving on this, we can set
[FONT/] Merle.listening [/FONT] to any value we choose, thus
controlling how long Merle will wait before continuing with his
script. Perhaps he should wait two turns. The player gets a chance to
say something else, and it will seem that not only is Merle listening,
but that he is waiting for the next question. The main Merle routine
now looks like this:
<P>
[FONT/]
NPC Merle
   ...
   counter 0                  ! The is Merle's main script
                              ! counter, which starts from zero.
<P>
   special_message 0          ! This counter will tell the
                              ! daemon if it's time to give
                              ! the player the special message.
                              ! Counting starts from zero.
<P>
   special_message_seen 0     ! Has the player seen the message?
                              ! 0=No. 1=Yes.
<P>
   listening 0                ! Normally, this is zero. "1" or
                              ! more means Merle is listening.
<P>
   ...
   interacting [              ! This is the routine that handles
                              ! Merle's responses.
<P>
      Merle.listening=2       ! Merle will pay attention
                              ! for two turns. If the player
                              ! continues to talk to Merle,
                              ! Merle.listening will be           
                              ! repeatedly set to 2.
<P>
      "Ask" responses         ! Merle's code to respond
      "Tell" responses        ! to the player's interactions.
      "Give" responses
      "Show" responses
      ...
   ]
   ...
   daemon [
      if (player can see Merle) and if (Merle.counter>135)
      and if (Merle.special_message_seen=0)
      {  Merle.special_message=Merle.special_message+1
      }                             ! We begin incrementing the
                                    ! special message counter,
                                    ! so Merle will wait a few
                                    ! turns before speaking.
<P>
      else Merle.special_message=0  ! If the player leaves
                                    ! before the counting is
                                    ! completed, we reset the
                                    ! counter to zero. When the
                                    ! player returns, we start
                                    ! counting again.
<P>
      if (Merle.listening=0)        ! If Merle is not listening,
      {                             ! continue with the script.
                                    ! Otherwise, skip this code
                                    ! and just listen.
<P>
         if (Merle.special_message>2)
         {  subroutine Merle_Special_Message()
         }
         else
         {  Merle.counter=Merle.counter+1   ! Increment each turn
            switch based on Merle.counter {
               0 to 29:    subroutine Merle0()
               30 to 60:   subroutine Merle1()
               61 to 120:  subroutine Merle2()
               121 to 180: subroutine Merle3()
               ...
            }
         }
      }
      else 
      {  if (Merle.listening=1) print "Merle waits patiently."
         Merle.listening=Merle.listening-1
      }
   ]
...
[/FONT]
<P>
If Merle is listening to the PC, we don't want to suddenly change the
subject, so we'll put our subroutine calls inside the braces that are
controlled by the "listening" check. We've also added a statement that
prints "Merle waits patiently" when Merle is waiting for the PC to say
something else.
<P>

The NPC Lives!
<P>
Merle is certainly much more interesting than we might have first
thought. He has a full biography with a family history, desires, and
goals of his own. In the course of creating Merle, we have come to
know quite a bit about him: how he walks, talks, acts, and
reacts. Merle has the freedom to move about following the script we
have written, and when he has something important to say, he will wait
for an appropriate time, then give us his special message. He will
stop and pay attention when the player wants to interact with him. He
is infinitely patient while the player is talking, but he will go on
about his business if we just watch him or if we go away.  More than
that, Merle is someone the townspeople like, and we have come to like
him as well. In my mind, Merle is a real person. It's not hard to
write about a real person; we simply have to imagine what that person
would do and put those words to paper.
<P>
So, the NPC lives. He has come to life through the clever arrangement
of some simple coding techniques. These techniques can be used with
any interactive fiction language that supports daemons and
subroutines. The methods here can be improved upon and made much more
complex. Treat your NPCs with care, as you would a good friend, and
they will come to life in your story, motivating your players to "turn
the page". Good luck with your NPCs.
<P>
===
<P>

Sidebar
<P>
Questions to Ask an NPC
<P>
Creating a believable NPC is more than just coding. Not only should he
act like a real person, but the depth of his character helps us to
understand him, and will bring him to life. To assist you in coming up
with the details you need to flesh out your NPC, here are some
questions you can use to interview your NPC. With your mind's ear,
listen to what your NPC tells you, and keep a journal of the questions
and answers. Refer to your notes as you progress with the development
of your game or story, and make sure the details stay consistent
throughout. Orson Scott Card's book "Characters and Viewpoint" may
also be helpful. Get inside your NPC's head and ask him:
<P>
Who are you?
Describe yourself.
Where and when were you born?
What are your parents like?
What was your childhood like?
Do you know your family tree?
Are you single, married, divorced, or widowed?
Do you have any children?
What kind of education do you have?
What do you do for a living?
Why do you have this job?
What are you most afraid of?
What makes you happy?
What makes you angry?
What is your personality type?
What do you dream about?
What do you daydream about?
What are your goals?
<P>

[[ As far as being a "How To" article, it mostly succeeds.  If
I were going to construct this sort of essay, I think I'd start
by discussing generally well-known character-building techniques
from static fiction, and then segue into some of the unique
demands of IF and how to deal with them.  I'm still not convinced
the pseudocode is particularly useful or illustrative. ]]