Outbreak Quest: A 90-day Game Development Initiative

Academic ADL Co-Lab University of Wisconsin System Administration

Monica Marlo Martinez-Gallagher, Dan Norton and Staff May 2004

1

Abstract

In February 2004, staff from the Academic ADL Co-Lab and the Centers for Disease Control

(CDC) set out to build the prototype of a game for public health workers to identify a potential

outbreak. This initiative had a self-imposed deadline of 90 days to determine just what resources

would be needed to complete a larger initiative.

2

Introduction

This project was a collaboration between the Centers for Disease Control and Prevention (CDC)

and the Academic Advanced Distributed Learning (ADL) Co-Lab, and involved the creation of a

pilot simulation of one partial scenario encompassing the activities and events leading up to the

detection of a potential outbreak at a state or local health department. This simulation was created

within the context of a self-instructional training product for front-line public health workers on

outbreak detection and initial response.

Initial Project Description

The end product for this project is intended to serve as a model for the complete training product on

outbreak detection. A description of this complete training product is provided in “Appendix A:

Complete Simulation Training Product Description”.

The pilot simulation includes elements of one functional scenario which simulate the events of the

“Outbreak Detection Process”. The visual treatment of the simulation is one in which the student

will feel immersed into the scenario. The interface is designed to be intuitive and representative of

the typical tools found in a public health setting.

For the pilot, developers at the Academic ADL Co-Lab used a product entitled Game Maker, so that

within the initial compressed development time period, the majority of the time could be spent on

the interface and interactivity, rather than the underlying engine.

As developers created the pilot simulation, we took into account the following requirements for the

complete simulation training product:

• be as 508-compliant as possible given current development tools and technology. • be compatible with standard Microsoft Windows operating systems, Macintosh (OS 10 and

above) and Linux. • operate on a range of playback options including:

o online via Internet browser with both low and high connection options o downloadable from Internet for local playback o stand-alone media such as CD browser locally; executable version

3

Goals

Create a self-instructional training module on outbreak detection and initial response for front-line

public health workers. This phase of the project is intended as ‘discovery’ of requirements for

further development of a complete game module.

Process

Project Roles:

Nancy Gathany, CDC

Project Lead

- Ensure project adheres to schedule and scope as closely as possible and stays on track to meet CDC’s goals - Review for scenario content and draft products for appropriate design strategies given content and audience - Provide available CDC resources as needed

Jeanette Stehr-Green, MD, PHF

Leads/Subject Matter Expert

- Outline scenario content and possible student options (i.e., most likely actions that would be undertaken in response to specific events) - Develop characters involved in scenario and likely content of conversations - Provide scientific information/basis needed for scenario - Coordinate and interpret input from other subject matter expert reviewers (including initial review of prototype) - Review product for realism

Judy Brown, Director, Academic ADL Co-Lab

Academic ADL Co-Lab Lead

- Liaison between CDC and Academic ADL Co-Lab - Ensure project stays on track to meet Co-Lab’s goals

Kurt Squire Consultant on game design, pedagogy and assessment

Dan Norton Lead User Interface and Visual Developer

- Knowledgeable Game Resource - Graphic Designer and Developer

Monica Marlo Art Director / Lead Illustrator

- Illustrator - Graphic Designer and Developer

Project Communication

Conference calls with the Academic ADL Co-Lab and remote partners took place bi-weekly for the

first half of the project. These became weekly meetings for the last half of the project, as the need

arose for more close contact with our subject matter expert (SME). Following a structured agenda

4

each week, these sessions were used to gain feedback on design iterations, clarify script questions,

and share what our remote teams were discovering about the design process.

Decisions

Game Design

OutBreak Quest uses very traditional game play designs. In its look and feel, its objectives, and in

the way it interacts with users, it draws upon several gaming genres and sub-genres.

OutBreak Quest can be easily, though not most accurately, compared to the adventure games that

game players have played and enjoyed for years. Within the traditional adventure game format, the

player navigates from one location to another, encountering puzzles and clues. By successfully

solving each puzzle the player propels the game’s plot forward. One example of this genre of game

is Myst, in its time an extremely popular adventure game for the PC, and one of the best-selling

computer games of all time. Depending on his or her style of game play, a player could be playing

to either solve the puzzles to advance the plot, or advance the plot to solve more puzzles.

The structure of Outbreak Quest is similar to that of Myst. Both have specific spaces, or “rooms” in

which the player encounters challenges and puzzles. In both, the player navigates between spaces

and encounters new game elements and puzzles.

Outbreak Quest differs from Myst in some important ways, however. In Myst players used

analytical and logical skills to solve puzzles. In Outbreak Quest, players use investigative decision

making to advance the plot. A player in Outbreak Quest can still be motivated by a desire to solve

puzzles or to advance the plot, but in place of puzzle solving, the dialogues and interactions

themselves serve as the temporal incentive to propel the character forward.

Many contemporary games have structures analogous to those encountered in Myst. The PC game

“Law & Order” and its sequel are very similar to Outbreak Quest. Both involve navigating between

different locations, collecting information, and coming to conclusions. The differences here are

mostly in aesthetic and tone, budget and time.

Perhaps the “true” root or inspiration for the structure of this game, and also of the “Law & Order”

series, is traditional text based adventures. Many game genres owe a debt to this early game-type,

5

and Outbreak Quest, as well as “Law & Order,” can be seen as modern interpretations building on

this earlier model.

In a text adventure, a text narrative describes the players’ location, and players are prompted to

describe the ways they interact with the world by typing in text themselves. Much like in Outbreak

Quest, players navigate through an environment, encounter characters and situations, receive

positive and negative feedback based on their decisions, and advance the narrative.

Many text games, and later adventure games, require that the player gather a number of items while

he or she navigates through the games. These items are kept in the player’s “inventory” and can be

used later to overcome obstacles. Thus the player can acquire a key to open a door, or an Amulet to

destroy a wizard, etc. Outbreak Quest uses the same model, except that instead of the character

arming themselves with a sword and shield, the character is arming themselves with facts and

forms. Disease investigation relies on the investigator to build their own story, the story of a

disease’s development and spread.

One could argue that a disease investigation is not a quest through a fantasy world. However, the

role of an epidemiologist is uniquely suited to this type of structure − a game that requires

interesting characters, pseudo-linear game play, and threaded positive and negative feedback.

User Interface (UI)

6

Many within the gaming and educational communities believe that an attractive and user friendly

UI is just “eye candy,” and that to develop a successful game all that is needed is good game

structure. It is true that incredible graphics and lavishly rendered interface elements are not

requirements to an immersive gaming experience.

However, UI design is essential to good game play. Ensuring the quality of a UI also requires

extensive testing. Given the deadlines on this project, developing a deliverable beta, an extensive

post-development testing phase was not possible. Instead testing was done throughout the

development process. Additionally, our decision to use Game Maker as a development tool had

such an impact on many aspects of our UI design that we had to develop a separate module not

developed using that tool to demonstrate the UI interface that we envisioned for the final version of

Outbreak Quest. Given that UI usability and game play are so closely linked, our ability to game

play test was limited.

Explanatory entry screen

The ways in which users interacted with the introduction screens for Outbreak Quest provide good

examples of how game play and good UI are interrelated. In the version of the game that users

tested, introduction screens explain much of the background of the game, providing information

about the game’s goals, game play, and usability. Testers, however, found it easy to skip these

pages, if they deemed them to be “click-throughs,” like much online content. Because of this, some

users wound up in first scene of the game with no clue as to who they were, and what they're

objectives were.

7

The Player Office

Leveraging more of the actual game description and help into the game play itself would have been

far more effective. An example of this type of feedback would given notes from a mysterious

character, attached to throwing stars be that found in the Xbox game “Ninja Gaiden” In this game

the player begins the game in a safe environment, and is given notes, attached to throwing stars,

from a mysterious character. In-game notes offer basic information about game play, and user tips

to help the player solve simple puzzles using the controller’s extensive array of buttons. Game play

can teach UI, and UI affects game play.

Another compelling example of the interrelation between UI and game play comes from the 2004

Indie Game Jam, a contest to create an interesting game in four days. To win the contest developers

rushed their prototypes out of development to explore different aspects of game play and

development. One game, called “Robot Circus,” by game designer Charles Bloom, was described

by the creator:

“(it was).a robot circus that never really became a game. I wired these

complicated controls where you could hook up, I had like mouse and keyboard and

game pads all controlling different levels and springs and widgets on these robots.

The idea was to play with different kinds of robots and direct control, and see if it

was possible to learn to control these weird devices and make them do something.

It actually wasn't. It was really fun to make the robots but it wasn't fun to do

anything with them, was the problem.”

8

As the reader can see, even when a game is designed so that a challenging UI can be an element in

game play, even the developer can concede that behind the flashy UI there is no game.

Outbreak Quest’s UI went through many iterations and sub-iterations. Originally, the UI was going

to have more features, and be split into two distinct sections: User Tools and Room Tools. User

Tools were “items” that were always present and permitted a variety of user interactions with the

game at any time. These included a list of forms to reference, and buttons permitting navigation out

of whatever room in which the player was located. These were persistent from room to room and

were placed in the upper left hand corner. In the upper right hand corner, Room Tools were unique

to a specific room or place within the game. By clicking on the Room Tools, players could initiate a

conversation with characters in the game, and access items in the room.

The Boss’ Office

At that point users had access to the phone, office forms, and other items that would be user tools in

a projected interface for future version, by clicking on objects in that room.

It is unclear whether having the user navigate through the office by clicking on objects in the room

was more effective in facilitating game play than providing them with an array of buttons. Many

classic “puzzles,” which users often found frustrating, may arise when users can't see or locate

elements of use to them. A small key on the ground may go unnoticed, for example. These were

leveraged in early Sierra titles like the King's Quest series to challenge users, but most often players

met these challenges by “cheating” − relying on a hint program or asking a friend to tell them where

to click and how to move on. This could be construed, although some may not agree, as another

9

“UI-as-game play-challenge” failure, like Robot Circus. However, even in new user created

renditions of these classic games, “pixel hunts” are still present as game play elements. Whether this

is merely homage to a classic convention or a statement of the quality of the technique is debatable.

Our testers and projected users for this game may not be traditional game-players, and we could not

assume any game play literacy on the part of users when designing the UI. One particular instance

of note was early on in development, when we discovered that the term “inventory,” which is very

commonly used in adventure games as a reference to the character's collection of items, was

baffling to some users who were not familiar with games.

Overall, given restrictions on development due to time and the Game Maker tool, many challenges

relating to the UI are still not resolved. Hopefully, with further development, more extensive testing

and prototyping on a more robust platform will enable us to refine the product further.

Graphics

Since Game Maker is a 2-D game tool, and our game is additionally 2-D, it was decided early on to

not attempt photorealism or 3d modeling for the graphics of the game. Instead, graphics were hand

drawn by Monica Marlo and Dan Norton (using Adobe Illustrator) and using photographs as

references. Occasional photographic elements were collaged in as well.

Mark Braun, Bistro Manager

Characters were all rendered by Monica Marlo, with the exception of Roger Snow, who was created

using a tool called Oddcast. Oddcast is predominantly used for the animating of characters for

10

online use in Flash applications, but his character was sampled and brought into the game. Later, we

used the same character from Oddcast in the Flash demo, but now animated, using Oddcast’s tool.

Additionally, the artists visited a public health building in Madison, Wisconsin, to acquire more of

the visual aesthetic of epidemiology. A large amount of wall art and posters was photographed, and

for further development of the project it will be incorporated into the game’s surroundings to

enhance the ambience.

Example of forms in game.

Some base level graphics were rendered using Game Maker itself, such as the text boxes and

majority of the text itself. The notable exception was the text that appeared next to buttons. The text

was originally rendered by Game Maker, but testing revealed issues with making text clickable, and

all buttons were replaced by externally rendered graphics.

Tools

Game Maker (http://www.gamemaker.nl/index.html) was used to create a prototype of a traditional

dialogue driven adventure game, similar to Myst. In the adventure game genre, the player takes the

role of a particular character, and progresses through a story by talking to characters within the

game and interacting with their environment. Everything is pre-scripted, and the game is purely 2D.

This type of game structure is ideal for pushing a narrative structure − it's similar to interactive

fiction, as discussed in the book "Twisty Little Passages", by Nick Montfort, but with graphics and

graphic representations of common commands.

11

Game Maker was selected because of its intuitive programming structure and its built-in structures,

allowing us to easily construct games that fit with our game model. Game Maker has built-in tools

for constructing rooms, items, and graphics for a game.

The developers’ background was with ActionScript programming in Macromedia Flash. Game

Maker shared much of the standard ECMAScript syntax used by Flash, but there were several

differences. Most of the opinions here regarding these issues will be in relation to the developer’s

experiences as Flash programmers.

Game Maker − Advantages

Game Maker was very effective as a tool for creating prototypes. It let the development team build

the beta quickly, and quickly allowed for game play, UI, and structural issues to be discussed.

Extensive redrafting was possible as new game play elements were tested and reviewed, enabling us

to make decisions regarding basic UI and game play quickly. For example, the model for

representing the conversation in two windows next to each other went through extensive redesign.

Originally conceived as one panel, it was then changed to two. Later revisions changed the presence

of the second window from permanent to intermittent. Using Game Maker, these drafts were able to

be drafted and reconsidered quickly, with little effort.

Game Maker also offered a quickly graspable programming language, driven by graphic

representations of code. The ability to generate logic visually further accelerated the prototyping

process. The language and logic behind the game structures was exceptionally easy to design, edit,

and describe.

The sprite object system was easy to manage and implement. Objects use sprites, and sprites can be

changed as necessary to design new elements of UI, background objects, and more. This enabled us

to simultaneously design individual graphics and the look of the game as a whole while

programming it, and in many cases a simply reloading the graphic was all that was required to make

a change.

The built in room architecture was also efficient for design. The team was able to construct logical

structures for each room, allowing them to better maintain and keep track of the code. Once the

script began being implemented in earnest, and an extremely large quantity of text objects were

being handled, this was essential.

12

Game Maker − Drawbacks

The biggest hindrance for this prototype was the way Game Maker handles text. Game Maker

creates text on screen from a given x-y coordinate. All indentation and line breaks must be hand

written, so as to make them fit into the correct space. Additionally, text must be put into a very

small window − one line, maybe thirty characters long. After thirty characters, the text scrolls.

There is no way to view the text in its entirety except by mousing over the current code object, and

there is no way at all to see the indentation except by running the game and testing it. Since some

text occurs fairly late in the prototype, testing was extremely time consuming.

Additionally, rendering text on screen is an enormous processor hit, and it is believed to be the

cause of several bugs that still exist in the prototype. If several text instances are on screen at once,

the game can slow down, and in some cases stop. This occurs even though there is nothing else

occurring on the computer. The solution would have been to pre-render all text as graphics, but the

loss of the ability to edit text and time required to pre-render all text screens was unacceptable for

this project.

Another drawback to Game Maker is its lack of object oriented development. With each text box

requiring personal attention for fitting text, box sizing and menu placement, what was great for

prototyping became poor for scaling. Using an alternative development platform, creating a generic

text box component that could have dynamically scaled to the correct size would have been more

time consuming up front, but would have led to superior efficiency in the end. Even the small scope

of the prototype began pushing the limits of what could be handled by hand.

Alternative Design

Given our limited development timeline, we were forced to belay creation of our ideal game demo.

During the final week of development, additional hours were put into the project to create a

Macromedia Flash version of one scene. This file was intended to project what a final version of

this game would both look and function like.

Oddcast VHost technology (www.oddcast.com) was used to rapidly deploy characters in the game

that were able to speak their own scripts. Stanford University has established through research into

avatars and education that information delivered via a “talking head” can be more engaging and

well received than in text or text and static images alone. We hope to harness that intrigue to deliver

13

content to the end user that engages them to both retain what is presented, as well as the desire for

further information.

The user interface evolved to include proposed visual meters of time, budget, and goodwill, all

factors that will be tracked to assess performance, and offer relevant feedback for the game playing

student. A physical “map” was also added to the interface to aid the player in situating themselves

in the game environment. By creating virtual physical distances between interaction points in the

game, an auxiliary level of consequence (in the form of virtual motion between points costing time)

could be factored into the game. This was done in our attempts to honor the idiosyncrasies of

disease investigation in real time, without offering the banal actions of actual movement about the

environment.

Discussion

The only real difficulty on the project was the time scale. The allotted 3 months to create a game

prototype was extremely short, and the lack of time for testing and QA hurt the delivered project.

Production of the prototype went very smoothly, with only a few hitches to the process. Game

Maker was a solid and adequate tool for our purposes, and the game play was refining rapidly over

14

weekly meetings with the team. However, the process of refinement and feature addition was cut

short, and the focus of the last week of the project was simply to finish the project as much as

possible.

Since the game play prototype was made using a very basic tool, and there was no time for edits

before presentation, the prototype was not nearly as polished as it could have been for presenting.

After the initial presentation, another two weeks was put into user testing and bug-catching, which

resulted in a smoother, more presentable product.

In order to further develop the game, extensive time for testing, both in the beginning and end of the

project will be required.

Results

Presentation: Wisconsin Department of Public Health

To get initial reaction and feedback from members of the target audience community, the elements

of our presentation prototype were taken to the Wisconsin Department of Public Health (WDPH)

for a ninety minute discuss and probe walk-through of the materials. A short survey garnering

department position, verification of involvement with games and a self-rated scale as to gaming

experience level was completed by approximately eighty percent of the participants. The Academic

ADL Co-Lab presentation committee consisted of Monica Martinez-Gallagher, Dan Norton and Dr.

Kurt Squire.

What we found when discussing the project with people who work in the field, and afterward in a

casual post-presentation meeting, was that most of the group could see something like this aiding a

novice epidemiologist to gain more interest in the subject, but that the information that we had

provided was far to shallow a survey of the subject (symptoms, available questions to ask, etc.) as

well as a little ‘preachy’. When shown the talking version of Roger Snow, there was a rather

unanimous vote that even if the characters spoke, potential players desired the ability to turn sound

off in an office environment. There was some recognition in how sound effects could assist in

setting a mood and tone for the game. They seemed less than enthusiastic about talking characters

altogether.

15

The presentation began with the trailer being shown, sound being played out of laptop speakers

which were less than ideal for the purpose, but adequate. The file being displayed at original

resolution wasn’t large enough to be useful for the projector, and when expanded lost it’s masking

abilities. It would do presentation of these materials well to receive a resizing for higher resolution

monitors and presenting. There was general laughter about the room, and when asked why they

laughed, the response was that it was a very dramatic opening, cinematic, maybe too dramatic, as

the drama might be construed as playing on the fear factor of public health. There seemed to be a

disdain for the use of such tactics in the participants’ underlying response. Suggestion was made to

make it “local” rather than “metropolitan” health department, so as not to alienate smaller

departments. Also, graphics could be maybe not as ominous and conspiratorial feeling – the group

definitely responded negatively to anything that suggested the fear and unknown element of their

function in society.

There was a good general understanding of what the Flash User Interface (UI) was representative

of, which we presented next. A request of making what type of goodwill that slider represented was

made, as well as raising the contrast on the green budget bar. It was difficult to see when projected.

There also seemed to be some ambiguity as to what the difference between the ‘Info’, ‘Help’ and

‘PDA’ buttons was. When asked how many of them had and used PDA’s, about half of the group

possessed some form, and about half of them (about a fourth) reported that they use their PDA’s for

contacts,(especially during an outbreak), addresses, appointments; general ‘Outlook’ type duties.

The in-game forms seemed less than intuitive to them. Access to the forms, as well as their general

function in the game, were both unclear. When probed with the question as to whether they would

prefer to keep notes in some sort of online diary, or rather just have a pen and paper in front of

them, their response was that it would seem a more authentic experience if the user were required to

keep notes on their own, discerning what of the interaction with the game character was pertinent to

record. Maybe to that end an additional feature the game might possess would be the ability to print

out the forms, rather than or in addition to making them available in-game, so that players can

physically fill out the form they are collecting information for. Maybe the ability that is now present

to auto-fill out information as interactions amongst characters happens could be a selectable option.

Another suggestion that was made by participants of the focus group was that we should attempt to

incorporate a deeper intimacy with the tools of their trade. An example of this would be to

16

incorporate the actions of creating a line list and “epi-curve’” of known cases to determine outbreak

status.

The presentation group was lively and responsive, and open to our questions and probing. The

presentation lasted one hundred minutes, and the majority of it was recorded via digital camera by

Dr. Squire.

The Trio

Our presentation files consisted of an HTML page that launched the trailer (Flash movie) the

alternate version in Flash, and the Game Maker version.

Outbreak Quest Trailer

This thirty second cinematic style opening puts both Academic ADL Co-Lab and Centers for

Disease Control branding on the prototype. Using sound and a slow pan down an animated

monolithic building proclaimed to be the “Metropolitan Health Department”, a first person

perspective camera shot follows point of view to the sound of footsteps approaching the building to

dramatic music. A cell phone rings twice, it is answered, and out fades the scene, in fly the words

“Outbreak Quest”.

Flash Alternate Version

A single page interaction with content, button and icon map driven navigation of information and

places. Oddcast ‘VHost’ character placed to read text that also is available for player review via

scrolling text box.

Game Maker Version

The game is playable through the entire script, with the exception of the conversation with Dr.

Hudgings and the laboratory. The file size is roughly 4MB, and is compressible to roughly 2.5 MB.

It is a standard Windows executable, created by the Game Maker tool. This file gives an example of

game play flow and was a test bed for basic UI drafting.

17

Proposed Development Cycle Changes

Since the most difficult part of building the prototype was dealing with text issues, an immediate

switch to a Macromedia Flash engine driven by XML and possibly some further application

language and database technology that would support the possible integration of sequencing into

game play via SCORM 2004 guidelines would be required for further development. Further

development of the script would be needed as well − we have 20% of the entire script thus far. This

game could be testable for hands-on play if this switch in technology were made, and the entire first

part of the script were finished, now that we know better as a team what is necessary to create such

a script.

The division of content for team development, review and editing further supports the technology

evolution to a rich internet application built with a Flash front end. With careful planning of the

structure to be as extensible as possible for its future use in alternate scenarios (possibilities of

bioterrorism, communicable disease, and career guidance were all suggested) the project would be

structured to be more simply divided amongst team members. One suggestion toward this end

regards the naming of text parts (text that displays with each choice made, character interaction,

etc.) − this started out very matrix oriented, based on an arbitrary numerical structure. Were this

system slightly altered so that names of text parts correlated a real world understandable name to

the game so that it could be understood to program with, wiring the game flow to match the

progressive logic of the script would have been a more streamlined task, if both are listed in a parent

document script,

Budget and Timeline Estimations

The initial planned timeline for this project was 12 weeks, though the first two weeks were given to

project planning, asset gathering, and many discussions amongst remote teams as to what this

project was to be. Taking this in consideration, the development cycle was allotted 10 weeks, and

then there was some edit time of the materials between the end of the development cycle, and the

final presentation to WDPH. Considering that during this time we got approx 20 % of the script

done, and 10% of it added into media content, projections suggest that full creative development

and iterative testing of the script would take approximately thirty more weeks;. A rebuild of the

interface in to a Macromedia Flash based XML environment would also take approximately that

much time. Further illustrations to flesh out the story, a revisit of the interface based upon feedback

from the WDPH presentation would all take time. In depth user testing should be done at the next

18

phase of development’s roll out, upon 100 % completion of one scenario of the script. This would

reasonably add approx. twelve weeks to the development cycle.

19

Appendix A: Full-Scale Simulation Description

The final file format for the simulation has not yet been determined but may be Macromedia Flash

or Macromedia Director. We would strive to be as 508-compliant as possible given current

development tools and technology. This product would be compatible with standard Microsoft

Windows operating systems, Macintosh (OS 10 and above) and Linux. We will consider a range of

playback options including:

• online via Internet browser with both low and high connection options • downloadable from Internet for local playback • stand-alone media such as CD browser locally; executable version Selection of playback options will take into consideration the hardware and software available to

the target audience.

Intellectual documents

For this collaboration, documentation is critical in order to facilitate development of subsequent

scenarios and future simulations. The team plans to create a series of documents that describe the

“standard best practices” of the process undertaken to create the simulation. The “paper-trail” will

also include the instruments used for formative testing and summaries of those tests. The

intellectual documents will be in the public domain.

Code

The scenario specific code (graphics, etc.) is in the public domain and will be available upon

request. However, reusable code is owned by University of Wisconsin Board of Regents and will be

licensed for free use & reuse by the Centers for Disease Control and Prevention but not for

distribution by CDC. The purpose of the licensing is to protect the generic code from non-CDC

uses. The reusable code will be separated and obvious to any developer, and likely not visual but an

'engine' that loads and runs the simulation.

Compiled Code

The compiled code which consists of the Shockwave Flash and Executable files that learners run is

completely public domain.