Outbreak Quest: A 90-day Game Development Initiative

Outbreak Quest: A 90-day Game Development Initiative

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


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.



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



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.


Project Roles





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

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

Academic ADL Co-Lab Lead Judy Brown,



ADL Co-Lab

Kurt Squire

- Liaison between CDC and Academic ADL Co-Lab

- Ensure project stays on track to meet Co-Lab’s goals

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


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.


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,


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)


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.


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.”


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


“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.


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


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.


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.


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


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.


Game Maker


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


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.


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


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.


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.


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


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.


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


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.


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.


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.


Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Related manuals

Download PDF