MIDDLE EAST TECHNICAL UNIVERSITY Department of Computer Engineering

CENG 491 Computer Engineering Design I

Senior Project VIRTEC3D

Requirements Analysis Report

Aslı ÖZAL 151486-8 Bahadır ÖZDEMİR 139534-2 Duygu ATILGAN 139466-7 Nilgün DAĞ 139485-7

November 4, 2007 Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

Table of Contents……………………………………………………………………………………………..2 1. Introduction………………………………………………………………………………………………..4 1.1. Background……………………………………………………………………………………………………………….4 1.2. Detailed Problem Definition………………………………………………………………………………………4 1.3. Project Goals and Scope…………………………………………………………………………………………….5 2. The Process….……………………………………………………………………………………………..6 2.1. Process Model…………………………………………………………………………………………………………..6 2.2. Team Organization…………………………………………………………………………………………………….6 2.3. Project Constraints……………………………………………………………………………………………………7 2.3.1. Project Schedule……………………………………………………………………………………………..7 2.3.2. User Interactivity/Controls Constraint……..……………………………………………………..7 2.3.3. Realistic Game Play………………………………………………….……………………………………..7 2.3.4. Realistic Scene…………………………………………………………………………………………………7 2.3.5. Network Constraints ………………………………………………………………………………………7 3. Research………………………………………………………………………………………………………8 3.1. Literature Survey and Technical Analysis……………………………………………………………………8 3.1.1. Graphics………………………………………………………………………………………………………….8 3.1.1.1. Crystal Space……………………………………………………………………………………….8 3.1.1.2. Java3D……………………………………………………………..………………………………….8 3.1.1.3. Ogre…………………………………………………………………………………………………….8 3.1.1.4. Ogre4J………………………………………………………………………………………………….9 3.1.2. Sound………………………………………………………………….………………………………………….9 3.1.2.1. OpenAL…………………………………………………………………………………………….….9 3.1.2.2. FMOD………………………………………………………………………………………………….9 3.1.2.3. jVoiceBridge………………………………………………………………………………….……10 3.1.3. Network…………………………………………………………………………………………………..……10 3.1.3.1. RakNet………………………………………………………………………………………….……10 3.1.3.2. ZoidCom Automated Network System………………………………………………10 3.1.3.3. Project DarkStar…………………………………………………………………………………10 3.1.4. Other Tools……………………………………………………………………………………………………11 3.2. Existing Systems Analysis…………………………………………………………………………………………11 3.2.1. Advanced Disaster Management Simulator………………………………………………..…11 3.2.2. Commandos…………………………………………………………………….……………………………12 3.2.3. Unreal……………………………………………………………….………………………………………….12 3.2.4. Age of Empires……………………………………………………………….……………………….….…12 3.2.5. Project Wonderland……………………………………………………………….………………..……12 3.3. Meeting with Tolga Can…………………………………………………………………………………………..13 3.4. Potential User Meetings……………………………………………………………………………………….…14 4. Requirements Specification………………………………………………………………………14 4.1. Functional Requirements…………………………………………………………………………………………14 4.1.1. Menu Requirements…………………………………………………………………………………..…14 4.1.1.1. Main Menu………………………………………………………………………………………..14

Page | 1

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

4.1.1.2. Pause Menu…………………………………………………………………………………..…..15 4.1.2. Game Flow Requirements……………………………………………………………………………..16 4.1.2.1. Game Logic Requirements…………………………………………………………….……16 4.1.2.2. Environment Requirements……………………………………………………………….16 4.1.2.2.1. Area………………………………………………………………………………………..16 4.1.2.2.2. Resources……………………………………………………………………………….17 4.1.2.2.3. Other Characters…………………………………………………………………….17 4.1.2.3. Character Requirements…………………………………………………………………….17 4.1.2.3.1. Movement Abilities for All Characters…………………………………….17 4.1.2.3.2. Search and Rescue Team Manager Abilities…………………………….17 4.1.2.3.3. Fire‐fighting Team Manager Abilities………………………………………17 4.1.2.3.4. Medical Team Manager Abilities…………………………………………….18 4.1.2.3.5. Vehicle Manager Abilities……………………………………………………….18 4.2. Non‐Functional Requirements……………………………………………………………….………………..18 4.2.1. Usability…………………………………………………………………………………….………………….18 4.2.2. Quality…………………………………………………………………………………….……………………18 4.2.3. Documentation……………………………………………………………………………………………..19 4.2.4. Platform Compatibility………………………………………………………………………………….19 4.2.5. Reliability and Robustness…………………………………………………………………………….19 4.3. Hardware Requirements……………………………………………………………….…………………………19 4.4. Software Requirements……………………………………………………………….………………………….20 5. System Analysis and Modelling…………………………………………………………………20 5.1. Structured Analysis and Functional Modeling………………………………………………………….20 5.1.1. Level 0 Data Flow Diagram…………………………………………………………………………….20 5.1.2. Level 1 Data Flow Diagram (Client Side) ………………………………………………………..21 5.1.3. Level 1 Data Flow Diagram (Server Side) ……………………………………………………….22 5.2. Control Specification and Behavioral Modeling……………………………………………………….24 5.2.1. Use Cases…………………………………………………………………………………….………………..24 5.2.1.1. Menu Use Cases…………………………………………………………………………………24 5.2.1.1.1. Start Menu Use Case……………………………………………………………….24 5.2.1.1.2. Pause Menu Use Case……………………………………………………………..25 5.2.1.2. Character Use Cases…………………………………………………………………………..25 5.2.1.2.1. Search and Rescue Team Manager………………………………………….25 5.2.1.2.2. Medical Team Manager………………………………………………………….26 5.2.1.2.3. Fire‐fighting Team Manager……………………………………………………26 5.2.1.2.4. Vehicle Manager…………………………………………………………………….27 5.2.2. Activity Diagrams………………………………………………………………………………………….28 5.2.2.1.1. Fire‐fighting Team Manager Activity Diagram…………………………28 5.2.2.1.2. Medical Team Manager Activity Diagram………….……………………29 5.2.2.1.3. Search and Rescue Team Manager Activity Diagram………………30 5.2.2.1.4. Vehicle Manager Activity Diagram………….………….…………………..31 5.3. Data Object Description of Problem………………………………………………………………………..32

Page | 2

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

5.3.1. E/R Diagram for the Database of the Program………….………….……………………….32 5.3.2. Class Diagram of the Program………….………….………….………….…………………………32 6. Project Schedule……………………………………………………………………………………….34 6.1. Project Scheduling……………………………………………………………….………….………………………34 6.2. Gantt Chart……………………………………………………………….………….………….……………………..35 7. Time and Effort Estimation…………………………………………………………………………35 8. Risk Management Plan………………………………………………………………………………36 8.1. Project Risks……………………………………………………………………………………………………………36 8.1.1. Staff Size and Experience……………………………………………………………………………….36 8.1.2. Customer Characteristics……………………………………………………………………………….36 8.1.3. Product Parameters………………………………………………………………………………………37 8.1.4. Development Process……………………………………………………………………………………37 8.1.5. Development Environment……………………………………………………………………………37 8.2. Risk Table…………………………………………………………………………………….………………………….38 8.3. RMMM Table ………………………………………………………………………………………………………….39 9. Software Quality Plan………………………………………………………………………………..41 9.1. Introduction……………………………………………………………….………….……………………………….41 9.1.1. Scope……………………………………………………………….………….………….……………………41 9.1.2. System Overview……………………………………………………………….………………………….41 9.2. Organizational Structure……………………………………………………………….………………………..41 9.3. Software Quality Assurance Tasks…………………………………………………………………………..42 9.3.1. Procedures and Protocols………………………………………………………………………………42 9.3.2. Review Practices……………………………………………………………………………………………42 9.3.3. Determining the Next Step…………………………………………………………………………….42 10. Appendix………………………………………………………………………………………………….42

Page | 3

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

1. Introduction 1.1. Background A disaster may strike anytime, anywhere. It may take the form of a tornado, a flood or a fire. It may hit suddenly or may build over days. In any case, millions of people face its terrifying consequences. Many become homeless, many lose their health but among these, death is the worst terrifying one. In a disaster, urgent intervention is needed to prevent the worsening of the situation. Such an intervention is only possible with experienced emergency agencies, and with detailed emergency planning and qualified management. However, agencies may be unprepared to these situations since they are not well‐trained. Training of agencies can be done only in “safe” virtual environment, since it is prohibitively expensive or simply too dangerous to allow trainees to use the real equipment in the real world. However, there are limited numbers of tools or software aimed for this kind of training.

1.2. Detailed Problem Definition Simulations are considered as the next big step in training. As simulations offer complexity, realism, and opportunities to practice new skills, trainees generally prefer them. Also, managers prefer simulations to motivate the trainees and to help them develop their skills. Although the simulation training was expensive and creating a simulation was time‐consuming in the past, with more powerful hardware and software support, it is now easier to develop these simulations. However, the largest barrier is the lack of understanding of what is possible in the area of simulation training, tools, and content. In this project, we aim to produce a well‐defined, realistic, and useful disaster management simulation. It will be an online virtual team collaboration platform with 3D graphics. There will be four users each from a different department of emergency agency and they will be able to see the scene from first‐person view. They will communicate vocally, and coordinate with other team members. They will have resources which can be divided mainly into two groups: figurants and equipments. Players’ knowledge about the situation and the usage of these resources under certain conditions will be tested. The aim of each participant is to achieve the common goal of the team while performing his own role. The scenario in the simulation will be variant. These variances will be generated by creating fires in environment, causing damages in buildings, causing people to be hurt…etc. An interactive and dynamic environment will be created in the simulation so that trainees will face different conditions in

Page | 4

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007 every execution. The environment is aimed to be created similar to a university campus, especially METU campus will be considered as a model.

1.3. Project Goals and Scope While developing the simulation, we aim to realize following goals within the project scope: • Developing a dynamic and interactive environment with the help of scripting features. • Using 3D graphics to provide a virtual reality. • Maintaining a deterministic and consistent simulation state. • Using object oriented approach for game design. • Increasing the quality of the product by reducing bugs as much as possible. • Creating a modular application. • Providing an easily understandable application. To realize these goals we determined specific topics that we need to focus on. We examined the design of the 3D applications with multiplayer support. We got in contact with the potential users to be able to create a realistic environment. We investigated requirements in detail.

In the scope of the project: √ Audio communication will be provided so that the users will be able to collaborate with each other. √ Each user will be able to see the environment only from first person view. √ Graphics will be as of good quality as possible. √ An interactive and a dynamic environment will be provided with the help of scripting.

Not in the scope of the project: × Artificial intelligence won’t be used in the Project according to current Project plan. × There won’t be physical simulation in the application.

Page | 5

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

2. The Process 2.1. Process Model As we will do the project in the content of Ceng491 course, requirements and the design parts of the project will be improved sequentially and they will be completed by the end of first term. Therefore, we cannot use any incremental or evolutionary model. Also, requirements are well‐defined and reasonably stable so there will be limited number of new development efforts in the project. We will try to make a realistic and safe requirements analysis so that we will have a robust design, which will prevent us from returning back to design phase. Taking all of these into consideration, waterfall process model is the most appropriate model for our project. However, there will be some modifications in this model such that coding, testing‐debugging and integration will be performed in one phase under the name ‘construction’, as seen in Figure 1.

Figure 1 ‐ Modified Waterfall Model

2.2. Team Organization We decided our team structure to be Democratic Decentralized (DD). Our team is relatively small, and there is no team leader. Communications within the team are horizontal. Decisions about projects are taken by all members of the team so that each member contributes to project equally. Also,

Page | 6

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007 in the democratic model, each member is encouraged to contribute to the project and would come up with innovative ideas.

2.3. Project Constraints 2.3.1. Project Schedule

Developing a 3D simulation environment with users communicating vocally over a network requires good knowledge of computer graphics, network and game design. Learning these subjects, developing a game concept, implementing and documenting the project are time‐consuming tasks. Within a 7‐and‐a‐half month time, we aim to come up with a final product with its testing and debugging completed. 2.3.2. User Interactivity/Controls Constraint Our product is targeted to be used by people having no or very little knowledge of computers. Therefore, there will be two modes of the simulation; one with limited interactions with the program and one with very detailed interactions. In the first mode, user will perform his actions only by microphone. On the second one, however, user will be making all his actions by directly interacting with the program by keyboard. 2.3.3. Realistic Game Play

Since we are developing a simulation environment, we need our program to be as realistic as possible. Users should face real emergency situations, and should come up with solutions using their limited resources as in real life. Simulating this on computer is not an easy task; both graphically and conceptually. Also to not end up with mistraining and faulty evaluation of user performances, we have to design the game play very carefully. 2.3.4. Realistic Scenes

Quality of 3D graphics, models, textures, sound and animation will make our simulation look more realistic, while costing a considerable amount of disk space and intensive processing. 2.3.5. Network Constraint Network connection speed is an important constraint on the amount of data that will be transmitted over the network. Kind of data that will be transmitted also effects our design decisions.

Page | 7

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

3. Research 3.1. Literature Survey and Technical Analysis To find the most suitable tools and environments for our application, we made an all‐round research related to different fields of our application. 3.1.1. Graphics We made a wide research with respect to graphics part, as it is thought to be the most challenging and time consuming part of the project. We decided to use a graphics rendering engine for modularity and ease of writing code. The engines chosen to be examined are given in details in the following subsections. 3.1.1.1. Crystal Space This is a framework rather than a simple rendering engine. It has modules for 2D and 3D graphics, sound, collision detection and physics. However, it is not appropriate for our project in two reasons. Firstly, its documentation and developer support is not very satisfactory. Secondly, an all‐in‐ one engine including all kind of features is not appropriate for our project’s needs. We thought it would restrict us in terms of functionality. Instead, we intend to use different API’s/engines specialized in its own area. 3.1.1.2. Java 3D As we had not decide about the programming language, we examined both kind of engines written in C++ and Java. Java3D is one of the few rendering engines written in Java. Java3D Project, running under Java Community Process, does not seem to be developed very professionally. Its documentation is poor and the demos do not attract much. We also searched for the games written in Java3D such as Law and Order 2, Pernica, Roboforge and Flying Guns. From those, only Law and Order 2 made a considerable profit out of market. As Java3D does not seem to satisfy our needs, we had to give up on it. 3.1.1.3. Ogre Within all the graphics engines we have searched, Ogre was the most impressive one. It is a scene‐oriented, hardware accelerated 3D engine. Ogre would be useful for us in many respects. Firstly, it has an active community contributing to the project, in case of any problem with the engine such as a bug, or a confusing way, one can easily get an answer to his questions from its developers in the forums. Also, Ogre has quite a rich documentation including the Project Ogre Wiki

Page | 8

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007 where one can find code, tutorials, art tutorials and many examples. Also the book “Pro Ogre 3D Programming by Gregory Junker” is dedicated to teach new users the fundamentals of using Ogre. Secondly, Ogre’s being scene‐graph‐based makes it very appropriate to develop a 3D application rich in objects. Scene graph data structure makes it easier to arrange the logical representation of a graphical scene. It helps the programmer to define logical relations between the objects (entities) which correspond to the nodes in the graph. Although Ogre is not an all‐in‐one solution in terms of game development or simulation, it is compatible with many external add‐ons, tools and libraries. This gives freedom to us to use whatever input, audio and scripting libraries we want. 3.1.1.4. Ogre4J Ogre4J is a project that enables the use of Ogre libraries in Java applications. As Java is considered as the alternative programming language, Ogre4J seemed quite appropriate at first sight. However, it is a new project and it is strongly possible that it includes bugs which would be very difficult for us to deal with in the process of implementing the project. As we cannot take such kind of risk, Ogre4J is not suitable for this project.

3.1.2. Sound Our criteria for sound libraries are: platform independency, free license, 3D audio, recording and documentation support. Suitable sound libraries for our project are listed and briefly described in subsections between 3.1.2.1 and 3.1.2.3. 3.1.2.1. OpenAL It works on both Windows and Linux and mainly free under LGPL. It supports 3D audio and suitable for game applications. Functions for recording sound also exist. OpenAL consists of low‐level functions. Furthermore, there is a high‐level utility library called ALUT similar to OpenGL‐GLUT. Documentation of the library is sufficient and active forums exist. It is used by most of the well‐known game engines such as Unreal Engine, Torque Engine, Delta3D Engine and Doom3 Engine. 3.1.2.2. FMOD It is available for both Windows and Linux. It is commercial, but free for non‐commercial use. FMOD supports 3D sound, and many audio formats such as midi, mp3, ogg vorbis. In addition, it supports recording, internet streaming and sound effects. Documentation is sufficient. Furthermore, FMOD is actively developed, with regular releases of new features. Some famous game companies like

Page | 9

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

Blizzard, Microsoft, Activision and NVidia are in the customer list of FMOD. Moreover, it has a sound manipulation tool called FMOD Designer. However, it is only available for Windows. 3.1.2.3. jVoiceBridge The voice bridge is software written in the Java Programming Language that handles Voice over IP (VoIP) audio communication. Also, it mixes tasks such as conference calls, voice chat, speech detection, and audio for 3D virtual environments. In addition, it can be used as a component of other applications, i.e. Project Wonderland. It is available for both platforms – Windows and Linux‐ by taking advantage of Java programming language. Negative aspect for this library is poor documentation support.

3.1.3. Network 3.1.3.1. Raknet It is suitable for Windows and Linux; free for non‐commercial use. It is Ogre‐compatible and preferred in a quite number of Ogre projects. It is a networking API that is for reliable UDP and higher level functionality. It allows any application to communicate with other applications on the same computer, over a LAN, or over the internet. It was developed specifically for development of online games and the addition of multiplayer to single player games. It provides detailed reference and tutorials. 3.1.3.2. ZoidCom Automated Network System This library is also platform independent and free for non‐commercial use. It is a high‐level, UDP‐based networking library providing features for automatic replication of game objects and synchronization of their states over a network connection. The project has extensive documentation and lots of example programs. 3.1.3.3. Project Darkstar It is a developing project which is supported by Sun Microsystems and its aim is to develop a reliable, scalable, and fault tolerant system for low‐latency, high‐interactivity online content. Its primary target is Massively Multiplayer Online Game content but it is also used in small group online games. The project is written in Java Programming language so it is system independent. It is a new project and it develops actively. For this reason, it may be risky to use. However, it is used in Project Wonderland.

Page | 10

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

3.1.4. Other Tools We have examined Python and Perl to use in the scripting part of the project. We decided to use Python for scripting language regarding to our previous experiences. Crazy Eddie's GUI System is also decided to use for GUI library which is compatible with Ogre. Also, CeGUILayoutEditor will be used to design GUIs. For 3D model creation, we will use one or more modeling tools. We have examined 3D Studio Max, Maya, Blender to get an idea about the modeling tools. For texture and image creation, Adobe Photoshop, CorelDraw and Paint Shop Pro will be used. For Integrated Development Environment, Microsoft Visual Studio and Eclipse will be used. For text editor we will use Vim editor.

3.2. Existing Systems Analysis This project encapsulates many different disciplines. It is similar to games as it involves features such as 3D programming, multiplayer playing, and audio communication between users. It is similar to simulators as it involves an education purpose and simulates a real environment and a realistic scenario. Therefore, we searched for both multiplayer games and simulators. The games and the simulations examined are given in following sections. 3.2.1. Advanced Disaster Management Simulator ADMS is the most similar program to our project; both in technical and logical features. It is an interactive virtual reality‐based team system. It provides training opportunity to emergency responders trying to develop skills in Command, Control, Coordination and Communication. It involves audio communication between users. As a qualified simulator, ADMS also has a scenario generator which enables users to create any type of disaster scenario and generate situational details such as people, weather, time of day and threats. Variety in scenarios enables the users to use the system many times and develop stronger skills. Also it has a scoring and record keeping system which maintains trainee data including time and date of training, modules completed and all scores. This also adds to the quality of training as each user can see his improvement in time. It has rich 3D Model Catalog involving real vehicle models, resources and model needed for a realistic environment.

Page | 11

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

3.2.2. Commandos Commandos is a stealth‐oriented real‐time tactics game series. The reason we examined this game is the fact that the game involves seven different characters each having a different role and different resources. In this respect, graphical user interface and game logic of Commandos would be useful for the project. Also Commandos has multiplayer support in Commandos 3, giving an idea about the network. 3.2.3. Unreal Unreal is a first‐person shooter game which is considered to be technically superior to most of the games in market. It has multiplayer support with strong network architecture. Due to its technical capabilities and developer support, we examined it as a model for the project. Unreal is considered to be the pioneer in many areas in game development. It has strong graphics capabilities and very efficient network architecture. In the network architecture, generalized client server architecture is used rather than monolithic server architecture used in other games such as Quake and Ultima Online. Unreal implements a more efficient way for the network architecture with the help of game state concept. In this concept, clients’ game engines also deal with the game logic instead of just sending the input to network and getting the output from network. Also its network architecture has an intelligent side as it makes predictions about the coordinates of the objects with the help of current coordinates and trajectories. Although implementing such advanced features would be quite hard in the scope of this project, examining Unreal gave very useful ideas for providing the efficiency in the application. 3.2.4. Age of Empires Age of Empires is a series of real‐time strategy video games. We examined it in terms of its multiplayer support. In the beginning of the game, the person who sets up the game is the creator. The other players join the game by specifying their IPs to the creator from the network. We consider taking Age of Empires as a model for setting up process. 3.2.5. Project Wonderland: 3D Scene Manager for Virtual Worlds Project Wonderland has developed by Sun Microsystems as open‐source software written in Java. It is a 3D scene manager for creating collaborative virtual worlds. Within those worlds, users can communicate each other, with audio and can share live applications such as web browsers, OpenOffice documents, and games. “MPK20: Sun's Virtual Workplace” is a sample environment created by this project. It is similar to our project in terms of online collaboration platform, communication with audio and 3D graphics environment. However, there are some differences, i.e. user number is much higher,

Page | 12

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007 advanced features such as sharing applications and using camera are included. On the other hand, the graphics are simple. Three libraries used in this project can also be used in our project, so we had examined them in detail. These libraries are: jVoiceBridge for sound, Project Darkstar for network and Java3D for graphics.

3.3. Meeting with Tolga Can We arranged a meeting with Tolga Can because we were inexperienced about game programming and we had only a little knowledge about graphics. Although we had performed many researches about graphics, network and sound libraries, choosing the ones that are most suitable to develop a simulation required some experience in game programming. Mr. Can helped us to make some critical decisions for our projects given below: √ He advised us to prefer the graphics library with most support. As we were thinking about Ogre, Java3D and Ogre for J as alternatives, he stated that Ogre with C++ would be the most appropriate choice. He stated that Ogre for J would be too new and would be really risky. Also, finding models in Java3D would be harder compared to Ogre. √ At first, he told us to use an existing game engine. Then, we thought that it would be harder to understand an existing code than writing a new engine with desired properties in modeling, networking and audio. Also, it would be too easy for Ceng 491 project. √ For network part of the simulation, we had some concerns about C++ network libraries. He told us that C++ has most of the functionalities that Java provides. This supported us to prefer Ogre as graphic libraries other than Java3D. √ For network architecture, we were thinking about two alternatives: monolithic client‐server (used by Quake) and the generalized client‐server model (used by Unreal). He stated that it would be better to choose second one so that client will maintain a subset of game state locally and will predict the game flow by executing the same code as the server which will minimize the amount of data exchanged between client and server. √ In order to include some real‐time responses in our simulation ‐ i.e. grow fire if it is not intervened ‐ he suggested us to do scripting instead of physical simulation. He advised to predefine some alternative scenarios and hardcode them in the project. √ He told us that we do not need to use any physics engine.

Page | 13

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

√ Also, he promised us to send sample codes for Java3D and sending audio files within network written in Java to give us an idea about these issues.

3.4. Potential User Meetings Our company requested to include some details about roles in the simulation, so that knowledge of each player at different situations for his role can be tested. Therefore, we arranged a meeting with Nuray Kaya (Teacher from Civil Defense College) to learn about search and rescue, first‐aid and fire‐fighting in a real city evacuation situation. She informed us about details for each role, and explained some important technical details that each one should do in a situation similar to the one in our project. Also, we got many technical presentations and videos, by the help of which we have detailed our scenario for each role. To add, she promised us to give support any time we request. In addition, we have communicated with Istanbul Technical University Center of Excellence for Disaster Management to get information about disaster management. We got in touch with Administration Board Member of the center Dr.Hikmet İskender. Mr.İskender was willing to help us in the scope of this project. He assured to provide documentation for disaster management.

4. Requirements Specification 4.1. Functional Requirements 4.1.1. Menu Requirements 4.1.1.1. Main Menu Main menu will be displayed to the user at the beginning of the simulation. Details of the menu are listed below: Main Menu: 1. Language Selection 2. Select User 2.1. New User 2.2. Enter Username and Password 3. New Game 3.1. Create (Facilitator) 3.1.1. Mode Selection

Page | 14

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

3.1.2. Difficulty Level Selection 3.1.3. Send Message (Chat with others) 3.1.4. View Signed In Users 3.1.5. Start Game 3.1.6. Cancel 3.2. Join 3.2.1. Enter IP Address 3.2.2. Player/Role Selection (Fire‐fighter, Medical, Search& Rescue) 3.2.3. Send Message (Chat with others) 3.2.4. View Signed In Users 3.2.5. I’m Ready! 3.2.6. Cancel 4. Load Game 5. Learn to Play 6. Options 6.1. Audio Settings 6.2. Microphone Settings 6.3. Graphics Settings 6.4. Controls Settings 7. Statistics 7.1. View Performance Of User 7.2. View Performance Of Team 8. Exit Game 4.1.1.2. Pause Menu Pause menu will be displayed to user when the user strokes the pause keystone during the low of the simulation. Pause Menu: 1. Resume Game 2. Options 2.1. Audio Settings

Page | 15

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

2.2. Microphone Settings 2.3. Graphics Settings 2.4. Controls Settings 3. View Resource Details 4. Statistics 4.1. View Performance of User (Current game performance) 4.2. View Performance of Team 5. Exit Game

4.1.2. Game Flow Requirements 4.1.2.1. Game Logic Requirements 1. Simulation will take place in a restricted open area. 2. Players will have one of the four distinct roles which are: Search and Rescue Team Manager, Fire‐ fighter Team Manager, Medical Team Manager, and Vehicle Manager. 3. There will be a facilitator different than these four players who will manage the game flow. 4. Introductory video of the simulation will be displayed before the simulation starts. 5. At the beginning of the simulation, there will be damaged buildings, injured people, and areas in fire... etc. Aim of the team is to rescue as many people as possible from the area in a minimum amount of time. 6. Players will interact with each other with audio chat. 7. Players will have limited resources. 8. Game will be interactive such that fires with wrong precautions will spread around, or the people that are not treated in a certain time will die.

4.1.2.2. Environment Requirements 4.1.2.2.1. Area 1. The area of METU will be simulated. 2. Area will include buildings, openings and forests. 3. Buildings and openings will have different properties. (Wooden, concrete, steady, wrecked…etc.)

Page | 16

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

4.1.2.2.2. Resources 1. Resources will be different for each role. 2. They will be limited. 3. They include inventory items such as tools, medical equipment...etc. and staff. 4.1.2.2.3. Other Characters (Figurants) 1. Staff will follow orders and finish given tasks. 2. Inhabitants will cry for help, and shout. 3. Hurt inhabitants will die eventually if not treated.

4.1.2.3. Character Requirements 4.1.2.3.1. Movement Abilities for All Characters 1. Walk 2. Run 3. Use Resource 4. Turn 4.1.2.3.2. Search and Rescue Team Manager Abilities 1. Ask Buildings Structural Properties 2. View Damage of the Building 3. View Number of People Inside the Building 4. Enter the Building 5. Call Medical Help 6. Call Fire‐fighter 7. Call Vehicle 4.1.2.3.3. Firefighter Team Manager Abilities 1. View Fire Type (Chemical, Gas, Solid...etc.) 2. View Size of the Fire 3. View Spread Rate of Fire 4. View Possible Dangers (Explosion, electricity, chemical substances...etc.) 5. Call Medical Help 6. Call Search and Rescue

Page | 17

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

7. Call Vehicle 4.1.2.3.4. Medical Team Manager Abilities 1. Check Respiration 2. Check Consciousness 3. Check Blood Circulation 4. Check Area Security 5. Pass to Other Patient 6. Divide Into Groups (Group people into four according to their state of health) 7. Treat Patient 8. Call Fire‐fighter 9. Call Search and Rescue 10. Call Vehicle 4.1.2.3.5. Vehicle Manager Abilities 1. Search for Available Vehicles 2. Repair Vehicle 3. Move Vehicle

4.2. Non‐Functional Requirements 4.2.1. Usability Being an education tool, our program will be used by the trainees including both experienced and inexperienced computer users. Taking this into consideration, we try to design human‐program interaction as clear as possible. The program is aimed to be easy to learn and satisfying to use. In this respect, we follow a user‐centred design paradigm keeping the users’ needs in mind all the time.

4.2.2. Quality Quality of the design and quality of conformance to this design is one of the major requirements of the project’s development. The phases should be completed in certain time and the resulting software should be free from the bugs as much as possible. Also it should be user‐fault‐tolerant to provide a user‐friendly environment.

Page | 18

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

4.2.3. Documentation We plan to provide a detailed end‐user documentation and technical documentation. End‐user documentation will include user manual for installation and playing. Tutorial approach will be followed in end‐user documentation. End‐user documentation will mainly aim to describe each feature of the application, and assist the user in realizing these features. Technical documentation is especially important for developers to be able to understand each other’s code. Since explaining the code literally is a difficult process, tools that auto‐generate the code documents may also be used for technical documentation.

4.2.4. Platform Compatibility Broad compatibility with various systems is critical to have a large market for a product. However, this is not the reason why we aim this product to be platform‐independent. We want it to be platform‐independent since we disagree with the monopolism tried to be forced. We want to give freedom to the user to choose any hardware platform or operating system as much as we can do. So we will not contribute to monopolist approach currently existing in the market.

4.2.5. Reliability and Robustness The resulting application is aimed to be both reliable and robust. In other terms, it should perform and maintain its functions in routine circumstances, as well as unexpected circumstances. As mentioned above, it may be used by inexperienced users too and it should continue to operate despite possible abnormalities in user inputs. Also as it’s a training program, it should be consistent and repeatable. If the user plays it in the same conditions with the same inputs, the program should behave same as before. Reliability and robustness is one of the main issues for customer satisfaction and reliance upon the project. Therefore, we aim to give importance to it within all process.

4.3. Hardware Requirements Minimum System Requirements: • P4 class or equivalent CPU • 128 MB Memory • 3D Graphics Card with 32 MB memory and graphics accelerator • Modem/Ethernet Card

Page | 19

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

• Sound Card • Hard Disk • Microphone, Speaker, Keyboard, Mouse, Monitor.

4.4. Software Requirements Linux/Windows Operating System

5. System Analysis and Modelling 5.1. Structured Analysis and Functional Modeling 5.1.1. Level 0 of Data Flow Diagram Level 0 of data flow diagram is shown in Figure 2. The diagram shows the general input and outputs of the program. The structure shown in diagram is same for both client and server.

Page | 20 Figure 2 ‐ Level 0 Data Flow Diagram Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

Program takes input commands via keyboard and mouse, and recorded sound via microphone from the user. At the same time, program sends the audio output to the speaker. In addition, program takes configuration data, script, audio, video, models and textures from repository (hard disk), and saves the configuration data, saved game, and statistics back to repository. Program sends the graphic outputs to graphic card that will be displayed in the monitor of user. Furthermore, program communicates with other programs running on other users’ machines through the network card. 5.1.2. Level 1 of Data Flow Diagram (Client Side)

Figure 3 ‐ Level 1 Data Flow Diagram Client Side Page | 21

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

The recorded audio data are sent to other users over the network module. Similarly, other users’ recorded audio data are transferred over network module to audio module of the client. Input handler evaluates the keyboard and mouse inputs and sends the data that will affect all users of the program to server via network module. The data that affect only the user like menu commands are sent to game engine by input handler. On the other hand, the game state coming from server is passed over network module to game engine. Game engine then sends the information about sound data to audio module and audio module gets the corresponding audio data from repository. Like audio module, graphics module gets the information about graphics data from game engine and gets the data itself from repository. 5.1.3. Level 1 of Data Flow Diagram (Server Side) Level 1 of data flow diagram for server side is given in Figure 3. The diagram is very similar to the one for client side. However, there are minor differences. Server is the decision centre of the program and the real game state is stored in the server. Other client machines have approximate game states, so server continuously sends game state to clients and the clients updates their data accordingly. Also, server gathers all the requests from users about the game flow, and makes decisions about flow by using script engine.

Page | 22

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

Figure 4 ‐ Level 1 Data Flow Diagram Server Side

Page | 23

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

5.2. Control Specification and Behavioral Modeling (Use Case Diagrams) The use case diagrams for the program are given in following subsections. 5.2.1. Use Cases 5.2.1.1. Menu Use Cases 5.2.1.1.1. Start Menu Use Case

Page | 24

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

5.2.1.1.2. Pause Menu Use Case

5.2.1.2. Character Use Cases 5.2.1.2.1. Search and Rescue Team Manager

Page | 25

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

5.2.1.2.2. Medical Team Manager

5.2.1.2.3. Fire‐fighting Team Manager

Page | 26

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

5.2.1.2.4. Vehicle Manager

Page | 27

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

5.2.2. Activity Diagrams 5.2.2.1. Fire‐fighting Team Manager Activity Diagram

Page | 28

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

5.2.2.2. Medical Team Manager Activity Diagram

Page | 29

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

5.2.2.3. Search and Rescue Team Manager Activity Diagram

Page | 30

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

5.2.2.4. Vehicle Manager Activity Diagram

Page | 31

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

5.3. Data Object Description of Problem 5.3.1. E/R Diagram for the Database of the Program

5.3.2. Class Diagram of the Program The class diagrams provided below do not display the exact classes exactly. They are given as sample to display the game logic and provide data description.

Page | 32

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

Person -id : int -coordinates : double

PassivePerson ActivePerson -name : char #move() : void -score : int #listen() #useResource() #move()

CivilPerson Staff -health : Health -available : bool -saved : bool +animate() : void +animate() : void

Firefighter Medical SearchRescue VehicleManager -resource : FireResource -resource : MedicalResource -resource : SearchResource -resource : VehicleResource +viewFire() : Fire +viewHealth() : Health +viewBulding() : Building +viewVehicleInfo()

FireStaff MedicalStaff SearchTeam VehicleTeam -equipment : FireEquipment -equipment : MedicalEquipment -equipment : SearchEquipment -equipment : VehicleEquipment

Resources -available : bool -totalCount : int

VehicleResource MedicalResource FireResource SearchResource -staff : VehicleStaff -staff : MedicalStaff -staff : FireStaff -staff : SearchStaff -equipment : VehicleEquipment -equipment : MedicalEquipment -equipment : FireEquipment -equipment : SearchEquipment

Page | 33

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

Building Health Fire Vehicle -usageInfo : String -healthRate : int -fireClass : char -vehicleType : int -structuralInfo : String -actualTreatment : String -burningMaterial : String -vehicleSituation : int -actualGroup : char -actualExtinguisher : String -damageClass : String -consciousnessInfo : String -elapsedTime : int -noOfBlocks : int -respirationRatePerMinute : int -gasToxicRate : int -noOfPeopleInside : int -hasOpenAirway : bool -windDirection : String -isOnFire : bool -pulseRatePerMinute : int -windSpeed : float -explosionRiskRate : int -colorTransformationTestResult : String -fireLevel : int +collapse() : void -bodyHeat : float +grow() : void -skinInfo : String +shrink() : void -pupillaInfo : String +goOff() : void -movementAbilities : String -lostOrgans : String -painInfo : String -bleedingInfo : String -purpleSpotInfo : String -nauseaDisgorgementInfo : String -burnInfo : String

6. Project Schedule 6.1. Project Schedule To schedule our project, we first needed to identify main tasks and subtasks in the project. Also, determining relationships between subtasks was important to make a consistent schedule. While assigning start and finish dates for the tasks, we tried to distribute the workload in time equally so that we would never fall behind the schedule. Following the schedule, we will manage our time efficiently and in the meantime, finish all tasks in the specified time interval. Task assignment is done considering team members' interests and skills. Also equal distribution of workload among team members was taken into consideration. We grouped our tasks into 8 main groups. Documenting our project, analyzing development tools and developing game concept are the main tasks we schedule to complete this semester. Tasks related to game resource production and implementation are planned to be started and finished next semester. Specifically, these tasks are divided into groups such as game resource & game art production, graphics & audio development, network development, game logic development and game deployment and testing.

Page | 34

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

6.2. Gannt Chart The Gantt chart explaining tasks, resource assignments and start and finish dates can be found in Appendix in detail.

7. Time and Effort Estimation

Function point analysis technique is done to estimate project time, because the size and complexity of our software system can be quantified in terms of the functions that the system delivers to the user. Details of the function point analysis are given below:

Information Domain Value Count Weighting Factor

External Inputs 15 4 (average) 60

External Outputs Files 3 7 (complex) 21

External Inquires 6 4 (average) 24

Internal Logical Files 7 10 (average) 70

External Interface Files 5 7 (average) 35

TOTAL 210

The count total shown in table is adjusted using the equation;

FPestimated = count total x [0.65 + 0.01 x∑(Fi)]

Here Fi (i=1 to 14) are value adjustment factors. ∑(Fi) is assumed as 46 (moderately complex product) for the purposes of the project.

FPestimated = 210 x [0.65 + 0.01 x 46] = 233 Estimation is then continued by converting function points into line of codes. Based on the fact that an object‐oriented programming language will be used, one FP will be translated into nearly 55. Lines of Code/ Function Point = 55. Lines of Code = 55 * 233= 12815

Effort (Person Month) = 1.4 * thousands‐of‐line‐code

Page | 35

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

Effort (Person Month) = 1.4 * (12815/1000) = 17.9 Person months As the team has 4 members, project will take nearly 17.9/4 = 4.5 months.

8. Risk Management Plan

Risk management is a key issue for completing a project successfully in time. Having a plan beforehand would certainly decrease the impact of a risk. As the subject of the project is mainly about saving human life, it is risky by nature. The people who are using this simulation program are always faced with challenging conditions involving risk. Their each decision may result in many people’s death or survival. Therefore, training of them also involves risk. Implementing the project successfully is crucial in this sense. Requirements should be understood very well. The pathways that the user will choose should not cause him to be trained incorrectly and the application should evaluate the user correctly. Especially for this project, not achieving those criteria are possible and hazardous risks. Therefore, we try to do a detailed risk plan and avoid the possible risks as much as possible.

8.1. Project Risks 8.1.1. Staff Size and Experience (SS) • Member’s lack of training on the used technology and tools: Current experience of team members on game programming may result in inefficiency and may require extra training. • Underestimated minor roles: While working on major tasks, extra details may be overlooked and they may cause overhead later. • Members lacking sense of responsibility: Considering the fact that team is small and tasks are equally divided to team members, members not finishing the given task in a certain time may cause problems in meeting project deadlines. 8.1.2. Customer Characteristics (CC) • Customer’s being instable about requirements: Changes on the given project scope and objective or additional requests that are not stated in the project layout, may force team to reconsider the project plan and redefine project design.

Page | 36

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

• Customer’s dissatisfaction: End‐users dissatisfaction from the project such as demanding enhancements may force team to reconsider project scope and may cause changes in project layout. 8.1.3. Project Parameters (PP) • Wrong estimation of hardware requirements: Since the project has an important graphics feature that depends on CPU and Graphics Card wrong estimation of hardware requirements may cause harm to reality of program and may end up with dissatisfaction of end users. • Misconception in project subject: Since the project subject is about saving human life, the project involves risk by nature. Misunderstanding the subject and requirements would certainly result in unpleasant situations. 8.1.4. Development Process (DP) • Lacking Component Integration : As the project involves many different technologies and environments, project team may have difficulty in integrating the components and making the application work • Lacking Software Quality Assurance: As the software quality assurance encompasses entire development process, disregarding it in any phase of the project may result in a dissatisfactory product. • Lacking Systematic Tests: In the construction phase, project team’s getting stuck with the coding would cause them to overlook testing and this would inevitably result in many bugs. 8.1.5. Development Environment (DE) • Used technology’s being defective, halfway or incompetent: In the project, mainly open source tools and environments are used. If those are not examined carefully at the beginning, project team could face with many problems such as bugs, halfway components, etc… and this would definitely slower the project for no reason. • Use of complicated technology: Especially for game programming, there are lots of libraries, engines and tools. Although they could be quite useful, learning to use

Page | 37

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

them is another big task. Getting stuck with those could result in hazardous delays in the project.

8.2. Risk Table Risk Category Probability Impact Wrong estimation of hardware requirements PP 20% 3 Not obeying given deadlines PP 10% 1 Large project size PP 30% 2 Misconception in project subject PP 20% 3 Inappropriate assignment of tasks DP 30% 3 Difficulty in maintaining the robustness DP 40% 3 Difficulty in implementation DP 30% 1 Lacking component integration DP 40% 2 Lacking software quality assurance DP 40% 3 Lacking systematic tests DP 50% 3 Use of complicated, inappropriate technology DE 15% 2 Defective, halfway or incompetent technology DE 25% 2 Customer’s being instable about requirements CC 20% 3 Customer’s dissatisfaction CC 20% 3 Underestimated minor roles SS 40% 3 Members lack of training on used technology SS 60% 4 Members lacking sense of responsibility SS 20% 2

ImpactU Values: 1 Catastrophic 2 Critical 3 Marginal 4 Negligible

Page | 38

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

8.3. RMMM Table Risk Mitigation Monitoring Management Broaden the hardware Spending too much Decrease the Wrong estimation of requirements in the time on program complexity hardware requirements beginning execution Make a reasonable Being behind schedule Increase working time Not obeying given schedule equally to catch up on the deadlines distributing tasks in schedule time Give Priorities to tasks Incomplete tasks and Give Priorities to tasks Large project size and advance level by being behind schedule and advance level by level level Make a clear and Conflicting with the Redefine the problem. Misconception in project detailed problem customer later in the Change requirements subject definition interviews and design accordingly Equally distribute Unequal workload Redistribute tasks Inappropriate workload among team among team members among team members assignment of tasks members Make detailed tests Nondeterministic Try to eliminate bugs Difficulty in maintaining behaviour of the the robustness application Clearly identify Insufficient progress in Review implementation Difficulty in implementation tasks implementation tasks and increase implementation and assign appropriately working time Check integrability of Facing errors after Reimplement some Lacking component libraries before deciding integrating components so that integration to use them components they integrate well with all other components. Lacking software quality Use quality Observe low quality in Implement software assurance management the application quality assurance

Page | 39

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

techniques activities Make regular tests Identifying defects Make regular tests Lacking systematic tests afterwards Make a comprehensive Progressing very Change the technology Use of complicated, research about slowly due to being used inappropriate technology technologies that are complexity of the

planned to be used tools Make a comprehensive Not progressing due to Change the technology Defective, halfway or research about defects in tools being used incompetent technology technologies that are planned to be used Make interviews with At each interview Agree with the Customer’s being customers and make customers change customers on the instable about sure both sides agree on requirements requirements requirements the requirements Make interviews with Get negative feedback Communicate with the Customer’s customers and make from customer customer to specify the dissatisfaction sure both sides agree on needs the requirements Clearly identify tasks Some tasks require Increase working time Underestimated minor and their workload more time than to catch up on the roles estimated schedule Check if the used Spend much time on Spend extra time Members lack of training technology is well learning how to use training on used on used technology documented and has the technologies technologies or switch an API easy to learn to another technology Provide good Detect incomplete Communicate with the Members lacking sense communication tasks team member of responsibility between team members

Page | 40

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

9. Software Quality Plan 9.1. Introduction A Software Quality Plan is done to define software quality tasks and responsibilities, to provide guidelines while performing software quality activities, to provide standards, practices and conventions used in SQA activities, and to provide techniques, methodologies to support SQA activities and SQA reporting. 9.1.1. Scope This plan establishes the SQA activities performed throughout the life cycle of the project ‘Savior’. The goal of team is to verify that all delivered software and documentations meet the requirements. The SQA procedures will be used to examine all software and documentation to determine compatibility with technical and performance requirements. 9.1.2. System Overview The ‘Savior’ is an online virtual team collaboration platform with 3D graphics. The intended features of the project are given as follows: • Main aim of the simulation is to give the illusion of a real world to the user. The software should allow the user to observe a realistic physics environment. • Since the application is an education program, it is important to give feedback to user according to player’s performance. This feedback will be given by comparing the achievements of player with possible optimum solutions. • The program has an educational purpose. Therefore, not to be useless by having the same scenario again and again; different situations and different conditions in each execution of the program will be developed. A simple scenario generator to arrange buildings, people, resources…etc will be realized. • To make the application usable for all kind of users, different levels of difficulty should be offered.

9.2. Organizational Structure The team structure is democratic decentralized, and communications within the team are horizontal. The roles in the project are distributed among members and each role’s responsibilities are specified clearly.

Page | 41

Fall 2007 ‐ SpongeSoft Requirements Analysis Report November 4, 2007

9.3. Software Quality Assurance Tasks 9.3.1. Procedures and Protocols To make the code understandable and to ease debugging in case of error, a coding standard document will be prepared and all members will write the code according to this standard. Also a configuration management plan will be prepared consisting of the decisions about what will constitute a baseline of the product and when baselines will be captured. With the help of this, the team will avoid deviating from the deadlines, and will have more control over the project. 9.3.2. Review Practices A standard procedure for conducting reviews will be established. At the reviews, the working document will be overviewed. The necessary changes will be expressed and if the team voices consensus, the changes will be accepted. Also these changes will be tracked with the help of the editor so that a turn back will also be possible.

9.3.3. Determining The Next Step Since we will use an almost sequential model in the project, risks will be assessed before going to a next step. The team will follow this course of action and also will try to pursue a proactive agenda. Before going to a next step, our approach to development will be assessed and practices that could improve productivity and the quality will be designated. If policies for improving the development process could be formulated, those will be stated.

10. Appendix

Gantt chart of the project are given below in following pages.

Page | 42

ID Task Name Duration Start Finish

1 Project Management 174 days Tue 02.10.07 Wed 28.05.08 2 Proposal Report 5 days Tue 02.10.07 Mon 08.10.07 3 Requirement Analysis Report 19 days Tue 09.10.07 Sun 04.11.07 4 Initial Design Report 20 days Mon 05.11.07 Fri 30.11.07 5 Final Design Report 31 days Sat 01.12.07 Fri 11.01.08 6 Web Page 170 days Mon 08.10.07 Wed 28.05.08 7 Development Tools Analysis 41 days Fri 05.10.07 Fri 30.11.07 8 Open Source Graphics Engine Analysis 41 days Fri 05.10.07 Fri 30.11.07 9 Open Source Network Library Analysis 41 days Fri 05.10.07 Fri 30.11.07 10 Open Source Audio Library Analysis 41 days Fri 05.10.07 Fri 30.11.07 11 Modeling Tool Analysis 22 days Thu 01.11.07 Fri 30.11.07 12 IDE Analysis 41 days Fri 05.10.07 Fri 30.11.07 13 Game Concept Development 74 days Tue 02.10.07 Thu 10.01.08 14 Game Subject Decision 4 days Tue 02.10.07 Fri 05.10.07 15 Scenario Development 71 days Fri 05.10.07 Thu 10.01.08 16 Information Gathering about 28 days Wed 24.10.07 Fri 30.11.07 17 Emergencies 28 days Wed 24.10.07 Fri 30.11.07 18 First Aid 28 days Wed 24.10.07 Fri 30.11.07 19 Fire Fighting 28 days Wed 24.10.07 Fri 30.11.07 20 Search & Rescue 28 days Wed 24.10.07 Fri 30.11.07 21 Evacuation 28 days Wed 24.10.07 Fri 30.11.07 22 Character Roles & Resources Identification 71 days Fri 05.10.07 Thu 10.01.08 23 Gameflow Design 70 days Mon 08.10.07 Thu 10.01.08 24 User Interactivity/Control Decisions 70 days Mon 08.10.07 Thu 10.01.08 25 Sketching 49 days Thu 25.10.07 Mon 31.12.07 26 Game Map Design (METU Campus) 49 days Thu 25.10.07 Mon 31.12.07 27 Graphical User Interface Design 47 days Mon 29.10.07 Mon 31.12.07 28 Storytelling 31 days Fri 30.11.07 Thu 10.01.08 29 Game Resource & Game Art Production 65 days Fri 01.02.08 Thu 01.05.08 30 3D Objects Modeling 65 days Fri 01.02.08 Thu 01.05.08 31 Buildings 21 days Fri 01.02.08 Sat 01.03.08 32 Collapsed Buildings 21 days Fri 01.02.08 Sat 01.03.08 33 Buildings in Fire 21 days Fri 01.02.08 Sat 01.03.08 34 Undamaged Building 21 days Fri 01.02.08 Sat 01.03.08 35 Cars & Vehicles 43 days Fri 01.02.08 Tue 01.04.08 36 Fire Engine 43 days Fri 01.02.08 Tue 01.04.08 37 Ambulance 43 days Fri 01.02.08 Tue 01.04.08 38 Ring & Bus 43 days Fri 01.02.08 Tue 01.04.08 39 Helicopter 43 days Fri 01.02.08 Tue 01.04.08 40 Cars 43 days Fri 01.02.08 Tue 01.04.08 41 Fire Extinguishers 21 days Fri 01.02.08 Sat 01.03.08 42 First Aid Equipments 21 days Fri 01.02.08 Sat 01.03.08 43 Strecher 21 days Fri 01.02.08 Sat 01.03.08 44 Trees / Forest / Plant 43 days Fri 01.02.08 Tue 01.04.08 45 Stadium, KKM,Carsi, Rektorluk, Teknokent 65 days Fri 01.02.08 Thu 01.05.08 46 Statues 65 days Fri 01.02.08 Thu 01.05.08 47 3D Characters Modeling 43 days Fri 01.02.08 Tue 01.04.08 48 Fireman 21 days Fri 01.02.08 Sat 01.03.08 49 Yellow Fireman 21 days Fri 01.02.08 Sat 01.03.08 50 Orange Fireman 21 days Fri 01.02.08 Sat 01.03.08 51 First Aid Personnel 21 days Fri 01.02.08 Sat 01.03.08 52 Doctors 21 days Fri 01.02.08 Sat 01.03.08 53 Nurses 21 days Fri 01.02.08 Sat 01.03.08

Page 1 ID Task Name Duration Start Finish

54 Search & Rescue Team 21 days Fri 01.02.08 Sat 01.03.08 55 Search & Rescue Staff 21 days Fri 01.02.08 Sat 01.03.08 56 Search & Rescue Dogs 21 days Fri 01.02.08 Sat 01.03.08 57 Injured People 43 days Fri 01.02.08 Tue 01.04.08 58 Unconscious 43 days Fri 01.02.08 Tue 01.04.08 59 Severe Bleeding 43 days Fri 01.02.08 Tue 01.04.08 60 Burn 43 days Fri 01.02.08 Tue 01.04.08 61 Broken Bones 43 days Fri 01.02.08 Tue 01.04.08 62 Healty People in Panic 43 days Fri 01.02.08 Tue 01.04.08 63 Treated People 43 days Fri 01.02.08 Tue 01.04.08 64 Texture Creation 65 days Fri 01.02.08 Thu 01.05.08 65 2D Map Modeling 21 days Fri 01.02.08 Sat 01.03.08 66 Sound Effects & Music Generation 23 days Tue 01.04.08 Thu 01.05.08 67 Graphics & Audio Development 72 days Fri 01.02.08 Sat 10.05.08 68 Surface Texturing 65 days Fri 01.02.08 Thu 01.05.08 69 Graphical User Interface Implementation 65 days Fri 01.02.08 Thu 01.05.08 70 3D Object Loading and Rendering 65 days Fri 01.02.08 Thu 01.05.08 71 3D Environment Implementation 65 days Fri 01.02.08 Thu 01.05.08 72 Illumination Implementation 45 days Fri 29.02.08 Thu 01.05.08 73 Sound Effects Implementation 44 days Mon 03.03.08 Thu 01.05.08 74 Animation 30 days Tue 01.04.08 Sat 10.05.08 80 Network Development 65 days Fri 01.02.08 Thu 01.05.08 81 TCP Based Low-Level Protocol 21 days Fri 01.02.08 Sat 01.03.08 82 High-Level Server-to-Client Protocol 21 days Fri 01.02.08 Fri 29.02.08 83 High-Level Client-to-Server Protocol 21 days Fri 01.02.08 Fri 29.02.08 84 Packet Creation 23 days Tue 01.04.08 Thu 01.05.08 85 Packet Parsing 23 days Tue 01.04.08 Thu 01.05.08 86 Packet Transfer 23 days Tue 01.04.08 Thu 01.05.08 87 Server Network Implementation 44 days Mon 03.03.08 Thu 01.05.08 88 Client Network Implementation 44 days Mon 03.03.08 Thu 01.05.08 89 Send and Receive Modules 44 days Mon 03.03.08 Thu 01.05.08 90 Server Multi-threading Implementation 23 days Tue 01.04.08 Thu 01.05.08 91 Synchronization 23 days Tue 01.04.08 Thu 01.05.08 92 Compressing 13 days Tue 15.04.08 Thu 01.05.08 93 Encryption 13 days Tue 15.04.08 Thu 01.05.08 94 Game Logic Development 55 days Mon 03.03.08 Thu 15.05.08 95 Game Logic Implementation 44 days Mon 03.03.08 Thu 01.05.08 96 Game Scripting 44 days Mon 03.03.08 Thu 01.05.08 97 Database Implementation 23 days Tue 01.04.08 Thu 01.05.08 98 Game Save/Load Implementation 34 days Tue 01.04.08 Thu 15.05.08 99 Game Deployment and Testing 142 days Sat 01.12.07 Fri 13.06.08 100 Optimization 5 days Sat 10.05.08 Thu 15.05.08 101 User Manual 5 days Sat 10.05.08 Thu 15.05.08 102 Installation Manual 5 days Sat 10.05.08 Thu 15.05.08 103 Demo Portfolio 142 days Sat 01.12.07 Fri 13.06.08 104 Prototype Demo Implementation 36 days Sat 01.12.07 Fri 18.01.08 105 Final Demo 97 days Fri 01.02.08 Fri 13.06.08 106 Test Cases Design 8 days Thu 01.05.08 Sat 10.05.08 107 Alpha Testing 8 days Sat 10.05.08 Tue 20.05.08 108 Beta Testing and Getting Feedback 18 days Wed 21.05.08 Fri 13.06.08 109 Debugging 22 days Thu 15.05.08 Fri 13.06.08 110 Upgrades/Patches 21 days Fri 16.05.08 Fri 13.06.08

Page 2 ID Task Name Septembe 01 October 01 November 01 December 01 January 01 February 01 March 01 April 01 May 01 June 01 J 09 23 07 21 04 18 02 16 30 13 27 10 24 09 23 06 20 04 18 01 15 29 1 Project Management 2 Proposal Report A;D;B;N 3 Requirement Analysis Report A;D;B;N 4 Initial Design Report A;D;B;N 5 Final Design Report A;D;B;N 6 Web Page N 7 Development Tools Analysis 8 Open Source Graphics Engine Analysis A;N 9 Open Source Network Library Analysis B;D 10 Open Source Audio Library Analysis B;D 11 Modeling Tool Analysis B;D 12 IDE Analysis B 13 Game Concept Development 14 Game Subject Decision A;B;D;N 15 Scenario Development A;B;D;N 16 Information Gathering about 17 Emergencies D 18 First Aid A;N 19 Fire Fighting A;N 20 Search & Rescue A;D 21 Evacuation D 22 Character Roles & Resources Identification N 23 Gameflow Design A;D;N 24 User Interactivity/Control Decisions N 25 Sketching A 26 Game Map Design (METU Campus) A 27 Graphical User Interface Design N 28 Storytelling B;D 29 Game Resource & Game Art Production 30 3D Objects Modeling 31 Buildings 32 Collapsed Buildings A;N 33 Buildings in Fire A;N 34 Undamaged Building A;N 35 Cars & Vehicles

Page 1 ID Task Name Septembe 01 October 01 November 01 December 01 January 01 February 01 March 01 April 01 May 01 June 01 J 09 23 07 21 04 18 02 16 30 13 27 10 24 09 23 06 20 04 18 01 15 29 36 Fire Engine A;N 37 Ambulance A;N 38 Ring & Bus A;N 39 Helicopter A;N 40 Cars A;N 41 Fire Extinguishers A;N 42 First Aid Equipments 43 Strecher A;N 44 Trees / Forest / Plant A;N 45 Stadium, KKM,Carsi, Rektorluk, Teknokent A;N 46 Statues A;N 47 3D Characters Modeling 48 Fireman 49 Yellow Fireman A;N 50 Orange Fireman A;N 51 First Aid Personnel 52 Doctors A;N 53 Nurses A;N 54 Search & Rescue Team 55 Search & Rescue Staff A;N 56 Search & Rescue Dogs A;N 57 Injured People 58 Unconscious A;N 59 Severe Bleeding A;N 60 Burn A;N 61 Broken Bones A;N 62 Healty People in Panic A;N 63 Treated People A;N 64 Texture Creation A;B 65 2D Map Modeling A 66 Sound Effects & Music Generation B 67 Graphics & Audio Development 68 Surface Texturing A 69 Graphical User Interface Implementation D;N 70 3D Object Loading and Rendering D

Page 2 ID Task Name Septembe 01 October 01 November 01 December 01 January 01 February 01 March 01 April 01 May 01 June 01 J 09 23 07 21 04 18 02 16 30 13 27 10 24 09 23 06 20 04 18 01 15 29 71 3D Environment Implementation A;D 72 Illumination Implementation N 73 Sound Effects Implementation B 74 Animation 80 Network Development 81 TCP Based Low-Level Protocol B;D 82 High-Level Server-to-Client Protocol B;D 83 High-Level Client-to-Server Protocol A;N 84 Packet Creation B;D 85 Packet Parsing B;D 86 Packet Transfer B;D 87 Server Network Implementation B;D 88 Client Network Implementation A;N 89 Send and Receive Modules B;A 90 Server Multi-threading Implementation D;N 91 Synchronization D;N 92 Compressing B;A 93 Encryption B;A 94 Game Logic Development 95 Game Logic Implementation D;N 96 Game Scripting D;N 97 Database Implementation A 98 Game Save/Load Implementation D;B 99 Game Deployment and Testing 100 Optimization B;D 101 User Manual A;D 102 Installation Manual N 103 Demo Portfolio 104 Prototype Demo Implementation A;B;D;N 105 Final Demo A;B;D;N 106 Test Cases Design N 107 Alpha Testing A;N 108 Beta Testing and Getting Feedback A;N 109 Debugging B;D 110 Upgrades/Patches A;B;D;N

Page 3