|
|
       |
              |
Session Design Tutorial In this tutorial we will try to explain some basic design choices you need to do when creating the session configuration. The design of a session depends on the purpose of the research or training. It can be a demanding task to set up the configuration and it is always well spend effort to make live tests of the configuration before using it in a real research or training situation. The session configuration is described by an XML-file, configuration examples. You can read about the basic configuration properties at session configuration This tutorial gives you knowledge about: The players information sources The players communication paths Work processes and Dependency constraints Examples of two research projects Hierarchic structure for communication and control No organizational structure for communication and control In the configuration menu there are examples of configurations that are included in the standard distribution of C3Fire. The first table of configuration examples below links to a short discussion at this tutorial about each of the examples. The second table of configuration examples below links directly to their page in the configuration menu.
The players information sources This section describes the sources of information a player have during a session and how you can manipulate the sources when designing a session. Fire Information Unit Information Geographical Information Fire Information The players access to information about the fire is set in the session configuration. A session configuration is an XML-file, configuration examples. The type of fire information given to one player can very well be different from the type of fire information given to another player. The configuration depends on the purpose of the session. Field of vision The basic way for a player to get information about the fire is to "see" everything that is immediately around the units that the player get his information from. If the fire is close enough to a unit the player will see it. If the fire is to far away the player will not see it.
See all fire It is possible to let the player see all of the fire regardless of the units range of sight.
See fire around units In the case where "SeeAllFire" is set to false and the only fire seen is immediately around the units you can make another choice when you design the configuration.
See other units fire In the case where "SeeAllFire" is set to false the configuration can allow fire information from units of other team members to be exposed on the map.
Visual fire information sent from other players When the C3Fire session starts the team members need to have tools for communication. Communication in general will be discussed later at this page, view communication.
Message based fire information send from other players For sending fire information to other team members as a text message both the email tool and the diary tool is possible. The email tool is similar in function of voice talk. The use of a diary tends to be stricter, similar to a log. All written messages during a session with C3Fire are saved in a log file. Configuration of the email and the diary tools will be discussed later at this page, view communication. The most obvious message based fire information is just talking during the session, but when designing a configuration also talk need consideration. For example, in a team with three players acting as fire brigade chiefs and three players acting as staff, talking can be restricted to the staff and leave the fire brigade chiefs with emailing as communication tool. Unit Information The players access to information about the units is set in the session configuration. A session configuration is an XML-file, configuration examples. The configuration depends on the objective of the session. Control a unit The ability to control a unit is set individually for each player.
A strict configured hierarchy with a staff and firefighting brigade chiefs with access to a reasonable amount of units are easy to recognize for the team. Their communication will probably handle matters about the task of putting out fire, formed by hierarch. If you design a less obvious hierarchy without a staff and titles, but let the players have access to a reasonable and equal amount of units. Then the team might try to develop a leadership, unspoken or clearly communicated. The probability for their communication to handle matters other than only the task of putting out fire rise. If you let all players have access to all units, then players need to organize a hierarchy and set allowance to control units by them self. The communication of this team will in some stage probably focus on the organization and responsibilities. Define a unit In the session configuration file a unit is defined, with many properties, as a sub element of the element "Units". Each unit has its own configuration and the appearance of the unit in a session depends on it. If the fleet of vehicles differs in type and capacity, then give different values to properties like "MovingSpeed", "FireFighterFightingSpeed" and "FuelLevelCountDownSpeed". In the game the members of the team will learn each vehicles capacity. They will communicate and discuss them and find the best usage of each vehicle. If you want to raise the level of frustration in one team member, let one of the units in his command have a higher "FireFighterFightingSpeed" and do not compensate with slower fire. The player will notice this, start complaining to these teammates and develop a strategy to overcome the units "lousy" firefighting abilities. You can as a designer of a set of sessions let one player command slightly better units in the starting sessions and one player slightly poorer units while the rest of the team have just ordinary units. After some sessions let the two selected player also have ordinary units. Does the confident player still perform high? Have the unconfident player learn to fight harder and, given same conditions as the rest of the team, is he now a better player?
Unit information table The values of the properties that define a unit can be exposed in a table on the players screen during a session. The table is a combination of two and easy for a user to handle, more complex for you to configure, view UnitInfoDisplay. It is you that decide how much information that shall be available and for who.
Visual unit information sent from other players Information from units of other team members can be exposed on the map even if the player does not command all units.
This give the player a good information about the other team members strategies and intentions even if they are not spoken.
Message based unit information send from other players For sending unit information to other team members as a text message both the email tool and the diary tool is possible. The email tool is similar in function of voice talk. The use of a diary tends to be stricter, similar to a log. All written messages during a session with C3Fire are saved in a log file Configuration of the email and the diary tools will be discussed later at this page, view communication. The most obvious message based unit information is just talking during the session, but when designing a configuration also talk need consideration. For example, in a team with three players acting as fire brigade chiefs and three players acting as staff, talking can be restricted to the staff and leave the fire brigade chiefs with emailing as communication tool. Geographical Information A map is a powerful information source. When you use C3Fire you must consider if your map should be a constructed map or a real existing map, or perhaps a combination of the two.
A map that is constructed by geographical objects only makes an impression of being simple, but could very well be the best choice. It depends on the objectives of the training. The constructed map above has water and fuel stations, pine and birch and also house and school as geographical objects. Images of these objects are included when you download C3Fire. An ordinary map looks more professional. The map can be given dynamic by putting transparent geographical objects on it configured with different fire properties. Visual geographical objects on an ordinary map could give extra attention to the object, for instance a school that need to be extra protected. Set fire speed to a geographical object There is no limit to how many types of geographical objects that is possible to create. You create them by writing them down in the element ObjectTypes of the session configuration.
For a geographical object to function properly it must be configured in the session configuration with an IDName and a FireSpeed but it also need an image and it need to be put out in the map. How to create an image and put the object on a map is described below. Set image to a geographical object You can make your own image for a geographical object. The name you give the image must be consistent to some rules and the image must be saved at the correct directory, Read more. If you have a real map as background you can construct some transparent images, save them at the correct directory and configure them with different IDNames and FireSpeeds. For example, a lake at the map should not have burning abilities. Give a transparent image the name "lake12.gif" and save it at the correct directory. Then configure it with IDName "lake" and FireSpeed "0". The Main GIS data The Main GIS data are the geographical objects that the simulation handles as the real world. Before the simulation can handle a type of geographical object it must be configured in the session configuration and it must have an image saved at the correct directory. How to achieve this is described above. When this is done each geographical object must be put on the map. This also is done in the session configuration.
The figure above shows only positions of four objects. In a regular configuration the amount of objects is huge and also the amount of positions. The Users start map The Main GIS data is handled as the real world by the simulation, but the objects are not visible on the team members start map. The objects are revealed when they are in range of a units sight. If the objects shall be displayed on the users start map they must be configured.
If all objects shall be displayed on the start map or not depend on the task assigned to the team. An example where not all objects should be visible is, the team knows about the fire spreading in an area where also a group of people is camping. Their task is to find the group and protect them as well as putting out the fire. Another example, the fire brigade chiefs have a map that is not updated and they have to deal with the environment on-site. Map Layers If you have more than one map over the same area and of the same scale one possibility is to use them all as layers. You add a button panel to the players user interface and each button is connected to one of your maps. This is useful when each map contain its specific information. The team can switch map and benefit of all information. Read more about map layers.
Communication The paths of communication a player have that you can manipulate in a session configuration. Diary GIS Voice The mail system of C3Fire is possible to change, first consider your needs, and then configure the mail system. All mails that are sent during a session are saved in a log file and possible to analyze immediately after the session. This is an advantage compared to communication during a session based on voice communication only. Three examples of the mail system:
Communication through the mail system of C3Fire between the players are defined by the configuration and the possibility to use the mail system is set up for each person participating in the session. Individual mail settings For each role in the configuration you must consider to whom this role shall have ability to send mail. For example, a strict hierarchy with one person acting as emergency alarm center, three persons acting as staff and three persons acting as fire brigade chiefs. In this hierarchy the emergency alarm center can email only the chief of the staff. The chief of the staff can email his staff members and the emergency alarm center but not the fire brigade chiefs. The two staff members can email the staff chief, each other and the fire brigade chiefs, but not the emergency alarm center. The fire brigade chiefs can email the two staff members and no one else. Another example, a flat hierarchy of four players together commanding twelve units. In this case all four players can email every other player. The way you configure the email setting for each participating role support your choice of hierarchy.
Properties of the mail system
Mail properties of the different user interfaces of C3Fire Each separate user interface of a C3Fire session that shall have a mail panel present needs to have it configured. Most often it is only the user interface of a player that needs a mailbox. The user interfaces that possibly can have a mail panel are the interface of a player, a manager, an observer and the replay. Each element "Role" is given a value to the property "UserInterfaceLayout" in the session configuration file. For example, UserInterfaceLayout = "Staff Member", or, UserInterfaceLayout = "Ground Chief". Sometimes each role have a unique UserInterfaceLayout, other times, for example, Ground Chief X, Y and Z can all use the same UserInterfaceLayout and the same mail panel.
Diary
Properties of the diary system
Diary properties of the different user interfaces of C3Fire Each separate user interface of a C3Fire session that shall have a diary panel present needs to have it configured. Most often it is only the user interface of a player that needs a diary. The user interfaces that possibly can have a diary panel are the interface of a player, a manager, an observer and the replay. Each element "Role" is given a value to the property "UserInterfaceLayout" in the session configuration file. For example, UserInterfaceLayout = "Staff Member", or, UserInterfaceLayout = "Ground Chief". Sometimes each role have a unique UserInterfaceLayout, other times, for example, Ground Chief X, Y and Z can all use the same UserInterfaceLayout and the same diary panel.
GIS Fire, unit, and geographical object marks It is possible for the players to communicate without words, by putting out marks on the map. All marks that exist in the session are put at the user interface in different palettes. It is easy for a player to use the marks. Just mouse click on the selected mark in the palette and then click at the map where the mark is supposed to be. It can be more difficult for the team members to understand and recognize the meaning of the marks. The different marks that can be used in a session are fire, unit and geographical objects. Then you also can create marks all by your self. It is described below, read more.
The session configuration must be manipulated in two things to make this work. The first is to make the players marks add to a database and set who shall have the information. The second is to make the palette panel to appear at the user interface of the player. These two are described below.
Each separate user interface of a C3Fire session that shall have a palette panel present needs to have it configured. Most often it is only the user interface of a player that needs a palette panel. The user interfaces that possibly can have a palette panel are the interface of a player, a manager, an observer and the replay. Each element "Role" is given a value to the property "UserInterfaceLayout" in the session configuration file. For example, UserInterfaceLayout = "Staff Member" or, UserInterfaceLayout = "Ground Chief". Sometimes each role have a unique UserInterfaceLayout, other times, for example, Ground Chief X, Y and Z can all use the same UserInterfaceLayout and the same palette panel.
Marks When the players communicate with symbols rather than words most probably the fire, unit and geographical objects, described above, will not be enough. Then it is possible to create an image of your own, name it and save it at the correct directory and make the necessary adding to the session configuration. The player handles the marks that you create yourself in the same manner as all other marks. The player makes a mouse click on the symbol at its palette panel. Then the player clicks on the map where the mark is supposed to be. There is some extra work with the configuration that has to be done. The configuration of properties "MapDB" and "MapDBTo" in the element "Role" are not done for marks that you create yourself. Instead the two elements "MarkType" and "MarkSendRule" of the session configuration must be done.
The configuration of a MarkPalette panel for the user interface of a player are the same as for the palette panels above except for the property name that should be MarkPalette, Name = "MarkPalette", otherwise the system will not recognize it as a MarkPalettePanel. Dual GIS screens When you use marks and symbols for communicating it can be difficult for the team members to understand and recognize the meaning of the marks and symbols. The simulation and the fire fighting work going on there can confuse them. It is possible to supply a player with two screens. One of them is the ordinary screen where the simulation and the firefighting are taking part. The other screen could consist of matter that deals with communication on the map. When one screen contain the simulation and the other screen contain all strategic thinking and symbols it can be easier for the members of the team to recognize the information that are supplied. If the hierarchy contain one or two layers of decision makers it is possible to let them have dual GIS screens as a strategy tool, but not the players doing the actual firefighting. When you create an extra screen what you really do is creating an extra role. For each extra screen an extra role is created. As for all roles, the ones for dual screens need much consideration. What kind of information shall be added to it, how much communication shall be possible, who shall have access to it and so on. Voice communication Communication between the players during a session by speaking freely is the most obvious and easy communication. Especially if all players are in the same room and close to each other. This communication does not need configuration. The players will have time to make reply to each other without disturbing their actions in the game, by taking time to write an email. They can perform more thorough discussions. Some problem is associated with speaking freely. If the communication is supposed to be saved for later analysis the speak must be recorded. When recorded you must be able to separate the voices and determine who said the message. When you speak freely and also have eye contact with each other it is more difficult for the players to play their role. Visual and audible impressions easily influence our judgment. Face to face communication The advantages of face to face communication is that it is easy and the participants can have thorough discussions when they meet difficulties. Disadvantages will be to save and identify the spoken at later analysis. The voices can be recorded on videotape. This is practical because then you also know which player said what. It is possible to combine written and spoken communication. For example, a strict hierarchy with one person acting as emergency alarm center, three persons acting as staff and three persons acting as fire brigade chiefs. In this hierarchy the emergency alarm center can only email and only to the chief of the staff. The chief of the staff can email his staff members and the emergency alarm center. The chief cannot email the fire brigade chiefs. The two staff members can email the staff chief, each other and the fire brigade chiefs, but not the emergency alarm center. The three persons acting as staffs are not in the same area as the other team members and they are allowed to talk and discuss their problems. This will probably diminish their ambition to mail each other. All video recording is concentrated to the staff and the amount of video material is reduced compared to recordings all of the players. The fire brigade chiefs can email the two staff members and no one else, not even each other. The communication structure in the example will be that, Chief of staff has mail contact with emergency alarm center. Staff speaks with each other and forms a strategy. The two staff members have contact with the fire brigade chiefs and the fire brigade chiefs are the ones that get the fire fighting job done. Phone and Radio communication Phone and radio can be an option for communication in a session. Still extra equipment must be added to C3Fire as none of them are included in the system. Work processes and Dependency constraints There are three concepts that you have to consider when designing a session configuration. They are work processes, work load and dependency constraints. Below they are mentioned briefly and also in the two examples "Hierarchic structure for communication and control" and "No organizational structure for communication and control". The three consepts are important to consider when designing a session configuration. It is recommended to make live tests of the configuration before using it in a real research or training situation. Live tests give the best indication on when a session configuration err. Work processes Work load Dependency constraints Work processes Work processes are the amount of actions a player have to deal with during a session. Examples of such are, mail, diary,making marks on the map, handling fire fighting units and fuel supply units etc. You have to consider if you gain at having many workprocesses or at focus on some. Work load Work load are how often the work processes are needed to be done by the player during a session. For example, if the burning speed of the fire is configured to be slow, then the player does not have to handle the firefighter often and he have more time for sending mail. Or if the e-mail tool is restricted, then the player does not recieve so many emails and have more time for fighting the fire. On the other hand, if the fire is configured to burn fast, then the player need to focus on the fire fighting units and he have less time for sending mail. Also if the email tool is not restricten and everyone can email the player, then probably the amount of email will increase. Dependency constraints Dependency constraints are how a work process depend on another work process. The processes a player depend on others to do, in order to achieve his own mission. For example, a player in control of three firefighting units cannot fight fire unless his units have sufficient amount of fuel and water. The task of extinguish fire depend on other players whos task are to supply fuel and water. Hierarchic structure for communication and control The session configuration that we are going to examine in this example is from a research project where the main goal was to find differences in usage of traditional paper maps versus computer based maps. We are not analyzing the project, we just take one of the session configurations that was used during the research and consider it a bit. This configuration have a very obvious structure, rigid but easy to understand and accept. The firefighting task is held simple, but it encourages the participants to use the maps. The participants where not expected to put any energy in establishing command and control structures or in logistic firefighting issues. The configuration is set to rigid. The creativity of the participants is focused on usage of maps. Experiment constraints Information sources Communication Work processes and Dependency constraints Experiment constraints
Within the staff group all communication are allowed, email, talk, paint with ordinary paper and pencils or anything the participants found needed during the session. Communication between staff and fire brigade chiefs was restricted. Only S1 and S2 were allowed to communicate with the fire brigade chiefs and only with email. Fire brigade chiefs Three roles, X, Y and Z, function as fire brigade chiefs. The fire brigade chiefs are the ones that put out fire. They are in command of three fire fighting units each. X, Y and Z were only allowed to communicate through email and only to S1 or S2. No talking to, listening to or seeing anyone else was possible. The fire brigade chief got his orders via email from the staff and left his information to the staff. The only possibility for a fire brigade chief to have other contact with the other two fire brigade chiefs was when a unit from another chiefs command was in eyesight of any of the fire brigade chiefs own units. The fire brigade chiefs were equipped with only one map. Units, Fire and Geographical objects The configuration has nine firefighting units, F1-F9. They all fight fire and have an unlimited supply of water. No fuel or water logistic task was added to the configuration. The expectation was that C3Fire should be really easy to handle so no logistic problems would override the map issue. The start points of the fire were carefully chosen on the map. Each session had two fires. The configuration of the fire was set to spread in a speed that would challenge the fire brigade chiefs although they did not have any fuel or water logistic task added to the configuration. The whole map was carefully plotted with geographical objects, a total of 11 different types. Each type of geographical object has its own fire speed set in the configuration. This gives the fire a very dynamic appearance and depending on how well the staff manage to acquire the information given from different maps the fire can be controlled or not. Information sources Fire Information The information given to the players about the fire was chosen to be only from the field of a units sight.
Unit Information The information given to the players about the units was chosen to be only from the field of a units sight. The three fire brigade chiefs, X, Y and Z, were in control of three firefighting units each.
Geographical Information
This research project had two conditions. In one condition the staff had access to paper maps only and the other condition had access to computer based maps only. The staff that had computer based maps had access to three different kinds of maps over the same area and they also had an overview map. The staff easily changed between the different maps at a button panel. It was only the staff that had access to the map layers. The fire brigade chiefs had only one map and their situation was the same in both conditions. The three maps, visually contained different type of information and over lapped precisely. The maps did not interfere with the configuration of geographical objects. When the staff changed maps the same view appeared with the same fire simulation but the underlying map was another. C3Fire of course registered all changing of maps for later analyses on witch type of map were most in use. The fourth map was an overview map and did not contain the fire simulation but it contained the fire fighting trucks positions.
Read more about map layers. Communication The configuration of mail has to be set individually for each role in the configuration. For this research the mail communication paths was set up strict and hierarchal. No effort was expected to be used by the players for making extra communication. All the creativity of the players was expected to be used on the maps.
Diary No diary was used. The staff, where most of the work around the maps where done, was very well documented. The experimenters had no wish for the players to spend extra effort on a diary as it tend to be used as a log and therefore would take time. GIS
Voice The three players acting as staff was allowed to talk during the session. The chief, C, of the staff had the maps and the email tool at his working space. Staff member 1, S1, and staff member 2, S2, had only the email communication tool at their workspace. The three sat close and was allowed to speak freely and must bend over each other to se the map clearly. The situation and the task made them talk and reason a lot, and their position close to each other made them easy to record with audio and video equipment. The fire brigade chiefs, X, Y and Z, had no possibility to talk, listen or see any of the other team members. Work processes and Dependency constraints In this research project the organizational structure for communication and control is very obviuos and rigid. It is finding differences in collaboration and decision-making in the staff that is of main interrest. Differences in how a staff, using only paper maps, act compared to a staff using computerbased maps. Each team consist of a staff and three firebrigade chiefs. The staff have many work processes to handle. They receive alarm email from the population. They are in control of all maps with geographical information. They handle email communication with three fire brigade chiefs. They are responsible for finding all fire and decide what strategy to use for putting out the fire. The work load is big. If they make god decisions and success in communicating these to the fire brigade chiefs then the staffs work load decrease towards the end of the session, and the fire brigade chiefs work load increase. The staff depend on their fire brigade chiefs to follow their decisions and put out the fire. The staff it self cannot extinguish the fire. The fire brigade chiefs have a very resonable amount of work processes to handle. For instance, using the fire fighting units for finding and putting out fire and also have email communication with the staff. The work load is reasonable. Therefore it is important that the speed of the fire is set high enough to challenge the firebrigade chief. When the cheifs have reached the fire their work load increase and they are engaged . A firebrigade chief does not have any obvious dependancy constraints towards the other fire brigade chiefs. But they all do depend on decisions of the staff, information about where the fire is and what their responsibilities are. No organizational structure for communication and control The session configuration that we are going to examine in this example is from a research project where the main goal was to identify clusters of expectations and behaviors that vary systematically across cultures. We are not analyzing the project, we just take one of the session configurations that was used during the research and consider it a bit. This configuration has no established organizational structure for communication and control. The firefighting task has logistic difficulties that would encourage the participants, of cultural homogeny groups, to create such structures during the sessions. This research project aimed at finding differences between ethnic groups in collaboration and decision-making. Experiment constraints Information sources Communication Work processes and Dependency constraints BCB-1, BCB-2, BCB-3, and BCB-4, configuration examples Experiment constraints This research programs goal is set to contribute to the training of the UNDAC (United Nations Disaster Assessment and Coordination) team by identifying clusters of expectations and behaviors that vary systematically across cultures and have the potential to raise barriers to collaboration and decision-making. Coordination of international relief teams is not an easy task. The teams that arrive at the affected area talk different languages, have different backgrounds and training, and bring differing numbers of people and types of resources to the site. In fact, coordination is so difficult that UNDAC has created a coordination concept called the OSOCC (On Site Operations Coordination Center). The OSOCC is the actual physical location where the UNDAC team does its work. As a Joint Cognitive System, OSOCC operations place strict constraints on the conduct of the experiment. OSOCC teams are formed ad-hoc and on-site. Team members may or may not know each other. Because there is no time for team-building, they get to know each other as they work. As they get to know each other, their way of working together is likely to evolve. These considerations led researchers to design the experiment to meet three sets of constraints:
Experiment Procedure The participants reported to the laboratory in ethnic groups of eight. In the laboratory, the eight were randomly and anonymously assigned to two teams of four decision makers. The purpose of the random and anonymous assignment to teams was to emulate the ad hoc nature of OSOCC team formation. The teams’ task is to work together to control and extinguish a series of four simulated forest fires. This takes half a day and is repeated twice. Altogether eight series of simulated forest fires are done. Information sources Fire Information The four team members, A, B, C and D, received a lot of information about the fire and they all received the same information.
Unit Information The four team members, A, B, C and D, are given information about all units, the units position and intended position.
Geographical Information
Communication The configuration of mail has to be set individually for each role in the configuration. For this research the mail communication had a very generous set up. No hierarchical paths were created in advance. Rather it was desirable if the team it self established communication paths. All team members had possibility to communicate with every one in the team. Mail was the main communication tool for the team. No other communication channel was created in the session configuration.
Diary No diary was used. GIS
Voice No voice communication was allowed during the sessions. Between sessions the team had an open conversation about their play and they also viewed a replay. Their conversation was recorded using both video camera and audio equipment. Work processes and Dependency constraints In this research project no organizational structure for communication and control is established. The situation has, on purpose, from the beginning, a huge amount of work processes, the work load is big and tasks depend on eachother. The session configuration need to elicit and capture spontaneous but collaborative emergency-services decision making in response to a simulated emergency. Examples of work processes are, sending email, handle fire fighting-, water supplying- and fuel supplying units and establish organizational structure. The work load is big. On-site, while the session is running the team must make all decisions, distribute responsibility, handle different types of units, save civilians, houses and environment etc. The level of dependcy constraints are high. Firefighting units will not work without fuel and water, in fact, no unit will work without fuel. The firefighting task cannot be done without communication, all emails must be read by everyone in order to be able to form a joint strategy for the task. P1-F4W0-Layout and P1-F4W0-1024x768 Different screen sizes The configurations, P1-F4W0-Layout and P1-F4W0-1024x768, are examples of configurations that are included in the standard distribution of C3Fire. The distribution also supplies a replay for each configuration, read more. They are designed as very basic configurations, identical in all but screen size. One player with the role "Ground Chief X" command four fire fighting units, F1, F2, F3 and F4. The player cannot see the fire unless it is within range of the fire fihgters sight. The player can view emails, but not send emails. The scenario attached to these configurations in the standard distribution of C3Fire deliver one message to the player with information about the start of a fire and its position. The players task is to use his resources and extinguish the fire. These configurations are very elementary. They have not been designed to meet any constraints from a research or training situation. They are good as framework when designing a configuration as the amount of units and geographical objects, speed of fire and wind etc are balanced for one player. They are also good as tools for getting to know C3Fire and for comparing layout designs of different screen sizes. Layout based on a 1280x1024 screen. Location: <C3FIRE-SESSION-DEFINITIONS>\SessionConfig\P1-F4W0-Layout.conLayout based on a 1024x768 screen. Location: <C3FIRE-SESSION-DEFINITIONS>\SessionConfig\P1-F4W0-1024x768.con
P1-F2B2W1-FireBreakSeeAllFire The configuration, P1-F2B2W1-FireBreakSeeAllFire, is included in the standard distribution of C3Fire. The distribution also supply a replay for this configuration, read more. It is a basic configuration, but it includes both firebreak units and a water supply unit. One player with the role "Ground Chief X" commands five units. The player commands two fire fighting units, F1 and F2. He commands two fire break units, B3 and B4. Also, he command one water supply unit,W5. The task of the firebreak units is to create firebreaks at strategically areas. The fire grows along the firebreak and finally, if not extinguished, round it but it does not jump over a well done firebreak. The fire fighting units extinguish fire. For this they need water. It is the water-refilling units task to supply the fire fighters with water. The water-refilling unit cannot extinguish fire. The water-refilling unit gets water from a water tank station. The player can see all the fire in the simulation regardless of the units range of sight. This configuration is elementary. It has not been designed to meet any constraints or wishes from a research or training situation. Layout based on a 1280x1024 screen. Location:
<C3FIRE-SESSION-DEFINITIONS>\SessionConfig\P1-F2B2W1-FireBreakSeeAllFire.con
GIS-1, GIS-2, GIS-3 and GIS-4 Four examples from GIS effects on command and control study The configurations, GIS-1, GIS-2, GIS-3 and GIS-4, are examples of configurations that are included in the standard distribution of C3Fire. The distribution also supplies a replay for each configuration, read more. These configurations design are constrained by the research project, GIS effects on command and control, described above. The research project aimed at finding differences in collaboration and decision-making between groups using traditional paper maps versus groups using a geographical information system, GIS. These configurations are designed for six players. Three of the players work together in a staff. Three of the players work solitary as fire brigade chiefs with three fire fighting units each. Two conditions were created. The first condition used traditional paper maps in the staff. The second condition was supplied with a GIS function of four map layers. This function was only available at the screen of the staff chief.
The fire brigade chiefs of both conditions had access to only one map and their configuration does not differ between the two conditions. Neither do the configuration for communication and control differ. The fire brigade chiefs can only see the fire in eyesight of its units. The units send information to their fire brigade chiefs. The staff in the condition where GIS is used receives information from the units. During each session three different fires are started. A lot of effort was spend to make the fire respond to the maps used in this experiment. It was necessary to have a huge amount of geographical objects to achieve this. Each geographical object has a transparent image and as background to the session are different map images. The configuration of roles, units and geographical objects are the same for all configurations. The configurations differ in start position of the units and the fire. These configurations are very specific. They have been designed to meet constraints from a research situation. They challenge any team of six players. The task of fire fighting is set to an average degree of difficulty but cannot be performed unless the team work together and uses the information supplied by the maps. Configuration: GIS-1 Location:
<C3FIRE-SESSION-DEFINITIONS>\SessionConfig\gis1\gis-1.con
GIS-1, Chief of staff layout, blue map layer. Configuration: GIS-2 Location:
<C3FIRE-SESSION-DEFINITIONS>\SessionConfig\gis1\gis-2.con
GIS-2, Fire brigade chief Z layout, green map. Configuration: GIS-3 Location:
<C3FIRE-SESSION-DEFINITIONS>\SessionConfig\gis1\gis-3.con
GIS-3, Manager layout, red map. Configuration: GIS-4 Location:
<C3FIRE-SESSION-DEFINITIONS>\SessionConfig\gis1\gis-4.con
GIS-4, Replay layout, blue map. BCB-1, BCB-2, BCB-3 and BCB-4 Four examples from Bridging Cultural Barriers study The configurations, BCB-1, BCB-2, BCB-3 and BCB-4, are examples of configurations that are included in the standard distribution of C3Fire. The distribution also supplies a replay for each configuration, read more. These configurations design are constrained by the research project, BCB, described above. The research project aimed at finding differences between ethnic groups in collaboration and decision-making. The configurations of BCB have a high level of logistic difficulties and no organizational structure for communication and control. These configurations are designed for four players. The players control six fire fighting units, F1, F2, F3, F4, F5 and F6, three water tank units W7, W8 and W9, and three fuel tank units G10, G11 and G12. The players can see all the fire in the simulation regardless of the units range of sight. All players can control all units. The Units send information to all players. The configuration of roles, units and layout are the same for all configurations. The configurations differ in positions of geographical objects and start position of the units and the fire. These configurations are very specific. They have been designed to meet constraints from a research situation. They challenge any team of four players inexperienced in using C3Fire. The amount of units and geographical objects, the level of logistic difficulties, speed of fire and wind etc are set high. Configuration: BCB-1 Location:
<C3FIRE-SESSION-DEFINITIONS>\SessionConfig\bcb1\bcb-1.con
BCB-1 Configuration: BCB-2 Location:
<C3FIRE-SESSION-DEFINITIONS>\SessionConfig\bcb1\bcb-2.con
BCB-2 Configuration: BCB-3 Location:
<C3FIRE-SESSION-DEFINITIONS>\SessionConfig\bcb1\bcb-3.con
BCB-3 Configuration: BCB-4 Location:
<C3FIRE-SESSION-DEFINITIONS>\SessionConfig\bcb1\bcb-4.con
BCB-4 |
