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

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