Lab Two
Prototype
Product
Specification
For Dr.
Sawbones
Vs. the
Medical
Monsters
Professor Brunelle
Lab 2 Version 2
March 14
2012
CS 411W Lab
II prepared
by: Michael
Peterson, Red
Team
1
Lab Two
Contents
Figures ........................................................................................................................2
Introduction ................................................................................................................3
1.1 Purpose .............................................................................................................4
1.2 Scope ................................................................................................................5
1.3 Definitions, Acronyms, and Abbreviations ...................................................7
1.4 References ........................................................................................................9
1.5 Overview ..........................................................................................................9
2 General Description ................................................................................................9
2.1 Prototype Architecture Description .................................................................9
2.2 Prototype Functional Description ..................................................................11
2.3 External Interfaces .........................................................................................16
2.3.1 Hardware Interfaces ................................................................................16
2.3.2 Software Interfaces .................................................................................17
2.3.3 User Interfaces ........................................................................................18
2.3.4 Communications Protocols and Interfaces .............................................20
Figures
Figure 1: MFCD .......................................................................................................11
Figure 2: Reporting Algorithm ................................................................................12
Figure 3: Monster Database ERD ............................................................................14
Figure 4: Medical Database ERD ............................................................................15
Figure 5: Game Database ERD ................................................................................16
Figure 6: Controller Mapping ..................................................................................17
Figure 7: Game Site Map .........................................................................................18
Figure 8: Menu Interface..........................................................................................19
Figure 9: Heads Up Display .....................................................................................20
2
Lab Two
Introduction
Right now in America, childhood obesity and consequently diabetes are on the rise. The
current methods of treatment are ineffective to combat this rising epidemic. Every year, roughly
15,000 children are diagnosed with Type 1 diabetes. Over the last 30 years, one third of all
children in America have become obese. According to a new U.S. Center for Disease Control
and Prevention study, the annual medical care for children with diabetes is six times higher than
medical care for children without the disease (Herzog, 2011). A large portion of this cost is due
to the education required of the child to learn to manage their disease. This education is
currently provided by doctors and certified experts through one on one appointments which can
become quite expensive. This cost falls mainly on two individuals: the parents of the child and
the insurance company.
Another much more cost effective approach would be to teach the children through an
educational video game that focuses on diabetes management for children. According to Richard
Van Eck, an Associate Professor of Instructional Design and Technology at The University of
North Dakota, games can be effective learning environments because they are immersive, require
the player to make frequent, important decisions, have clear goals, and adapt to each player
individually (Oblinger, 2006). “Also games embody many attributes associated with how people
learn: games are social and experiential, they require players to recall prior learning and develop
new understanding, and being successful depends on problem-solving.”(Oblinger, 2006)
3
Lab Two
1.1 Purpose
Real Edutainment Development (R.E.D.) plans to solve this problem through the
development of the game “Dr. Sawbones Versus the Medical Monsters (DSVMM)”. It will
teach the children to manage their diabetes through an educational video game. This solution
will be much more cost effective than relying on one on one visits with the doctor to educate the
child, but just as effective.
DSVMM will be an educational videogame based around teaching children to manage
their diseases and their overall health. The game consists of the child having to ward off
monsters that attack them. Each of these monsters represents a disease, or major symptoms of a
disease. In order to fight the monsters, the child will have to make healthy decisions, such as
eating vegetables instead of candy, exercising, or a relevant disease management practice. They
will also receive help from a non-player character named Dr. Sawbones with the mission of
helping the child combat the monsters and learn to manage their disease.
The idea of an educational video game that teaches children through battling monsters is
not entirely innovative. It is the use of individual customization and direct communication with
the physician that sets Dr. Sawbones Versus the Medical Monsters apart from similar games.
The patient will receive a copy of the game from the doctor. Before the child leaves the doctor’s
office, the doctor will customize their copy of the game to fit the patients’ specific medical
issues. They will accomplish this using the customization interface which will be provided on
the program the doctor receives upon purchasing their license of the game.
The other innovative feature DSVMM offers is the use of reporting. As the child
progresses through the game and learns to manage their disease, reports will be sent to the doctor
updating them on the patients’ educational progress. These reports can be viewed through the
4
Lab Two
reporting interface also provided on the program used by the doctor receives. The doctor can
also request trend based reports, through the same interface, to monitor the patients’ progress
over time. An important note is that the report will only consist of game play data. No medical
information or data will ever be transmitted, to avoid violating HIPPA.
1.2 Scope
Before DSVMM can be fully developed and marketed to health care officials, a prototype
must first be created. The purpose of this prototype will be mainly to show a proof of concept.
It is also necessary to test the effectiveness of the game play in teaching children to manage their
diseases. Real Edutainment Development plans to develop a prototype that will still contain the
major defining features of the application, while lacking some of the more minor features and a
good portion of the data. Although the databases will be set up to receive the real medical data,
test data will be used for the purposes of the prototype. Also, only a few levels of game play will
be created, focusing largely on diabetes. The customization aspect of the game will be present in
the prototype, but to a lesser degree. The levels will be able to be customized based on a few key
parameters, instead of the wide range of parameters used for customization in the final product.
Reporting will also be available in the prototype. Basic sample forms will be created during
game play and sent to the customization and reporting application, which will also be prototyped.
With these few exceptions, the prototype should be very similar to the finished product. Table 1
outlines the prototype versus real world product capabilities.
Table 1 Comparison of Prototype Versus Real World Product
Capability or Feature
Final Product
Game Interface
Controller/Keyboard
XBox Controller or PC Keyboard
Menu GUI
Full options (includes parental controls)
In-game GUI
Heads Up Display
Prototype
Keyboard
Minimal options (start, continue,
quit)
Full-game GUI
5
Lab Two
Reporting
Web interface
Full graphical interface
Generate local reports
Report generation
Game will report certain elements
Simulated report
Milestones
Checkpoints throughout the game to monitor
the lessons learned and successful
completion
Final Product
Basic milestones
Full graphical interface
Includes major diseases and will expand over
time
Includes minor diseases and health focuses
Attributes specific to the child to create a
“personalized” experience (i.e. age)
Game pulls in the data automatically and
generates dynamic reports
Simple C# interface
Diabetes
Capability or Feature
Customization
Web interface
Disease options
Other ailment options
Child attributes
Game utilization
Game Algorithms
Blood sugar
Level up system
Health
Monster difficulty
Monster AI
Game Interface
Objective-based level
design
Monster design
Items and powerups
Game play techniques
Mini games
Personalized avatar
Over-arching story
Voice acting
Soundtrack
Prototype
Tooth decay and obesity
None
Basic implementation
In-depth algorithm to mimic blood sugar levels Simple blood sugar algorithm that
in the real world
adjusts over time
Flexible system that improves the player's
Simple Level Up
avatar through good decisions and
game progression
Customized based on age and other factors of Not Customizable
the player
Fully customizable and effects both the
Not Customizable
health/attack as well as the AI
A semi-intelligent AI which can be scaled with A single AI for basic monsters and
the difficulty and is different for the different
a single AI for boss monsters
"monsters
Levels that are designed to be able to be
accomplished with a specific learning
objective
A full cast of monsters (boss and regular) who
impede the player's progress
Items based on real-world preventions
techniques
A full "battle" system which uses prevention
techniques to defeat the monsters
Mini games at the end of levels and specific
points to enforce lessons learned
The player can customize their avatar to allow
for a "realistic" feel
A full engaging story to draw the player in
which spans the entire game
All dialogue voiced
Fully flushed soundtrack
Several "objectives" to show
scalability
A few monsters covering different
areas
Minimal items to demonstrate
effectiveness
A few techniques to demonstrate
use
Small sampling of mini game
One static model
A simple story of one level
No dialogue
Minimal sounds
6
Lab Two
1.3 Definitions, Acronyms, and Abbreviations
1. Attributes: A characteristic of a person, and its effects on digital characteristics in
DSVMM
2. Algorithm: A step-by-step procedure for calculations used for data processing and
automated reasoning.
3. Area of Focus: A term used to describe a medical
4. Asset: An element used in the game engine. Includes textures, models, audio,
networking, etc.
5. Caregiver: Parents, physicians, school teachers, or legal guardians
6. Children: Young people between the ages of 6-12.
7. Customization: A form the physician completes which gives each child’s copy of
DSVMM a personalized factor.
8. Diabetes: A group of metabolic diseases where a person battles high blood sugar. Refers
to both types I & II
9. Diabetic Hypoglycemia:
10. Diabeto: The virtual representation of diabetes and the arch-enemy of the player.
11. Doctor Sawbones: The doctor character himself.
12. Doctor Sawbones Versus the Medical Monsters (DSVMM): The educational video
game developed by R.E.D. to help children understand chronic illnesses.
13. Game Engine: A system to build games. This system aids in the development of most
assets to be included in the game.
14. Game Platform: A type of medium to play games on, a computer, console, or mobile
device.
7
Lab Two
15. Game World: The virtual environment where the game unfolds and the player moves the
game forward.
16. HIPAA: Health Insurance Portability and Accountability Act
(http://www.hhs.gov/ocr/privacy/)
17. Learning Modules: Sets of game levels revolving around different diseases and their
prevention techniques. Using a modular design makes adding new diseases easy.
18. Management: All methods of treatment, including medication, lifestyle changes, and
therapy
19. Medical Milestone: Progression through DSVMM where the player overcomes a certain
medical-based obstacle
20. Medical Monsters: These are digital representations of the real world diseases and
health problems who are in the form of a graphical sprite and enemies of the player.
21. Non-Player Character (NPC): A type of avatar in a game that players interact with
through their avatars and is computer programmed.
22. Physician: A doctor, nurse, medical caretaker, etc. of children.
23. Plaq: A Medical Monster representing tooth decay.
24. Player: A child user of DSVMM
25. Player Avatar / Avatar: A virtual character in a video game which is a representation of
a person in real life, usually the player.
26. Power-Up: Virtual representation of something that aids the player
27. Product: DSVMM
28. Real Edutainment Development (R.E.D): The development group designing DSVMM
8
Lab Two
29. Report: A graphical culmination of a player’s progress through the game and medical
milestones passed.
1.4 References
Peterson, M. (2012). Lab 1 DSVMM Descriptive Paper.
Herzog, K. (2011, april 28). Yearly medical care costly for kids with diabetes. Retrieved from
http://www.jsonline.com/features/health/120933004.html
Oblinger, D. (2006, January 30). Games and learning. Retrieved from
http://www.educause.edu/EDUCAUSE
1.5 Overview
This product specification provides the hardware and software configuration, external
interfaces, capabilities and features of the DSVMM prototype. The information provided in the
remaining sections of this document includes a detailed description of the hardware, software,
and external interface architecture of the DSVMM prototype; the key features of the prototype;
the parameters that will be used to control, manage, or establish that feature; and the
performance characteristics of that feature in terms of outputs, displays, and user interaction.
2 General Description
Dr. Sawbones vs. the Medical Monsters is composed of several different types of
components. These components together make up the prototype architecture, the functional
components, and the external architecture. Each of these represent different portions and
description levels of the overall project.
2.1 Prototype Architecture Description
The prototype is made up of a few different major components. All of which are represented in
Figure 1. The Dr. Sawbones vs. the Medical Monsters prototype is made up of the following
components:
9
Lab Two

A data access layer, consisting of the major databases within the game and the
scripts used to access them. This component will be demonstrated using two
other components. The reporting interface will pull data from the databases, and
the customization interface will change values within the databases.

A presentation layer, which will consist of two major types of interfaces: the web
services and user interfaces. The web interfaces will be used by the physician to
access each players in-game progress and customize their game play. The user
interfaces will be used by the patient to play the game.

Simulated game data will be provided to the databases for the prototype. This
will be used in the place of actual in-game data. It will be this information that is
displayed in the form of a report in the web interface.

A personal computer will be required for the prototype. This will be used to run
both the game itself, as well as the physicians’ client application.

The Internet will be used for communication between components. It will allow
the databases to communicate with all running game instances. It will also allow
the physicians’ client application to communicate with the databases for reporting
and customization.
10
Lab Two
Figure 1: MFCD
2.2 Prototype Functional Description
The major functional components of DSVMM are as follows:

Algorithms: DSVMM will consist of five major algorithms. These consist of the
Blood Glucose, Reporting, Difficulty Scaling, Customization, and Monster
Artificial Intelligence algorithms. Togethor they allow the customization of the
game to fit the individual user.
o Blood Glucose Algorithm: This algorithm is used to inform the player
whether decisions they make in the game are positive or negative with
respect to their blood glucose level. The algorithm will focus on nutrition
and exercise-based decisions. Poor decisions will have visible negative
effects within the game.
o Reporting Algorithm: This algorithm is used to present game play data to
the physician in the form of a report. The players’ progress will be polled
during game play and stored into a database. This information will be
11
Lab Two
pulled from the database and presented to the physician when a report is
requested through the reporting interface. Figure 2 shows how the
algorithm will work.
Figure 2: Reporting Algorithm
o Difficulty Scaling Algorithm: This algorithm is used to scale in-game
variables such as monster health or attack abilities to each players’ skill
level. The initial skill level will be set by the physician for each patient
during the initial customization of the game. As the child progresses
through the game, the difficulty scaling algorithm will tailor this difficulty
level to suit their progression through the game.
o Customization Algorithm: When the physician modifies a patients game
through the customization interface, this algorithm is used to create a new
build of the game for that child with the customizations in place. It mainly
modifies variables related to the player, such as their areas of focus.
12
Lab Two
o Monster Artificial Intelligence Algorithm: The Monster Artificial
Intelligence (AI) must be scalable for the difficulty options presented in
the difficulty scaling algorithm. Easier difficulties must make the
monsters less aggressive. Harder difficulties must make the monsters far
more aggressive. This must be dynamically scalable to react to the player
skill level determined by the difficulty scaling algorithm.

Databases: There are four major databases within the game. The monster
database holds the information on the monsters in the game the player must face.
The medical database hold the information on different diseases used to
determine characteristics of the monsters. The game database holds information
on each of the respective players and the milestones they have reached. The
reporting database holds the usernames and passwords used by doctors to log into
the reporting and customization interface.
o Monster Database: This database is used to hold information about each
of the monsters represented in the game. It must contain a monster to
represent each disease in the game. Each Monster must reference the
disease it is associated with in the Medical Database. See Figure 3 for the
Monster Database ERD.
13
Lab Two
Figure 3: Monster Database ERD
o Medical Database: This database is used to hold medical data for each
disease covered in the game. This information will be used in pop-up
medical facts shown throughout the game. These facts are used to inform
the player about facts related to their disease. See Figure 4 for an ERD of
the Medical Database.
14
Lab Two
Figure 4: Medical Database ERD
o Game Database: This database is used to keep track of individual player
and game play data. This is the bulk of the information that is changed by
the customization algorithm. It is also the main information that is
updated during game play. See Figure 5 for an ERD of the game database.
15
Lab Two
Figure 5: Game Database ERD
2.3 External Interfaces
The next few sections identify both the physical and logical interfaces that will be used
by the prototype. Section 2.3.1 discusses the hardware interfaces required. Section 2.3.2
discusses the software interfaces that will be needed. Finally, Section 2.3.3 deals with the
various user interfaces that will be required.
2.3.1 Hardware Interfaces
The only hardware requirements for the prototype are an X-box 360 game controller, and
a PC. The controller is used by the patient to play the game. If a controller is not present, the
16
Lab Two
game controls must map themselves to a keyboard and mouse. Figure 6 contains an overview of
the controller mapping.
Figure 6: Controller Mapping
2.3.2 Software Interfaces
The major software interfaces in the prototype deal with how different software
components access and effect the databases.

The prototype uses the Microsoft SQL Server to handle its various databases. The
database tables were originally set up using the SQL Management Studio, a
graphical database management suite provided by Microsoft.

The databases will be accessed through both the web interfaces and the in-game
interfaces. The web interfaces access the databases using a SQL authentication
based connection, an internet connection requiring a username and password.
Once the connection is set up tables are modified via the entity framework, a
17
Lab Two
framework built into visual studio that is optimized for accessing SQL Server
databases.

The in-game interfaces will also access the databases using a SQL authentication.
Once the connection is established tables are modified via embedded SQL in the
C# scripts that make up the game.
2.3.3 User Interfaces
There are four major GUI interfaces used in DSVMM. These are broken into two
categories: the web-based interfaces and in-game interfaces. The web-based interfaces consist of
the customization and reporting interfaces. The in-game interfaces consist of a menu interface
and the heads up display (HUD). Figure 7 contains the in-game GUI site map.
Figure 7: Game Site Map
18
Lab Two

Customization Interface: This interface is used by the physician to customize
each patients’ game play to fit their needs. The interface will allow the physician
to set certain variables, such as difficulty scaling. Once the variables have been,
set the interface will call the customization algorithm to actually make the
changes and build a new version of the game.

Reporting Interface: This interface is used by the physician to view the patients’
progress through the game. It will allow the physician to choose from a list of
patients. Once the patient has been chosen, the interface will run the reporting
algorithm to retrieve the necessary information from the database.

In-Game Menu Interface: This interface is used to give the player options, such
as starting a new game or continuing a previous game. It must also include
parental options. These include allowing the parent to set a time limit, and a link
to the reporting interface for the parent. Figure 8 shows an example of the menu
interface.
Figure 8: Menu Interface
19
Lab Two
 In-Game Heads Up Display: This interface must contain various meters used by
the player to track their current statistics in the game. These include: health,
glucose level, active weapon, among others. Figure 9 shows an example of the
heads up display taken from game play.
Figure 9: Heads Up Display
2.3.4 Communications Protocols and Interfaces
The only communication related requirements within the prototype deal with the Internet
connection for the various users. The player must have a stable Internet connection both during
the initial install, and during game play. The connection is required during game play to allow
the game to update the database using its update scripts. The physician also needs a stable
Internet connection while using both the reporting and customization interfaces. This connection
is required in the reporting interface to query the databases for necessary information. It is
needed in the customization interface to update values within the database tables.
20