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
How is StoryHarp different from other IF systems?There are many other adventure authoring systems out there for Interactive Fiction (IF). Three of the most widely used currently are Inform, TADS, and Hugo. How is StoryHarp different? StoryHarp was designed with two ends in mind: To make the authoring environment as simple as possible so you can focus on creative writing, and To provide the best environment for creating and playing voice-operated adventures. How does this affect StoryHarp? Because of this simplicity and dedication to voice, StoryHarp adventures will tend to have a certain style. Our suggestion is to learn and make the most of that style, and not try to force it into styles that are more appropriate for other systems. How does voice operation make the adventure different? Voice-operated adventures have different requirements for commands than text-based adventures given today's level of speech recognition accuracy. In short, the more things a player can say, and the closer those things sound to each other, the less likely it is the voice recognizer will match the player’s speech to the correct text. For example, if the commands 'wreck a nice beach' and 'recognize speech' are available at once, the computer will likely as not pick the wrong one. By restricting the available commands to a small number depending on the context and other requirements, StoryHarp avoids this problem. This makes the voice adventure move forward smoothly so the player can concentrate on the story. When writing a StoryHarp audioventure you need to keep this restriction in mind – that a relatively small number of commands should be available in any context, and that available commands should not sound like each other. If you write the adventure correctly, when players get to the context of a party with friends on the coast they can choose to 'wreck a nice beach' (which may result in trouble with the local conservationists). When they get to the context of being near a JAL 1000 computer in a research lab they can tell it to 'recognize speech'. So these two phrases can be in the same game without confusion, but only in different contexts. What other differences are there? If you are used to another adventure authoring environment you may be in for a bit of culture shock with StoryHarp. Here are some other differences between StoryHarp and other IF systems. No explicit objects: There is no explicit concept of an object in StoryHarp. Allowing the adventurer to pick up and put down things everywhere is discouraged because it leads to too many options for a player to say at once ("take" and "drop" and "examine" and "use" combined with every moveable object). The emphasis is more on having the player do things, acquire knowledge, meet people, and move around than it is on acquiring and manipulating objects. StoryHarp adventures are much more like stories built from choices than they are real-world simulations. In this sense, StoryHarp is heading in a different direction than the current IF trend towards ever greater realism in the sense of (text-based) virtual reality and greater player possibilities. StoryHarp audioventures can have objects – but they are defined implicitly through rules defining the interrelations of commands as they apply to the object. No explicit rooms: There is no explicit concept of a room in StoryHarp. Instead there are contexts. Contexts can represent people, places, things, or states of mind. An adventurer may be in several contexts at once (like in the lobby, accompanied by the old man, and happy). You can use contexts to represent as many locations as you want, and these locations can be used as rooms – but they don't have to be rooms. No randomness or scores: Some other built in features StoryHarp lacks which you may be used to are randomness, keeping a record of what turn it is, and keeping score. While these features are certainly useful, you can still make interesting story experiences for people without them. You can use StoryHarp to create some uncertainty or require multiple attempts, to track what the player has been doing, and to give feedback on performance, but these must all be crafted through creating specific rules. Unique features: StoryHarp has some features many other authoring systems don't offer. You an edit the game while it is running. You can do some of the editing graphically with a map and wizards. You can use a browser to manage some of the complexity of a really big adventure. Short learning curve: StoryHarp is especially friendly to IF novices. You will find that StoryHarp does not have as steep a learning curve as some other systems do. But advanced users will also find a lot of things they can learn to do with StoryHarp that may not be obvious at the start. A comparison of StoryHarp and parser-based IF systems One of the biggest differences for authors who have worked with other systems may be that the player can't say very many things at any time. There is no grammar with variables like 'give X to Y'; so there is no parser to wrestle with. All phrases a player can say are specified in full in advance. Also, the player usually can't say things that don't make sense at the time (like 'use the aardvark to unlock the lamp' when they are not carrying the aardvark, or the lamp can't be unlocked). In part, this comes from the need to limit the available commands the player can say to improve voice recognition accuracy. But this also stems from a desire to focus on defining what the player can do, rather than responding to things they can't do. This gives you, the author, the freedom to focus mostly on what you want to say, rather than anticipating problems. As players, we want to be adventuring, not wordsmithing. Parsing can make or break an IF adventure; and often times it breaks it. We feel as players that is usually not fun when it takes a long while to figure out precisely what to say to accomplish some otherwise obvious goal. And after being spurred on by those eventual successes, it is also usually not fun to then spend a long time typing in lots of variants of phrasing for some action that should be possible with those sorts of objects in the real world, but will never work in this particular story world (i.e. "make a net from the rope and catch the fish"). Instead, as players we like having our limited options available without requiring much guessing. This also greatly reduces the burden on the author to figure out what we might say. Of course, we acknowledge that in some adventures, guessing the right thing to do is half the fun. Those sorts of puzzles won't do as well in StoryHarp, although they can sometimes be posed as riddles. As authors, of course, wordsmithing itself is part of the authoring game, but we prefer to restrict it mainly to descriptions. Well-written adventures in other IF systems usually do not present many of these frustrating situations where it is hard to guess phrasing. However, developing such well-written adventures may take much time and much user testing. That is time which might otherwise go into writing descriptions or developing story lines. In brief, focusing on what the player wants to say leaves less time for focusing on what the author wants to say. Other IF systems and their libraries help you create interactive worlds where the player typically has many more actions they can do in a standard way, with the possible consequences to the actions being much more complex than StoryHarp supports; we do not deny this. This is appropriate for many adventures, especially of the style of "collect everything and try it everywhere". However, in practice, we question if this level of complexity is always necessary for telling a story (especially a story with a message). For example, rather than simulate all the things you can do with a rope in an adventure, our solution to having a rope in the story is simply to let a player pick it up in one place and only give them a few specific options for its use. True, the player may not be able to unwind the rope into thread and weave a garment out of it, or use it to tie four objects in a row and drag them around (unless that was designed into the story). But then, we're telling a story here, not simulating all of reality. Because of the StoryHarp user interface of displaying a set of options than can be clicked on or said, the player will probably be much less frustrated with this rope, because they won't invest hours trying to get it to do something real rope can do but story rope can not. By providing a list of options, the StoryHarp GUI tries not to raise expectations in the player it can't satisfy. That is the key difference in approach between StoryHarp and many other IF authoring systems. Out of this comes a very different style for StoryHarp adventures. They are likely to be breezier, in the sense that a player keeps moving forward since the options are always available (except for riddles, which must be used cautiously). Objects are likely to be given and then discarded automatically after use. Information collection is likely to be paramount, with more information leading to more options. Of course an especially poorly-written story can always be frustrating or no fun to play no matter what system was used to write it. StoryHarp can only do so much towards addressing this issue. As with any writing tool, StoryHarp can't make someone a good writer overnight. Nothing prevents one from creating lots of badly written stories. Becoming a good writer simply takes years of writing experience (and of course some talent, as well as having something to say). Hopefully, if you are a novice author, StoryHarp will let you focus more on becoming a good writer and less on becoming a good programmer (which by itself takes many years of experience too). Authors have less unexpected interactions to worry about using StoryHarp. Thus, StoryHarp audioventures may well be large, with lots of description and many rooms and characters, each of which has a fixed set of typically five to ten interactions. Some interactions the player may expect may be missing, but players won’t waste time trying to do things the story does not support -- which tends to break the suspension of disbelief essential to any story experience. Of course, certain expected standard interactions (like lighting rooms with various lamps, or managing containers) are much easier to create in different IF systems than in StoryHarp. Yet, taken as a whole, it is possible a large StoryHarp adventure with missing interactions is more likely to be a good story than a similar large adventure with a complex parser and the same missing interactions. Because they are easy to get started by creating a few rules, StoryHarp audioventures may also be smaller, with less options, played in minutes, but containing a short message (like Aesop's fables). An experienced author can create an interesting adventure that takes five or ten minutes to play in a couple hours of work by creating only fifty rules or so. In general, there may well be more variety to StoryHarp audioventures than other IF because short ones can be produced more quickly. The more adventures there are, of a greater variety, the more likelihood that some of them are going to be really, really good. Because authoring a short piece may be done quickly, there is some potential here for school teachers to use IF to make a short piece to make a point in a lesson. It is likely a StoryHarp adventure would probably provide less playing time than a similar parser based one, since parser based systems provide more linguistic territory for the player to explore by writing various turns of phrases in commands. This is offset some because StoryHarp worlds might be significantly larger for the same amount of authoring effort. Each type of adventure will be a very different experience for both the player and the author. StoryHarp doesn't claim to be as powerful or even as concise as other IF authoring systems for many things. It does claim to be a tool you can use to rapidly create adventures of a certain style which work well with voice commands. Can’t you just add speech recognition to other IF systems? You may wonder why we didn’t just add speech recognition to an existing IF system. Well the answer is, we tried. Our first prototype was to prove the concept of voice-operated adventures and used discrete word-by-word SR and a hard-coded story with a tiny vocabulary. From that, we decided that continuous SR of a wide variety of words was desirable. We thought it would be super to use the wide variety of existing IF stories with SR. So our second prototype involved modifying JZIP (a widely used IF interpreter) to work with a continuous SR engine capable of taking dictation. What we discovered was that the dictation recognition accuracy in our rough prototype was too poor to make it fun to use. This was due in part to the wide deviation of a typical adventure’s vocabulary from the standard office vocabulary. Out of this second attempt came our feeling that the state of the art in SR isn’t quite there yet for working with the broad flexibility in language and grammar allowed by IF systems like Inform, TADS, or HUGO. No doubt our opinion was also prejudiced by wanting to build an authoring environment that incorporated some different ideas and that was easier to use. Recognition results could likely have be improved quite a bit in that prototype by adding all the words of the adventure to the SR engine’s dictionary, which we did not do. We could have also used the SR engine for command and control using grammars modeled on the ones specified say in Inform source code, but again, this we did not do. Two limits of present-day SR were in the back of our minds. Even with using only words in the SR engine’s dictionary, typical recognition rates of ninety-five percent accuracy in a moderately noisy environment would mean a mistake about every twenty words, or in practice every few commands. In really good circumstances, one might be able to reach ninety-nine percent accuracy with a continuous dictation SR engine (one mistake in one hundred – so maybe every ten or twenty commands). Also, grammars used for command and control can still produce less than what is desired when there are too many variants of phrasing. One might also be able to simplify the grammars of some existing stories and get authors to recompile them. But neither of these fixes would be achieving the goal where most people could use existing IF adventure files – at least, not widely in this year or next. There are many other things one could try to do to reduce misrecognition in dictation. The best candidate may well be using probabilistic assessments of top choices for recognition. This would require major changes to any IF interpreter used, and possibly the authoring environment as well. Given all this, we decided to take the direct approach of restricting StoryHarp’s use of SR to continuous recognition of discrete phrases instead. This is something that today’s hardware and software can do fairly reliably. As an added benefit, by eliminating the need for a parser, we eliminated some of the complexity of IF authoring (and we admit some of the soul too, hopefully made up for in other ways). Almost certainly, SR will be up to working with complex IF grammars and unusual vocabularies in the years to come, especially when combined with better integration with those IF authoring systems. Until then, we offer StoryHarp as a way to get started in this exciting field of audioventuring.
Updated: March 10, 1999. Questions/comments on site to firstname.lastname@example.org.
Copyright © 1998, 1999 Paul D. Fernhout & Cynthia F. Kurtz.