Configuration Tutorial

From C3LearningLabs
Revision as of 12:55, 13 August 2019 by Juthamad Granlund (talk | contribs) (Work processes and Dependency constraints)


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.

C3fire-config-tutorial-xmlwindow-radius.gif


C3fire-config-tutorial-window-radius1.gif
WindowRadius = "1"

C3fire-config-tutorial-window-radius2.gif
WindowRadius = "2"

C3fire-config-tutorial-window-radius3.gif
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.

C3fire-config-tutorial-xmlsee-all-fire.gif


C3fire-config-tutorial-map-see-all-fire.gif
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.


C3fire-config-tutorial-map-see-all-fire-false.gif
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.

C3fire-config-tutorial-xml-remember-fire-on-map.gif


C3fire-config-tutorial-map-see-all-fire-false-remain.gif
SeeAllFire = "false"
RememberFireOnMap = "true"

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


C3fire-config-tutorial-map-see-all-fire-false.gif
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.

C3fire-config-tutorial-xml-send-info-to.gif


C3fire-config-tutorial-map-unit-nosend-info.gif
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.

C3fire-config-tutorial-map-unit-send-info.gif
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.

C3fire-config-tutorial-map-fire-palette.gif
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"

C3fire-config-tutorial-xml-mapdb.gif


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.

C3fire-config-tutorial-xml-fire-palette.gif


C3fire-config-tutorial-map-marks.gif
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.


C3fire-config-tutorial-map-unit-send-info.gif
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.

C3fire-config-tutorial-xml-control-unit.gif

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>C3fire-config-tutorial-xml-unitf1.gif


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.

C3-fire-doc-config-tutorial- ex-1-f3-w190.jpg


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.

C3fire-config-tutorial-xml-send-info-to.gif


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

C3fire-config-tutorial-map-unit-nosend-info.gif
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.


C3fire-config-tutorial-map-unit-send-info.gif
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.

C3fire-config-tutorial-map-gis-geo-obj.gif
A map constructed with
geographical objects.


C3fire-config-tutorial-map-gis-map.gif
An ordinary map no extra
objects


C3fire-config-tutorial-map-gis-combination.gif
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.


C3fire-config-tutorial-xml-fire-speed.gif


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.


C3fire-config-tutorial-xml-main-gis-data.gif


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.


C3fire-config-tutorial-xml-users-gis-data.gif


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.

C3fire-config-tutorial-map-map-layer1.gif C3fire-config-tutorial-map-map-layer2.gif C3fire-config-tutorial-map-map-layer3.gif C3fire-config-tutorial-map-map-layers.gif


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:


C3fire-config-tutorial-mail-box.gif

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


C3fire-config-tutorial-mail-viewer.gif

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


C3fire-config-tutorial-mail-alfa05.gif

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

C3fire-config-tutorial-xml-mail-send-to.gif


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.


C3fire-config-tutorial-xml-mail-config.gif


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.


C3fire-config-tutorial-xml-mail-object.gif


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.


C3fire-config-tutorial-diary-panel.gif


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.


C3fire-config-tutorial-diary-config.gif


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.


C3fire-config-tutorial-xml-diary-object.gif


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.


C3fire-config-tutorial-gis-fire-palette.gif
FirePalette


C3fire-config-tutorial-gis-unit-palette.gif
UnitPalette


C3fire-config-tutorial-gis-object-palette.gif
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"


C3fire-config-tutorial-xml-map-DB.gif


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"


C3fire-config-tutorial-xml-fire-palette.gif


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.


C3fire-config-tutorial-xml-mark-type.gif


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.


C3fire-config-tutorial-xml-mark-send-rule.gif


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.