1. Building Game Qualities into an
Online Case Simulation Engine
Michael Anderson
UT System TeleCampus
UT TeleCampus | www.uttc.org | www.uttcturns10.org
2. The beginnings of simulation
Learning objects
Tool templates
• Content control with faculty
• Design control with developers
UT TeleCampus | www.uttc.org | www.uttcturns10.org
3. Templates are a dead-end
• Reuse becomes overuse
•Computer interaction becomes
boring
UT TeleCampus | www.uttc.org | www.uttcturns10.org
4. The rules of educational play
• Competition – goal
• Narrative – case scenario
• Fantasy – tools to do things you
normally can’t do
• Choices – control, scaffolding,
uncertainty
UT TeleCampus | www.uttc.org | www.uttcturns10.org
5. Medical Domain
• Goal
• Situated case
o patient complaint
• Tool access for guided activity
o history, exams, labs and results
•Authentic performance
o diagnosis and treatment
UT TeleCampus | www.uttc.org | www.uttcturns10.org
6. The Domain Engine
Content UI
Components
Domain
Style Engine
Tools
Rules
UT TeleCampus | www.uttc.org | www.uttcturns10.org
7. Domain Layers
Click the XML
filename below to
see a sample.
Click here to go
to the next slide.
UT TeleCampus | www.uttc.org | www.uttcturns10.org
8. The Archetype Engine
Domain
Engine
Tools Rules
Elements
Archetype
Engine
UT TeleCampus | www.uttc.org | www.uttcturns10.org
9. Domain Analysis
• Deconstruction of learning goal
• Mapping to authentic assessment
• Construction of enabling
activities
• Building domain-specific tools
UT TeleCampus | www.uttc.org | www.uttcturns10.org
10. Compliance Domain
• Goal: recognition of a specific
requirement
• Assessment: correct quiz score
• Activities: matching appropriate
behavioral responses to scenarios
• Tools: accessibility toggle
UT TeleCampus | www.uttc.org | www.uttcturns10.org
11. Future Archetypes
UT TeleCampus | www.uttc.org | www.uttcturns10.org
12. Communication Says it All
Content UI
Components
Domain
Style Engine
Tools
Rules
RSS IMPP
Score
board
UT TeleCampus | www.uttc.org | www.uttcturns10.org
Despite that academic title, this session is about having fun. Now if you ask my 13- and 15- and 19-year old children what’s fun, they are sure to include video games as one of their top 5 answers. And not just any old video game. Online video games. And online social networking. And instant messaging. As I’ve struggled over the last 5 years to convince them that learning is fun—you can imagine the rolling of the eyes I get with that one—I have come to believe that it is incumbent on me to go at this thing backwards. Instead of trying to make formal learning fun, I believe we need to first figure out what’s fun—and then build those qualities into our learning. So let me start with a verbal picture, a narrative, a fantasy. As we’ll see in a moment, those are some of the qualities of games.
So, how did we start down this fun path? Learning materials that draw context from a specific instructor’s use and intent, which can adapt their style to fit the larger course of which they are components, and thus are reusable across a wide variety of learning situations offer the potential of efficient and engaging instruction. However, from a practical point of view, the UT System TeleCampus has faced issues implementing a learning object strategy due to faculty reluctance to reuse content. Despite familiarity with the textbook metaphor, online faculty have declined for the most part to incorporate third party content into their courses, choosing instead to create their own materials. The exception we have discovered after numerous trials and even more errors lies in the development of tool templates. Upon reflection, that makes sense. Tools place content control in the hands of the faculty. The technical creation and implementation of the tools allow developers to exercise design control. And the tools can be used in an almost infinite variety of pedagogical implementations. While they are NOT learning objects themselves, these contextually-agile tools serve as containers for specific pedagogical implementations.
After producing these and other tool templates over the past nine years, however, we ran into a dead-end: they are interesting for a while and they continue to be useful, but ultimately, they are boring. Layout templates, whether in Javascript or Flash, accomplish uniformity of navigation and style design but do little to further learning except to remove some impediments due to cognitive overhead. Course templates assure uniform application of structure for quality control but produce uniformly pedestrian content. And even interactive exercises with adaptive human-computer interaction—because it is scripted—becomes a predictable script. However, there may be a solution. Problem-based learning demands real-world (albeit simplified) simulation. A simulation engine that could pull its content (and its context) from external resources offers efficiency through the reuse of the engine itself—but would avoid the repetition because the content would vary almost infinitely in the same way that real life cases vary infinitely. And by further separating the style and user interface from the application code, learning creators could be unleashed from the tyranny of boilerplates.
And so we turned to games. What are the rules of play, to steal the title of a superb book on the topic, and specifically the rules of educational play? Here are some of the key characteristics that map particularly well to learning theory: Competition – games have a goal, a climax, an objective which is also the resolution of a story in many cases Narrative – good games weave a story that draws us in and gives us something to identify with and stimulates our memory; this narrative or metaphor situates the game Fantasy – games provide an immersive escape and provide players with tools to do things they can’t normally do Choices – games give players control to make choices; mastery is scaffolded as players level up but an almost infinite decision points means that outcomes are always uncertain
Let’s apply this to higher education—to a specific case study if you will. A few years ago, the University of Texas Southwestern Medical Center asked us to develop a library of learning exercises. The primary requirement was content scalability: the need for a mechanism that allowed medical faculty to quickly develop more educational modules, each oriented to the diagnosis of a specific disease, without needing to go back to Flash developers for each new exercise. The efficiency of a learning object approach offered a potential solution. However, the constraints imposed by a linear template ignored the potential diversity of diseases. To meet these two development objectives, the TeleCampus developed in 2005 and then expanded in 2007 a case study engine using an object-oriented separation of the content from the style from the case logic. In multiple interviews with medical educators, we defined the characteristics of a medical case problem. The consistent requirement was to situate the case in a realistic medical scenario which involved opening each case with a patient complaint. This had the additional advantage of providing an attention-getting motivational beginning. In order to inductively teach a standard operating procedure (no pun), the educators required patient histories, exams, and a differential diagnosis, followed by ordering lab tests. These processes defined the tools to be developed; other medical disciplines would use different tools. After the lab test results were evaluated and augmented by pre-scripted expert advice, students made a final diagnosis and recommended a treatment plan. In the case of the dermatology cases developed last year, the treatment plan had only a pharmacology component; however, other medical cases might involve multiple treatment modalities. For example, a case on psychiatric intervention—following the same general domain process—would require both counseling and pharmacology treatment modalities. Thus, even within the relatively narrow domain of medical cases, we quickly realized the need for flexibility in both the tools and the rules. Goal: recognition of a specific disease and treatment; Tools: image magnifier, family history, consultant advice, and lab tests; Activities: patient evaluation; lab results; and Assessment: correct diagnosis and care plan recommendation.
In the first design iteration, the medical domain engine hard-coded the tools and specific rules, and specific case characteristics were divided into user interface (UI), stylistic, and content components. For example: A necessary tool was an image magnifier. A necessary tool was a patient history or chart. A required rule (for these cases) was that learners had to run labs and get results before they could make a diagnosis. A required rule that quiz access is dependent on successful clinical progress. This approach enabled the use of custom components and self-contained interactive features; in the dermatology implementation, the Image Magnifier tool allowed students to view clinical images in greater detail. Other medical disciplines might require a different tool such as a customized video players; these devices can be easily integrated with the XML-driven interface through development of the required component and modifications to the application-specific logic layer—when to make the tool available.
In programming terms, this meant separating the application logic, the “top” layer, from the interface engine that handled the UI, content, and style; both of these code streams were built on a Flash 8 foundation. To facilitate the scalability of content development, a subfolder of XML documents was created to provide content developers with the structure they needed to efficiently edit the content for each section, as well as to define the media and data required by the application. An XML-driven interface layout engine was implemented to allow developers to extend the user interface via a single file which defines the navigation menu bar component, form components that contain nested display (such as text area or images), selection components (clickable areas, radio buttons), and form components that contain further nested components such as those that display feedback and progress in the feedback panels (Patient File). So how does this work at the layer level? The application interface and text content is is defined by the XML source document called Case Study. The logic is defined by the separate ActionScript file called Main. The layout engine, a series of ActionScript classes, applies the logic (essentially the “game” rules) to the interface and the external text, image, audio, and video content files. The advantage of this approach is a clear separation of the GUI, rules, and content files. The faculty content developer simply edits the text content files and adds new image files into the content folder to create a new medical domain case study. The style itself is easily modified in the style header section shown in the example. More importantly, from a reuse perspective, the application developer can redefine the case study application interface for a different discipline and create a new set of discipline-specific requirements by editing the configuration and component definitions within the single XML source document and by modifying the main.as application logic file to accommodate specific interactivity requirements of the new case implementation. This is basically where we where we were in 2005 when the 2004 prototype of this project received a Computer World Heroes Laureate award.
While this specific interior engine design seems satisfactory for the medical field, when rewriting the engine to be accessible, we started thinking about PBL in other disciplines such as Law, Business, Anthropology, and Political Science—indeed any field of study in which case-based learning provides an academically-acceptable instructional paradigm—may require a different set of rules and tools. For example, the medical case engine specifies that learners must conduct a physical exam of the patient before making a differential diagnosis; they must order labs and procedures before recommending a treatment. While this ordered progression is endemic to the diagnosis and treatment of disease, cases in the social sciences may require an oblique structure. As a result, the case application was redesigned as an engine within an engine to allow greater reusability. The core “elements” define the implementation of the archetype for each discipline.
Pedagogically, that means the archetype engine can be considered a meta-template, not only for case-based learning designs but also for scenario and constructivist paradigms. Whatever the specific instructional design model, a similar analysis proceeds: Deconstruction of the learning goal layer; Mapping that goal layer to an authentic assessment; Construction of enabling activities; and Making available those domain-specific tools of invention, discovery, and community that guide the activity performance toward the goal as measured by the assessment.
If this archetype approach was real, we had to make it work with a completely different domain—so the next field we selected was compliance training. This instance of the case engine replaced the components on a one-for-one basis. However, a revision at the meta-template layer to create a scenario-based compliance training module using the same archetype produced a distinct but instructionally-equivalent analysis from the identical archetypical codebase. Let’s see what that looks like. Goal: recognition of a specific compliance requirement; Assessment: correct score on a quiz; Activities: matching appropriate behavioral responses to scenarios; Tools: an audio or text accessibility toggle and access to applicable policies. This is where we are today: a generalized PBL template driven by XML files for content and style and by configurable Flash components for separate pedagogies. But we’ve failed to address a key aspect of gaming.
“ What we have here is a failure to communicate.” (from Cool Hand Luke )
This is what we’re missing—communication. Future development of this and other envisioned learning archetypes will incorporate outbound messages such as RSS, assessment posting to a scoreboard (similar to a high-score leaderboard in online games), and a RESTful implementation IMPP, a standards-based instant messaging protocol that will allow learners to find and communicate with other learners who are online at the same time. This is where we want to be…but we need help.
In order to accomplish this, we will be releasing next week the case archetype code as a Creative Commons work under a non-commercial, attribution, share-alike 3.0 license. We hope that by doing so, we will encourage other developers to not only work with the Action Script classes we created but also release their own projects. Our vision is the employment of games and simulations, not as content repositories, but as learning engine archetypes populated by personal XML and media. We see these engines as giving us a fun place to play, because more than anything else, we have come to believe that if we can play as we learn, we will once again learn to have fun learning.
