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