Take a look at the file on the left. It is a sample props file. Its purpose is to describe the props that the player can interact with. The first line, <?xml version="1.0"?>, is required and tells the browser that this is an XML file.
The next element is the props element. Each props file will have one and only one props element. The closing props tag is the very last tag in the file.
The next element is the prop element. Each prop in your story is contained within this element. You must specify a unique id for this element which you will use whenever you need to refer to a specific prop. You must also specify the location of the prop. The locationType may be "scene," "prop," or "character" although "scene" or "character" are really the only things that makes sense. The locationId is the id of the scene (or prop or character) where the prop is located. You must also specify the value of the prop. The player's score is increased by the amount in the value attribute. If you do not want to award points, make the value of the prop zero.
The next element is the longDescription property. This is a required property used to describe the prop. Although you can change this property with the changeProperty action during the play of the game, the text here tends to be fairly static.
You may be wondering about all those [p]'s and [/p]'s in there. Well you can include html tags in your file, but to keep the browser from mis-interpreting the angle brackets as XML you need substitute square brackets. The game engine turns the stuff in the square brackets back into HTML when it displays the text on the screen. Yes, this means you can include graphics and just about anything else you can think of in your story.
The next element is the shortDescription property. This is a required property used to give a short name to the prop. This is the description that shows up in the inventory area of the game.
Believe it or not these are the only elements requires for a prop. As with scenes and characters, you may define additional properties for your prop.
Of course the player won't be able to do much with the props if you don't include any dialogs. The dialog element allows your story to respond to the player's input. After the <dialog>, you need to enter the player's command that you want to process. Only enter as much text as you need to make the player's command understandable. For example, key eat orchid instead of eat the beautiful orchid. In this example we want to respond when the player eats the orchid.
Inside the dialog element you will see the when element. A series of conditions and actions go inside the when element. You can have as many when elements as you need in a dialog. Each when responds to a different set of conditions.
The condition elements describe under what conditions the actions will take place. You may include as many conditions as you need. Refer to the conditions and actions reference for a list of conditions that you can use.
After your conditions, you list your action elements. These are the elements that cause things to happen in your story. They move the player from scene to scene, change the properties of scenes, props, and characters, and display messages in the browser. See the conditions and actions reference for a list of actions you can perform.
Eventually you will want to put a handled element in the inside the when. This says that this particular dialog was able to totally handle the player's command. You can write more than one dialog to handle the player's input, but eventually one of those dialogs must mark the input as handled. Otherwise the dreaded "could not process command" message will appear in the browser.
You may also include monologs for your characters. Monologs work exactly like dialogs except that they execute before each of the player's turns instead of in response to the player's input if the prop is in the player's posession or located in the current scene. In this example a message displays if the player is at the top of the stalk.
Well, that's it for props. Let's go on to synonyms.