Building a Scenario-Based Conversation Simulation with Flash, XML, and AS3

I posted earlier about a scenario-based conversation simulation that I created as part of a recent course. If you want to read about the simulation itself without the XML and AS code-ish techno garble stuff, click here to visit my previous post. You can also view the course itself within my online portfolio by clicking here.

Screenshot from loan officer simulation.

In this post, I focus on how I used XML and AS3 to dynamically generate dialogs and interactions for the simulation as well as control of the branching logic. My goal is to give an overview of the technical structure, without getting too terribly deep in – however, this post is definitely aimed at people who develop using Flash, XML, and AS.

General Design Structure

I like to use Flash to design elements of my activity interfaces, but control almost everything else using AS3 and XML. This lets me take advantage of Flash’s friendlier design environment while still keeping the logic of my activities flexible.

Dialog Boxes

So, for example, for the dialog boxes in this simulation, I created a MovieClip in Flash with a background, text fields for the dialog title and content, and a Continue button.

Empty dialog box MovieClip.

Less than thrilling, right? However, with some XML and AS, it’ll magically become more exciting.

In the XML for this section, I created an element for each dialog box and interaction. Here’s an example of the XML for a standard dialog box:

XML for dialog box

Within the dialogBox element, the child elements id and launchNext define the simulation branching. The child elements title and description define the text that appears in the dialog box.

When the SWF for the course first loads, the AS for the loan officer simulation section loads and cycles through the XML to create all of the dialog boxes and interactions using the given elements and data. Each dialogBox element results in an AS generated dialog box, using my Flash created MovieClip. Same for the interactions and several other simulation objects.

For example, the AS uses the XML dialogBox element from the sample above to create the following dialog box in the course:

Dialog box in SWF

Clicking the Continue button moves the user to the dialog box or interaction defined in the launchNext element – in this case, the dialog box with the id Interface_Dialog.


I created interactions in the course using a similar framework, but the interaction elements contain more child elements, since user choices affect both the course variables and the simulation path in various ways.
Here’s an example of the XML for an interaction :

XML for an interaction

For some options, I also added elements to introduce special variables to trigger events later in the scenario and other elements that would remove or add options to future interactions (these aren’t shown in the example above).

The XML above results in the following interface in the loaded SWF:

Interaction in SWF

Because the AS dynamically generates all of the dialog boxes and interactions when the SWF loads, I could happily edit, create, or remove dialog boxes and interactions to my heart’s content, without ever editing the AS or republishing the SWF, except in the moments where I wanted to the logic of the simulation to move beyond simple branching (more on that later).

Planning Flow Charts

To plan the logic of the simulation, I created flow charts for each section. Here is an example of a flow chart, from the Promotion and Sales section of the simulation (click to view a larger version):

Flow Chart for Sales and Promotion

In total, there were five sections in this simulation: Promotion and Sales, Evaluation, Approval, Disbursement, and Collections and Recovery.

Beyond Simple Branching

I mentioned above that there were times that I wanted to move beyond simple branching, so the launchNext element alone wasn’t adequate. I had a couple of additional XML elements that the AS would watch for and use to override the default launchNext. For example, in dialogBox element below, the checkPotentialEnds element triggers the AS to evaluate whether or not any of the key indicator variables had fallen low enough that the user simulation should end. If so, the user would be brought to one of several potential simulation ends, instead of being brought to the dialog box with id Application_Redo_Dialog.

XML for a dialog box with checkPotentialEnds element

Similarly, at the beginning of some sections, I wanted to vary the opening dialog that the user would see based on his or her past decisions. In the XML below, the variableLogic element would trigger the AS to evaluate the past decisions to decide which opening dialog to launch for the Application section.

XML with variableLogic element

If you want to take a closer look at how all of this looks in action, you can view the course within my online portfolio by clicking here.

5 thoughts on “Building a Scenario-Based Conversation Simulation with Flash, XML, and AS3

  1. Great work Amanda, your work is an inspiration. Like you I’m a flash programmer and learning designer. I’m considering creating a scenario-based conversation simulation with the same tools you’ve used, flash AS3 and XML. But I’m wondering if there is an advantage to this over creating simulations in Captivate 5.5.

    * Advantage: With flash I can change the scenario by creating a new XML file and dropping it into the folder with the compiled swf.
    * No Advantage: I need the ability to include audio/visual assets for each dialog Box and Interaction. This can be accomplished by including references via the XML. But this might be my restraint. This provides no more advantage over creating animations, images and audio and including them within a Captivate file.
    * Disadvantage: I will have to create a custom SCORM wrapper for LMS reporting and compliance. I believe this will be a disadvantage because this is built into Captivate.

    The AS3 classes can serve as a template for creating simulations. But is there an advantage to this over Captivate?

    1. Maybe I just can’t count, but it seems to have issues when there’s uimtlple scenes. Let’s say I have 3 scenes with 100 frames each. Seems like frame 210 should be the 10th frame in the last scene, but it doesn’t seem to work that way. The times I’ve tried it an unexpected frame printed out. Guess I need to dig a bit

      1. I don’t work off of timelines that frequently and use scenes even less frequently, so I don’t know for sure what would be causing that issue. Do you also have the problem if you use frame labels? When I’m using the timeline (say, for animations), I tend to favor navigating to labels instead of frame numbers, since frame numbers change if I adjust the length of the animations.

  2. Thanks Matt! Those are good points, and I’ve included my thoughts on them below. One caveat – I’ve spent very little time in Captivate 5.5, though I previously used versions 3 and 4 pretty extensively and have worked a bit in 5. So, it’s possible that Captivate 5.5 has some functionalities that I don’t know about.

    For me, though, on of the major advantages of building these types of courses with Flash/XML/AS3 is that the simulations end up not being screen/slide based, since I don’t have to build a separate screen with every single dialog. Instead, my AS3 automatically generates as many dialogs as needed based on the XML and loads them when appropriate. This is a huge time-saver for me and as far as I know, this isn’t possible in Captivate. With the course mentioned in this particular post, there are also lots of situations where I need to loop around to the same dialog multiple times, but with different options showing each time. This would have taken forever to build if I’d had to create screens for each of the possible combinations of options.

    I have also loaded audio, images, and animations to go with dialogs using XML references as you described, and it’s worked really well. This method requires some additional AS3 upfront, but once that’s in place, I can have the dialogs auto-generate just like with dialogs without media. The times when I’d imagine that it wouldn’t work as well (though it would still be possible) would be if the location or behavior of the audio/images/animations needed to be significantly different for each dialog.

    For SCORM packaging, I generally use the Manifest Maker 1.2 extension for DreamWeaver and Pipwerk’s JavaScript and AS3 SCORM files. It takes a little time to set up the first time, but after that, it’s a pretty quick process (though, admittedly, not as fast as selecting Publish in Captivate). The other good thing about managing the SCORM packaging myself is that I can use the suspend data to store and load pretty much whatever data I want, which I’ve found really useful with simulations, when simple bookmarking isn’t always enough.

Comments are closed.