A method for automatic situation recognition in collaborative multiplayer Serious Games

One major Serious Games challenge is adaptation of game-based learning environments towards the needs of players with heterogeneous player and learner traits. For both an instructor or an algorithmic adaptation mechanism it is vital to have knowledge about the course of the game in order to be able to recognize player intentions, potential problems, or misunderstandings both of the game(play) and the learning content. The main contribution of this paper is a mechanism to recognize high-level situations in a multiplayer Serious Game. The approach presented uses criteria and situations based on the game-state, player actions and events and calculates how likely it is that players are in a certain situation. The gathered information can be used to feed an adaptation algorithm or be presented to the instructor to improve instructor decision making. In a first evaluation, the situation recognition was able to correctly recognize all of the situations in a set of game sessions. Thus, the contribution of this paper contains a novel approach to automatically capture complex multiplayer game states influenced b y u npredictable p layer b ehavior, a nd t o i nterpret t hat i nformation to calculate probabilities of relevant game situations to be present from which player intentions can be derived. Received on 19 December 2014; accepted on 02 June 2015; published on 02 July 2015


Motivation
Especially for game-based collaborative learning scenarios, major fields of research are adaptation of learning content, difficulty, as well as game-pace and content.First approaches to address problems in those fields have been proposed, focusing on human instructor support and Game Mastering.Many of those approaches consider what information needs to be presented to the instructor and what adaptation mechanisms are necessary and should be regarded.
A different approach is automatic adaptation of multiplayer Serious Games.Any adaptation algorithm, however, needs knowledge about the game state, the learner/player state, and player progress and behavior in order to be able to decide about proper adaptations for the present game state.In particular, an algorithm needs to be aware of problems and misunderstandings during the game.Whereas a human Game Master can rather easily recognize and judge what a player or a group of players is doing at a certain moment during the game session just by observing the scene, his/her background knowledge of the game, and human reasoning, this is extremely difficult to recognize automatically.Especially in game genres where players control an avatar in a rather open world and where they can move freely in that world, deciding for themselves about what to do next and how, it is a challenge to automatically recognize what a player -or a team -is doing at a certain moment.Examples for this are Second Life 1 , mods of commercial role-playing games, or collaborative multiplayer Serious Games like Woodment [1] or Escape From Wilson Island [2].
The scenario observed here focuses on non-scenebased open world action-adventure-like games using V. Wendel et al. avatars to (re-)present players.In this paper, we propose an approach for automatic situation recognition in multiplayer Serious Games.The goal is to automatically recognize what a single player or a group of players are likely doing at a certain point in a game, based on information about their locations, their movements, their actions, and their interactions.Therefore, an interface is defined to access elementary and abstract game states, current and past player actions, game quests and (learning) tasks, and game relevant attributes.Based on this, state diagrams regarding dependencies between states are created and different kinds of criteria to calculate probabilities of situations are used.Criteria are defined based on space, time, and state, like local or global criteria, distance criteria, or criteria based on game states or attributes.The concept further includes an algorithm which calculates which criteria are fulfilled using the data gathered from the game.Based on that, the algorithm calculates probabilities for players being in certain situations, like trying to solve a certain task or exploring the level, etc.
We implemented our concept as an extension of the existing collaborative multiplayer Serious Game Escape From Wilson Island (EFWI) which offers group tasks designed in a way such that players need to work together and communicate in order to succeed [2].A Game Master Frontend has been implemented to enable an instructor to perform instructor tasks from inside the game at run-time [3].EFWI is a game with an open level in which multiple players can act freely and concurrently, hence altering the game in an often unpredictably way.Therefore, it is considered to be well suited as an evaluation platform for the situation recognition concept presented here.The situation recognition described in this paper is a direct extension to this Game Master framework with the objective of enabling the Game Master framework to automatically recognize game relevant situation in order to inform and support the Game Master and automatically perform adaptations based on the recognized situations.An initial study to evaluate the soundness and correctness of our approach has been carried out comparing the recognized situations with the situations recognized by a real GM.The initial results are very promising.The situation recognition was able to correctly recognize the defined game situations in all cases.However, further evaluation is required including a bigger set of users as well as additional games.Thus, the contribution of this paper contains a novel approach to automatically capture complex multiplayer game states influenced by unpredictable player behavior, and to interpret that information to calculate probabilities of relevant game situations to be present from which player intentions can be derived.

Related Work
To the best of our knowledge, there are no similar approaches for a situation recognition in collaborative mutliplayer Serious Games.Hence, in this section, the underlying concepts and related approaches are described, on which this work is based.Those are the fields of collaboartive learning, Serious Games for collaborative learning, and adaptation in the context of games.

Collaborative Learning
Roschelle and Teasley [4] define collaboration as "a coordinated, synchronous activity that is the result of a continued attempt to construct and maintain a shared conception of a problem".The concept of collaborative learning is used widely in e-learning and gamebased learning.Dillenbourg [5] defined collaborative learning as "a situation in which two or more people learn or attempt to learn something together".Various parameters define the success of collaborative learning: One core element is the group of learners, characterized by its size and its composition.In this work, the focus is on small learner groups (2-6 players) suitable for cooperative learning scenarios.Johnson and Johnson [6] define five essential elements of cooperation which are a prerequisite for cooperation to take place in cooperative learning scenarios:positive interdependence, individual accountability and personal responsibility, promotive interaction, appropriate use of social skill, and group processing.
Computer-supported collaborative learning (CSCL) is the combination of computer technology and collaborative learning concepts.The fields of application are communication, coordination, cooperation in groups, and cooperative learning rooms (especially virtual learning rooms) (Haake et al. [7], p. 358).Whereas first virtual learning rooms were CSCL applications specifically designed for a CSCL purpose, most often integrating a chat system and a shared screen, later versions used existing virtual worlds like Second Live or Massively Multiplayer Online Role-Play Game (MMORPG) worlds [8].

Serious Games for Collaborative Learning
In Recent years, first CSCL Serious Games have been designed and implemented.They incorporate the CSCL principles and combine them with Serious Games principles resulting in first multiplayer Serious Games for collaborative learning [9].Hämäläinen [10] describes an approach of a collaborative game for vocational learning focusing on design elements essential for collaboration.Reuter [11] describe an approach for designing and authoring multiplayer adventures for collaborative learning deriving concepts for puzzle design in multiplayer games.

Adaptation
The actions and tasks of the instructor can essentially be categorized as assessment and adaptation.Adaption might occur for factors like difficulty, narration, players'/learners' preferences, or the need to compensate a deficit.In general, a common definition of adaptation is "[the] ability to make appropriate responses to changed or changing circumstances" [12].It is desirable to adapt games in various dimensions, like those stated above.Charles et al. state that "learning and adaptation are viewed by some as a having a crucial part to play in next-generation games" [13].Kickmeier-Rust and Albert [14] provide an overview over adaptation principles and techniques in Serious Games, like adaptive behavior of agents, motivational interventions, procedural and adaptive level and content generation.Sweetser and Wyeth [15] defined the term 'GameFlow', transferring the concept of 'Flow' [16] to games with the goal of designing and evaluating enjoyment in games.Their model includes the eight dimensions concentration, challenge, skill, control, clear goal, feedback, immersion, and social interaction.Chen [17] states that one fundamental condition for Flow in games is that the game must provide the right amount of challenges to match with the players' abilities.This, as well as the adaptation principles stated by Kickmeier-Rust and Albert [14], requires that the game knows about the current game state and in what situation players are currently in.
In order to be able to soundly adapt a game to player's needs and preferences, a sound model of a player is necessary.A widely used player model is Bartle's player model [18] for multi-user dungeons which has been adapted for roleplay games.A more generic model is proposed bei Houlette [19] which is based on a set of player traits which can be freely defined according to the game domain whereas each trait is assigned a value in the range [0, 1].Smith et al. [20] developed a taxonomy of player modeling.They define a player model using the four dimensions scope of application, purpose of use, domain of modeled details, and source of model's derivation or motivation.The situation recognition proposed here will eventually feed and update a player model which again will be used to select appropriate adaptations.

Problem Statement
The approach presented here focuses on the scenario of collaborative learning in small groups using multiplayer Serious Games.The Serious Games regarded here are considered to be non-scene-based, i.e. the games are open in terms of sequence and pacing.Typical games and genres include action adventures, roleplay games, games with first person shooter mechanics, and games which rely on an open world, like many sandbox games (e.g.Minecraft).Therefore, it can be stated that it is impossible to predict the next game state from the current game state due to the high degree of player freedom.This means that it is practically impossible to foresee player movement or player actions based on the current game state.An example is a group of players standing at a certain point in a roleplay game.They can decide to go east, west, north, or south, or -to make it even more complicated -they can go east for a few steps and then change direction.The possibility space is infinite merely through player movement, not including any other player actions.Thus, as each player has full control over his/her character, it cannot be predicted what will happen next.This is contrary to e.g.scene-based games where it is much easier to define concrete game-states due to limited player freedom.In that type of game, usually player actions at a specific point in the game are clearly defined and limited (i.e. by predefined dialogue options, doors to chose, or buttons to press, which deterministically lead to a next 'scene', i.e. 'state').The player freedom in the open world is the core problem for recognizing what situation a playeror a group of players -is in.Machine-based situation recognition needs to derive a situation from certain environmental conditions which are clearly defined.This can be easy in some cases, e.g. when a player action is triggered by interacting with a game object.If a player clicks on a game object, like e.g. a berry bush, it can be stated that the player is in a 'gather berries' situation.This situation can clearly be gathered from the game as it is linked to one concrete trigger ('clicking the "Gather Berries"-button').An example for a converse case is a situation which occurs in Escape From Wilson Island.Players need to surround a heron in order to hunt it.A human instructor can easily judge when players are moving to hunt and surround the heron from the players' movements.However, as there are no hard triggers (players are just moving) or events clearly defining the start of the hunting situation, this is very difficult to recognize automatically.The players' actions (including their movement) need to be evaluated algorithmically.Merely evaluating a player's position is not enough in this case as a player can be at a position for various reasons.

Game Interface
The developed situation recognition mechanism uses elemental game-data like game variables, player parameters, or elemental game actions, like moving, or triggering events by pressing a button.Based on those, game states and tasks are defined.Game situations are defined using different kinds of criteria which indicate that the situation is currently present.Finally, all situations are evaluated periodically, calculating a probability for each situation to be present at a certain point in the game session.Following, core definitions will be presented: Game variables can change either through game events or through player actions.
Definition (Game State).The Game State GS is a concrete allocation of all game variables V in the game: The game state changes whenever a game variable v ∈ V changes.

Definition (Action
).An Action a ∈ A is an elemental player activity which has a well-defined effect on the game state GS.A is the set of all Actions.The effect on GS is defined as a manipulation α of a subset of game variables V ⊆ V : An action can be as simple as 'move forward' triggered by pressing the respective key, or 'gather berries' triggered by clicking on a berry bush game object.Note: Although in a game an action might have a number of prerequisites which have to be fulfilled for the action to be executable (e.g. a player needs to be within a certain distance to a game object in order to trigger the object), this is no relevant information here.The game itself takes care about checking the prerequisites.The situation recognition only needs to know when an action was performed.

Definition (Shape).
A Shape s ∈ S describes a complex combination of game variable states.S is the set of all Shapes.
Thus, a shape is a boolean expression over a set of game variables which evaluates to true or false.
A shape s is considered 'active' if the boolean expression be s describing the shape evaluates to true, else 'inactive'.A boolean expression be is either an elemental boolean expression or a composed boolean expression.An elemental boolean expression compares the current value of a game variable v ∈ V with a target value using an arithmetic test operator.The arithmetic test operators used are: =, , >, <, ≥, ≤; The target value is a concrete value of the respective game variable's value range (e.g.x > 5).A composed boolean expression combines two boolean expressions using a boolean operator.The boolean operators used to define a game state are: and, or, not, xor: The set V s ∈ V is the set of game variables which are used in the boolean expression be s .The value of all used variables V s is taken from the current game state GS.
The function f assigns {true, false} to the boolean expression be depending on the current game state GS, i.e. depending on the current allocation of the relevant variables which are used in be.The function g assigns {active, inactive} to a shape depending on the value of its boolean expression.
f : be, GS → {true, f alse} with f (be, GS) = true if be evaluates to true using the variable allocations in GS; g : S → {active, inactive} with g (s) = active if f (be s , GS) = true, else inactive; ( According to the above definition, at every point in the game, n states can be active simultaneously, with n ∈ [0, |S|].
A task is a well-defined assignment which has to be fulfilled by one or more players.A task consists of a set of states Σ, a start state σ s ∈ Σ, an active state σ a ∈ Σ, and a transition function δ which defines the successor state for each state.The set Σ contains all states of t.The start state defines conditions to be met before the task can be started (or for the task to be assigned).There can be a number m with m ≥ 0 of states between start and end state.The function δ defines which successor state becomes active after performing a (player) action a.Thus, δ is a semantic note telling the situation recognition which action(s) are expected to be performed by players next for them to advance in the respective task based on the task's current state.The situation recognition can use this information to adapt the game if necessary (e.g. if players are taking too much time to execute this action, or if they lack a skill required for this action).Due to the clear unambiguous structure of a task, it is possible to use state transitions to predict players' most probable next actions and subsequently the next situation.
Whenever an action a now is executed, the situation recognition checks whether a task t's active state s a t

changes. If δ(s a t , a now
) is defined, s a t = δ(s a t , a now ), else s a t .

Definition (Region).
A Region is a well-defined area in the game world (e.g.defined by a square or a circle).
The specific definition of a region is left to the game.The relevant information about a region is whether one or more game-relevant entities are inside an area.
In order to be able to evaluate which situation is currently present, a set of criteria is used.A situation is defined to be true if all of its criteria are fulfilled.

Definition (Criterion).
A Criterion c ∈ C, whereas C is the set of all Criteria, is an item which defines if a game condition is fulfilled.
For each type of criterion, an evaluator function e continuously evaluates to which extend it is fulfilled.Many criteria can either be 0 or 1 as they are evaluated in a binary way (either 'true' or 'false').Whenever a player is referred, one or more players who are part of the situation, are meant.A player is part of a situation if he/she is part of at least one criterion of the situation.

Atomic Criterion
A criterion which is directly retrievable from the game (state), i.e. from a game variable, e.g.'Is player x moving?'.An Atomic Criterion refers to the question if a game variable has a specified value.Thus, it can only be evaluated to 0 or 1, respectively 'false' or 'true' for the related condition.
e(c) = 1, if the respective game variable has the desired value, else 0.
The Atomic Criterion specifies the player which is related to the game variable, if any.

(Class) Spatial Criterion
A class of criteria which make use of player or object positions.Three concrete criterion types are defined: Local Criterion, Global Criterion, and Distance Criterion.

Local Criterion
A Local Criterion is considered fulfilled if the respective player is in the related Region.A player can either be in the specified region or not.Hence, the Local Criterion can only be evaluated to 0 or 1, respectively 'false' or 'true' for the related condition.
e(c) = 1, if the a player is in the specified area, else 0.

Global Criterion
A Global Criterion is based on the Local Criterion type.It contains a set of regions and defines the relationship between them.Possible relationship types are: 1. Visiting a set of specified regions in a given order.
2. Being in a set of specified regions at the same time.
For the former relationship, the following evaluation function is used: For the latter relationship, the criterion can be either fulfilled or not, thus: e(c) = 1, if all areas are being occupied by at least one player, else 0.

Distance Criterion
A Distance Criterion is based on the distance between a player and another player/object/region.Therefore, a player, an object, a region and a value max_distance is specified.

Time Criterion
The Time Criterion can only be fulfilled at a certain point in time (this point can actually be a time span, like e.g.'at night').Therefore, two points in time are defined: t min and t max .Let t now denote the current point in time: e(c) = 1, if t min ≤ t now ≤ t max Note: t now , t min , and t max can refer to continuous time scale (global time) or recurring time (e.g.time of day).If it refers to a continuous time scale, there can only be one time interval where e(c) = 1.Otherwise, there can be a time span with e(c) = 1 every cycle.

Interval Criterion
The Interval Criterion is used to measure the time distance since the last occurrence of an event or action.Therefore, an action or an event is specified, as well as a max_distance value.Let t now denote the current point in time, and t lastoccurence the point in time when the action or event occurred the last time: e(c) = min((t now −t lastoccurence ),1) max distance .

(Class) State-oriented Criterion
The class of state-oriented criteria is based on a certain (part of the) game state, i.e. a shape or a player attribute.Three concrete criteria are defined: Shape Criterion, Attribute Criterion, and Inventory Criterion.

Shape Criterion
Uses a concrete shape, i.e. is considered fulfilled if the respective shape is active: e(c) = 1, if the a shape is 'active', else 0. Criteria which need to be fulfilled for this situation to be true

Attribute Criterion
The Attribute Criterion is based on player attributes.If a player attribute has a certain value, is above or below a certain threshold, or is in a certain range, the criterion is considered fulfilled.Therefore, either x min is specified as a lower threshold, x max is specified as an upper threshold, both x min and x max are specified as a range, or x eq is specified as a concrete value.Let x now be the current value of the player attribute.
1.If only x min is specified: e(c) = 1, if x now ≥ x min , else 0.

If only
x max is specified: e(c) = 1, if x now ≤ x max , else 0.
3. If x min and x max are specified: e(c) = 1, if x min ≤ x now ≤ x max , else 0.

If only
x eq is specified: e(c) = 1, if x now = x eq , else 0.

Inventory Criterion
This criterion is used to model the necessity of an item to be in a player's inventory.
e(c) = 1, if the specified item is in the player's inventory, else 0.

Task Criterion
This criterion is used to make a task a prerequisite of a situation.The task needs to be either in the state 'not started', 'ongoing', or 'finished'.Therefore, x task is specified as 'not started', 'ongoing', or 'finished'.Let x now be the current state of the task.

Situation Evaluation
Definition (Situation).A Situation sit is a point of interest in the game which can be considered interesting or relevant due to its meaning for the game or game purpose.
In contrast to shapes, situations are not easily tangible by defining a boolean expression over a set of concrete game variables.Rather, situations are used to describe vague incidences during the course of the game.Those incidents would usually be categorized by a human person which is able to recognize and judge player behavior and game situations.
A situation is defined via a set of criteria C sit : sit := C sit ⊆ C. A situation is considered partially present if only a part of its criteria is fulfilled or one or more of its criteria are only partially fulfilled.A situation is either caused by one player or by the whole group.
Note: in contrast to a shape, which has two concrete states: active and inactive, a situation has a continuous value range of [0, 1] indicating the probability that the situation is present.
For each situation, the situation recognition calculates how likely it is that the situation is currently present.This is performed on a cyclic basis, like every frame.However, for performance reasons this can be reduced to once per second.Therefore, it evaluates the situations' criteria.For each criterion, an evaluator function e assigns a value between [0, 1]: e : C −→ [0, 1] The situation sit's degree of presence e(sit) thus is: Hence, it is possible to assign a probability value (between 0 and 1) for each defined situation in the game.The evaluator then orders all situations according to their evaluation value in a descending order, trimming those situations where e(sit) < δ with δ being a threshold to define a minimum probability.• Distance Criterion: Is the player close to the nonplayer character Proventus Avenicci?

Situation Examples
• Inventory Criterion: Does the player possess more than 5000 pieces of gold?
If all of the criteria listed above are fulfilled, there is a high probability that the player is on his/her way to buy a house in Whiterun.If however, only some of the criteria are fulfilled, the player however is not Thane, it is still possible that he/she is trying to buy the house, but just does not yet know that he needs to be Thane.Or, he/she approaches the NPC because he/she wants to buy something else.Subsequently, the probability that the player is about to buy the house is still relatively high.
Example 2: EFWI -Building the log hut: • Local Criterion: Are the players close to the hut building area?
• State Criterion: Is the first part of the hut built already?
• Atomic Criterion: Is a large palm being carried?If all of those criteria are fulfilled, it can be assumed with a very high probability that players are trying to finish building the log hut.If, however, only a part of those criteria is fulfilled, the players are probably trying something else (like building the raft, or carrying logs to make firewood) or they, for example, do not know where they have to build the hut.Therefore, the probability that the players are actually building the log hut is lower, but significantly above zero.

Implementation
We implemented our approach as a Unity3d-based library coded in C# and used the existing Serious Game Escape From Wilson Island for a first evaluation.Due to its Game Mastering interface, EFWI already provides access to its Game Variables and Actions.That provides all necessary information for the situation evaluation.

Escape From Wilson Island
EFWI is a multiplayer Serious Game focusing on collaboration and teamwork.The narration can be described as a collaborative 'Robinson Crusoe scenario'.The tasks to be solved by the players are designed in a way such that players need to work together and to coordinate their actions.The overall task is to escape from a deserted island where the players stranded.In  2. Criteria of the' Filling Gas Bottle' situation order to achieve this goal, the players need to build a log hut for shelter, establish a food supply, build a raft, find and fill a gas bottle, steer the raft towards the second island, and ignite a signal fire.The single tasks require a high amount of teamwork and coordination.Carrying a palm to build the log hut, for example, requires three players to coordinate their movement to not let the palm fall down.More detailed information about the game can be found in [2].The Game Master concept and frontend is described in [3].

EFWI Tasks
In EFWI, players need to solve several sub-tasks, like building the log hut, or filling the gas bottle, in order to finally fulfill the overall task of escaping from the island.

EFWI Example Situation
The following example describes the definition and evaluation of the Situation 'Filling Gas Bottle'.Table 2 shows a list of the defined Criteria.
The gas bottle can only be filled at night.Therefore the first Criterion evaluates to 0 if it is day, and to a value between 0 and 0.2 at night, with 0.2 at midnight.A player needs to provide light to find the correct geyser at night.Therefore, a player needs to have a flashlight in his/her inventory.If this is the case, the second Criterion is evaluated to 0.2, otherwise to 0. Players also need to have the empty bottle in their inventory.So this criterion evaluates to 0.2 or 0, if not.Players can only fill the bottle, if they are in the 'Geyser Region' of the island.If players are close to the geysers, this Criterion evaluates to 0.2.The farther away players are, the lower this value becomes, until it reaches 0 when players are far enough away.Finally, the flashlight needs to be on, so that players can fill the bottle.So this Criterion evaluates to 0.2 if the flashlight is on, and to 0 if not.Thus, if all of those Criteria are fulfilled completely, the Situation would be evaluated to a value close to 1. Once players filled the bottle with gas, they won't try to fill it again.Therefore, the FilledBottleInInventory Criterion is added which is evaluated to -1 if a player already has a filled gas bottle, zeroing out all positive evaluations of the other Criteria.So, even if players are moving around the geysers at night, having a flashlight on, they probably are not trying to fill the bottle, if it is already filled.
The following Table 3 contains Game Variables and Actions which are being accessed to evaluate the Criteria:

EFWI Situation Recognition GUI
In the Game Master GUI (Figure 2), the highest evaluated situations are being displayed for each player and for the whole group.The GM can adjust how many situations to display for each player/group between only the most significant or all situations.

Evaluation
An initial study to evaluate the soundness and correctness of our approach has been carried out comparing the recognized situations with the situations recognized by a real GM.Therefore, the following situations have been defined as relevant because they reflect the major game tasks or are steps towards fulfilling them (except for the 'Idle' situation): 'Build log hut', 'Build raft', 'Drive raft', 'Explore island', 'Fill bottle', 'Hunt heron', 'Idle', 'Ignite fire', and 'Search berries'.Those situations cover the first part of the game until steering the raft towards the second island.

Setup
Five game sessions (with two runs each) were played with random players.In each session, four players played the game.For the second run in each session, four different players were selected.Thus, in sum 40 participants (8 female, 32 male) aged between 16 and 27 (M = 20.90;SD = 3.05) took part in the study.
In the first run, a Game Master was watching the gaming session via the Game Master Frontend.The visualization of recognized situations was disabled.The Game Master was instructed to write down what he/she thought what a player/the group was doing once per minute or whenever he/she thought players were doing something new.The notes were provided with a timestamp.Those notes were then compared to the situations recognized by the situation recognition.The  situation recognition was always able to recognize the same situation for the group within 1-5 seconds of the actual situation happening.Moreover, the recognition ratio (the percentage of time the situation is recognized while it is active) is ≥ 48% for all situations, with recognition ratios of ≥ 90% depending on the situation.For single players, the correct situation was always among the three most significant evaluated situations.After that, in a second game run, with the same Game Master and a new set of four players, the visualization of the situation was enabled.Now, GMs again observed the game.After the game run, the GMs gave feedback on the situations which the situation recognition had proposed.All of the GMs stated that the situation they thought to be present was among the first three situations recognized for a player, and among the first two situations for the group.

Discussion
In sum, the initial study showed that the situation recognition worked very well for the game EFWI.A Game Master can use the information displayed as a means to reduce to cognitive load during the process of moderating a game session.The additional information might help to judge the current state of the game and the learning/gaming process and help to decide about adaptation measures.In terms of automatic adaptation of multiplayer games, it can be stated that the automatic recognition of game situations can be viewed as a prerequisite of being able to make sound adaptations to a game.Therefore, the situation recognition presented here might be a first step towards a sound adaptation of non-scenebased multiplayer games with a high amount of player freedom.Being able to automatically recognize the situation, a group of players/learners is in, might help to recognize problems in the learning/gaming process and subsequently react with an appropriate game adaptation.However, a comprehensive study under laboratory conditions is required for further, more precise statements.Moreover, it is necessary to evaluate the situation recognition framework in other similar games for evidence about the genericity of the concept.

Conclusions
In this paper we presented an approach for automatic situation recognition in collaborative multiplayer Serious Games as a foundation for automatic adaptation of collaborative multiplayer Serious Games.Our approach uses basic information about the game, like elemental game variables and player parameters as well as player actions and game events.Situations are defined based on criteria which describe a game situation using elemental game information.An evaluation algorithm periodically evaluates the probability of a situation to be present.We implemented our approach as an extension of the existing collaborative multiplayer Serious Game Escape From Wilson Island and performed an initial evaluation.First results showed that our approach is able to correctly recognize the defined situations in congruence with human instructors.However, a more comprehensive study is required for more detailed results as well as information about the transferability of our concept to other games of similar type.Altough the implementation presented here is specific to EFWI, the situation recognition can easily be transfered to similar games, provided they offer an interface to access relevant game parameters, actions, and events.If this is the case, it is possible to define criteria and situations specifically for that game.It is however recommended to implement a graphical representation of the situation recognition's results within the game as this can be considered useful for an instructor.

2
EAI Endorsed Transactions on Serious Games 08 2014 -07 2015 | Volume 1 | Issue 4 | e4 an elemental piece of information about the game.The set V contains all game variables.The function ω assigns a value of v's codomain: ω : v → {N, R, B}.
e(c) = 1 − min(current_distance,max_distance) max_distance (Class) Temporal Criterion A class of criteria which are based on a point in time or on a time interval.Two concrete criterion types are defined: Time Criterion and Interval Criterion.

Following, two examples
will be presented showing the use of criteria to define a situation: Example 1: Skyrim -Buying a house in the city of Whiterun: • Local Criterion: Is the player in Whiterun?• Task Criterion: Is the player 'Thane' of Whiterun? 2 EAI Endorsed Transactions on Serious Games 08 2014 -07 2015 | Volume 1 | Issue 4 | e4

Figure 1 .
Figure 1.Schematic of all Escape From Wilson Island tasks

Figure 2 .
Figure 2. Game Master overview over the game including the situation recognition

Table 3 .
. Wendel et al.A method for automatic situation recognition in collaborative multiplayer Serious Games Example Game Variables, Player Actions, and Regions in EFWI 8 EAI Endorsed Transactions on Serious Games 08 2014 -07 2015 | Volume 1 | Issue 4 | e4V