Chapter 9: Non-player characters

Animated non-player characters (NPCs) can really make the game world come alive. In their simplest form, NPCs are just ordinary objects whose antics are narrated spontaneously from time to time:

A slightly more sophisticated NPC might interact with other objects in the room, such as the player's possessions:

The library predicate (randomly select $Element from $List) picks a random element from a given list, or fails if the list is empty.

Movement

The library provides a predicate called (let $NPC go $Direction), to allow NPCs to roam the game world.

Here's a character who moves around on a fixed schedule:

The caller of (let $ go $)—typically an (on every tick) rule, as above—is responsible for supplying a direction that corresponds to a valid exit.

It is instructive to look at the library code for (let $ go $):

The predicate ($ is in room $) traverses the object tree, via ($ has parent $) links, from a given object all the way to its enclosing room.

The predicate (from $ go $ to room $) consults the story-supplied tables of obvious exits and doors, (from $ go $ to $) and (from $ through $ to $), to find out what room lies in a particular direction. It is also possible to query this predicate “backwards” with a given originating room and neighbouring room, to obtain the direction.

The library provides default implementations of (narrate $ leaving $ $ to $) and (narrate $ entering $ from $), deliberately bland, which the story author may wish to override for flavour.

Note in particular the queries to (player can see $). That predicate also comes in handy when writing story code that's dealing with moving NPCs, because we generally only want to describe their actions when they're in the same room as the player:

Random movement

Here is an example of an NPC moving randomly through the game world:

But in the above example, the rover might easily go back and forth between neighbouring rooms several times in a row. To avoid that, we can refine the code with a global variable that keeps track of the last direction of movement—or rather its opposite:

To populate the game world with several identical rovers, we'd have to animate each one of them. In that case, it would make sense to use a per-object variable instead of a global variable:

Moving towards an object

Using the path-finder from the standard library, it's straightforward to create an NPC that moves towards another object, such as the player character:

Other NPC actions

In the previous section, we saw that (let $ go $) can be used to move non-player characters around, and that it makes queries to (narrate $ leaving $ $ to $) and (narrate $ entering $ from $).

The following predicates are also provided:

All of these let-predicates have the same internal structure: First they check whether the player can see the action, and query the narration predicate if so. Then they update the world model, which often boils down to a single (now) statement.

In other words, these predicates are quite simplistic. They can work as a foundation for more sophisticated story-specific rules, or as a template for rapid prototyping of game ideas. But it is also possible to sidestep them entirely, and do everything from within the (on every tick) rules.

Note in particular that these predicates do not check whether the requested NPC action is possible; that is the responsibility of the story author. If you let an NPC pick up the moon, they will happily go ahead and do so, even if it's in a different room and not an item.

Taking orders

The parser understands e.g. TELL BOB TO GO EAST as well as BOB, E as the action [tell #bob to go #east]. That is, [tell $NPC to | $Action]—a list of the word tell, the NPC object, the word to, followed by whatever elements make up the requested action.

By default, NPCs refuse all such requests. Obedience is enabled on a case-by-case basis, by overriding action-handling predicates as usual. We can make use of the let-predicates of the previous section, but remember that we have to ensure that the action is possible. Thus:

If there is no exit in the given direction, (from $ go $ to room $) fails, and the perform rule falls back on the default rule provided by the library, wherein Bob refuses.

The above is sufficient in a game where Bob is free to roam the map using obvious exits. But if Bob is e.g. locked up in a cage at some point, the rules have to take that into account. Thus, for instance:

Ask and tell

The library provides a set of standard actions for communicating with NPCs. These include the classical “ask x about y” and “tell x about y” actions, which redirect by default via “talk to x about y” to a simple “talk to x”.

The story author deals with the [talk to $] action as with any other; namely by overriding the default action-handling predicates. For instance:

The ASK and TELL verbs redirect to a common TALK TO action by default, but they can be overridden with more specific responses. However, modern players may expect games to treat ASK, TELL, and TALK TO as synonyms.

In the above example, ASK LIBRARIAN ABOUT BOOK only works if both the librarian and the the book are in scope. Otherwise, the game will print a generic “I don't understand” message.

But in text adventures—and real life—people often want to talk about things that are outside the current room. The library provides a mechanism for this: Objects with the trait (topic $) will always be recognized as valid topics, regardless of scope:

Topic objects can also be used to refer to abstract concepts. Such intangible topics won't appear in any rooms, but they can have (name $) and (dict $) entries like any other objects. They are usually proper nouns. The game might refer to them during disambiguation: “Did you want to ask the librarian about life, the universe, and everything or the copy of Life magazine?”

As a convenience, (proper topic $) can be used to declare both traits in one go:

Using dictionary words to represent topics

To save memory, it is also possible to represent conversational topics using dictionary words.

A couple of rules such as these:

will make the parser understand TELL DOCTOR ABOUT THE SHATTERED DREAMS OF CHILDHOOD as [tell #doctor about childhood] (recall that the @ character can be omitted inside list expressions). But if you also define:

then THE SHATTERED DREAMS OF CHILDHOOD contains two valid keywords, and the game will ask, did you mean to tell the doctor about your childhood or your dreams?

Looking for keywords is a simple approach to topic parsing, but it is occasionally too crude. In the next chapter, we will see how to write arbitrarily complex parser rules for topics.

The unrecognized topic

The dictionary word @? (a single question mark) represents a topic that was unrecognized by the parser. It can be handled as a special case:

But bear in mind that the player might ask an NPC about any portable object, as well as any topic object. The parser will recognize those, and construct corresponding actions (with objects rather than @?), even if there are no explicit rule definitions that match those actions.

Most talking NPCs will therefore have some kind of catch-all rule, defined towards the end of the story source code, where they confess that they don't know much about the subject:

The two techniques above can be combined:

Choice-based conversation

One possible approach to conversation in parser games is to temporarily switch to choice-based interaction. If you haven't already read the chapter on choice mode, please do so before proceeding.

Typically, one would create a set of choice nodes where the labels represent lines spoken by the player character, and the display-texts contain responses from the NPC.

In the following playable example, the NPC object itself acts as a central hub node, offering an initial set of choices. Some choices cause the conversation to branch away from the hub in order to focus on a particular subject, represented by a separate hub-like structure. Some of the choices are gated, and appear only if certain other nodes of the conversation have been exposed.

And this is what it looks like:

Ask-and-tell topic objects can serve as shortcuts to conversation nodes. Recall that (choose $) prints the label, i.e. the player character's line, in a separate paragraph before activating the node: