Doc/ConfigTutorial

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.
Tutorial:

P1-F4W0-Layout
P1-F4W0-1024x768
GIS-1
GIS-2
GIS-3
GIS-4
P1-F2B2W1-FireBreakSeeAllFire
Bcb-1
Bcb-2
Bcb-3
Bcb-4

Configuration example:

01 - P1-F4W0-Layout
02 - P1-F4W0-1024x768
07 - GIS-1 (Example from GIS study)
08 - GIS-2 (Example from GIS study)
09 - GIS-3 (Example from GIS study)
10 - GIS-4 (Example from GIS study)
11 - P1-F2B2W1-FireBreakSeeAllFire
12 - Bcb-1 (Example from Bridging Cultural Barriers study)
13 - Bcb-2 (Example from Bridging Cultural Barriers study)
14 - Bcb-3 (Example from Bridging Cultural Barriers study)
15 - Bcb-4 (Example from Bridging Cultural Barriers study)

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.

The size of the area visible around a unit is set with the property "WindowRadius" of the element "Unit" in the configuration xml-file. "WindowRadius" have three sizes 1x1, 3x3 and 5x5. The WindowRadius is individually set up for each unit.

WindowRadius = "1"


WindowRadius = "2"


WindowRadius = "3"

See all fire

It is possible to let the player see all of the fire regardless of the units range of sight.

It is the property "SeeAllFire" of the element "Role" in the configuration xml-file that settles if all fire should be seen or not.

If "SeeAllFire" is set to true all fire information will be seen. Then also "RememberFireOnMap" must be set to true.

If "SeeAllFire" is set to false only the fire in the eyesight of a unit will be visible.

SeeAllFire = "true"
RememberFireOnMap = "true"

The player has full visual information about the fire, and will
probably start to develop a strategy for putting the fire out.
The player needs to communicate and collaborate with the
other players.

SeeAllFire = "false"
RememberFireOnMap = "false"

The player has visual information about the fire only in the
range of the units sight. The player can be very close to a
fire without knowing about it. The need of communication
with other players will rice.

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.

Either you choose to let the fire information remain as the units move or you choose to let the fire information vanish.

It is the property "RememberFireOnMap" of the element "Role" in the configuration xml-file that settles if all fire should remain or not at the map. If "RememberFireOnMap" is set to true the fire information will remain. If "RememberFireOnMap" is set to false only the fire in the eyesight of a unit will be visible.

SeeAllFire = "false"
RememberFireOnMap = "true"

The remembered fire information will after some time not
correspond with the real expansion of the fire.

SeeAllFire = "false"
RememberFireOnMap = "false"

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.

The property "SendInfoTo" of the element "Unit" in the configuration xml-file settles which players should share the units information. It is the IDName of the players role that is set to the property "SendInfoTo". For example, SendInfoTo = "A, B, C, D"

The information that is sent is the units position, intention and the surrounding environment in the range of the units sight.

No information from other units is send to this player.

The player has no visual information about the fire other
than what his units have in their range of sight.
The player needs to communicate with the other team
members in order to have an understanding of the fire.


Information from other units is send to this player.

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.

Communication through the map concerning the fire is possible. A player can make marks on the map. This is use full as a note tool for
the player.

The marks can be configured to turn up at some or all other team members screen. The player thereby communicates his knowledge.

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 Fire Palette to appear at the user interface of the player. These two are described below.

The player has visual information from all units about their
position, intention and fire in range of sight.
The player has a better understanding of his team members
strategy without direct communication.

The fire palette that is used
for making fire marks on the map.

Two properties, "MapDB" and "MapDBTo", of the element "Role" are used for the configuration.

If "MapDB" is set to true the fire marks made by the player will be saved to a database. If "MapDB" is set to false this will not happen and the marks will not be possible to send to any team members. They will only turn up at the players own map and can still function as a note tool.

The IDNames of the team members that the fire marks shall be send to are set at the property "MapDBTo". For example, MapDBTo = "D, E"

The fire palette is set in the sub element "Object" of the element "Layout". The property "name" of the sub element "Object" must be Fire Palette, Name = "FirePalette", otherwise the C3Fire system will not recognize the object as a fire palette panel. The property enabled must be set to true, Enabled = "true" Read more.

Fire information is send to this player as marks.

The units in command of this player are F4, F5 and F6. The
player has no visual information about the fire from other
units, but the other players have made marks on the map.
The marks are visual on this players map.

The actual position of all units.

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.

Setting access for a player to a unit is done with the property "ControlUnits" of the element "Role" in the configuration xml-file. For example, ControlUnits = "F1, F2, F3" The player of a role with this configuration can only command three units, F1, F2 and F3.

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?

The image to the right is the configuration of a unit.

This unit is called F1. It is a fire fighter. It has a water tank and a fuel tank. It always need water to be able to put out fire and it need gas to be able to move.

One way to learn about the properties of a unit is to compare our configuration examples and look in the session configuration about units. Consider your objective for the session. Then make own tests.
>br>

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.

The table is a part of the team members user interface. If all team members have access to information from all units then the need of communicate around unit matters diminish.

If a team member has information only about the units in his command then he might need to communicate the information to other team members when fuel or water is out.

In the case where you have a staff, and the staff is equipped with information from all units they run the risk of having to detailed information and consistently risk giving to detailed orders. With some training this problem is mastered.

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.

The property "SendInfoTo" of the element "Unit" in the configuration xml-file settles which players should share the units information. It is the IDName of the players role that is set to the property "SendInfoTo". For example, SendInfoTo = "A, B, C, D"

The information that is sent is the units position, intention and the surrounding environment in the range of the units sight.

This give the player a good information about the other team members strategies and intentions even if they are not spoken.

No information from other units is send to this player.

The player have no visual information about the fire other
than what his units have in their range of sight.
The player needs to communicate with the other team
members.

Information from other units is send to this player.

The player has visual information from all units about their
position, intention and fire in range of sight.
The player has a better understanding of his team members
strategy without direct communication.

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 constructed with
geographical objects.

An ordinary map no extra
objects

An ordinary map and
geographical

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.

The property "FireSpeed" of the sub element "ObjectType" in the configuration xml-file settles the speed of the fire when the fire enters the object. Read more about fire speed.

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 Main GIS data, the geographical objects that the simulation handle, are configured with the sub element "Object " in the element "Objects", and have as properties Type and Pos.

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.

The users starting GIS data, the geographical objects that the team member se at start of a session, is configured with the sub element "DisplayObject " in the element "DisplayObjects", and have as properties Type and Pos.

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.

Mail
Diary
GIS
Voice

Mail

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:

A standard mailbox with one
window for viewing a mail and
one window for writing and
sending a mail.

This mailbox has only a window
for viewing a mail. The player can
only receive mail, not send mail.

A lot of effort is spent in designing
this mailbox. Here the mail communication
is of great importance.

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.

The session configuration is described by an XML-file, configuration examples

For each role in the configuration you must consider to whom this role shall have ability to send mail. It is the property "MailSendTo" in the sub element "Role " of the element "Roles" that is manipulated. For example, MailSendTo = "B, C, D".

Properties of the mail system

The element "MailConfig" have a few properties that must be set for the mail system to work properly, Read more.

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.

The mail panel is set in the sub element "Object" of the element "Layout". The property "name" of the sub element "Object" must be Mail, Name = "Mail", otherwise the C3Fire system will not recognize the object as a mail panel. The rest of the properties are manipulated according to your needs, Read more.

Diary

The diary system of C3Fire is similar to the mail system, but the possibility to set up individual arrangements, like for the mail, does not exist. The diary looks the same for everyone that disposes it.

The use of a diary tends to be stricter than the use of a mail. In the diary all written messages is visible for everyone that have the diary panel at their disposal. It is often used like a log.

All configuration settings done for the mail system, except for the individual, must be done for the diary.

Everything written in the diary is saved and accessible for analyses immediately after the session.

Properties of the diary system

The element "DiaryConfig" have a few properties that must be set for the diary system to work properly, Read more.

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.

The diary panel is set in the sub element "Object" of the element "Layout". The property "name" of the sub element "Object" must be Diary, Name = "Diary", otherwise the C3Fire system will not recognize the object as a diary panel. The rest of the properties are manipulated according to your needs, Read more.

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.

FirePalette

UnitPalette

ObjectPalette

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.

Two properties, "MapDB" and "MapDBTo", of the element "Role" is used for making a mark add to the database and set to who the information is send.

If "MapDB" is set to true the fire marks made by the player will be saved to a database. If "MapDB" is set to false this will not happen and the marks will not be possible to send to any team members. They will only turn up at the players own map and can still function as a note tool.

The IDNames of the team members that the fire marks shall be send to are set at the property "MapDBTo". For example, MapDBTo = "D,E"

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.

A palette panel is set in the sub element "Object" of the element "Layout". The property "name" of the sub element "Object" must be FirePalette, UnitPalette or ObjectPalette depending on which of the three panels you configure at the moment. The example of the image to the right is a fire palette panel, Name = "FirePalette", otherwise the C3Fire system will not recognize the object as a fire palette panel. The property enabled must be set to true, Enabled = "true"

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.

MarkType define some properties of the mark. One of these must be done for each mark. Note that the name of the image representing the mark must be named and saved correctly, read more.

MarkSendRule define who can send marks, which marks and to who,
read more. It is possible to make more than one "MarkSendRule". Some session
require quite complex sending rules.

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. Read more. 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

The configuration has six roles and six participants are needed for a session.

Three roles function as staff and three as fire brigade chiefs. The configuration also has nine firefighting units.

Staff
Three roles, C, S1 and S2, function as staff.
C, Chief
S1, Staff member 1
S2, Staff member 2

The staff is of main interest in the research. It is the staff that is equipped with paper maps or computer based maps and their work is
documented not only by C3Fire but also filmed with a video camera.
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.

The size of the area visible around all nine units is set to 5x5 squares in the map matrix. WindowRadius = "3"

The fire brigade chiefs, for example X, can only see the sight of their own units. Chief of the staff, C, can see the sight of all nine units. SendInfoTo = "X,C"

None of the players was allowed to see all fire. This would give too much and to obvious information about the fire and distract the players from using the more subtle information supplied in the maps.
SeeAllFire = "false"

No fire was remembered on the map. It could have been a good idea to let the staff have access to this property and it definitely could be demanded of a system with computer based maps, but the research project had experiments of two conditions. To have the fire remembered on the map in the computer based map condition would have made it differ too much from the condition with paper based maps.
RemeberFireOnMap = "false"

The participants could not make marks on their map about the fire and have it send to the other players. MapDB = "false"
MapDBTo = ""

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.

The three fire brigade chiefs, X, Y and Z, were in control of three firefighting units each.
This is very clear and discussions on who was supposed to be in control of witch unit never arose.
ControlUnits = "F1,F2,F3"

The participants could not make marks on their map about their units and have it send to the other players.
MapDB = "false"
MapDBTo = ""

All unit information available for the players is given from the field of the units sight. The biggest size of the sight possible is chosen, 5x5 squares in the map matrix. WindowRadius = "3"

The fire brigade chiefs, for example X, can only see the sight of their own units. Chief of the staff, C, can see the sight of all nine units. SendInfoTo = "X,C"

The property FireFighterUnit is set to true for all units and none have FuelTankUnit or WaterTankUnit set to true, as no fuel or water logistics was needed in this project FireFighterUnit = "true"

The last fifteen properties are not of any value to this project and they all have values that do not interfere with the session.

Geographical Information

This research project aimed at finding differences between using a traditional paper map compared to a computer based map. Therefore it was of great importance that the simulation during a session clearly responded to geographical information given from the map. The simulation had to follow the information.

For making this possible eleven different geographical objects was created and given an IDName and a FireSpeed. As each geographical object had its own fire speed the fires development fits fine with the map and the teams effort to think about and use the information from the different maps pay of.

Each geographical object also needs its own image. The name you give the image must be consistent to some rules and the image must be saved at the correct directory, Read more. During this research it was important to make the fire follow the map with as less visual interference as possible. Therefore all images were transparent, but they were saved at the correct directory. This must be done otherwise the simulation cannot use the geographical objects.

The eleven types of geographical data were plotted out on every position of the map matrix that was the area for the simulation. The size of the map matrix was 113 * 99. This gives a lot of positions that carefully must follow the geographical information from the map.

This configuration of data is done twice; first for the simulation as the main GIS data, then for the players start map. In this research the two was the same.

This configuration take the biggest part of the session configuration and the two images below that are examples of them are shortened severely for looking at their real size look at the last eight tenth of the configuration.

The main GIS data as the simulation handle as the real world.

The data at the users start map, in this case the same as the main GIS data.

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

Mail
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.

This configuration has six roles. Their respective configurations are

Role C,
MailSendTo = "S1,S2"

Role S1,
MailSendTo = "C,S2,X,Y,Z"

Role S2,
MailSendTo = "C,S2,X,Y,Z"

Role X,
MailSendTo = "S1,S2"

Role Y,
MailSendTo = "S1,S2"

Role Z,
MailSendTo = "S1,S2"

No special considerations where made about the properties of the mail system.

The mail panel on a players screen is very traditional with a viewer, an editor and information about from who the mail was send and how
many mails that are unread.

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

Communication with marks at the map was not allowed.

"MapDB" is set to false and "MapDBTo" is left without value

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:
- They needed to elicit and capture spontaneous but collaborative emergency-services decision making in response to a
simulated emergency.
The experimental platform was the C3Fire micro world simulation of an OSOCC-like setting.
- They needed to emulate the ad-hoc nature of OSOCC team formation and to capture the actions, words, expectations, and
norms for decision making that guide the development of teamwork in the simulated OSOCC.
They used the C3Fire network of computers to form ad-hoc teams of four individuals (either Bosnians,
Indians, Iranians, or Swedes).
- They needed to gather individual self-report information about values, personality, and preferences.
Each participant completed a series of six questionnaires including the NEO-FFI and the 57-item
Schwartz value scale.

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.

The size of the area visible around all twelve units is set to 3x3 squares in the map matrix. This is not of great importance as all players are allowed to see all fire, and also all units, the units position and intended position.

WindowRadius = "2"
SendInfoTo = "A, B, C, D"

All players were allowed to see all fire. This gives a lot of information about the fire that the players have in common. The idea is that the different teams that are of homogeny cultural background, with their common knowledge about the fire approaches their task in somewhat different patterns. SeeAllFire = "true"

The fire also was remembered on the map for all team members. This accumulates their common knowledge of their task, to put out the fire. RemeberFireOnMap = "true"

The participants could not make marks on their map about the fire and have it send to the other players. MapDB = "false"
MapDBTo = ""

Unit Information

The four team members, A, B, C and D, are given information about all units, the units position and intended position.

The four team members, A, B, C and D, are all in control of all twelve units. As all team members have the same knowledge about the fire and the task, to put out the fire, was clear and also no restrictions on who are in control of witch unit exist, the team it self must establish a pattern to use for controlling the units. This pattern, standard, of the team is what the examiners wanted to find. ControlUnits = "F1,F2,F3,F4,F5,F6,W7,W8,W9,G10,G11,G12"

The participants could not make marks on their map about their units and have it send to the other players. MapDB = "false"
MapDBTo = ""

The size of the area visible around all twelve units is set to 3x3 squares in the map matrix. This is not of great importance as all players are allowed to see all units, the units position and intended position, and also all fire. WindowRadius = "2"

All unit information is send to all team members. Their knowledge about the units is equal. SendInfoTo = "A,B,C,D"

The property FireFighterUnit is set to true for six units, F1-F6. The Unit configuration at the image to the right is for unit F1, witch is a fire fighting unit. FireFighterUnit = "true"

Three units are WaterTankUnits, W7-W9, and three units are FuelTankUnits, G10-G12. Fuel and water logistics add complexity to this configuration. It encourage the team to establish a pattern to use for controlling the units and put out the fire. The properties concerning water and fuel logistic, like size of tanks and start levels, must be set.

The last five properties are not of any value to this project and they all have values that do not interfere with the session.

Geographical Information

In order to encourage the team to create patterns for collaboration and decision-making some complexity was added to the map. Eight geographical objects was created and given an IDName and fire speed, Two of the objects, "Water" and "Fuel", support the water and fuel logistic system. Each position on the map matrix plotted with any of these two geographical object function as a water or fuel tank position. These can be represented on the map as a lake, gas station etc.

Each geographical object also needs its own image. The name you give the image must be consistent to some rules and the image must be saved at the correct directory, Read more. This must be done otherwise the simulation cannot use the geographical objects.

The eight types of geographical data were plotted out on some positions of the map matrix that was the area for the simulation. The size of the map matrix was 40 * 40. This gave areas of positions that altered the fires development. Swamps ended the fire, pines slowed it down and birches fastened it. The water and fuel objects do burn down but are still functioning as tank positions.

The configuration of data is done twice; first for the simulation as the main GIS data, then for the players start map. In this research the two was the same.

This configuration take the biggest part of the session configuration and the two images below that are examples of them are shortened severely for looking at their real size look at the last half of the configuration.

The main GIS data as the simulation handle as the real world.

The data at the users start map, in this case the same as the main GIS data.

The main interest of the research was to find differences in how the teams collaborated, made decisions and established organizational structures.

As the session configuration used the fuel and water logistics of C3Fire, the task of putting out the fire was challenging enough with out any real map image as background on the map matrix. Instead of a real map image a solid green image was used as background and the geographical objects created the world where the team conducted their task.

A map constructed with
geographical objects.

Communication

Mail 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.

This configuration has four roles. Their respective configurations are: Role A, MailSendTo = "B,C,D"

Role B,
MailSendTo = "A,C,D"

Role C,
MailSendTo = "A,B,D"

Role D,
MailSendTo = "A,B,C"

No special considerations where made about the properties of the mail system.

The mail panel on a players screen is very traditional
with a viewer, an editor and information about from whom
the mail was send and how many mails that are unread.

Diary

No diary was used.

GIS

Communication with marks at the map was not allowed.

"MapDB" is set to false and "MapDBTo" is left without value

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.

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.con

Layout based on a 1024x768 screen.
Location: <C3FIRE-SESSION-DEFINITIONS>\SessionConfig\P1-F4W0-1024x768.con

Player layout based on a 1280x1024 screen.
P1-F4W0-Layout.con

Player layout based on a 1024x768 screen.
P1-F4W0-1024x768.con

Manager layout based on a 1280x1024 screen.
P1-F4W0-Layout.con

Manager layout based on a 1024x768 screen.
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

Manager

Player

Observer

Replay

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.

Three of the four map layers and the switch layer button panel, read more about map layers.

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
Replay session nr: 07.

GIS-1, Chief of staff layout, blue map layer.

Configuration: GIS-2
Location: <C3FIRE-SESSION-DEFINITIONS>\SessionConfig\gis1\gis-2.con
Replay session nr: 08.

GIS-2, Fire brigade chief Z layout, green map.

Configuration: GIS-3
Location: <C3FIRE-SESSION-DEFINITIONS>\SessionConfig\gis1\gis-3.con
Replay session nr: 09.

GIS-3, Manager layout, red map.

Configuration: GIS-4
Location: <C3FIRE-SESSION-DEFINITIONS>\SessionConfig\gis1\gis-4.con
Replay session nr: 10.

GIS-4, Replay layout, blue map.

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
Replay session nr: 12.

BCB-1

Configuration: BCB-2
Location: <C3FIRE-SESSION-DEFINITIONS>\SessionConfig\bcb1\bcb-2.con
Replay session nr: 13

BCB-2

Configuration: BCB-3
Location: <C3FIRE-SESSION-DEFINITIONS>\SessionConfig\bcb1\bcb-3.con
Replay session nr: 14.

BCB-3

Configuration: BCB-4
Location: <C3FIRE-SESSION-DEFINITIONS>\SessionConfig\bcb1\bcb-4.con
Replay session nr: 15.

BCB-4