Take a look at the file on the left. It is a sample scenes file. It's purpose is to describe the scenes that make up your story. The first line, <?xml version="1.0"?>, is required and tells the IFML engine that this is an XML file.
The next element is the scenes element. Each scenes file will have one and only one scenes element. The closing scenes tag is the very last tag in the file. You can use the id attribute to name your story, but it is not required.
The next element is the scene element. Each scene 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 scene. You must also specify which scenes the player will go to when traveling up, down, north, south, east, west, northeast, northwest, southeast and southwest. Use the reserved word "nowhere" to indicate that travel in the that direction is not allowed.
The next element is the setting property. This is a required property used to describe the scene to the player. 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 IFML 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.
Believe it or not the scene and setting elements are the only elements requires for scene. The weather element is an example of an author designed property. You can create as many properties as you need for your scene. Give the element a meaningful name and include a default value for it. Later you will act upon these properties based on the actions the player takes.
Of course the player won't be able to do much 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 out instead of go out of the plane
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.
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 in your scenes. 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.
Well, that's it for scenes. Let move on to characters.