StoryHarp Help: Advanced Tutorial -- Step 3: Add conversation scripts

Note: This page is no longer being maintained and is kept for archival purposes only.
For current information see our main page.

	Kurtz-Fernhout Software Developers of custom software and educational simulations.
	Home ... News ... Products ... Download ... Order ... Support ... Consulting ... Company

StoryHarp
Product area
Help System
Index
Introduction
Definitions
Tutorials
Worlds
Agent
StoryHarp & IF
StoryHarp & Java
Registering

Advanced Tutorial -- Step 3: Add conversation scripts

--|---- Back | Next | Index

About conversations in StoryHarp
You can use StoryHarp to set up simple conversation scripts a player can take part in. StoryHarp does not support artificially intelligent conversations. The best you can do is create lots of alternatives of things the player can say, and allow multiple conversation threads to be active at once. While it is true you are leading the player around, if done well, this can still be fun. People seem to really enjoy saying things in just the right tone; well written scripts can bring out the actor in the player.

You can also allow the player to say some things only if they have acquired information previously during the course of the adventure. For example, in a conversation you might let them ask, "How can I open the pod bay doors?" only if they have previously encountered those doors.

Conversation paths and topics
Conversations can be thought of as having one or more paths. A conversational path is a linear sequence of topics, in the form of player command and character reply. You can think of topics as stones you step on to cross a conversational river. At each step along a conversational path, the player can also say other things which have replies, but which do not usually lead off the conversational path. These are called topic expanders, because they expand on a topic. They are like stepping stones that don't get you further across the river, but maybe give you a better view or provide a wider place to stand and rest. Just because a conversation path exists, does not mean the player can progress all the way down it. Frequently, a topic or a topic expander will be blocked by having a requirement that the player has acquired some object, done some action, or progressed to some topic in some other conversation before they can say the relevant command. For example, if a player is conversing with a shopkeeper, you probably would not let them "ask about the shopkeeper's secret herring smuggling operation" unless they had found out about it previously, probably by talking to someone else.

A conversation can have more than one path. Some topic expanders can lead to other conversational paths. Paths can interact in that you may have to go down one path to find a piece of information that enables you to progress along another path beyond where you ran out of things to say. A path can go up to a point and then split into two or more paths. Two or more paths can also converge back into one path. There are endless possibilities. Depending on how the conversation's pathways are structured, and how far the player is into the conversation, there may be a dozen or more things the player can say or there may be only one.

Three conversation techniques
There are three main techniques which can be used to create a conversation script. These three techniques can be used separately or together.

Technique 1: use contexts and moves
The first approach is to set up the conversation like a series of locations, using moves to go from one topic in the conversation to another. This is most useful if the player must complete the conversation before progressing. It also requires the conversation to have a readily identifiable backbone structure, or in some other way have only one major conversational pathway active at a time. You can go fairly far with this approach in many cases, and so it should be considered first because it is the least work, and can always be replaced or added to by the other approaches.

The biggest drawback with this first approach is how to end the conversation. You need to move back to the location where the player started, or to some other place that makes sense in the context of the last part of the conversation. This is not a problem when conversing with a character in a fixed location, or when the intent of the conversation is to move the player somewhere at the end. If the conversation can be started in multiple locations, you can use changes made at the start of the same conversation from different places and requirements for the final step of the conversation to return to the original location. But if you are anticipating this, you may wish to try the next technique instead.

Technique 2: use requirements and changes
The second approach is to create contexts as topics in a conversation, but to not use them as locations that are moved to or from. Often, if you took the first approach and things are getting out of hand, you can transition it to this by removing all the moves. Instead of moves, use changes to control which topics are active in a conversation. Topics can be activated by a change like "talking about the herring smuggling operation" and they can be deactivated when no longer of interest or when fully discussed by a change like "~talking about the herring smuggling operation". You can use changes in conjunction with commands in each context to create a very complex set of possible conversational paths, with all sorts of topics becoming active and inactive over time. Typically such a conversation will take place in a location or when a character is present.

Using this second approach, you will need to have some way of making these topics inactive when discussion is no longer appropriate (like when the player moves away from the character somehow). This can be done by setting all the topic contexts in the conversation to false when the player moves away from the character. Alternatively, if you want the system to remember the current state of the conversation, every command for conversation can have a requirement related to the character conversed with or the location of the conversation.

Technique 3: use a sequence of commands
The third approach is more ad hoc and is most easily used for simple conversational paths. One can create a series of commands for a context which have requirements and changes using other variables. By arranging these requirements and changes, one can create conversation sequences tied to some specific other context. So for example, for a character who is always in one place, one could just add a few commands to go through a simple conversation sequence, using other variables to record the progress through the conversation. This approach can be overlaid on top of the previous two approaches or used on its own. A later step in this tutorial describes using the new commands wizard to add sequences. These sequences can be applied to conversations. Ending one of these conversations is usually not a problem, since they usually depend on the context the character is in. Moving just ends the conversation, leaving it to be resumed if the player returns.

Let's create one conversation using each of these three approaches. We will not cover combining the approaches, which should be easy enough to figure out once you have the three approaches down.

Make a first conversation using contexts and moves
The first approach is to use contexts and moves to create a conversation. Let's pick the tree top (a context which is a location) to start and end the conversation. Here is a simple conversation to enter. As you can see, even the simplest conversation can generate many rules. Notice that commands have to be in all lower case, so entering direct things to say look a little funny. Often what the player says can be set up as more general questions than specific phrases.

context	command	reply	move
tree top	shout hello	Someone shouts back, "Hello there".	hello there
hello there	stop shouting	You decide to rest your voice.	tree top
hello there	shout how are you	Someone shouts back, "I'm fine. How are you?"	how are you
how are you	shout i am fine	Someone shouts back, "Great to hear that".	i am fine
i am fine	shout who are you	Someone shouts back, "Arnie Sachnusem".
i am fine	shout where are you	Someone shouts back, "I'm over here".
i am fine	shout nice talking to you!	Someone shouts back, "Nice talking to you, too!"	tree top

Test the first conversation
Now you can test this. Notice how commands related to moving from the tree top are no longer available when you are involved in the conversation. However, commands related to inventory or other characters (like the squirrel) will still be available. You want to be careful not to create situations where more than twenty or so commands are available at once.

Complex conversations are difficult to write so they have leading statements which suggest what the player can say. It is likely the player will have to look at the monitor or often ask for options to complete one. You can add the macro "{options}" to any reply to have the options said automatically at the end of the reply. You can use this in certain cases to help lead the player along.

Note that all these replies begin with "shout". You can use "shout" or "say" or "ask" at the beginning of items in a conversation, but you do not have to. You could just use phrases like in a normal conversation. Just be aware that short phrases of one word will be more easily misrecognized than longer phrases.

After some reorganizing, here is what the map looks like:

The forest map after adding the first conversation
Make a second conversation using requirements and changes
Now, let’s create a conversation using the second approach (by creating new contexts again, but this time using requirements and changes instead of moves). Let's create an acquisitive hermit who comes by, takes a few things, gives them back, dislikes hypocrisy, and maybe leaves you with a valuable clue.

Now, this may look like a very long table (eleven rules), but it only takes a few minutes to add in and it’s the last big table in the tutorial. Hang in there! Also remember that you can copy the replies from the help system and paste them into StoryHarp. (If you get some extra text, just delete it in the reply field after you paste.)

context	command	reply	requirements	changes
hermit	look	You see a hermit here.
hermit	hello sir	The hermit says nothing.
hermit	nice day, isn't it?	The hermit says nothing.
hermit	do you know who this knife belongs to?	The hermit snatches it out of your hands and says, "mine!"	holding knife	~holding knife snatched knife
hermit	can you tell me anything about this nut?	The hermit snatches it out of your hands and says, "mine!"	golden nut	~golden nut snatched nut
snatched knife	give me back that knife!	The hermit says, "Mine!"
snatched knife	whose initials are on the knife?	The hermit cowers a little, and tries to sneak a peek at the knife, and then says "Not mine." and hands it back.		~snatched knife holding knife hermit chastened
snatched nut	give me back that nut!	The hermit says, "Mine!"
snatched nut	so whose machinery does the nut belong to?	The hermit cowers a little, and fidgets, and then says "Not mine" and hands it back.		~snatched nut golden nut hermit chastened
hermit chastened	you really should not take things that don't belong to you	The hermit looks at you kind of funny, and walks away.	holding knife golden nut	~hermit chastened ~hermit
hermit chastened	they are not mine either	The hermit chants, "Arnie, Arnie, Arnie!" and walks away.	holding knife golden nut	~hermit chastened ~hermit arnie clue

Make the hermit appear
The only thing left to do is to make the hermit show up. You need to add a change somewhere -- let's say, after the vine bridge gets broken. So add "hermit" as a change to those two rules. To tell the player about this, add the sentence "Hearing all the noise, a hermit shows up." to the replies of those two rules as well. You can get to these two rules easily by browsing on Changes and choosing “bridge broken” from the first list.

Note that if we were to make the hermit go away before the conversation is complete (like if the hermit did not climb trees), we would have to make sure to deactivate the contexts for the conversation (perhaps losing the knife or golden nut in the process).

Why do the last two rules have requirements?
You may be wondering why the requirements on the last two rules are there. We could allow the hermit to respond to the commands in the last two rules if the player is not holding the knife or golden nut. But, that would lead to a problem if the hermit was still holding the items. If the requirements of "holding knife" and "golden nut" were not in those last two rules, the hermit could walk away with the nut or knife, leaving the commands relating to the nut and knife still available, because the contexts "snatched nut" or "snatched knife" might still being active. To prevent this, in that case you would need to put "~snatched nut" and "~snatched knife" in the changes for the last two rules where the hermit leaves.

But of course, then the player would lose the nut or knife if they don't say the right thing to make the hermit leave. But maybe that's the way you want it. In that case, because of the way the rest of the adventure is constructed, the knife would end up back in the tree house, and the big nut would reappear to feed to the squirrel again. If you wanted either of those two object to disappear for good, you would need to make another variable to represent that it was lost, and modify some of the rules to check for that being not true.

Something’s wrong here
Actually, there is a bit of a bug in this set of rules. When the hermit has the knife, it would be possible to go back to the tree house and get it again. Same with picking up the big nut when the golden nut is gone. To prevent this, we need to add requirements to several rules. Add "~snatched nut" as a requirement to the rules involving looking at and picking up the big nut. Add "~snatched knife" as a requirement for looking at the knife and taking the knife in the tree house. These extra requirements correspond to the new state these objects can be in ("snatched") besides being held by the player.

Conversations and objects together
Notice how we have made a conversation that manipulates objects as a side effect. It also uses that status of those objects in some requirements of the conversation. You don't have to have a conversation that includes manipulating objects; conversations can be about anything at all. More typical as a result of a conversation is in the last rule, where we set an "arnie clue" flag to indicate the player should now know something. We could use this as a requirement in other conversations.

The last conversation will be a simple one. We will use the third approach -- that of using a sequence of commands to structure the flow. However, we will use the new commands wizard to do it. This will be explained in the next step.

Home ... News ... Products ... Download ... Order ... Support ... Consulting ... Company
Updated: March 10, 1999. Questions/comments on site to webmaster@kurtz-fernhout.com.
Copyright © 1998, 1999 Paul D. Fernhout & Cynthia F. Kurtz.