Note: This page is no longer being maintained and
is kept for archival purposes only.|
For current information see our main page.
Developers of custom software and educational simulations.
|Home ... News ... Products ... Download ... Order ... Support ... Consulting ... Company|
StoryHarp & IF
StoryHarp & Java
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.
Updated: March 10, 1999. Questions/comments on site to email@example.com.
Copyright © 1998, 1999 Paul D. Fernhout & Cynthia F. Kurtz.