Street Alchemy - designs by Alex Porter

demo

XML is your friend! Part 1

XML is your friend!

So you're interested in learning how to use XML with Flash efficiently and easily eh? Well ok, I suppose we can accommodate you then. First things first, we have to know what we can build with xml.

Places XML can be used with Flash:

  1. Anywhere external data can be used.
  2. Anywhere a database could be used (in this tutorial we're only going to pull data)
  3. Anywhere you freakin' want.

So basically, XML can be used just about anywhere with Flash, but here are some specific ideas on what you could do with it.

  • You could keep an active calendar in xml for a Flash website. Instead of building a full back end with a database, or changing a Flash file whenever you want to update a calendar, you just edit and upload one XML file.
  • You could create a "contacts" type of app and keep all of the data in an XML file.
  • You could create a Flash navigation for a website and use link locations from an XML file so that you only have to publish the navigation swf once, allowing you to pull and change the link locations from the file.
  • Or you could do what we're going to do. We're essentially going to create a "Choose Your Own Adventure" style text-based game, building the interface in Flash, but pulling all the story data, and choices, from an external XML file.

So after you've decided what to build, you need to decide how to organize the data, and what the data will be.

(Note: I'm assuming a 'basic' knowledge of what XML is for this tutorial. If you don't know what it is, feel free to read up on it here: http://en.wikipedia.org/wiki/XML, but I will do my best to explain it all in high-level form as we go if you don't feel like reading that.)

No matter what you may or may not know about XML, for this demo/tutorial, you need only to know one main thing, that xml allows us to essentially organize and write our own languages (or language subsets more appropriately), which we can then write interpreters for in Flash.

So on with organizing the data:
Well, for this exercise we're going to create a small game called 'Froggy Land' which will be a choose your own adventure game about a frog. So basically you are presented with some text telling you what's going on, and you are then given choices as to what to do next. You decide what to do, and the game moves forward. Pretty straight forward don't ya think?

So let's build the organizing structure.

First we start our new text file with the typical XML header and doctype:

<?xml version="1.0" encoding="UTF-8"?>

Next we create our root element, the thing that all the info would fall under if the data was a hierarchy... which it is... We'll call is a storybook, since that's in essence what we're building. When you write data in XML, a great rule of thumb is just to make sure that your element names make sense, describe what the information is, and aren't just gibberish if you can help it.

<storybook></storybook>

In our storybook, we have pages, and on each page there is some text, some choices, and the number of the next page that the reader is supposed to go to depending on their choice. Here is some XML to represent the pages, and I'll go through it step by step afterward.

<page id="1">
    <text>
        Once upon a time, there was a teeny tiny frog, who lived by a well in a small meadow. On this day the little frog was trying to decide what he should do. What do you think?
    </text>
    <option nextPage="2" color="blue">
        Hop toward the pond.
    </option>
    <option nextPage="3" color="green">
        Hop toward the forest.
    </option>
</page>

Ok, so what do we have here? First we have the page element. This page will contain all the information we need for each section of the game. Each page also has an id attribute. This id is quite simply the page number in our choose your own adventure, or CYOA for short.

Next, nested within the page element, we have a text element. Think of this simply as the text on the page, the part of the story that happens on that page and nothing more.

After the story has been read, the player or reader has to make some choices. Generally in a CYOA at the bottom of each page there are some options or decisions to make, and what new page to go to once that has been decided. We have exactly that here. We have a series of option elements, each with a nextPage attribute that tells us which page to turn to, a color attribute (which for this exercise is just used to pick what color the option's button should be), and the text between the opening and closing tags of the option element. The text between the opening and closing tags is the actual option text.

That's it, that's all each page needs, and essentially all our XML needs. If you fill a CYOA with pages, each with options, you have a full, interactive story and that's all there is to it!

Below I've attached the xml file for the full demo app so you can look it over, make sure it all makes sense, or even create a totally new story or way to use the information that suits you better.

Next time we're going to talk what to do with this info now that we have it. In other words, we're going to talk about how to bring Froggy Land to life, lol.

storybook.xml