My favorite project from my Texas A&M days is this challenging create-a-scenario engine, created with Storyline 2 and JavaScript.
My faculty client, Dr. Patricia Lynch, wanted to develop a series of branching scenarios highlighting issues K-12 teachers could face when teaching developmentally challenged students. In our brainstorming sessions, we developed a huge list of desired features, including
- a high number of scenarios featuring a diverse cast of characters,
- the ability for instructors to mix-and-match scenarios from a “scenario bank” to suit their individual lesson plans,
- the ability for instructors to easily add new scenarios to the ‘scenario engine’
- mini games that would interrupt the scenarios to reinforce class content, much like a student with a nosebleed would interrupt a teacher’s dialog with another student.
With this wishlist in hand I dove into the project. Over two years later we emerged triumphant. Here is an example of our finished project.
Writing the complex scenarios
While I was working on the technology, the SME team developed character sketches for six different students. They also began writing scenarios, but we realized early in the process that keeping track of all the details from all the branches of the scenarios is difficult. (We decided to use three choices at each branch, with 27 possible endings.) To make it easier to keep track of the information, I designed a macro-enabled Excel spreadsheet. The opening page, pictured below, contained an overview of the scenario.
Our SMEs could put short descriptions on each node to see an overview of the scenario. The black shape in the corner of each node linked to a detail page, like this one:
Detail pages featured drop-down menus whenever possible, to minimize typos. The detail pages also had images from a prototype scenario I created to remind the SME team what the game looked like at that stage.
An export page compiled the data. SMEs saved this page as a .CSV file, then added the scenario to the Storyline SCORM ZIP file.
We quickly realized other classes could benefit from the scenario engine. One of the graduate students, for example, planned to use the scenarios to teach instructors different ways to include math throughout the curriculum.
Creating our fabulous project artwork
Our impressive project artist, Lindsey Hitch, a student in Maroon Research University’s Department of Visualization, drew all of six of our students, two other instructors, three parents, and a principal. Lindsey also created two of the characters at three different stages of growth — elementary, middle and high school — for a total of 12 distinct characters. Additionally, each character had 24 different expressions, including happy, sad, enraged, etc. Lindsey generated 288 different character illustrations, plus our backgrounds (a museum, the classroom, and a conference room) and most of the interface elements. Lindsey’s amazing work impresses everyone who looks at the project.
Tackling our ambitious Storyline integration
We began by researching ways to import the scenario dialog, characters, and other information into an authoring system so my small team (me and my student assistant Gwen Kimble) wouldn’t have to manually cut and paste information from 25 scenarios. A ZebraZapps tutorial, Build A Role Play in a Day, caught my attention. I loved the basic setup for the scenarios. The tutorial’s scenario featured tips and visual indicators to help students complete the scenarios, ideas which influenced our build. (I had hoped to use ZebraZapps to construct the scenarios, but the lack of an array-like object and a lack of JavaScript integration sent me elsewhere.)
After much experimentation, we decided to use Storyline for our authoring environment, primarily because we already used it on a daily basis, and because we could integrate JavaScript with Storyline.
I developed a script using the PapaParse JavaScript library that would import our CSV files, and create Storyline variables as needed. In Storyline, the variables controlled what game details would appear on screen at any given moment, including which character would show, the character’s current expression, and what the character is saying/doing/thinking.
The triggers for this project were off-the-charts crazy. For example, each character is a Storyline object with 25 states, a default state plus one for each mood. When mood variable changed for the main character, we’d have to work our way through an enormous list of triggers that looked something like this:
If Gabe is the main character, and Gabe’s mood is Angry, then change the Gabe object’s state to Angry.
If Gabe is the main character, and Gabe’s mood is Anxious, then change the Gabe object’s state to Anxious.
If Gabe is the main character, and Gabe’s mood is Confused, then change the Gabe object’s state to Confused.
. . . plus more Gabe triggers, then
If Jada is the main character, and Jada’s mood is Angry, then change the Gabe object’s state to Angry.
If Jada is the main character, and Jada’s mood is Anxious, then change the Gabe object’s state to Anxious.
If Jada is the main character, and Jada’s mood is Confused, then change the Gabe object’s state to Confused.
That’s right, we had 288 different triggers for the main characters. And then, early in the project’s development, a SME turned in a scenario with two characters. I was aghast. That meant we’d have a minimum of !!!!576!!!! triggers on the slide. I wanted to tell the SMEs we had to stick with only one character, but Dr. Lynch talked me out of it. She reminded me that many of the difficult situations teachers experience arise when students interact with each other. Our game needed to reflect this reality by showing two characters, even if it did double the number of triggers on a slide.
This became a real, honest-to-goodness time suck. In Storyline the order of the triggers matters. The interface has little buttons to move triggers up and down the stack, so you can organize them to make sure they process in the correct order. When you create a new trigger, it appears at the bottom of the stack. If I needed a trigger near the top of the stack (which happened often) I had to press the up arrow 576 times.
And as I had designed the entire scenario engine on one slide (including the mini games) the slide had about 800 triggers. (I never did count the final total; I was a little afraid to.)
It was crazy, but it worked.
Project hiccoughs
- Scope creep. This project had a ton of scope creep. I am very thankful Dr. Lynch was willing to delay project delivery in order to see all our great ideas incorporated into the final result. She’s a dream client. Her interest, enthusiasm and understanding helped me through the project’s roughest days.
- At one point, one of our character’s states flat-out refused to show up. The problem happened very early in the development cycle but wasn’t caught until the project was near completion, so restoring a backup wasn’t much help. So we tried in vain to fix the graphic. Nothing worked, so we had to rebuild the entire game from scratch. That cost us about two weeks. I’ve learned to be more careful about testing.
- I tested the Storyline-default Flash output, but when one of the GA’s web browser defaulted to the HTML5 version we had a nasty shock. The HTML5 version was incredibly slow. It turns out Storyline doesn’t have a graphics preloader for HTML5. We re-optimized the graphics, but it’s still very, very slow. Happily, in an educational environment we can tell students they need to use the Flash version. Hopefully Articulate will take care of this in future, less Flash-centric updates.
- ARRRRGGGGG TRIGGERS!!!!! Please, Articulate, give us folders to organize the triggers. And the ability to re-order triggers easily. Or at least make the triggers panel keyboard-accessible so it’s easier to write AutoHotKey macros for triggers.
If we had to do this again . . .
I’d probably go full HTML5/JavaScript. When we started this project, I didn’t feel I had the skill to write a pure JavaScript learning object, but now (thanks in part to this monster project) my skills have improved. I’m not sure I could write the SCORM or XAPI piece, but I know we could place the scenarios in Storyline as web objects, then let Storyline deal with SCORM/XAPI for us.
Future uses
I’m hoping the graduate students in the project use the scenarios in the future, and author additional scenarios. Maybe one day we’ll hire Lindsey to draw new background and new characters, and use this with Business classes to teach customer relations.