Keywords

1 Introduction

Nowadays, scientific literature in the emergency management domain suggests serious games as a new opportunity of training for the emergency practitioner, volunteers and the public at large is increasing and gaining popularity [1]. For example, a quick search of literature indexed in the Scopus database using exact phrases “serious games” AND “emergency management” between 2005–2017, returned 51 documents. Only five documents or ten percent were published before 2010, and the rest were issued after 2010. Ninety percent of them mention training as a purpose of the games. Why is the serious game (SG) approach for emergency management training becoming popular? The advantages of gaming approach are numerous. It is a less costly alternative for training activities that can complement field training or alternative to the table-top exercise, and allow intended trainees (e.g. emergency management personnel and decision makers) to train more often than they otherwise would be able to do in field-based exercises. Well-made training games can replicate conditions in various scenarios, allow organizations to record the exercises and logging the actions for later review, debriefing or repetition. Moreover, of course, games are a less dangerous environment to train new personnel rather than exposing them to risk.

This background has motivated us to develop a 3D SG intended for training the decision making when a responder faces series of events occurred in extreme weather, as reported in this paper. The so-called “Operasjon Tyrsdal” SG is built by taking the extreme weather event Synne happened in the west coast of Norway in 2015 as a case. In the National Risk Analysis 2014 on the disasters that affect Norwegian society [2], extreme weather has been listed as one of six natural events that has the highest likelihood to occur and one that has the greatest societal consequences. Therefore, this scenario is selected in this work.

Yet, as in other crisis scenarios, there are general, typical crisis situations where the emergency responders have limited resources, limited time to respond, and often facing simultaneous events that need prompt responses. Sometimes, a decision maker has to make a priority, which event requires immediate actions, and which event can wait for further actions. Given all complexities in the real-world crisis and the principles of making serious games that need to be taken into account, then the main research question in this paper is: How can we design an SG for training that incorporates elements of the real-world crisis so that the developed SG is learnable, playable and can be used for decision making and managing extreme weather events?

The SGs have been applied for fire scenario [3, 4], crisis communication [5,6,7,8,9,10] or city context [7, 11, 12] as well as extreme weather scenarios such as hurricane [13] and floods [14], but the last two papers require a lot of participants to be able to run the SG. The contribution of this paper lies in our efforts on tailoring the real-world information of extreme weather situations and the game design principles into the “Operasjon Tyrsdal” game. Many actors need to collaborate in a crisis. However, to ensure successful development within a five months’ timeline of a bachelor thesis, the SG is designed as a single player game acting as an on-scene commander who is responsible for making decisions and managing resources in a crisis.

An iterative Scrum method was used during the development process, comprising seven Sprints which were divided further into smaller technical development tasks. To allow the involvement of users and local responders in providing feedback during the development process, the language used in the game is in Norwegian. However, for reaching out in the future, it is possible to translate all text and instructions in the game into other languages.

The paper is organized into six sections. After this introduction, the next section briefly presents reviews on related works and state of the art concerning serious game. Section 3 elaborates the scenario and the game design, while Sect. 4 reports the results or end-product, i.e., the “Operasjon Tyrsdal” game. Section 5 describes the users’ role as testers in the game development process. Section 6 concludes the paper and reveal potential research directions from this work.

2 Related Works

Games approach with a stress on learning, participation, encouragement, and behavior improvement has been applied in many domains, and therefore repurposing games beyond entertainment is not entirely new [15, 16]. The “serious games” term itself is an old concept, migrating from mainly military use into many domains, denoting the games used for non-entertainment purposes [17], or education [18]. In other words, SG does not have entertainment, enjoyment or fun as a primary purpose, and emphasizing the importance of the careful balance of education and play as a core of this game genre [19]. SG has been applied as well for crisis management, where the intertwining between these two elements have been considered [20,21,22,23,24]. Mitgutsch and Alvarado [25] suggest that the purpose of the SG needs to be coherently reflected throughout the formal conceptual design of the game. Otherwise, the system is conflicting and not cohesive.

Suttie et al. [19] propose a framework that shows the relationship between game mechanics and learning mechanics through six wide categories of “Thinking Skills” i.e. creating, evaluating, analyzing, applying, understanding and retention. Games that are intended for improving “evaluation skills” seem to fit the spirit of the “Operasjon Tyrsdal” game. The suggested game mechanics comprises the following properties: action points, assessment, resource management; while the suggested learning mechanics include assessment, incentive, motivation and reflect/discuss properties. Bedwell, Pavlas [26] scrutinize SG literature and analyze the link between SG and expected learning outcomes. The most common learning outcomes of SG literature can be grouped into twelve patterns, i.e., declarative knowledge, motivation, application, adaptation, cognitive strategies, psychomotor, compilation, knowledge organization, attitudinal valuing,  automaticity set,  internalizing values, and receiving/responding phenomenon. The authors argue that this taxonomy will influence the way SG is designed so that effect on learning can progress purposefully. To sum up, there is no consensus in the SG literature what should be included in learning mechanics and game elements. Yet, there are numerous suggestions on making a good game which can be incorporated into an SG design whenever these elements are suitable for the game purpose.

Now, we shift our attention to exploring the current state of the art of crisis management SG. Di Loreto, Mora [27] analyze the current state-of-the-art of 10 simulation and game type of SGs. The paper identifies elements existing in the SG games. These elements are: a mix between predictable and unpredictable elements; problem dissection; making plans; local optimum vs. global optimum; communication and cooperation; roles; time pressure for decision making; links to territory; asymmetric information; quick convergence toward objective as well as coaching and debriefing. The authors also point out missing elements in current state-of-the-art of SG for crisis management, i.e.: (1) connection with an actual territory is lacking (i.e., the game takes place in an abstracted environment); (2) there is virtually no possibility to play with roles; (3) lacking of emphasis of the importance of the debriefing phase, and (4) no support for coaching during the playing sessions. Our Operasjon Tyrsdal SG at least took into account points 1, 3 and 4 in the development process.

Another direction in SG for realistic training is Pandora [28] that creates a rich multimedia training environment where games and multimedia technologies are heavily used in combination with Augmented and Virtual Reality. It is designed as single site training, deployed and distributed. While SIMFOR SG [29, 30] uses a multi-agent simulation and assessment approach of SG players, targeting the management of distributed and heterogeneous information (in nature or source) based on the concept of Evaluation Space. This is basically a multiplayer game training, but having quite advanced architecture by incorporating Intelligent Tutorial System to enable the playful learning. The Non-Player Characters for SIMFOR SG has been thoroughly studied [29, 30]. Praiwattana and El Rhalibi [31] review another trend for crisis management SG which focuses on existing work regarding automated scenario generation techniques, and not so much on the game development itself.

Lastly, the authors are also aware of some commercial training tools and services in the market dedicated to crisis management, security, and safety training; for example, XVR On Scene [32], Virtual Crisis CRISE [33], RescueSIM [34] and MASA [35]. XVR, CRISE, and RescueSIM provide an interactive 3D environment. In XVR, the user can enter buildings, vehicles and experience a change in conditions, for example, smoke, fire, snow, or flood. The tool can be used to build an incident scenario, provide instant feedback, and challenge users with questions through the exercise. All these platforms are aimed at teaching, learning, and training for emergency handling. MASA has two products, i.e., MASA SWORD for military purpose and MASA SYNERGY that also has a simulation server, a game client, and tool for scenario preparation as many more to prepare and train their senior staff and officials for the management of planned and unplanned crisis and disaster response situations. It is worth to mention that some commercial tools also have some limitations for direct use especially concerning different standard procedures or language issues. The research and development of the SG in this paper are tailored to the local needs, standard procedure and language.

As an initial effort, our “Operasjon Tyrsdal” work is fairly straightforward, as it does not involve sophisticated infrastructure, complex algorithms or multiple players as we see in the Pandora or SIMFOR projects. However, we do include complex mechanics and thorough considerations to reach the status we present in this article.

3 Scenario, Requirements and Game Flow

3.1 Scenario

The game was inspired by big storm “Synne” that occurred in Eigersund on the west coast of Norway in December 2015, where continuous heavy rain caused significant evacuation of inhabitants. The flood reached “red level warning” the highest of four flood alerts that are typically used to tell the danger level of a flood event. Some areas nearby faced risks of avalanches and landslides. The main transport infrastructure both motorways and over 40 secondary roads in two counties were closed, and paralyzing the ground and inter-regional traffic.

The flood level supposedly exceeded the level of the 200-year flood, and the municipality officers could not estimate the height of the water level due to loss of communication with the weather stations. In short, escalated crisis over several days such as Synne offers a unique case for other to learn about managing a sequence of tight events over a longer period with limited resources [36]. When transforming this event into a SG, the time and place is fictional, but the plots, stories, and sequence of events were modified from series of events during this storm “Synne.” Finally, the role of the player is On Scene Commander.

3.2 Requirements

We used Unity [37] as a popular platform for game creation, and C# as a programming language. We also set up some high-level technical requirements for this “Operasjon Tyrsdal” game, i.e.:

  • The game was limited to a single scenario to allows us to focus on creating a detailed environment with enough features to create a realistic crisis scenario.

  • The game would not feature multiplayer activity and concentrate on the individual experience.

  • The player would be required to make difficult decisions regarding how to use the resources available. As the game was still designed for the limited environment, we used the local language, i.e. Norwegian, as it facilitated the better involvement of testers at the development stage. Therefore, common local crisis vocabularies were used as much as possible in the game text and stories.

  • The game would be stand-alone and playable from a laptop so that users can operate the game without internet or network requirements. The game would only be developed with a target platform of a laptop running Windows, but Unity’s’ portability means that in the future the game could be ported to multiple platforms.

3.3 Game Flow

The game begins slowly to ease the player into the mechanics, and gradually increase in difficulty and intensity as the crisis worsens. Therefore, it is useful to design the game as similar to crisis phases, where the criticality and complexities gradually increase over time, before the situation finally is normalized. The game flow of “Operasjon Tyrsdal” can be summarized as seen in Fig. 1.

Fig. 1.
figure 1

The game flow

Full size image

Notification Phase:

This is where the game begins, the player is introduced to a tutorial that informs them of the mechanics. After the first introductory event, the player is given full control and will be ready for the next phase.

Action phase:

This phase of the game is the early parts of the crisis. The storm has struck the coast, and the waterways are starting to flood. The increased water and heavy winds are having an impact on the region; telephone poles are starting to topple, as well as trees. Residents living in some of the more exposed regions should be evacuated by now. This phase is not too demanding and gives the player a sense of the impending danger.

Crisis phase:

The situation is at its worst, the player does not have enough resources to solve every problem, and this creates dilemmas and choices that are not easy to make. An example of this would be for the Player to have to choose to use manpower to strengthen the temporary dam, or abandon it and respond to a landslide with severe consequences.

Normalization phase:

The worst of the weather is over, and the game finishes.

This is bookmarked by the player deciding when it is safe for people to return to their homes, and when the first responders are not needed in any immediate and dangerous scenarios. When the “round” ends, statistics for the current game are shown together with a timeline of events, opening up for debate with any non-player participant observers.

4 Graphical User Interface, Game Elements, and Results

In this section, we present the results in terms of Graphical User Interface and game elements. The description of the game elements is presented based on an SG framework and how each element of this context is manifested in the game.

4.1 Graphical User Interface (GUI)

The object in the game can be placed into two categories, GUI objects and game world objects. The numbers 1–6 in Fig. 2 depict the main GUI when the game starts.

Fig. 2.
figure 2

Overview of GUI when the game is started (Color figure online)

Full size image

The Resources (1) contains the police, ambulance services, fire services and volunteers. The Notification Dashboard (2) is an area where the player will get a notification on a situation that requires a response. The player can click the new message (gray) and will be lead into the event location. A successful mission will be marked with green in the dashboard, while unsuccessful mission will be marked with red. The Resource Tracking (3): The bars tell players which and how many resources have been deployed in different events. Each bar represents one event being handled. The next section will explain in details the game mechanics of “Operasjon Tyrsdal”.

The Action Report Button (4) will trigger an action report, which logs all decisions and interactions that players have performed during the gameplay and the player’s answers to the quiz. The Time Counter (5) shows the game time and the length of the crisis. Compared to the real time, the game-time is condensed. The Setting button (6) can be used for regulating the screen resolution.

4.2 Game Elements and Results

The framework used for describing the game elements is adapted from Mitgutsch and Alvarado’s work [25] who applied it for evaluating SG (Fig. 3). We applied the framework to ensure some essential elements of SG are fulfilled and expressed in the proposed game. This framework offers a structure to study the formal conceptual design in relation to a game’s implicit and explicit purposes. The description of the overall “Operasjon Tyrsdal” game will follow the components illustrated in Fig. 3.

Fig. 3.
figure 3

Serious game design framework, adapted from Mitgutsch and Alvarado (2012)

Full size image

Game Purpose and Impact:

This game is intended as a training tool that allows decision makers (on-scene commander or those who want to learn about decision making at this level) to handle future events in an extreme weather disaster. As a decision maker in the field, the player has to manage the available resources, uphold communication and restore order to the affected area. His/her task includes managing services such as police, firefighters, and medical personnel. The expected impact on the player is the ability to reflect and discuss the decisions that have been made for each pre-defined, automatically triggered event, and what can be done better to encounter similar situations.

Content and Information:

As suggested by Mitgutsch and Alvarado [25], the content and information refers to the information and facts used in the SG that could be well presented, adequately formulated, “correct” or irrelevant, hard to access or insufficient, and in worst cases, just wrong and biased. In the “Operasjon Tyrsdal” SG, the main information is grounded from the real Synne extreme weather event and timeline [36]. Some information is presented as an alert message to the player, with slightly modifications such as simplification, the sequence of events, anonymizing names, and detailed messages. The information on an event is triggered by clicking the incoming notification in the dashboard in the lower middle of the GUI. Details of an event will appear in a window, in the middle of the GUI (Fig. 4, left). The player is also supplied with the information of their available/accessible resources (Fig. 4, right). The player can see figures of deployed personnel in the information window.

Fig. 4.
figure 4

Left: The detailed event notification and how units are represented and used in the event window. Right: what units that the player has at their disposal:

Full size image

One example of a message given to the player can be illustrated as follow:

“The NVE (The Norwegian Water Resources and Energy Directorate) has warned that large amounts of water in Søddafossen will rise and cause flooding. Residential areas in Sødda are in vulnerable areas and must be evacuated. Unless the civilian population is evacuated, we anticipate that 20 lives are at risk of being injured or for life to be lost. The civilian population has been warned by SMS, email, radio, and phone that evacuation is necessary. We believe that more elderly people will have trouble evacuating from their homes and will need assistance with evacuation”.

The player should think based on some relevant keywords in the message before acting. To support further content realism, we refer to the Police Contingency Guidelines that also explain the roles and responsibilities of the police during incidences such as floods, forest fires, and landslides.

Play and Target Group:

The gameplay has a strong focus on the player’s ability to manage the limited resources at their disposal. Some inspiration for this game is drawn from similar games in the management genre, such as Operator: 911 [38], This is the Police [39], and EmergeNYC [40]. A common gameplay element in these games is a more hands-off approach to problem-solving. The reason for choosing this resource management genre is that we decided to train decision making from the perspective of one who is responsible for coordinating the resources in the field, i.e. the police as on-scene commander. The target groups for learning is the newer responders who learn the leadership in the field in a crisis. Outside the target group, the wider audience who want to understand dealing with extreme weather crisis management can receive benefit from this game.

Learning, Goals, and Rewards:

When a user plays, the learning points are covered in three different areas: (1) During the play itself, the user should understand the notification and report on a situation correctly, to be able to mobilize appropriate personnel. Figure 5 shows how the message will be available to the player to discern. The notification with green color indicates successful mission with the following message: “10:29 On Scene Commander reports that High level of water that threat ILKO (place for On Scene Commander) has been completed”. The notification with gray color tells the user an incoming or ongoing event: “11:29 The necessary evacuation in Jotni is taken place”. The top red message indicates that the action was too late with an example of the following message: “11:29 West Jotni is prone to flooding failed as it was not resolved on time”; (2) The speed of making decisions; as the time evolves and the crisis turns acute, the new event notifications are tighter. The resources can deplete to zero, and a player should understand the correct time when to also include volunteers in the response. (3) A quiz to answer will sometimes pop-up in the middle of the game (Fig. 6, left). The questions can be true or false, yes or no, and multiple choices. The questions are straightforward and short so that they do not distract the game play. Points are assigned as a reward for right answers to the questions.

Fig. 5.
figure 5

Alert Notification area

Full size image
Fig. 6.
figure 6

Quiz (left Figure) and Action Reports (right figure)

Full size image

(4) Action reports and quiz results can be used for discussion after gameplay. As all decisions for each event and each answer to the quiz are logged, the user can discuss if they have made a correct decision or alternative actions. This action report updates automatically when there is a new entry into the log. All entries are available in chronological order with the most recent being at the top. The contents of the logs are saved in a format that makes it available for analysis after the game ends.

In addition to these learning points, “Operasjon Tyrsdal” will also notify the player of some indicators, such as event location and remaining time available to manage the crisis (Fig. 7 left), and success (green circle) and failure (red circle) indicators. To convey more information to the player, when the user sends units to respond an event, he/she can see information about the event by clicking the dedicated element in the log. If they had forgotten how many units they sent, there would not be any way of finding out.

Fig. 7.
figure 7

Left: An arrow indicates the event location (Translated message: Jotni West is prone to flood). Right: Success and failure indicators (Translated message: “High Water level threat place for On-Scene Commander”) (Color figure online)

Full size image

An event sidebar was designed to alleviate this problem (see Fig. 8). The idea was to have the sidebar become active when the user had dispatched units to an event. The name of the event and dispatched units would be visible to the player for as long as they are not at their station. The player can click on the event name to get more information on the event, or click on the various icons to move the camera to the dispatched units, and see where they are in the game world. When an event completes, an icon signifying if the event was a success or not is displayed.

Fig. 8.
figure 8

Event Sidebar

Full size image

Characters and Plot:

In the game world, the player takes on the role of an “On-Scene Commander” of a small municipality on the west coast of Norway. The player is notified that heavy rains during the past weeks have increased the chances of floods in the municipality and that more rain is expected in the days ahead. It is vital that the player prevents a potential crisis from occurring. The player must manage the resources available in an efficient manner during the extreme weather. During the game, the player will develop a better understanding of how all the different pieces of crisis management work together and what the function of each piece is, and how best to spend those pieces as a resource.

Setting and Visualization:

The map visualization and topography setting of the real extreme weather location were transferred into the game world, but the names of the places are fictional, as seen in Fig. 9 left. The visualization also resembles the west coast style of houses with bright colors. Since the environment of Norway’s west coast heavily inspires the game, the game area also needs to resemble this atmosphere. Fjords, mountains and rolling hills are core design elements for the game’s landscape. The visual graphic of the game is designed with a low-poly theme. This style emphasizes more blocky designs of both models, textures, and environment. It presents heavy winds and rain that lead to floods. The heavy downpour leads to washing the colors and low visibility. It is that cold and rainy atmosphere we wanted to capture in our game, as seen in the Fig. 9 (right).

Fig. 9.
figure 9

Left: A real map that is transferred into the game world. Right: Low-Poly Visualization Style (Color figure online)

Full size image

Finally, to sum up, we have presented some results tailored in a piece of playable SG with multiple elements interacted coherently and cohesively in the “Operasjon Tyrsdal” game system. Now, we return to our initial research question posed in the introduction section: How can we design an SG for training that incorporates elements of the real- world crisis so that the developed SG is learnable, playable and can be used for decision making and managing extreme weather events? The question has been answered through the development of the game world. Designed as a resource management game, it has succeeded to incorporate the real-world events in the game, presents stress and the dilemma of decision-making, quiz, and action point reports to trigger discussions e.g. with other players in a learning group, or with supervisor/trainer in a learning setting as described in this section. Most features in the game have fulfilled the requirements defined prior to the SG development, and these features are functioning well as expected.

5 User Involvement in the Sprint Cycles

Recall that we used a software development Scrum method [41, 42] during the “Operasjon Tyrsdal” development, which was divided into 7 Sprint cycles within five months. Typically, in a Scrum approach, different people involved in a software development project is divided into different roles: product owner (who maintains product backlog, prioritize product requirements, define features of the product), Scrum Master (who has a leadership role over team members and is responsible for running daily Scrum) and Scrum Team (the developers). In our group, the communications were maintained through different levels of Scrum meetings that addressed some important questions such as: what the team had done, what would be the team’s plans until the next meeting, what were the barriers for implementation. We used Trello boards (www.trello.com) for maintaining the artifacts such as product backlog and Sprint backlog.

A Sprint is basically a set of product implementation cycles that includes the development, the reviewing and adjusting of the software product, and are undertaken during a pre-determined timeframe. In our project, the sprints were designed as a flexible process but were always started with agreed tasks to do. Each cycle was split further into main tasks and sub-tasks. In the first three sprints, involving users were still hard as the main activities focused on finding out the mechanics of the game, how all information could be tailored to the game, and making sure that the mechanics worked well. Thus, visualization was not a priority. Likewise, decent stories and text were still not a focus, nor was user testing. The reason was that at these three initial stages, we already could detect flaws ourselves, and the game was not yet stable enough to show to third parties.

User feedback was elicited only after Sprint 4. We tested the game on six users who had never seen the game before, but we did not yet consider the game ready for testing on actual responders. First-time user perspectives were valuable, to detect if they had a problem with understanding and using the game. We received useful feedback, e.g.:

  • the game-control keys were not so intuitive to use;

  • the title of each event was not unique so that the user could not differentiate one event from another, and couldn’t see if an event was solved or not;

  • the game needed an opening that informs the players what to do;

  • the meaning of the red and green circles in the evacuation board was not clear;

  • the tester did not know what to expect after sending resources, and had no idea how many resources had been deployed and how many resources were still accessible;

In addition to input on these functional features and some minor technical difficulties, we also received comments on some visual design ideas that have been useful to improve the look of the game. All issues were resolved in the following Sprint.

In Sprint 5, a head of local fire service with more than 20 years’ experience tested the game. Here we noticed the differences on how he treated the game compared to the normal testers. For example, the user would all the time refer to the game time counter before taking a decision and highlighted how important it was for the player to understand this condensed game time and consequences to the success or failure of the mission. He provided deeper reasons, considerations, and explanation before taking decisions. Upon this understanding, we interpreted that some of the game goals for learning and training were well conveyed. However, he pointed out the need to provide players with some background information, so that they know what to do. This feedback was also handled in the Sprint 6 product.

We had the opportunity to show the game to police personnel at the Sprint 6, however, at this point, we regarded the feedback at this stage as a current limitation of this SG. For example:

  • To incorporate data and measures that are needed to make decisions.

  • To add more realistic visual graphics such as a crowd of people being evacuated, raised water, and other statistical indicators and big data.

At Sprint 6 and 7, the main development focus was to polish and ensure that all learning points are well received: the action reports, resource trackers, success-failure missions and quiz. From the learning perspective, we deem that the result produced in Sprint 7 shows decent game mechanics, features and learning points, and meets the requirements laid down in the beginning, especially when considering time available for the development. Indeed, more thorough user testing is needed, to know the usefulness of the game as an alternative tool for emergency management training.

6 Conclusion

In this paper, we have presented an SG for training on extreme weather events, where the mechanics follow the resource management genre and have fulfilled the defined requirements. During the development process, we have involved several testers, including fire service personnel and police, especially to test the realism of the game, where the feedback was followed up and expressed in the newer game versions. Innovation in this work is that it is “light” SG that can be deployed anytime, anywhere, running in independent, graphically less-sophisticated computers or laptops. It offers the possibility to conduct debriefing, trigger a discussion with a coach, which is actually missing in the current state-of-the arts. In addition the way we tailored several features have been implemented in the game, such as message notification with success failure code, resource tracking bars, a way to assign resources, information on time available to solve a case, quiz as well as after action report summary, is a part of our contributions to the 3D video-based serious game for emergency management.

Limitations of this work can be listed as follow: (1) We have a one level game as we prioritized that the many complex aspects that are taken into account in the game are represented in the game world. More advanced levels can be another way to go, which can be considered as future work. (2) We believe that the extreme weather case and components in the game are a useful case in a wider context. Thus, technically, it is possible to make it accessible in other languages to reach a wider audience who want to learn about managing resources and time pressure in extreme weather scenarios. (3) The game was only developed with a target platform of a laptop running Windows, but Unity’s’ portability means that in the future the game could be ported to multiple platforms. (4) The user testing was conducted in the Sprint sessions. In the future, the usefulness of the game can be evaluated through a thorough evaluation session.