Overview | Instructional Objective | Learners | Context | Scope | Object of Game | Design Details
Competing Products | Motivational Issues | Design Process | References
150,000 people were placed on home quarantine during the SARS outbreak in Taiwan alone, a country with a population of just 23 million. The SARS outbreak cost the world's airlines and global economy more than the attacks of 9/11, and health experts say SARS will come back. Ignorance regarding the nature of SARS was largely to blame for it's rapid spread, particularly within hospitals. This simulation attempts to help players determine what measures are most effective in containing an outbreak of SARS in a hospital while causing as little disruption as possible to routine hospital function.
Players are presented with a small hospital, and they must make decisions regarding how incoming patients are processed and how the hospital environment is managed. Players manipulate a wide range of variables regarding symptoms, patient routing, and the hospital environment. Players can create a quarantine area, and decide how patients are handled according to their symptoms.
Once the player is finished setting all the variables, the virus appears in a random location. As the virus spreads, the player can make adjustments to the environment and human variables in a desperate attempt to control the spread of the virus. But if the player applies draconian measures recklessly, organizational problems emerge.
This simulation is meant to show players how behavior, decisions and environmental design and management affect the spread of the SARS virus. The rapid spread of SARS in the spring of 2003 was largely due to ignorance regarding how to prevent and contain the virus. This simulation hopes to teach proper prevention, monitoring, and containment procedures. Players will learn how changes in daily routines and in handling suspected and confirmed SARS cases can contain the virus.
This simulation targets health care professionals, workers, and administrators. The simulation is primarily meant for those working in hospitals, clinics, and long-term care and assisted living facilities, but it could also be of value to public officials, students, and people involved in other situations that include a high degree of public contact.
This game is designed to be played within the context of a wider training program for SARS taking place in the health care facility. It could be played by individuals or groups; however, given the complexity of a health care environment and the variety of stakeholders involved, players would probably benefit most by playing with their coworkers, particularly with coworkers from a variety of disciplines. It is not a multiplayer game in principle, but it supports multiple scenarios using a database, so players can compare their results. The game is meant to be played more than once, with the player testing a variety of combinations of patient and environmental variables.
An introduction to how SARS is transmitted prior to the game could serve
as an introduction to the game. However, the game could also itself serve
as an introduction to a workshop on SARS. Given a group of players who
know little about SARS, playing the game before the workshop would probably
result in high transmission rates and generally poor performance in the
simulation, thus increasing participant curiosity, interest, and motivation.
Repeating the game during the workshop would then serve to reinforce and
demonstrate the usefulness of learned material.
This game allows the player to set variables in an environment into which a virus is introduced, and then observe how the virus spreads. The length of the simulation is determined by the player. The player can choose to run a simulation lasting only a few minutes, but it could easily take over 15 hours to conclude a more involved simulation. In fact, the player can choose for the simulation to progress in 'real time', meaning it could last for days or even weeks.
The players have to set a variety of variables that affect the transmission of the virus. The interface breaks these variables down into two categories, those for the patient and those for the environment. The variables for the patient determine where the patient will go in the hospital, and those for the environment determine how the segments of the environment can be accessed.
The object of the game is to contain the virus as completely as possible while causing as little disruption to normal hospital routine as possible. Before and after the virus appears, the player decides which containment measures to implement, and most of these measures place restraints of one sort or another on regular hospital activity. At the end of the simulation, the player is scored on two performances: the extent to which the virus was contained and the extent to which normal hospital activity was not impeded.
The primary model for the simulation is based on a StarLogo simulation for the SARS virus. The StarLogo model interacts with a case-based model that essentially determines if particular turtles may enter specific segments of the environment according to variables set by the player.
Initial Game State & User InputThe screen shot and user input forms below demonstrate the beginning state of the simulation.
The variables set for the patients direct the running of the StarLogo
model, while the variables set for the environment call up the appropriate
state-based model for that combination of variables.
When the user adjusts the variables for the patient, these are applied to all patients entering the hospital. Patients will then continue to move in and out of the hospital according to their defaults. For example, a woman giving birth might stay for a few days, a person arriving for minor surgery might leave the same day, people coming for regular appointments will represent a steady flow, and occasional accidents will flood the emergency room.
The default setting for the sections is very low. There are no default protections. The virus will spread very quickly if the user does not create some physical 'roadblocks' for it using the environment variables. There is no default quarantine area because the simulation assumes a pre-SARS environment. The player can create a quarantine area by manipulating the segment variables.
User defined settings
The user defines patient and environment variables using the following
map, legend, and forms.
THEN send patient to segment
| ENTRY REQUIREMENTS
completion of questionnaire regarding symptoms and recent travel or contact with SARS patients
sterilization scheduled every hours
no entry to public
NO ENTRY EXIT if
of the following symptoms present:
SARS positive within the past 3 weeks
Set universal variablesTime lapse minutes:hours (X minutes = X hours)
Turtle size (pixels) What is this?
When the simulation runs, patients, employees, and visitors to the hospital interact according to the StarLogo model and the variables set by the player.
Random appearance of virus
Once the simulation is started, a case of SARS appears in a random location. Sections of screen shots are used for the following sequence for the sake of clarity. Notice the 'red' patient in the first shot, indicating the first appearance of SARS.
From this point, SARS spreads according to the variables set. In our example, the player has not set the variables very effectively, so the virus spreads to nearby patients and employees, as demonstrated in the next screenshot.
Interaction of virus and variables
Though most of the infections are within the immediate proximity of the first one, notice that one case, an employee, has already migrated to the blood bank, certainly unaware that she is a carrier.
The initial case has since died, as indicated by the black square. Just as living patients that do not have SARS eventually leave the hospital, dead patients, regardless of how they died, eventually disappear as well.
The scoring for the performance in the simulation is shown when the player stops the simulation. The scoring is based on two types of performance: how widely the virus spread, and how effectively containment measures were applied.
The most applicable motivation theory for this game is Keller's ARCS model. The game is clearly relevant to the player, assuming he or she is working in a health care environment. By giving the player control over the simulated environment, the game allows the player to build confidence by improving the outcome over the course of multiple simulations. Finally, the player experiences satisfaction by eventually halting the spread of the simulated virus and saving lives.
The conceptual process was long and frustrating. I originally envisioned a much larger, more flexible simulation allowing for player created environments and all sorts of physical and behavioral variables to be set by the player. Dr. Dodge injected a needed bit of reality into my plans, in terms of identifying what is feasible and what isn't. I eventually narrowed the scope of the simulation to its present form. Once that definition was achieved, the rest fell into place fairly easily.
One interesting part of the process was that when I started putting together the interface for the simulation, I found that I had not thoroughly defined a number of elements. In other words, the process of designing the interface brought to light a number of weaknesses in my concept, and forced me to clarify a number of points. For example, prior to designing the interface, I had not carefully considered the relationship between different turtles (patients) and how they would interact with variables set by the player. I knew that I wanted the player to set variables that affected where the patients went in the hospital, but I hadn't considered the mechanics of that. Creating the interface forced me to identify and categorize variables into those affecting the StarLogo model and those affecting the case-based model.
I still need to learn a bit regarding the possibilities and limits of both StarLogo and case-based models, and if I were to pursue this or another simulation, I would start by sharpening my programming knowledge.