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.
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.
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.
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:
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:
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 :
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:
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):
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.
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.
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.