responder 108 : a disaster managements3images.coroflot.com/user_files/individual_files/365810... ·...

Responder 108 : A Disaster ManagementSimulation-Game

for Training First Responders.

Hari ShankarSrishti College of Art, Design and Technology

Centre for Study of Science, Technology and Policy

This thesis focuses on a project on developing the playable prototype of a disaster management game, and the concept and framework for developing the full game as a training tool for emergency personnel. It was developed at and in conjunction with the Centre for Study of Science, Technology and Policy, Bangalore (CSTEP).

I worked mainly under the guidance of Gabriel Harp and Bharath Palavalli who helped me understand the process of game design, and referred me to articles and books that explained the various aspects of the same. A special mention goes out to Lloyd Robert, who aided the streamlining of the various aspects that form this project. Two books that helped greatly and that facilitated the concepts that form the foundation of this game are Rules of Play by Eric Zimmerman and Katie Salen; and Game Design Workshop by Tracy Fullerton.

Abstract

for Mum, Dad, Chechi, Raj Bhaiya and little Mihika

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

Part I1. Introduction2. Why a Game?3. Game Overview/Summary4. Framework’s Overview5. Project Proposal

Part II1. Understanding this Thesis

2. Groundwork a. Choosing the Right Engine

3. Building the Framework a. Finalizing The Scenario/Story b. Probing Real Life Procedures c. The Scenario Scripted d. Building The Decision Charts

4. The Game Space a. Game Space Elements Explained

5. The CryENGINE a. Importing Geometry and Textures b. The CryENGINE FlowGraph c. Node Reference e. AI Control Objects

6. Conclusion a. Limitations b. Basic Play-testing c. Summary

7. Bibliography / References8. Credits and Thanks

12334

8

89

1010111315

1919

3232353637

38383839

4041

Table of Contents

responder 108 : a disaster management training game1

Earlier this year a summer internship was being offered at Centre for Study of Science, Technology and Policy (CSTEP), Bangalore, which involved working and understanding the CryENGINE® 3, an advanced game engine which is known for its dynamism and ability to recreate real world environments and physics for games. As a student of Animation and an avid gamer for years, this was an interesting opportunity. On further briefing about their various projects and CSTEP’s intention to develop a game as a training tool for disaster management, seemed like a good challenge as well as a change to deviate from making an animated film to making something functional and interactive, and that aims to serve a specific purpose at the same time.Through the originally decided internship period of two months, I decided to develop the game’s framework and a working prototype as my thesis project, with CSTEP as my client, and the various emergency services as potential clients. The game is meant for the training of only emergency service personnel, and isn’t a game for the general public.

Introduction


Why a game?

In the course of working on this project, and talking to people involved in the area of disaster management, It was found out that training games/simulations do exist, but they are mostly for higher level officials who mobilize services and strategize the deployment. There’s a dearth of simulations for the ground-zero personnel, who are active on the scene and make crucial decisions on a more micro level. The only source of training/know-how for these personnel is in the form of information handbooks and the occasional training drills that are performed.

The Dubai police are developing a game on traffic accidents and crime scene investigation for virtual training purposes (not available to the general public).Sixteen Tons Entertainment, a German game publisher has developed 4 games over the years, in its Emergency series, which involves managing disaster situations, playing a fire-fighter, policeman, or as other emergency response services (available to the general public). Triadic Game Design developed the Levee Patroller which deals with Levee Inspectors checking and monitoring dams/levees from flooding the mainland.http://tbreak.com/megamers/5982/news/dwge-dubai-police-showcases-traffic-accident-and-csi-game.htmlhttp://en.wikipedia.org/wiki/Emergency_(series)http://triadicgamedesign.com/leveepatroller.html

The game that’s being developing aims to be complementary to the drills, and not exist independently as a drill replacement. Emergency Personnel can experience real-world scenarios in a computer generated game

environment, explore various methods of dealing with disaster situations, and then apply that learning when they perform drills, or to real disaster situations. An aspect that a training game/simulation caters to is that scenarios previously un-experienced or scenarios that are difficult and resource intensive to re-create can be simulated with relative ease on such a system. Another application would be to re-create past disasters and investigate better and more efficient ways to have dealt with them.

After talks and discussions with people working on the disaster management projects at CSTEP and other resources from outside of CSTEP, it was decided to develop the game to aid First Responders at a given disaster situation. The First Responder, as the name suggests, is a member of any of the emergency services who arrives at the scene of the disaster/impending disaster. The first responder is supposed to manage and control the scene till the other support systems arrive and are set-up. First responders play an important role in such times, as their input and initial assessment of the situation indicates to the other services as to what would be required, and in what measures. Such a simulation would also help in increasing the general awareness and foresight of emergency personnel about the variables and problems involved in a projected disaster, and hence giving ideas that would help them cope better under crisis situations.


Game Overview/Summary

The game would be flexible in terms of the preset scenario.Firstly, the player would have to choose his/her character according to their response service, and that changes their game-play and objectives. There are difficulty levels to choose from, basic content can be added and subtracted suiting the situation. The overall challenges would be changed as per the type of responder chosen, the difficulty level selected. Other variables that can be changed or randomized would be the time of day and the weather conditions. But the main framework would be locked for the end-user, i.e. the emergency personnel or the department it would be used in. The main framework, i.e. the set design, and the assets, the game-flow, the objectives, missions, characters and character designs, structures, etc can be modified, added, or removed by a team of professionals who manage the game design.The player would be assigned Missions that need to be accomplished within a given time limit. There are different choices that the player would need to make towards the successful completion of a said mission, and the choice(s)/method(s) used to accomplish the mission would lead to scoring points ranging from high to low. The choices given are time based, so an efficient and effective choice would take lesser time and lead to a higher score, whereas a less efficient choice would take more time and lead to a lower score. There is also the possibility of the player not being able to complete the mission, which leads to the mission being restarted. A player can simultaneously undertake a maximum of 3 missions at a time, but he/she can undertake only one at a time as well.

The Framework’s Overview

The prototype that’s been developed includes the complete set design for a bomb scare scenario at Garuda Mall, game environment and one playable mission to illustrate the basic level of interactivity that can be achieved with the engine. It is accompanied by the game’s framework as a series of game logic charts, and decision charts which helps developers to add and subtract behavioural and environment based variables, missions. It allows them to understand how the game works and makes the development of new levels easier. The decision charts allow substitution, addition and removal of actions/steps.

An educational license of the game engine, CryENGINE® 3 was made available to CSTEP by Crytek® for non-profit, non-commercial use. Crytek® very generously also gave access to their knowledge base, the comprehensive game engine documentation, and also their forum where other developers of the game platform troubleshoot and discuss the workings of the engine. The engine is still in development, until at least the first quarter of 2011, around which Crytek® releases the sequel to their game, CRYSIS®, which is built on the same engine.


Project Proposal

I. Design BriefI would like to put forward the proposal for my work towards developing an Interactive Virtual Reality based Game Prototype / Personnel Training Tool that deals with Disaster Management during certain man-made/natural disasters.

II. BackgroundOver the two years as an Animation ADP student, I have been able to explore and develop my skills in almost all the processes involved in making an animated film, and I’ve applied it as well, into making at least 3 of my own short animated films; from script to screen. Experimentation with different styles and tools have added to my experience and knowledge as I’ve always believed that delving into areas little known or unknown to me lead to bigger challenges, acquiring new skills and of all, triggers a great learning experience.

The same feeling led me to taking up an internship about two months ago, at The Centre for Study of Science Technology and Policy (CSTEP), a project based on disaster management and was to be developed on the CryENGINE® 3, as they had been given an institutional license for using it.

Initially, what drew me towards taking up the internship was the opportunity to explore the engine and maybe develop something basic on it, as I’ve been an avid gamer for years, but I’d never worked on a game engine. So I joined CSTEP for a two month internship.There, I was given the project brief, about the situation of emergency services in India, and how their slow response leads to casualties. Be it Terrorist Attacks, Accidents, Natural or Man-Made Calamities; it is a widely known fact that the lack of coordination and preparedness of the emergency services and authorities in Bangalore, or for that reason, even other cities around India, have led to more

damage and casualties, that could be averted if the response by the authorities was more organized and efficient. Even news agencies and channels have been emphasizing on the same for quite some time now.

If the flow of information happens in an organized manner, if the personnel involved are trained to cope with and make decisions before such a calamity might strike, if the infrastructure systems and services are utilized resourcefully and efficiently, then the scale of the disaster and its effect can be considerably reduced and restricted.This has be deduced from the delayed response from the emergency services during the Carlton Towers fire, The Mangalore Plane crash, etc.., as reported in various newspapers, news channels, etc., Ambulances and fire engines arriving late. Diversion of traffic around the disaster struck area happens haphazardly. These seem to repeatedly occur in every single report on the news.

As a part of this project as an Animator, I am required to develop a prototype of an interactive game that would be used to give the First Responders a first hand experience at a disaster scenario that they might/might not be familiar with.

III. The Game’s OverviewThe game would have selectable characters; A Fireman, A Policeman, A Medical Personnel, A Security Guard, A Civilian, etc..Scenarios could vary from A Bomb Blast/Scare, A Metro Accident, A Big Fire, etc…At each step, the player would be posed with options/choices that pertain to handling the disaster. The decisions made and the options chosen grade the player’s attitude and behaviour, and inform the player about a better order of options that could have been chosen (If any).

The media of the outcome is something I can’t finalize completely, but I’ve


narrowed it down to two options that justify the process in the best way possible. Both would be based on the Flowchart / Options that has been created from the surveys and research. The final outcomes can have been categorized as follows.

1. Building that game on the CryENGINE® is definitely my first choice, as it uses real world Physics computations, and the level of interactivity and visual detail is very promising. The Flowchart / Options would be integrated into a third person player environment, and these options would be prompted to be chosen from, at different steps during the game. But the work-flow on the engine itself is quite complex and it requires animation as well as programming; the latter being something I’ve never had much experience in. So my concern with this is to not end up with something that’s half cooked, despite how good it might look.

2. The second option for the outcome would be a Graphical User Interface with the same Flowchart / Options incorporated into it. Instead of a Third Person/Videogame-like interactivity, this version would be based on pre-rendered cut-scenes/visualizations. The player would be presented the options on a map on the GUI, and once he/she chooses the option, the ensuing cut-scene would be triggered to play in order to show the result of that action.

IV. Research QuestionsOne of the first questions I want to design my game around would be whether a game will be accepted as a training tool for something this crucial?

The application of a game to real-life situations. Given the volatility of the real life variables that change with every situation?

The age old notion of games being something children play is definitely changing. But does a serious game debunk that notion and actually apply itself in showing

Policy Makers different disaster scenarios, and how they can strategize plans in order to achieve better efficiency and faster response times?

Would it help emergency personnel in accomplishing better response times?

How are these emergency services networked, if at all? And how better communication and coordination between them through the personnel can lead to better crisis management. Possibly a multiplayer feasibility, if it needs to be applied to a training game?

Also, by interacting with authorities as well as civilians, I’d like to find out their knowledge on how to react when faced with a disaster situation, and their awareness as to which service to contact and how.

How the demonstration of this game to policy makers would affect the current state of things.

V. Approach/ProcessThe prototype I propose to create aims to be a working model with one selectable character and one scenario; possibly a fire, due to the mismanagement of the past fires that have happened in Bangalore, most conspicuously, the Carlton Towers fire.The fact that the emergency systems aren’t networked efficiently and the lack of coordination between the different agencies ultimately leads to civilian casualties, made me realize the relevance and importance of the development of a tool that lets Emergency Personnel as well as Policy Makers experience a disaster situation in virtual reality, play through the options and figure out better ways to handle such situations, or at least put them in the shoes of those at the scene. It gives an interactive face to CSTEP’s Disaster Management Project, as most of it is based on collecting data, and creating graph based models and simulations.


A serious, interactive game would help bridge a simple, user friendly game with the data and behaviours that have been collated from the agencies, into a training tool that allows emergency/rescue agencies to understand situations beforehand.

VI. Steps to CompletionThe project would involve:1. Content/model creation from scratch, of a place in Bangalore. 2. A Scenario will be conceptualized, and the options for managing that situation

would have to be formalized.3. A definitive set of options for the scenario has to be built on the basis of

how different agencies; namely, The Fire Service, The Police, The Medical Services, The Public Works Department, etc, have protocols that define the set of actions their personnel are supposed to act on, coupled with the vox-populi from a survey that includes civilians as well as agency personnel about what they currently know about managing a situation, or what they think would be a rational set of things to do during a disaster.

4. After organizing these, a flowchart would need to be created, as different options would lead to different results; The Trainee playing the game could be rated on the basis of options he/she chose. They could be rated as rational/aggressive/casual/careless as each option chosen would contribute to an aspect of character. It would also reflect on the Trainee’s decision making abilities

5. Now the game would be built. The engine has to be chosen / understood according to the ease of implementation of the Artificial Intelligence that guides the Options Flowchart. Other factors would be ease of content creation, complexity of integration with 3D softwares that would be used to create models, minimum use of programming languages or maybe a simpler, Graphical interface that simplifies programming procedures. The created models would have to be localized, so that it looks Indian, which will help the Trainees to relate to the game environment.

6. The game would be tested at various levels during development, with civilians, as well as Rescue Personnel (if available and agreed upon) as their feedback would help fine tune the game as per their needs.

VII. Materials/ResourcesThe CryENGINE® is a revolutionary game engine that ushered in a whole new dimension to realism in games because of its use of real world physics calculations. It was first used for a game called FarCry®, but is most noted for the realism and quality achieved in another game called CRYSIS®.A game engine is basically software that allows different types of games to be created on it, and the games depend on the engine’s procedural Content / Environments / Objects /Libraries. They can be further customized with scripts and programming in the language that the engine supports.The CryENGINE® uses a mixture of Advanced programming (for people with prior knowledge of languages like Python, LUA, etc.) as well as Visual procedural programming, which helps non-programmers create basic scripts with the help of a graph based tool which connects attributes, and creates the script automatically. But for advanced AI, knowledge of the above specified languages is required.I’ve been trying to find alternatives to the CryENGINE®, which might have a less complex workflow. The Unreal® engine has a free SDK distribution, and it’s been around for very long, so documentation and tutorials wouldn’t be too hard to find. I’ve been looking at the Quest3D engine as well. It’s known to be less complex and powerful at the same time.In order to finalize the media of the outcome, I’ve been trying out the engine. I also intend to contact game programmers, who have prior experience on this engine or any other, so that I could learn the basic work-flow and figure out the rest as it comes.

VIII. Learning Outcomes I find this project quite challenging as it would need me to inquire into a lot of


areas I’ve never really explored before and hence, add to my skill and learning. I also feel that this project is important and relevant in the sense that it can be a part of a change that is necessary.Also, as the game is based in an Indian environment, an entirely new library of objects, buildings, crowds, vehicles, etc.., will have to be modelled from scratch, and the environment itself will have to look localized. This library can be added on to and re-used in future projects based on the Indian context.CSTEP would also need me to go back and complete the game, after the prototype is done, which will take more time. Depending on how scenarios can be added, or contextualizing the same for other cities, if the feasibility allows it, I would certainly look forward to being a part of it after this part is completed.

IX. Deliverables1. Framework for Training Tools for Disaster Management.2. A Game/Interactive Disaster Management Simulation Scenario.3. A library of Localized 3D Models, that applies to the Indian context, and

can be used in other projects.4. Thesis and Documentation on the Creation of a Disaster Management

Simulation.


Understanding this ThesisFor the sake of easier understanding,this book categorically explains the processes with respect to two inseparable aspects of developing this game; Conceptual and Technical. The Conceptual process involves charting out the game’s characteristics on paper, i.e. building a framework that can be implemented or translated into the final medium of execution to make it work (The medium of execution here being the CRYENGINE® 3). The second being Technical involves understanding the engine and building the game on it, and creation of assets to incorporate that into the same.The disaster management project at CSTEP involves the study of natural/man-made disasters. They require a different approach, policies and practices in an urban context at the institutional level. Inter-agency collaboration at multiple levels is important to handle such crises effectively and efficiently.Disaster are bound to occur, but mitigation of the magnitude is highly necessary.For example, during the Carlton Towers fires in Bangalore last year, the traffic

delayed the fire engines from reaching the disaster on time.Another example would be the terrorist attack at the Bombay Taj. The media was broadcasting the police and armed forces live on television, which gave the terrorists an advantage. Whereas the forces were on their own and had no idea about the terrorists actions.In all these situations, better trained and better equipped First Responders would’ve made a big difference on how these disasters were managed.

GroundworkAt the start of the internship, there was a briefing on the disaster management project that was going on at CSTEP, and how they planned to make a serious game as a training tool. But as an internship project, the basic motive was to understand the game engine, and build assets for the same. To start, a location needed to be finalized, that could be simulated in 3D. Various key locations in Bangalore that are prone to disaster situations and where management of probable disaster would be difficult/challenging were discussed. After short listing locations like

Garuda Mall, Bangalore Garuda Mall, modelled and rendered on Autodesk® Maya


the Brigade Road - M.G Road intersection, Forum Mall, Garuda Mall, Sigma Mall, etc.., Garuda Mall was zeroed in on due to the high density of traffic there at all times, the one-way flow of traffic at three out of the 4 roads that form the crossroad in front of it, its general popularity as a hang-out due to the presence of a multiplex and a wide array of stores and eateries. So it was decided to model Garuda Mall, and about half a kilometre’s radius around it. The next step was to model the location. Usually, a floor plan is ideal to model a building, but as the floor plans for Garuda Mall weren’t available, so the next best thing to do was to click photographs from all sides possible, and use those images as references. Once the references were in place, the model of the mall was made from scratch, textured, and then lit on Autodesk Maya. As a demonstration, a walk-through was rendered on the same to get a basic idea of the visual detail to be achieved when the set was imported into a game engine.

Choosing the right engineThere was a choice between three game engines at this point. The CryENGINE® 3 developed by Crytek® GmbH, The Unreal® Engine developed by Epic Games and the Quest3D engine by Act-3D B.V. The Unreal® Engine is one of the longest surviving game engines today and has been used to make countless games. It has

kept up with the gaming industry by updating the engine to be capable of physics and realism. It is available online, free for non-commercial use. But its environments and visual styles are very fantasy biased and usually used for sci-fi based games. Hence it wasn’t suitable for the environments and characters in this game.The Quest3D engine is relatively easy to use, but is also low on visual detail at the same time. It wasn’t a bad trade-off, but the problem was that it wasn’t available for free, and it was quite expensive.The CryENGINE®’s educational license was provided for free, and it had a vast documentation that enabled learning it much easier. It generates real world physics and dynamics in realistic looking environments which makes it easier for the player to relate to. The only drawback was that it was still in development, but there were constant updates that kept improving it. All this worked in favour of choosing the CryENGINE®.

Now that the set was complete, it was imported into the CryENGINE® 3 and changes were made to the set accordingly. Dust and pollution simulations were incorporated into the environment, to make it seem natural. Other elements were added as well, like clouds, vegetation, etc. The time of day can be set as required, and loads up with a level if programmed.


Building the FrameworkJust like a movie has to be scripted, a game needs a script too. The only difference being that the player makes the choices in the game, which leads to the eventual successful completion of the game, if the player made the right choices and achieves his/her character’s goal in the game. Unlike a film, a game’s genre depends on its gameplay, rather than its storyline/plot. The genre of the game puts limitations/boundaries on what the game can do. For example, a game belonging to the Shooter or Action genre would usually be restricted within a set boundary within which the missions are based, and the objective is to shoot or defeat an opponent/villain. Whereas a Strategy or Role Playing Game (RPG) or a Massively Multiplayer Online RPG would involve environments that can be explored and looked into and finding objects and gaining experience and scores while doing that. This game can roughly fall into a First Person Real Time Simulation game

Finalizing the scenario/storyI started looking into potential scenarios around which the prototype could be based on. After putting down scenarios like terrorist attacks, fires, bomb scares, bomb blasts, hostage situations, etc.., I decided to use a bomb scare scenario at the mall.

1. The primary reason for choosing a bomb scare as the scenario for my prototype was because they are fairly common at malls and market places.

2. Because crowded places tend to be potential targets 3. A bomb scare requires a fair amount of involvement from all emergency

services4. It also requires all the services to coordinate and work together.5. The prototype is meant to be a feasibility model. Only on the basis of what

reactions it gets from the end-clients, i.e., the emergency services, more complex and bigger scenarios can be built.

6. Important and critical as they are, I didn’t choose a bomb blast or a fire


scenario because they focus on rescue and salvage operations which reduce the role of certain services.

7. A hostage situation would also mean the reduced role of certain services, and also a much more complex set of operations and flow of command.

Probing Real Life ProceduresTo match the procedures as much as possible to imitate the actual procedures that are followed by personnel in real life, organizations and service personnel had to be approached with a set of questions. It is very important for the game procedures to follow the same methods of disaster management that are used in reality because after all, it is meant to be a training tool.The inquiries were modelled around these questions:1. Are there set guidelines or a set of actions that are to be followed by emergency personnel when they arrive at the scene of any disaster? If yes, is there any way i could know what these are, so that I could incorporate these into the game/simulation?2. What parameters could be added to such a game/simulation to make it actually helpful as a training tool?3. To what level are the said guidelines to a disaster followed, and is the hierarchy of orders strict, or is there scope for rescue personnel to take decisions on his own, in the absence of his superior?4. How well are the different support systems networked? i.e., is there a proper and continuous flow of information updates flowing between the police, public works, medical, fire personnel, during a disaster? Can this be made better?

Meeting with Mr. Arun Sahdeo from NIDMI approached the National Disaster Management Authority (NDMA) of India in New Delhi around July 2010 before starting on the conceptualization of the game.Like most government offices, it was quite hard to get in touch with officials there and enquire about procedures. It didn’t prove too helpful, as most of them were

busy, or refused to meet, or weren’t available.As most doors at NDMA seemed closed, I was told about the National Institute of Disaster Management (NIDM) by a friend. NIDM proved way more helpful. I contacted Mr. Arun Sahdeo who agreed to meet me and discuss my project. He is a consultant to the NIDM, Ministry of Home Affairs; Govt. of India. NIDM mostly deals with upper level disaster management, i.e. to say, it deals with strategizing disaster management situations for the higher level officials of the emergency services. Mr. Sahdeo went through the project proposal, and explained how simulations were available, but mostly for higher level disaster management, i.e. deployment and distribution of personnel, assessing the extent of a disaster, allocation of resources, etc… but these are strategy intensive, based on 2D engines and lacked visual detail.He said it was a good idea to have a training tool for the personnel. A multiplayer option and incorporating organizational structure into it would be ideal. Life-like visual detail would be a plus point, as long as there are configurable options that allow the change of weather, the time of day, etc…The simulations he was familiar with were based on sample cities, and not on specific cities. He said it made sense to have sample cities abroad because of the nature of the organizational structures and behaviours being identical all throughout. But in India, the situation is different. Each city is very different, the flow of command varies, the people’s behaviours vary, and the traffic movements vary, and so on. So implementation of localized data on such variables would be highly effective and advantageous for training personnel.It would be very important for the game to be multidisciplinary. Besides actors like the Police, Medics, Public Works, Fire Dept, etc, there are industrial agencies like CII that have trained personnel to cope with national disasters, so their inclusion would be good.Hence, meeting Mr. Sahdeo proved to be very helpful, and it strengthened the base and added quite a few factors to the existing proposal, and to the game structure and design.


(Address: NIDM, 5-B, IP Estate, IIPA Campus, Ring Road, New Delhi – 110002)

Meeting with Mr. Singh, a Sub-InspectorLloyd Robert was kind enough to help out with meeting policemen here, as previous attempts to meet or talk to them had proved unsuccessful. Gathering information about real life procedures is an important part of this framework, because a training tool cannot be based on assumptions; the procedures need to be accurate.The main agenda was:

1. To find out if there was a manual or guidebook for coping with disaster situations that they, as policemen, are supposed to follow.

2. To find out what the exact procedure is that they’re supposed to follow as prescribed in that guidebook/manual in case of bomb scares.

3. To what extent are these procedures actually followed, do they improvise? If yes, to what extent?

4. If they go through drills to train for such situations, and how helpful are drills when it comes to coping with such disasters.

5. If they’ve been in any emergency situation, and what procedures did they follow. Also, what was the behaviour did they experience from the civilians involved, what kind of reactions and behaviour they experienced from the civilians, and how that behaviour affected their judgement, if at all.

6. Lastly, would a computer based training tool help them cope with real life situations better? Or would it be of any consequence at all?

The response was quite informative. The Sub-Inspector, Mr. Singh (real name withheld on request) agreed to meet us, and provided some really good insight into the process. He came from an army background, so he mentioned how he was already trained for situations like bomb-scares, and how to handle bombs, but the routine training that policemen get isn’t quite enough.He explained the process of handling a bomb scare, and the procedures they follow.On the event of a suspicious package being found in a public place, or information

about a potential bomb planted in a public place, their first order of action is to secure the perimeter and evacuate all people from there. The beat constables and mobile units such as the bike/car patrols are immediately notified to go to the area in question. The response time for the first responder(s) is usually very less, as they are networked quite well. The policemen who reach the scene work on dissipating the crowds, and clearing out the perimeter. The civilians, according to Mr. ABC, usually cooperate, as they obviously fear for their safety. If the probable bomb package has been identified, it is sandbagged, and the area around it is cordoned off. In the meantime, the control centre has already notified the Bomb Squad and the Anti-Sabotage Cell, as a precaution. Mr. Singh explained how they are supposed to try and check if the package actually contains a bomb or not; i.e. a personal inspection of the package. He told us how this isn’t a recommended plan of action, as the package might be wired in a way to go off as soon as anything is touched, which is what happened around the stadium blasts in Bangalore in 2009. This puts the life of a policeman at risk, as they aren’t trained to handle bombs. He said it was better off for the policemen to wait for the bomb squad to arrive. Once the bomb squad arrives, they use sniffer dogs and bomb detection tools to confirm the presence of a bomb. If that is confirmed, they try to defuse it, and if they can’t, they initiate a remote detonation that would cause minimal damage to the infrastructure around the area. All this while, the police are involved in crowd control, as there are always curious bystanders standing away from the set cordoned area. Ambulances are also kept on standby, just in case. Another thing he pointed out was that it’s usually hoaxes that they’re called for.He felt that a training game on a computer would be helpful, but basic computer training would also be required in tow, as a majority of policemen haven’t had much exposure to working on computers. Also, on the time that it would take to go through this training shouldn’t be too much, as they have their routine duties to go on with.


Talk with a Mall ManagerAs my scenario involved Garuda Mall in Bangalore, it was important to find out what their procedures and emergency measures were, if any. But the manager refused to speak about these procedures outright. The only response from the Garuda Mall manager, was that they had their security procedures for emergencies, and that he couldn’t tell me anything about it. At this, the DT Mall, Gurgaon’s manager, Mr. Manish Sharma agreed to speak about security measures and bomb scares that have occurred on prior occasions there. This proved more helpful. He had never been a part of an actual bomb scare, but the emergency services organize drills at the mall sometimes. These are surprise drills, so there is no intimation from the emergency service’s side. According to him, no one besides the high level officials know about the exercise being a drill. All the personnel from all emergency services are led to believe that it is an actual emergency. In case of a bomb scare, a fake bomb is planted in the mall, and the services are called in. Evacuation of the civilians in and around the mall is the primal objective for the services. The police, ambulances, bomb squad and the CRPF (Central Reserve Police Force) are called in. Policemen arrive the soonest, and they secure the perimeter around the mall and together with the mall personnel, they evacuate the mall, and engage in crowd control outside the mall. People usually remain calm throughout the process, and exit the mall without much ruckus. A bomb search is initiated then. By this time, the bomb squad arrives with their implements and sniffer dogs and take over the bomb situation is taken over by them. They detect the bomb, and defuse it. Sometimes, they fake casualties so as to test the medical teams as well.Basically, from this interaction, It was understood that these exercises are aimed at training the personnel, as well as testing their response times and decisions. But at the same time, this drill does take up a lot of resources and does hamper activities. But not in the sense that they should be stopped, but in the sense that such drills cant be repeated too often. So if backed up with a training tool that recreated such scenarios at various locations, it would lead to a better and more efficient response.

The Scenario ScriptedNow that the scenario was finalized, coupled with accounts from people who have been involved in bomb scares and people involved in disaster management, the game needed to be scripted in order to know what would actually go on in it. Following is a rough draft of how the game’s narrative proceeds. It was based on the interactions with Mr. Sahdeo, Mr. Singh and Mr. Sharma mainly, and also on people’s experiences of bomb scares.

Scene 1

The game starts in first person, as a policeman.

The player gets a message on his walkie-talkie

about a bomb scare at the Garuda Mall. His spawn

point at the start of the game would be between

the narrow road that connects Magrath Road and

Brigade Road. His first directive is to go to

Garuda Mall quickly to assess the situation. This


establishes one of the key resources and modes

of communication that the first-responder would be

using, i.e. the Walkie-Talkie. The walkie-talkie

also acts as a means of assigning missions to the

player.

Scene 2

Once he gets to Garuda Mall, the player reports

automatically to the control centre with his

walkie-talkie that the situation around the mall

is still calm, and that nothing has happened as

yet.

At this the player is told that the other services

are on their way, and that he has to manage the

scene till such time they get there.

Scene 3

Now the player gets his first mission, which is

to divert traffic that’s coming into the area,

so as to secure the perimeter. (The purpose of

setting up barricades is two-sided. On one hand,

it is purely based on the actual first objective

policemen have, i.e. to secure the situation

perimeter; and on the other hand, from the game

design perspective, setting up barricades sets

up a defined boundary within which the player

would operate.)

Now the player would be updated with more missions

which contribute towards the accomplishing of

his objectives. The following summarizes the

missions that would follow.

Scene 4

He has to find the Mall Manager, who would be an

important human resource through the rest of the

level. Once the mall manager is met, the player

would get an estimate of the number of people

inside the mall, and this would be reported

to the control centre, so that the emergency

services are sent and set-up accordingly and

ambulances can be requested to be on standby

on that basis.

Scene 5

The mall needs to be evacuated. For that, the

player requests the movie shows to be halted

and the people to evacuate the halls calmly.

At the same time, the stores in the mall need

to be shut as well, and the evacuation of the

mall needs to be started as well. During the

evacuation, all exits need to be opened, and

in this task, the player requests for help from

all available mall security guards.

Scene 6

Once the evacuation is complete, the available

security guards are split up into groups and

the bomb search is initiated. They are to look

for suspicious packages and notify the player

as and when anything is found. The player is

to request an available security authority to

gather the surveillance tapes from the CCTV


cameras in the mall, and survey them for

suspicious activity.

Scene 7

As for operations outside the mall, the player

needs to notify the traffic police and request

them to divert all incoming traffic so that the

emergency services can arrive without getting

caught in traffic. Lastly, the surrounding

buildings also need to be evacuated.

Scene 8

The other emergency services have been arriving

in the meantime, and by now, they have all

been set up, so the player’s work as the first

responder is complete.

Once the narrative was finalized, a very basic Decision Chart of actions that the first responder would be required to follow was charted out.

Building the Decision ChartsA Decision Chart/Tree is a logic set/algorithm that displays the choices that arise from a problem. A problem may have one or many solutions. A Decision Chart defines all the choices that come forth from the problem, and the consequences of picking one choice over the other, and what that consequence leads to, or if it leads to the solution. (http://en.wikipedia.org/wiki/Decision_tree)

The decision charts form one of the most important cogs in this game’s framework. Without decision charts, the gameplay wouldn’t really exist.A decision chart enunciates the choice-consequence flow of a mission. One or multiple missions form procedures and then objectives.

The first Decision Charts


The final version of the decision chart for the first mission.


Hence a decision chart lets a player take up a mission, and deems that mission complete if the sub-objectives within the mission are completed. A game may have several decision charts, which lead the player from the start to the end. Without decision charts integrated into a game, it would just be an environment where a player can run around, as his objectives aren’t defined.Most missions can be taken up at the same time and can be worked on in parallel. But the order in which the missions and procedures are completed affect how much the player scores. For example, initiating the bomb search during evacuation would lead to splitting resources, and also slow down both processes.

Therefore, an efficient and rational flow of choices with respect to the time taken to complete the same leads to a better score.The problem with this decision chart was that it was too simple, and did not illustrate the choices the player would have, what the basis of scoring would be, etc… A decision chart needs to show the various options a player would have; what consequences those actions have; what actions would imply success and failure, and so on. So keeping the first decision chart as a roadmap, each mission needed to be visualized in terms of the various choices and consequences, and add the restricting variables of time and space as well.

Two missions in the decision flow


Difficulty Levels


The Game SpaceGabriel Harp and Bharath Palavalli’s guidance was instrumental in this process of mapping the various elements of game design. The aim was to basically construct the framework of the game so that the later levels could be developed on the basis of this framework. All games are designed around such models, so that more levels can be added on the basis of the basic elements that are shown in the main framework, and also so that changes and edits can be made with ease. Gabriel suggested I use the Story Space-Plot Space approach, and chart out everything that exists in the Story Space. So to say, put down elements that might/might not be a part of the plot (scenario) in question, but might be useful in another. Their interactions, dependencies, restrictions, locations, etc…

Game Space elements explainedActors: The type of characters involved in the game, based on their nature of

involvement. Actors in this game would be the emergency service personnel, the mall personnel, and the general public. I.e. the Police, Traffic Police, Fire Personnel, Bomb Squad, Medical Service Personnel form the Emergency Services. The Mall Management, Mall Security, Mall Parking Attendants are a part of the Mall Personnel. And then the General Public towards whose safety all the operations are directed towards.

Objectives: Are the broader individual goals that are dependant on the personnel’s service. Objectives are non-specific and address to a broad perspective and can be also be labelled as the duties of the personnel.

Procedures: Are the building blocks of Objectives. These are specific actions that are to be performed in order to successfully accomplish an objective. There might be one or several procedures that form an objective.

Resources: Are the tools or means of carrying out procedures. They could be specialized implements available to certain actors, or they could be general tools available at the scene of emergency that can be used by the actors to cope with the emergency.

Boundaries: Are physical area restrictions to which the players are bound in the level map. Boundaries could be of two types Level Boundaries; which restrict the player from exiting the level or entering certain areas that don’t need to be accessed during the game; e.g. Buildings/structures that aren’t pertinent to the gameplay. And Mission/Procedure Boundaries; which restrict the player from exiting the perimeter of the procedure/mission he/she is currently undertaking. Boundaries can be game based restrictions too, which present player interactions or actions.

Rules: Restrict players from performing certain actions that hamper the game-play, or aren’t required during the course of the game. Rules also challenge the player by curbing actions that would otherwise make the game-play too simple and unchallenging.

Missions: Are Sub-Objectives which contribute to the accomplishment of an Objective. To complete a mission, a player can use resources available to him, but is also bound to time limitations, boundaries and the game rules.

These elements were now graphically represented on a chart, with respect to each other, and how they interacted with each other. There were quite a few iterations which led to the final version. Each version was discussed with my guides and peers, and feedback that was felt to make it more understandable and efficient was included.The colour coding made a big difference. These charts and decision charts form the framework of the game, hence the visual grammar needed to be simple and each aspect needed to be easily understandable by people involved in developing the game later. The approach I adopted was to assign each actor with a basic colour that they are usually identified with. Shades of the same colour were assigned to their respective objectives, and the procedures that would fall under those objectives would be identified with that shade. This brought uniformity to the charts, and was relatively easily understood by most people it was reviewed by.The incorporation of icon sets to actors and resources adds to readability of the charts and understand the relationship between the various elements.


The Procedures Section cross references the actor involved, the type of objective and the resources that might be used to undertake that procedure. As mentioned earlier, an actor might have one or more Objectives, so taking the example of the Police, we see that they have three Objectives; Public Safety, Assess Situation, and Coordinate Services. Now referencing the shades assigned to each objective to the procedures list, we now learn which procedures come under which objective. And the icons appearing in each active procedure’s box are the resources that might be used in that procedure. This helps narrow down the important procedures and the resources used in them.It shows us the procedures that are specialized and can be undertaken by only one service with respect to other procedures which can be undertaken by most/services. It also shows the frequency of the use of a particular resource as well as well as the importance of an actor, which can be understood by checking the number of procedures undertaken, or the nature of the procedure(s) undertaken by that actor.When taken into the game, this controls which mission entails which procedure, and hence automatically locks on to the objective that it comes under. It also makes available resources with respect to the missions or procedures that are currently being played, by adding it to the player’s game inventory.The iconograhy makes it easier to recognize the actor and resources when cross-referenced.White icons are simply the resources, and actor icons are colour coded with their roles.


Actors with respect to their Objectives and Procedures


In the Resources Section, we can point out the actor using a particular resource and the objective(s) that resource is useful in. It helps in knowing what resources are important and specialized versus those that are available and can be used by all services. It also shows which service uses what resources which can be ported into the game design, by making certain resources available to a certain player, but not available to another.


Actors with respect to the Resources that are available to them for specific Objectives


The Rules Section shows what rule applies to which actor. These are guidelines that control the interactions between actors, the environment and objects. These guidelines also control the flow of missions and make available options or cut down alternatives accordingly.


Actors with the Rules that apply to them.


Boundaries mark out the regions where the player can walk around during the game. The intention of having boundaries is not to restrict the player, but to keep him/her within the game at all times. All games have boundaries. Just that their sizes vary. First/Third person shooters have medium sized levels, whereas Massively Multiplayer Online Role Playing Games have huge levels that span across acres. Depending on the game’s intent, the boundaries help the player focus. Some games want the player to explore and find out things, so huge spaces help whereas some games require the player to move only within a small radius. Boundaries also help on the technical side, as huge levels would result in more texture memory usage owing to navigation, light/physics simulation calculations; huge levels would require more structures and vegetation, which would result in utilizing more resources.

The Boundaries in this prototype are actor based. Each actor’s missions/procedures are limited to specific areas, and only in very few cases are they required to move out of that particular area. So binding them to those areas lets them focus more on the mission, rather than exploring the environment around it.To explain boundaries, sheets with cumulative procedure boundary areas were marked out for each actor on transparent sheets. An opaque base map of the entire game map forms the background, so the sheets can be placed onto it, and the boundaries can be studied individually, or with more placed over each other so as to understand areas which are important and have more than one service active in it.

Non-Physical boundaries are also a part of game design. These form limitations in the form of actions, or things the players cannot do so as to keep the realities of the game’s story in place, as well as maintain certain aspects of the environment as inactive so that the player’s focus isn’t lost on them. As a simple example, as a player in Responder 108, you don’t carry any weapons. This non-physical boundary is set because there are no missions that involve the use of weapons or force. On the other hand, another non-physical boundary of Responder 108 is that the player can’t interact with most civilians, unless they are a part of a mission. This boundary is set due to two reasons. The first being that the player gets most of his/her information by way of the walkie-talkie in his/her inventory, or through other non-player actors who are programmed to approach his/her character. The second reason being the technical limitations of programming the civilian crowds to respond to the player. This would be incredibly tedious, and time taking. Also, it wouldn’t be of much consequence to the training tool that it allows the player to interact with computer programmed bots, unless of course, it is a mission related interaction, or the general enquiries that the bots would be otherwise programmed to approach the player with.


Place the actor’s boundary sheet over the map to view their boundaries and resources. Place more than one sheet to view the inter-section of multiple player boundaries


Interaction between the ActorsThis illustrates the frequency and importance of the communication that occurs between actors during the specified scenario. This is a important as it shows the role of each actor with respect to the other, and also how critical those interactions are. In some instances, the actor might be performing lesser number of missions, but the importance of those missions might be critical to the emergency response. So this diagram illustrates the frequency as well as importance of missions and communication between the actors.

Iteration


Final diagram depicting the interaction importance and frequency between various actors


Heads-Up DisplayA Heads-Up Display (HUD) system shows the game statistics and tactical information on-screen, that is pertinent to the gameplay. A typical HUD shows the player’s health, the ammunition that he/she is currently carrying, a weapon or directional crosshair, inventory items available for use, a level map with an indicator of the player’s current postition and the location for the game missions. It could also show messages that are sent by other players, or by in-game guides that help the player understand missions, and so on. The objective of a HUD is to convey gameplay information to the player without him/her looking away from the game itself.HUDs are usually semi-transparent, so as to not completely take up the player’s focus, but at the same time, providing reasonable visibility when looked at. HUD information is supposed to be compressed and concise, but equally easy to understand at one glance.It was important to keep these things in mind while designing a HUD system for the game. Though it couldnt be completely integrated into the prototype, it was designed in a way that it would show the necessary information during game-play without distracting the player.

Initial iteration of the HUD


Final version of the proposed HUD


The CryENGINE®The CryENGINE® is a path-breaking, multiple award winning game engine developed by Crytek® GmbH, a German game development company. The first and second versions of the CryENGINE® were used to make the games Far Cry® and the CRYSIS® series, respectively. Both are known to have revolutionized the computer gaming industry, owing to the breathtaking realism that the engine permitted. The CryENGINE® 3 is currently being developed and used to make CRYSIS 2® (due in Q1, 2011), the sequel to CRYSIS®. The engine’s editor is called the Sandbox editor.The engine incorporates real world natural lighting, physics and rendering to an extent which couldn’t be achieved in any engine before. It also features advanced Artificial Intelligence (AI) behaviour and interaction with in-game objects. Great depth and realism is also achieved with character models and textures, water, snow, dirt, and other particle based systems. But one of the most advantageous features of this engine is the real-time environment rendering; WYSIWYG-What you see is what you get. While working on the editor, the scene doesn’t need to be rendered again and again each time a change is made or an object is added, as everything gets rendered in real-time.The editor requires knowledge of languages like LUA, C++ and XML for advanced AI behaviour and game flow scripting. It also has an in-built visual programming system to create game-logic, called the FlowGraph, which makes some of the programming and game-logic creation reasonably simpler.

Importing geometry and textures

To import structures, props, characters into the engine, they have to be modelled on 3D capable softwares like Autodesk 3Ds Max or Autodesk Maya. The Crytek® developer’s website provides several tools for the conversion of models and texture conversion tools for converting these into formats that are recognized by the engine. Static geometry is imported in the CGF format. Texture images use the DDS extension. For the material to be imported into the engine, each geometry file can have only one shader assigned to it. Preferable a layered or multi-material shader which can compile several materials into one material file. The preferred shader for the multi-material file is Phong. The material files are exported under the MTL extension.

The buildings and environment setup in the editor


Natural lighting rendered in realtime

The terrain editor dialogThe Material editor dialog in the editor

Independently developed export tools are also available, as the tools on the Crytek® website are exclusive for developers and studios that have licensed versions of the engine. One such tool available for free, is MayaCGF developed by Lionel Gallat.http://seithcg.com/wordpress/?page_id=56


Cloud formation over set Finalized set layout

Terrain lighting according to geographical postition


The CryENGINE® FlowGraphThe CryENGINE® FlowGraph, to put it simply, is a visual programming tool which simplifies the process of programming to a certain extent. It is a visual node based programming system with a Graphical User Interface (GUI) integrated into the main User Interface (UI) of the engine. Countless nodes are available in this, and a person with reasonable understanding of programming languages can build flow and logic models by dragging and dropping nodes into the programming canvas, and connecting one node’s output with another node’s input, or multiple nodes inputs as and when it is allowed, to create Artificial Intelligence (AI) or game logic sequences. The flow graph allows manipulating actor AI and objects within the game, visual effects, sound effects, triggering reactions/cut-scenes, etc… AI in this paper refers to the characters that depend on computer generated behaviours. They are also referred to as Non-Player Characters (NPC’s)

The Flow-Graph ExplainedThe flow-graph has two kinds of nodes; Entity Nodes and Component Nodes. Both have input and output ports. There are 6 kinds of I/O ports, categorized into colours depending on the kind of data they process.

Green: All unspecified data types can flow through these ports Red: Boolean operations. True (1) or False (0) statements, Blue: Integers. Processes only +ve or -ve whole numbers White: Float values, i.e. Values with decimal points. Turquoise: “Vec3” values or 3 float values. Usually represent position coordinates, angles, colour values, etc. Purple: String Values. Used to store/process text.

An example of a simple game logic executed on the FlowGraphA Flow node


Node Reference:A few useful nodes explained.

Animations:1. LookAt : to program AI to look at an assigned entity/object.

Target is the entity IDCoordinate postitions can be specified under Target Pos.

2. PlaySequence : Plays the specified TrackView sequence.Start Trigger is to set the action that triggers the sequence to start.Stop Trigger is to assign an action to stop the sequencePerform BlendOut is to make the sequence camera blend into the game camera at the end of the sequence.

Entity:1. AttachChild : Attaches another entity to the target entity. The child is

defined in the Child input port. 2. EntitiesInRange : Takes coordinates of two entities and checks if they’re in a

certain rage. The output triggers events on True/False occurance.Game Nodes:

1. Actor Sensor: Outputs events on output nodes when the target entity performs certain actions. E.g. when the actor grabs an object, or when the actor dies, etc…

HUD:1. DisplayTimedDebugMessage : used with a trigger to display message/

string values. Text to be displayed is entered into the Message port.

One of the flow logics used in the prototype The Time of Day editor


Input: 1. Key : is a simple key press trigger, i.e. to initiate an action or sequence when

a keyboard/mouse button is pressed.

Logic:1. All : Triggers the output when all the inputs conditions are triggered true.2. Any : Triggers the output when any of the inputs conditions are triggered

true.Misc:

1. Start : Triggers an output when going into the pure game mode or editor

game mode. Boolean values are to be specified in the respective ports to

trigger an event/sequence.

2. TrackEvent : Start/stop a series of track events.

Time: 1. Delay : Delays the triggering of the next flow-node specified in the output

by the set number of seconds.2. MeasureTime : To measure the elapsed time and set off an event or sequence

when the specified time elapses.3. TimeOfDay : Changes the current in-game time to the specified time when

triggered. Usually connected to the start node to set the game-time.Time: set in 24hour formatsetTime : the trigger node’s output is connected to this, to activate the said time

4. Timer : Counts from minimum to maximum value specified.Tick period is in seconds.

AI Control Objects1. AI Anchor : Define specific behaviour for an AI with reference to the location

of the anchor.Anchor Type: Preset listEnabled : On/OffGroup ID : AI Group that can use this anchor

2. AI Nav Modifier : the navigational setup of a level for special navigational setup, such as building interiors, flight navigation, water navigation, etc…

3. AI Path : Object that can be used to guide AI along a specific route from point to point.

4. AI Point : used within a Nav modifier to generate points for the AI to navigate between.

AI Control Objects rollup


Conclusion

LimitationsThe medium of execution almost always has its restrictions. This being a game, relying on programming codes can only have a fixed set of behaviours that apply to the game dynamics and the actors in the game. Only that which is defined is read by a computer, and the AI isn’t capable of generating its own responses that ape human behaviour. So interactions with NPC’s are minimal, and mission specific.

The game requires programmers with good knowledge of the LUA, XML and C++ programming languages. The prototype that has been created is basic because of my non-programming background. As an animator and designer, my aim was to create a functional framework that can be implemented, which in my opinion has been successful.

Basic play-testingPlay testing is when a game’s framework is tried out on paper. This helps find problems in the game logic, and it saves time as the game itself doesnt need to be built on the final medium for basic play-testing.Test subjects were asked to pick a choice set from the decision charts. This provided some insight into what civilians with limited or no knowledge about actual emergency procedures would react. It helped refine and iron out the decision charts and brought forward chinks in the machinery. For example, missions that involved two sub-objectives needed to have separate time counters. I.e. to say, we have Mission A, which includes Mission X and Mission Y (sub-objectives) to be completed. So Mission A has one single time limit, and Mission X and Mission Y need to be completed under the same. But if a player succeeds Mission X, but fails Mission Y, he would be sent to the start of the mission, which means completing Mission X again. So instead of having a single time counter for Mission A, we assign

Mission X and Mission Y individual timers, which in turn are combined to form the time taken for Mission A, hence eliminating the possibility of repeating tasks unnecessarily.Given that this game isn’t meant for the general public, it would make more sense to test it out with personnel from emergency services, as the feedback from them would be more specific and accurate.


SummaryIt is hard to come to any actual conclusion as of now because the actual game is far from completion. But the process of building the game’s framework is complete and a basic feasibility model is ready. This enables it to be presented to the decision makers as an example of what the full-fledged game could do, and how it could help as a training tool. Given the right resources and backing, it could be developed into a complete virtual training game, with sets of different scenarios allowing emergency personnel of all kinds to play-act their roles. There are certain chinks in the system, but to iron that out, much rigorous and formal play-testing would be required. Also, the completion of the game would depend on the level the framework can be incorporated into the engine, by way of AI and mission programming, which obviously required experienced programmers and designers familiar with the engine.It definitely cannot replace drills, but would certainly help improve the emergency personnel’s response to situations and also allow them to experience scenarios that they otherwise couldn’t experience by way of drills. Multi-player support would be a definite advantage as it would involve cooperation between services and hence promote teamwork

The framework and concepts that have been devised are quite comprehensive but need few improvements which can only be found out after intensive play-testing on the existing model. But otherwise, it can be used as a reference to design and develop other game models that are intended to be training tools or follow such a format.


Bibliography/References(in alphabetical order)

1. Balancing Play, Meaning and Reality: The Design Philosophy of LEVEE PATROLLERDelft University of Technology, the Netherlands Casper Harteveld ([email protected]) Rui Guimarães ([email protected]) Igor S. Mayer ([email protected]) Rafael Bidarra ([email protected])

2. Crytek Developer’s Knowledge Base, CryENGINE 3 Documentationhttp://www.crytek.com, http://www.mycryengine.com

3. CryMod Forumshttp://www.crymod.com/portal.phphttp://wiki.crymod.com/

4. Disaster Plan of AIIMS HospitalAll India Institute of Medical Scienceswww.aiims.eduhttp://www.knowledgeleader.com

5. Disaster Management Plan of the Indian Railways (2009)Ministry Of Railways (Railway Board)http://www.knowledgeleader.com

6. Game Design Workshop: Designing, Prototyping, & Playtesting GamesTracy Fullerton

7. InCrysis Forumshttp://www.incrysis.com/forums

8. International federation of Red Cross and Red Crescent SocietiesResources Cornerhttp://www.ifrc.org/what/disasters/resources/publications.asp?gclid=CNmgtJTA0qUCFQMb6wodJhohkQ#dptr

9. MayaCGFhttp://seithcg.com/wordpress/?page_id=56

10. ModDB CryENGINE 2 Developers Grouphttp://www.moddb.com/groups/cryengine-2-developers/

11. National Policy On Disaster Management 2009National Disaster Management Authority, Ministry of Home Affairs, Govt. Of India

12. Rules of Play: Game Design FundamentalsKatie Salen and Eric Zimmerman

13. Stafforshire County Council Bomb Threat Procedure Guidelines


Credits

Guides: Gabriel Harp, Bharath Palavalli

Mission Programming: Sathya Naidu

Game Design help and feedback: Namrata Mehta, Aliya Pabani

Technical Assistance: Sathya Naidu, Digbejoy Ghosh

FlowGraph Programming assistance: Sathya Naidu

Thanks to my panel members at Srishti; Lloyd Robert, Avy

Varghese, Geetanjali Sachdev, Vijay Sarathi, Venkat Ramanna

Special Thanks to Dr. Robin King and Prof. Eswaran

Subrahmanian, and to everyone else at CSTEP

A shout out to the support system

Aashim JoyAbhishek Nate NathanCaelisa Chinkles AppletonMansha Aloo ChughLaksh LG GulatiArun Thulla ChauhanMonish Manu NangraniDigbejoy Dig GhoshNamrata Nam MehtaTanvi Tintin SrivastavaAliya Rad PabaniBharat Bhoks GuptaBharath Biharidas HaridasEsther Esty LalrinzualiSandhya Sethumadhavan, Kunjika Gogna, Swati Prasad, Veecheet Dhakal, Nanki Jassal, Ramya P, Bharat Chauhan, et al.

and the PSP. and the D600.

responder 108 : a disaster managements3images.coroflot.com/user_files/individual_files/365810... ·...

Documents