A Living Framework for Understanding Cooperative Games

Playing cooperative games is recognised as a positive social activity. Yet, we have limited means to rigorously define or communicate the structures that govern these experiences, hindering attempts at consolidating knowledge and limiting the potential of design efforts. In this work, we introduce the Living Framework for Cooperative Games (LFCG), a framework derived from a multi-step systematic analysis of 129 cooperative games with contributions of eleven researchers. We describe how LFCG can be used as a tool for analyses and ideation, and as a shared language for describing a game’s design. LFCG is published as a web application to facilitate use and appropriation. It supports the creation, dissemination and aggregation of game reports and specifications; and enables stakeholders to extend and publish custom versions. Lastly, we discuss using a research-driven approach for formalising game structures and the advantages of community contributions for consolidation and reach.


INTRODUCTION
Playing with others has the beneft of enabling people to connect, form and maintain friendships, and strengthen social bonds [16,21,60,69,79,84,85].Playing cooperative games emphasises cooperation and teamwork among players, which has been associated with a positive impact on social aspects of players' lives [18,19,52].
However, there have been limited eforts in formalising cooperative games.We argue that to analyse, ideate, and consolidate knowledge about these games and their efects, there is a need for a shared language to describe the structures of cooperative games. 1revious eforts of systematising game design about cooperative games have relied on researchers' knowledge and/or analyses of a small set of cooperative games [63,64,66], often lacking methodological details, relying on informal procedures with the latest attempts almost a decade old.The resulting work is often expressed as a static compendium of patterns useful to inform any attempts to systematise and structure cooperative games.The informal procedures coupled with games being ever-evolving structures (i.e. last year alone, 676 games with the Co-op tag were released on Steam, compared with the 81 released ten years prior) call for rigorous approaches, easy to leverage by designers and researchers, and capable of adapting to new content.
In this paper, we go beyond existing eforts and rigorously develop a framework that conceptualises the structure and patterns found in cooperative games through a multi-step analysis.We followed an approach akin to Template Analysis [12], creating a template based on prior research, iterating it through the analysis of cooperative games, and the follow-up review and validation by three researchers, with no prior involvement, for a total of 129 games analysed.All steps included multiple consolidation sessions.
We present the Living Framework for Cooperative Games (LFCG), which captures high-level structures encountered in cooperative games divided into Play Structure, Player Context and Forms of Cooperation; and includes a compendium of Cooperation Design Patterns.Through it, we seek to provide researchers, designers and developers with tools to better describe, design, develop and study cooperative games, their structures and interaction patterns.It can be leveraged as a tool for analysis or ideation; or as a language to rigorously describe games, game design requirements, or detail study designs.
We discuss how LFCG can be leveraged through its web deployment, facilitating use, and enabling appropriation by the larger community.Recognising the dynamic nature of the gaming landscape, the framework is published as an interactive web application where researchers and designers can actively contribute and expand its scope.
We conclude by refecting on how LFCG can be a shared language to study the efects of design decisions by allowing us to detail and isolate design choices for and from empirical studies.We discuss our choice of relying on a research-driven approach during inception, and how any attempts to formalise game structures should include mechanisms for community appropriation and to support new knowledge.We argue for its use as a canvas for future eforts.
This paper contributes with a framework by which to defne and understand the structures in cooperative games, including an interactive web deployment to support its use.

RELATED WORK
In this section, we discuss 1) formal structures; and 2) the understanding of cooperative behaviours in digital games.

Formal Structures in Digital Games
In this work, we primarily focus on analysing play and its structure while recognising that games are cultural artefacts that combine "the rules that the player interacts with in real time with a fctional, imagine world" [51].Quoting Hunicke et al. [42], in their foundational paper, the researchers highlighted how we can "analyse the end result to refne implementation and analyse the implementation to refne the result".Without a rigorous defnition of the game artefact that produces the experience, the knowledge created will be impossible to extrapolate, synthesise and consolidate.In game design, the same structure will inevitably be afected by context and the player.Still, pre-determining the most likely experience and efect will make our design choices more purposeful.
Games can ofer a diverse array of experiences, but not all games impact the player in the same way.Diferent models for thinking about and discussing game design have been proposed.These can be useful for researchers and designers to discuss particular aspects of games they create or analyse.The Mechanics, Dynamics, and Aesthetics (MDA) framework breaks game experiences into 3 parts [42].Mechanics are the game's rules (e.g., how the player moves, how they interact with the environment), and Aesthetics relate to the player's idiosyncrasies (e.g., how they are feeling, where they are playing, etc.) and how these afect the perception of the experience.Dynamics, on the other hand, contain the interactions between the rules of the game and the player.While this framework does not contain practical information, such as design patterns, it has been used as a structure for discussion and analysis of games.This model supports high-level discussion, but it is also important to have frameworks that facilitate the discussion of lower-level concepts of mechanics, patterns, and features, and what impact these can have on the experience.
The systematisation of game mechanics and design patterns has been approached through various methods in past research.One approach involves researchers immersing themselves in a game, playing it extensively and taking detailed notes over an extended period of time to gain a deep understanding of its mechanics [20].This hands-on experience allows researchers to directly observe and analyse the intricacies of gameplay.Similarly, the work by Alharthi et al. [2] has relied on a grounded theory approach to analyse a set of 66 idle games to provide a taxonomy to support researchers and designers.Another approach, as seen in the works of Rocha et al. [64] in the context of cooperative play, the MDA framework [42], and the open-ended game classifcation model discussed in Elverdam et al. [1,22], relies on researchers' prior knowledge, critical analysis of their own experiences, and expertise to propose frameworks, models, and design patterns.These approaches leverage researchers' insights to uncover underlying mechanics and principles.
2.1.1Design Paterns and Mechanics.Game design patterns and mechanics are two concepts that are used in both academia and industry with recognised semantic overlap [56], which makes it difcult to distinguish.This is seen throughout the literature as patterns and mechanics are defned in many diferent ways [67], often overlapping.
Game patterns were frst proposed by Kreimeier in 2002 [53], further articulated by [9,10,40], and recently expanded in the book "Pattern Language for Game Design" by Chris Barney [5].In their approach, terms, ideas and patterns emerge from the gaming community and are meant to serve as a common vocabulary of concepts regarding game design.In 2004, the collection already included 300 patterns and has since been converted into a wiki format, inviting its use and contributions from the larger community.The process to identify these patterns was described as a "brute force" analysis of existing game concepts and design methods from other felds [40].Barney released their book [5] accompanied by an Interactive Pattern Library and Games Reference 2 , aggregating all patterns and making the tools necessary for creating and sharing new ones.Similarly, game mechanics are compiled by Järvinen [50] through the analysis of a sample of games, creating a library with over 100 mechanics that capture gameplay at a micro-level (e.g.Motion, Jumping).Järvinen argues that game patterns and mechanics difer in scope and point of view, the frst concerned with dynamics, and the other analysing game elements and their combinations.Further examples are the works by Harris et al. that formalized asymmetrical aspects of gameplay [38,39], including Direction of Dependence, Synchronicity and Timing, and Degree of Interdependence and by Toups et al. that identify and classify diferent types of cooperative communication mechanics [78].
These various approaches highlight the multi-faceted nature of studying games, each providing unique insights and perspectives.In our work, we do not seek to establish a new understanding of design patterns or mechanics but rather propose a shared structure to specify and analyse cooperative games.As such, we will use "Category" to describe concepts that aggregate multiple possible "Values".Values will often be equivalent to patterns or mechanics depending on the encapsulating category.Throughout the work, we will use cooperation patterns to describe the high-level categories associated with promoting cooperative behaviours.

Understanding Cooperative Behaviours in Digital Games
Prior work on cooperative games looked into identifying and exploring how specifc design choices and mechanics (e.g.asymmetry, interdependence, communication) afect social outcomes (e.g.connectedness) [17], performance and engagement [8].Other approaches have focused on examining behaviours that unfold in specifc cooperative experiences, such as characterising the social organisation [59], as well as instances of communication and coordination surrounding cooperative play in World of Warcraft.[14] Others focus on analysing a smaller set of games to extract broader knowledge and develop models [63,64,66,82].El-Nasr et al. [66] extended early work by Rocha et.al [64] (which identifed a set of cooperative mechanics) and was informed by game design patterns research [9,10,40] including cooperative patterns within board games [86].Specifcally, the work by El-Nasr et al. [66] analysed 14 games to identify and model specifc aspects of cooperative gameplay, such as sharing characters or puzzles or interacting with the same object.Additionally, the paper proposed a set of cooperative performance metrics (e.g.laughing at the same time) to be used to analyse cooperative play.Similarly, the preliminary work by Baykal et al. [7] is seeking to create a taxonomy to understand the levels of interaction by extending the MDA framework, incorporating the theoretical concepts of collaborative interaction levels [4] (i.e.coordination, cooperation and refective communication) and analysing verbal communication.
All prior approaches sought to identify commonalities and patterns across games, pre-defne structures to guide design and development, study the efects of cooperative games and their mechanics, or provide a common language to support game designers. 2

Interactive
Pattern Library and Games Reference: https:// patternlanguageforgamedesign.com/PatternLibraryApp/PatternLibrary/Recently, Gonçalves et al. [37] conducted a systematic review focusing on shared gaming experiences (i.e.social gaming).The work reviewed 263 publications, of which 16 specifcally focused on characterising cooperative play.The review highlighted how research has been scattered across dimensions, making it difcult to synthesise or understand what has been covered and how each study's artefacts and dimensions relate to one another.Furthermore, the work reveals how few focus on design patterns and mechanics, and even fewer of these provide a systematised way to analyse or leverage the knowledge.Overall, the work only made a limited theoretical contribution to the feld, with the majority of publications focusing on novelty, creating and analysing new devices and or unconventional interactions.It makes a call to action for game researchers to strive to consolidate knowledge to advance the feld, going beyond case studies and also providing comprehensive design frameworks.

METHODOLOGY: UNDERSTANDING COOPERATIVE GAMES
In this work, we extend past attempts at understanding cooperative play by conducting a qualitative analysis of 129 games.In this section, we describe the steps we took, outlined in fgure 1.We frst detail our Search Strategy, which we carefully designed aiming to collate a list of relevant cooperative games to analyse.Next, we detail the Selection Process, where we attributed individual games to seven researchers, which we will refer to as coders (i.e. one senior, and six juniors, all with prior experience in game research).In Game Analysis, we describe the steps followed by each coder when assessing a game.Then we describe the Data Analysis, where we followed the steps of template analysis: 1) become familiar with the data; 2) preliminary coding; 3) organise into meaningful clusters; 4) defne coding template; 5) apply to further data and iterate; 6) and produce the fnal template [12].We adapted the fnal step, which includes applying the template to the full data set, by having two researchers who were not involved in any of the prior steps or discussions, analyse a set of nine cooperative games using the LFCG's frst iteration, that was later reviewed by another senior researcher.We describe this last step in the section Validation & Review, followed by the resulting framework.

Search Strategy
We sought to create a pool of games that were 1) highly rated, 2) included games of the last fve years, and 3) covered a variety of types of cooperative experiences.This ensured we captured the latest design trends and innovations.As such, we selected the top 10 games from Metacritic (i.e.popular aggregator of game reviews with weighted scores from game reviewers and players that has previously been leveraged in research, e.g., [55]), of each year from 2017 to 2022.As there is no category for cooperative games, we searched the top-rated entries of each year until we had ten games.We selected games in which the description available included one of the keywords: "co-op", "cooperative", "cooperate", and "collaborative", excluding any that, through manual validation, were not a game with cooperative elements (e.g.singleplayer).This resulted in the frst 50 games selected.Next, we selected games from the largest video game digital distribution service, Steam, leveraging its Tag feature.A game can have any number of tags, but each is given a specifc weight according to developer input, and it evolves over time, as players apply new ones or reinforce existing ones.We manually assessed every tag displayed on the Steam storefront when navigating per tags and selected all which were related to cooperative play: Co-op (5637), On-line Co-op (4292), Local co-op (2408), Team-based (1471) and Co-op Campaign (515).From these, we fltered out all games in which the cooperative tag was not among the top 5 associated with the game (i.e. which are the ones that are displayed on the storefront, and used in many of the store flters) and all which were already selected from Metacritic.This led to a diverse pool of 118 games 3 , including 91 with a "Single-Player" tag and, at the time of writing, with concurrent users ranging from 0 to 110229 (with an average of 7833), an average percentage of positive reviews of 86.78%, release dates between 2004 and 2023, from free-to-play to buy-to-play models, with costs ranging from 3.99€ to 59.99€, with and without micro-transactions.We purposefully analysed all games which included cooperation, meaning the pool had fully cooperative games (e.g.A Way Out), team-based games that included competition (e.g.Counter-Strike: Global Ofensive), and others with multiple play modes (e.g.Age of Empires).

Selection Process
Each researcher self-assessed their experience with the 118 games (e.g.played it, played the franchise, no idea).We aimed to divide the games among researchers equally while maximising familiarity, each evaluating between 18 and 22 games.In total, 73 had been played by the responsible coder (i.e. or games of the same franchise), 16 were known to the coder but not played, and for 29 the coder had no prior knowledge.In addition, six researchers chose one additional cooperative game to guarantee the analysis of a highly familiar game, for a total of 124 games assessed.If a game had multiple play modes (e.g.competitive and multiple types of cooperative modes) researchers chose cooperative and the most relevant mode according to their judgement. 3List of collected games https://osf.io/92drw

Game Analysis
For each game, coders were instructed to take at least the following steps: (1) Find the game and read its store description (in Steam or other if unavailable); Coders had to fll out a review template for each game assessed, described in the following section.

Data Analysis
We followed an approach inspired by Template Analysis [12], referred to as codebook thematic analysis (TA) by Braun and Clarke [11].Template analysis is a form of TA that promotes hierarchical coding, seeking a high degree of structure and fexibility to extend dimensions where the data is richer.It does not require that the coding template exists a priori, but rather a code structure is created with a mixture of prior knowledge and familiarity with the data.After an initial coding template is defned, it is applied to the data, iterating as much as necessary.Finally, it recognises that a template is never truly "fnal", and further engagement with meaningful data might extend the template.The frst step was to deductively produce a codebook based on prior work and researchers' experience with the dataset, as they were already familiar with most.In particular, the codebook had all patterns identifed in El-Nasr et al., and Reuter et al. [63,66]; some established by Bjork and Jussi [9] in particular ones associated with social interaction; concepts related to interdependence, asymmetry and group play [17,39,82]; and informed by Elverdam et al. [22] work on game classifcation.
Aiming at systematising the analysis and creating a comprehensive corpus for discussion, we created a review template for all coders to use and expand as required after analysing each game.The template included felds for generic game information (e.g.play description, multiplayer modes), all the pre-identifed codes from related work, each with a feld for observations (i.e. which was expected to be used when the code was selected), and a dedicated space for new codes.The approach is similar to how prior work [2] has captured game observations and coding to support the following steps of analyses between team members.
First, all seven coders analysed the same game independently (i.e.Overcooked -which all had played) and then met to iterate on the review template, merging similar concepts from past work and dropping others.New codes were proposed and discussed until a consensus was reached.For example, one coder proposed "Collisions between players" related to Overcooked, which led to the creation of a "Shared Space Negotiation" category (which was later moved into a value within "Resource Sharing").This process was repeated twice, frst in a round where each coder analysed a set of 10 diferent games, meeting, and further refning the template.Secondly, all other games were analysed before three sessions, each for 3 to 4 hours, where seven coders and one additional senior researcher discussed the current codebook and template, including observations.These sessions were used to sense-check the data collected to defne and understand cooperative games, seeking to guarantee that the resulting structure accommodated all the identifed patterns and relevant features.During the sessions, one researcher acted as a moderator, using the whiteboard to focus the discussion on specifc groupings, defning merge opportunities and seeking to cluster similar constructs together, establishing hierarchies of meaning.Decisions on whether to include a code as a category or value were guided by a set of questions which included: Can this feature/element potentially afect collaboration by design?Is there an overlap with a previous category or value?Can we defne it objectively?How is it defned, and is there an example of its use?The category or value would only make part of the framework if a consensus were reached.These sessions resulted in an initial structure that was then written and iterated into the frst draft of the LFCG.As expected, the writing process resulted in additional unprompted discussions between the research team throughout the next two months to consolidate the framework.

Validation & Review
Next, we had two senior game researchers and one junior using and/or reviewing the framework; none had been involved or aware of the previous steps.Two (i.e. one junior and one senior), were invited to analyze 9 cooperative games using the frst draft of LFCG.We requested they applied three methods of analysis: of the nine games, three had to be played and then analysed; three had to have been played in the past and analysed based on recollection; and lastly, three had to be analysed based on online ethnography (i.e.observing gameplay, trailers, review, store descriptions, etc).For each set of the three, we requested that one was from the list of 124 games, one not from the list, and the last one was a free choice, resulting in a total of 129 diferent games assessed in this work 4 .This phase allowed the team to refect on how the framework accommodates the diferent types of analyses conducted within game research studies.
We provided each reviewer with a live document of the framework, and a Google Form prepared to analyse each game with two additional felds in each category to add observations (about the analysis), and provide comments, or doubts about the category and its values.All multiple-choice questions had an additional "other" feld to support identifying new values.Lastly, the form had two additional questions about the difculty of using LFCG and general comments and observations.After both reviewers completed their analyses, the remaining went through their reviews and systematised their comments in a shared document, before a session with each for further feedback and clarifcation.The third researcher, with over 10 years of experience in the feld, fully revised the framework and was involved in the last iteration process of LFCG.
We consolidated the knowledge created through multiple rounds of writing and reviewing by the whole research team with inimpromptu meetings throughout two months, leading to the framework detailed below.

A LIVING FRAMEWORK FOR COOPERATIVE GAMES (LFCG)
With the Living Framework for Cooperative Games (LFCG), we aim to provide a structure by which it is possible to analyse, ideate and understand cooperative games.We divided our framework into four major categories (see table 1): Play Structure and Player Context, which describe general gameplay, being mostly applicable to any multiplayer game; Forms of Cooperation, describing how the game supports diferent forms of cooperation; and Cooperation Design Patterns, capturing specifc design elements and strategies implemented to promote cooperation.Below, we describe each grouping with an example of their application.While the framework was conceived to capture the multiple dimensions of cooperative games, it does not solely focus on those that are pervasive or unique to cooperative games (e.g.individual player progress).
To describe the values of each category, we follow a simplifed version of the game design patterns format proposed by Holopainen et al. [40]: name, description and example.We do not detail the consequences nor relations of the patterns as neither can be established without carefully conducted user studies for each.While the consequences and relations are meant to describe the "likely" or "possible", according to Holopainen et al. [40], this framework seeks to avoid coupling objective categories, values and patterns with subjective assumptions of their consequences which require further investigation.The categories of this framework are not mutually exclusive.While, under certain circumstances, some values may be unable to coexist simultaneously (e.g.player viewpoint shared and split), they may, however, exist at diferent stages of the experience.The Progression structure describes how the overall experience provided by a game advances and develops, which often implies changes in the gameplay (e.g., unlocking new levels), reaching milestones (e.g., completing a quest), and unfolding new content (e.g., storyline).Progress may be centred on the individual or shared among a party, server, and/or community.Shared progression is often supported by establishing challenges that result in shared consequences, either to reward or penalise players as a whole (e.g., when one player dies, every player in the group also dies).While most games have a progression structure, some may be limited to game-session or match progression, with no carryover efects.Games   Example: In Squad [46], each team is composed of squads.Each squad has a leader that has abilities to organize squad members.

Category
One of the squads can also be responsible for organising the team.
4.1.3Goal structure.Goal structure outlines the objectives players are expected to achieve while playing the game.It was informed by similar constructs found in related work, such as "Shared Puzzle" [66], "Shared Goals" and "Synergies between goals" [63], and "Shared goals" and "Synergies between goals" [64].Goal Structure can be applied to the overarching game goal or to a specifc set of game activities.Usually, a game presents multiple goals throughout the gameplay and they may even be dynamic and change according to game rules or player actions.These goals may be Shared, Intertwined, Independent, or Conficting, or there may be No Goal Structure.
Shared goals consist of singular objectives that multiple players pursue and work together to achieve Example: In Flat Heroes [15], at least one of the players has to live after the timer/challenge is complete for all to progress.Intertwined goals determine individual objectives assigned to diferent players that, in some way, are dependent on each other.The dependency may be uni-or bidirectional.If the dependency is bidirectional, goals are interdependent.
Example: In BoxBoy! + BoxGirl! [54], each player is a box character in a 2D puzzle platform game.While players share the same end goal, in many levels, players have to unlock paths for one another while restricted to manipulate only a subset of the level.Conficting goals are also observable in some cooperative games, where typically, players compete in certain sections that do not afect the overarching goal of the game.While no semi-cooperative games were observed, in these types of games, conficting goals can also be mixed with shared goals.
Example: In A Way Out [72], players encounter various minigames where they try to outperform each other (e.g., playing darts).Independent goals defne individual goals that do not directly interact with other players, typically diferent from other players.
Example: In Gloomhaven [71], players can control one or more characters that have unique end-goal objectives to retire, which are independent of other players.
No Goal Structure is also a possibility.In some games, the experience in itself is the goal (e.g.simulation games), while in others, the expectation is for player-driven goals to emerge.
Example: In Minecraft [74], players are not given any clues when they start the game, nor what is expected of them.It is up to them to create their own goals to drive the gameplay forward.Example: In Tiny Brains [31], each player controls one small laboratory animal.Dispersed describes gameplay where players have control of multiple entities, which might be individually controlled or controlled as a group.

Player Context
Example: In Age of Empires IV [77], players control armies of multiple soldiers.Distinct means that each player controls a diferent entity or set of entities (Distinct Locus of Manipulation [76]).
Example: In Rayman Legends [57], each player has full control of their character Example: In Unravel Two [48], players start with one of the two characters (only distinguishable by their colour), based on the assigned player number (frst or second player).Pool describes when players are given an array of playable entities to choose from (e.g.characters, nations, class).These have predefned gameplay characteristics and in some cases, players can be forced to have a unique selection.
Example: in Fight'N Rage [65], players are given three options for playable characters and there cannot be two players playing the same character.Customisation applies when players select their identity by creating or modifying (with a certain degree of freedom) the play style of an entity.
Example: in Terraria [62], armour sets are often accompanied by a set bonus.These set bonuses beneft diferent play styles, by giving players bufs (e.g.melee damage) and incentivising specialisation in one of the diferent available classes.Progress While selection describes how the entity frst came to be, progress describes if it evolves throughout the gameplay and how.
Static applies when the player's entity is constant throughout gameplay.
Example: in Portal 2 [81] the player entities do not change throughout the gameplay, having access to the same abilities always.Predefned describes when progress is strictly linear, with no player choice (e.g., dictated by the storyline, predefned upgrades or progressing through switching entities).
Example: in Trine [26], the characters unlock new mechanics at defned points.Customisable encompasses all games with upgrades, levelling systems, and others that give players the ability to create and modify their representation throughout the game.
Example: in Guild Wars 2 [3], players can choose from multiple classes.This defnes a mechanical starting point for the playable character, but players are able to customise their character's equipment and abilities further.Switchable applies to games where players can change their playable entity throughout the gameplay.
Example: In Lego Star Wars [33], players assume diferent characters from level to level and can switch between a pool of characters during the actual level.Teammates, where players within a team need to coordinate their actions, abilities, and roles in order to reach a common goal against at least another team.
Example: In Ghost of Tsushima Legends [24] rival's mode, two players compete against another team of two to see who can fnish the rounds of enemies faster.Allies, when players are part of a shared faction/race etc, which causes players to have special gameplay mechanics between each other.Value also present as "Special Rules for Players of the same Team" in Rocha et al. [64].
Example: In World of Warcraft [23], in Player versus Player servers, players can only heal other players who are their allies.Competitors, where you may be able to compete with other players, either momentarily or through the whole game session (e.g.team vs team match-based games).
Example: It Takes Two [73], the gameplay presents short moments of competition between players (e.g., playing chess within the environment).Example: in Rayman Legends [57], players share the same screen, which afects the movement of the levels and the survivability of the players.Split typically divides the view by the number of players, with each being associated with a particular section.Players will have a smaller view of the game world as a result, but they will still be able to experience diferent game areas from the perspective of the other player.Similarly, this usually happens in co-located experiences with a single physical screen.

Game
Example: in It Takes Two [73], players have a split screen, allowing them access to the other player's perspective, which, in turn, allows for better coordination, cooperation, communication and support.Distinct refers to when each player has control of their viewpoint, typically through separate screens.
Example: in Destiny 2 [13], players do not share their screens or perspectives.

Forms of Cooperation
Players can cooperate in diferent forms, some directly supported by the game, while others emerge from the rules and challenges of the game.In most games, cooperation happens through in-game actions -we list a set of design patterns that allow or promote in-game cooperation in section 4.4.Some also require cooperation through communication -we detail aspects related to this form of cooperation below (overview on fgure 4).Other types of cooperation can also happen (e.g., sharing or assisting with controls), but are outside the scope of this work.
Regardless of the means leveraged to cooperate, how it is implemented and shaped by design varies from game to game.We categorise cooperation in terms of its arrangement and synchronicity, inspired by similar constructs in related work (e.g., "Concurrency" and "Parallelization" [63], and "Directional Dependence" and "Synchronicity and Timing" [39]).In many cases, cooperation over time is complex, and players fuidly transition between diferent arrangements and synchronicity, with interactions across the whole spectrum (e.g.complex MMO Boss fghts).

4.3.1
Arrangement.Arrangement describes how the game assigns cooperative tasks to players.There is a spectrum between strict and free assignment of tasks.Further, cooperation may happen with players performing tasks that are either coupled or coincident.
Strict cooperation, where the game assigns specifc tasks to players, with players having little freedom to shape their interaction.
Example: in We Were Here Together [34], the cooperation happens as it is scripted to happen, with one player typically interpreting and transmitting information while the other acts with that information.Free cooperation, where players can take on available tasks as they wish and decide how to contribute.
Example: in Lovers in a Dangerous Spacetime [6], players collectively control a spaceship and can assume the control of the station they wish, with its own challenge associated.Nuances about interaction synchronicity are also captured by past work on asymmetric game design [39].
Sequential cooperation, where players have to do tasks in sequential order, with tasks typically assigned to diferent players.
Example: in Mario + Rabbits: Kingdom battle [45], a tactical combat-based game, players take turns sequentially between their characters, moving them around the board and performing actions.While the order is free, the actions are always sequential.Concurrent cooperation, where players have to perform gameplay tasks concurrently.
Example: in Counter-Strike [80] players are playing simultaneously and are expected to coordinate actions for success.Asynchronous cooperation, where players are able to play at diferent times and still cooperate.
Example: in games with shared base building and persistent worlds, you can contribute to the Server's progress without playing at the same time as others (e.g.Minecraft [74]).

Communication Expected by Design
Agnostic, when the game is neutral to player communication, it does place any restrictions.
Example: in Necesse [68], players can cooperate on the missions, but the game does not require them to communicate in order to cooperate.
Limited, when the game restricts communication, while not prohibiting it as a whole.It can be achieved through gameplay mechanics such as designated time/space when communication is allowed, or through allowing communication through only specifc modalities (e.g.pings, emotes); or through rules that the players should follow (e.g.do not communicate your exact position).
Example: in Among Us [47], players can only communicate during specifc discussion phases, to decide on who to vote out, and not during the entire gameplay.Required/Incentivised, when the game challenges require players to communicate (e.g. when there is essential asymmetric information), or incentivises through challenges that are made easier through it (e.g.coordinating combined actions for maximum efect).
Example: in Keep Talking and Nobody Explodes [32], one player is presented with a bomb and the other one has the bomb defusal manual.Players are required to communicate in order to successfully defuse the bomb.

Cooperation Design Patterns
Cooperative games employ a variety of patterns and game mechanics that promote cooperative behaviours by their players.In this grouping (fgure 5), we identify what dimensions from the previous sections we construed as conducive to cooperation 5 .The following list is not a comprehensive list of patterns, but a frst step into collating and systematising design approaches found in cooperative games.It is expected to be a starting point to be expanded as new cooperation patterns are identifed.All the patterns and mechanics can be implemented with varying degrees of visibility.We divide the section into Play Structure, Player Context, Dependencies, Affecting Others, Resource Sharing, Asymmetry, and Relations between Players' Actions patterns.4.4.2Dependencies.This category encapsulates cooperation incentives derived from the way gameplay activities are structured or from the gameplay actions and the constraints that they put upon the players.It is divided into Task, Grouping, Spatial, Temporal Dependencies, Fixed Difculty, and Scaling Difculty Task refers to gameplay tasks where at least one player is dependent on another.These can force players to coordinate to be efective and complete them.
Example: in Unravel Two, there are multiple sections where you have to rely on each other to complete parts of the task in order to be able to progress.Grouping refers to activities that require a certain number of players to be accessed/completed.Example: in Destiny 2, some raids (designed for a group of six) have encounters that require a certain number of players to complete.Spatial, inspired by Reuter et al. [63] and El-Nasr et al. [66], happens when the game forces or incentivises players to be at a certain distance from one another.This can happen in a variety of ways, for example, by creating a radius around which players cannot trespass or by designing mechanics that punish players that move too far away from the group.
Example: in Left for Dead 2, the game makes the horde of zombies target a player that moves too far from the group, forcing this player to regroup.Temporal, when there are temporal dependent events that afect both players.For example, ensuring action concurrencies or timing.
Example: in Portal 2, both players need to be press two diferent buttons at almost the same time to complete some of the puzzles.Fixed Difculty, when games purposefully do not adapt the difculty to player count, making some challenges near impossible without more players cooperating.While some players can take it as a challenge to complete on their own, others can rely on their fellow players to lighten up the challenge.
Example: in Destiny 2, when a player wants to do a Strike, they can choose the difculty to do it in.The easier difculties are solo-able for the average player.However, as the difculty increases, fewer and fewer players try to complete them on their own.Some players still take it as a challenge and the game rewards these players with achievements.Scaling Difculty, most games that support a varied player count adapt the difculty to the number of players, so that players can play with more people if they wish without jeopardising the experience.
Example: in Diablo 2, the enemies scale with the number of players.

Afecting others.
Extending "Abilities that can only be used on another player" by Rocha et al. [64] and "Delayed Reciprocity" by Björk et al. [9], this category describes mechanics that enable players to afect others unidirectionally.All of them, depending on the context and implementation, can be altruistic (i.e.without any beneft to the player) or non-altruistic (i.e. with direct or indirect benefts).They do not necessarily create any dependence between players.It is divided into Assistive Actions, Manipulating Others, and Piggy-Backing.
Assistive Actions encompass actions that one player performs to the beneft of other/s (i.e.note that the player can have indirect benefts such as reviving others to increase their own chances of success).In these games, players can support and assist other players in achieving their objectives.
Example: in Age of Empires, players can assist their partners by sending armies to assist defend their territory.Manipulating Others' Entities is a specifc type of assistive action that refers to situations where a player can directly control or manipulate the actions, movements, or abilities of another player's character.This can lead to cooperative gameplay dynamics or just playful interactions.
Example: in Humans Fall Flat, players can grab other players and help them across a ledge.Piggy-Backing refers to a specifc mechanic, where one player's performance can be leveraged for others to bypass challenges.This mechanic was identifed in games like Lego Star Wars.[83] Example: in Super Mario 3D World, only one player needs to pass the challenges; the other can turn into a bubble and skip and join the other player.

4.4.4
Resource Sharing.This category captures when the control and/or management of resources (i.e.any element of the gameplay that can be utilised and/or managed by players) pertains to more than one player.This creates a direct way that players afect and/or interact with each other, incentivising them to collectively negotiate how to manage and utilise them.We distinguish between fve types of resources, namely consumables, unlockables, interactables, playable characters, and space, as well as detail ways these are shared by players.
Consumables refer to items that exist in a limited amount and can be utilised by players to invoke an efect (usually existing as a form of currency, materials, or food) or are not consumed on purpose by players but support the gameplay (e.g., health, energy).Consumables are shared when the agency to consume and manage them pertains to more than one player.This value was informed by the construct "Limited Resources" in related work [66] (not to be confused with the name of the category).
Example: in Cuphead, a player may consume the other's lives to respawn; in Don't Starve Together, both players may collect and then consume wood for building and crafting.Unlockables refer to content available in the gameplay but not accessible up until players are able and choose to get access to it.Unlockables are shared when the decision to unlock new content pertains to more than one player.The efect of the unlockables may or may not be shared (it might afect only one player, but they would still be shared if more than one player could make the decision).
Example: in Guacamelee, players can unlock new abilities that collectively afect their gameplay.The menu to acquire these abilities is accessible to every player.Interactables refer to virtual objects and non-player characters/entities within the environment that respond to players' actions and is inspired by the construct "Interacting with the same object" proposed by El-Nasr et al. [66].In some cases, interactables are also consumable (e.g., food in Overcooked is transported and modifed as an interactable, but also consumed to complete the recipes).Interactables are shared when their state and attributes can be afected by more than one player.
Example: in Sea of Thieves, all players are able to control the various objects existing on a ship (e.g., wheel, sails).By manipulating these, they also share the control of the ship itself.
Pais et al.
Playable Characters refer to every entity within the environment whose actions are controlled by player input.As mentioned before, the locus of control may difer from game to game, but usually, each player controls one playable character.Playable characters are shared when their state and actions can be assumed by more than one player.This may happen in diferent ways: 1) shared representation; 2) manipulating partner's entity; 3) switching between playable characters of a shared pool.
Example: in Lego Star Wars, players can, at any time, assume control of another playable character, including that of the co-player.Space is also a resource as it defnes the various places in the environment that a player can occupy and interact with.Space is shared when its utilisation is afected or constrained by others' presence or by others' actions.
Example: in Counter-Strike, the use of weapons and explosives constrains the space for everyone, given that these also hurt teammates.
4.4.5 Asymmetry.This category describes asymmetric patterns that are leveraged to promote cooperation between players.It is split into Information, Abilities, and Usefulness.
Information , as described by Harris et al. [39], is where one player knows something other players do not.In cooperative games, this is leveraged by ensuring the information is needed to be shared, or acted upon by more than the player with access to the knowledge.This is typically instantiated with players having Distinct -Player Views and Worlds.
Example: in The Timeless Child -Prologue, two players are on diferent temporal perspectives in the same mansion and have to solve puzzles by analysing their room and communicating with their partner.Abilities , as described by Harris et al. [39]  Synergies extended from Rocha et.al [64] allow one entity to assist or change the game actions (e.g.abilities) of another player.
Example: in World of Warcraft, a Shadow Priest can cause an enemy to become vulnerable to shadow damage, which also results in an increase in the damage that Warlocks (another character type) can cause.
Complementarity , extended from Rocha et.al [64], corresponds to when player actions are designed to balance each other's weaknesses or so that strengths complement each other.It is typically achieved through asymmetric game design, with each player bringing something to the shared experience.
Example: in Gloomhaven, each character has a unique deck of abilities that enable them to control the battlefeld in diferent ways, from characters with strong areas of damage attacks, to others with crowd-control abilities.

DISCUSSING HOW TO LEVERAGE LFCG
Presenting a conceptual work in a paper structure to be published in an international conference or journal ensures it goes through a rigorous peer-review process by experts who evaluate its credibility, validity, and contribution.However, a paper structure is not a good vehicle to facilitate dissemination and use, due to its inherent limitations.The framework would be static, with no updates to its existing content or any interactive form of consumption.Prior work in game design patterns [5,10], perhaps recognising these limitations, have published their eforts in wiki 6 and other website structures 7 that can provide the fexibility needed to maximise the potential use and expandability by its stakeholders.Inspired by their work, LFCG was deployed as a web app to be easy to access and interact with; and expandable and reusable.It includes a set of features which enables stakeholders not only to use but to appropriate the framework to their own endeavours.For review, the framework is currently available8 , and will be deployed to its own domain upon acceptance.As a Living Framework, the web application is and will be under continuous development.In this paper we describe the features available upon submission.
Below, we detail 1) the interactive view to facilitate use; 2) the authoring features to support creating and sharing game reports and framework extensions; 3) discuss recommendations of use; and lastly, 4) the limitations of both LFCG and its web deployment.

Interactive Framework
The web app (see fgure 6) allows users to consult LFCG, browse published game reports, and community-created framework extensions.While consulting, it provides an interactive navigation between categories and values with a detailed view of the selected category/value with its description.The detailed view also shows a list of underlying subcategories and values, if a category is selected, or, if a value is selected, it shows examples from game reports that include it.Each game report is represented by the game title, the author of the assessment and the framework version used.This allows for users to quickly navigate between examples and categories to facilitate use.Additionally, any game report published is automatically added to the corpus of examples, and frameworks are added to the list.Anyone can use the web app to author a new game report under LFCG or a Community version of it.

Authoring Reports and Framework Extensions
Unlike past attempts at structuring game design, we are not only concerned with identifying structures, and patterns but collating examples of their applications, and enabling the larger community to contribute and beneft from it.As such, the web app enables users to author new game reports through a guided process, which includes: 1) defning the type of report (i.e., analysis or specifcation), 2) choosing a framework version (i.e., LFCG or a community authored), 3) selecting which game to report on (i.e., using IGDB 9for unique identifcation) or none if specifying a new game, 4) providing additional details (e.g., game mode), defning the analysis level (i.e., Game Analysis (Macro) or Specifc Moment (Micro)) and possible value identifcation (i.e., all values or only relevant values), and a subjective goal, 5) identifying the existing categories/values with the option of making observations (i.e., including linking URL media), 6) details of method of analysis/specifcation, difculty of assessment, and game familiarity, and lastly 7) the option to either download the report and/or publish it contributing to LFCG corpus.Each contribution to the framework asks for the author to authenticate themselves, enabling authors to claim ownership and disseminate their analyses and/or specifcations.

Recommendations for Use
Games can be composed of a simple set of behaviours (e.g.casual mobile games), or incredibly complex (e.g.MMORPG).The framework can be applied at a macro level (i.e. the whole game), or at a micro level (e.g.specifc sections, such as a boss fght in a dungeon crawler).While the framework guides users towards one of these levels of analysis, it is up to analysts to be aware of their inherent goals to use LFCG efectively.The analyst has to be aware and decide if the goal is to identify which values exist, or which values are signifcant to the experience.For example, a cooperative game might have one moment in the whole experience where each player has a unique view, while the rest is fully played through a shared view.It is up to the individual to decide the relevance of it to the analysis.We recommend specifying only signifcant values when evaluating experiences and specifying all values and their signifcance when the goal is to identify less impactful design choices (e.g. using LFCG reports as evolving design documents to identify potential cuts).
Similarly, the framework can be used as a tool for design, providing a language by which stakeholders can communicate the requirements of the experience.For game designers and developers, this may provide a way to specify requirements of a particular section of the game or defne at a macro level the intended experience to be created.It can also be leveraged to promote ideation by prompting designers to critically refect on how their designs ft or not the dimensions described or how they could include new features to elicit specifc behaviours.With the continuous use of LFCG it will build a compendium of reports from which designers/learners can go from concept to how it is realized in practice across games and genres.
Additionally, for game researchers, it can provide a way to rigorously describe custom-designed prototypes, defning clear design variables (e.g.variations of Player View Point), while controlling covariables that arise from the creative process of developing games.Thus contributing to addressing reproducibility issues [35], that arise from a lack of common design specifcations.Furthermore, it creates a structure by which new study designs can be formulated to explore relevant play structures, behaviours and cooperation patterns, by outlining the dimensions and possible values within cooperative games.Lastly, it enables the cross-comparison of studies and prototypes.By systematically defning the concepts and capturing the space of design possibilities, future research is equipped with the means to understand better the efect of specifc implementations of cooperative play on the player experience.
To summarise, we recommend that, when using the framework, one clearly defnes the goal, the level of analysis, the signifcance level for the identifed values and the purpose of the game report (i.e.analysis or specifcation).

Limitations
Despite our attempt to make the framework based on objective descriptions, categories, values and patterns, there is an expected degree of subjectivity when using LFCG.As previously mentioned, it is upon the user of the framework to decide the goal and level of analysis, which will inevitably lead to subjective decisions about what to consider relevant.Furthermore, there is an inherent degree of complexity and detail of the framework which inevitably afects usability in practice.To counteract it, we publish the framework as a web app to facilitate use, but further work with end-users is needed.Still, we believe its current interactive use and fexibility to create custom framework versions (i.e.including simplifed versions) is a valuable attribute to guarantee it is useful and adapts to each stakeholder's necessities.
As our sample only included 129 games, it is not possible to say the framework describes a set of cooperation design patterns that is comprehensive and are instead expected to be expanded upon.Many of its categories and defnitions are broad enough that they can result in many diferent implementations of the same pattern with potentially diferent efects.While this facilitates encompassing and fnding similarities across games, we also risk generalising concepts that cannot be generalised.We expect that these values can be further specifed into particular implementations.
The framework is a frst attempt at a systematic approach to decomposing cooperative games, their patterns and mechanics.The framework treats games as artefacts that can be analysed as a whole or as a segment in time (e.g.boss encounter).However, the time construct is not considered in any dimension or design pattern.Games are categorised as having or not the dimension at a moment, and no information is captured regarding the relationship between patterns across time.We believe this to be an open challenge of how one captures the experience of play across time.
While extending and using new versions of LFCG is possible, the community cannot discuss, question or give any feedback about existing categories or values.For an ever-evolving framework that the community appropriates, we believe it has to provide a space for all to discuss.As such, one of the next planned steps of development, as part of a larger project, will be to create a discussion thread associated with each category and value for feedback, provide new feedback, clarifcations and discussions.
In games, language has most often been derived from gamers, designers and journalists [40,49], and not through any systematic approaches.Clear examples are how game genres and mechanics are ill-defned, with various abstraction levels (e.g.horror game, real-time game) which result in inevitable issues at any attempts to synthesise and systematise knowledge.We consciously chose to create the framework with a research-driven approach and analyse games to propose LFCG.Still, the number of games on the market makes conducting a full systematic review virtually impossible.We relied on prior work for our frst codebook, and through the analyses by multiple researchers, we slowly structured the LFCG presented in this paper.This enabled us to rigorously defne the core constructs of the framework and their values.However, there are inherent limitations to a research-driven approach, namely its ability to be appropriated and used by the larger community, its scalability and the struggles to stay contemporary.As such, we argue that for a framework to be successful it should start with a research-driven conceptualisation, followed by a deployment that supports and calls upon the larger community, thus shifting to a community-based approach.We believe the methodology presented can become a canvas for future eforts in systematising game design.

OUTLOOK AND REFLECTIONS
In this paper, we present the Living Framework for Cooperative Games, the process taken for its current iteration based on prior work, the analysis of 129 cooperative games and the contributions of eleven researchers.We outlined how we envision LFCG to be useful as a shared language to ideate, analyse and discuss cooperative games, and our eforts to create a tool that accommodate the community's evolving needs.In this section, we refect on possible avenues to study the efects of design choices and the pursuit towards modelling and consolidating game research knowledge.
With LFCG, we believe it is possible to defne and control game design variables and account for covariates, allowing us to design studies that explore complex design choices (e.g.Arrangement of the Forms of Cooperation).Past work has made signifcant eforts in understanding the impact of selected game design choices such as loot boxes [25] or balancing mechanics [36].We argue that we should commit equal eforts in the pursuit of understanding other design decisions that can instead have positive outcomes.Cooperative games and their structures are great candidates to explore efects on well-being and social relationships (e.g., how to design games to promote relationship maintenance behaviours [17], or increase in connectedness [38].We are committed to identify not previously explored, promising categories and understand their role in shaping cooperative experiences particularly in regards to player enjoyment, autonomy and connectedness.While LFCG is now a living framework of categories with no efects on the experience, one of the next steps will be to allow researchers to submit/link works to not only provide clear examples of when categories happen, but also what can research tells us about their specifc potential efects.
Hence, we are aiming in future work to move beyond a repository of features and categories, to an encompassing platform that provides game research insights to all.
In addition to proposing a shared language, we recognise that games are ever-evolving, and any attempts at creating a structure to model, describe and consolidate any type of game is destined to become deprecated as soon as it is created.As such, LFCG is built with the core principle of becoming a living framework expected to be continually updated and expanded by any stakeholder.While LFCG was constructed based on cooperative games alone, many of its structures can be equally applied to other game types, and future work could beneft from frst departing from LFCG in its eforts to formalise game structures and create a shared language.
We believe that only by creating useful tools for researchers and designers, can we expect any engagement.We believe that the consolidation of game design knowledge is beyond the reach of any individual research team.Only by creating the structures for the larger community to appropriate and contribute can we progress in our quest for developing theories and evidence about the efects of game design decisions.

Figure 1 :
Figure 1: Overview of our methodology

( 2 )
Read the top-level review (if available, flter minimum playtime 1h); (3) See Trailer/s (in-store if available, if not YouTube); (4) Watch the most Relevant video review on YouTube ("<game name> review") (5) Watch the most relevant video playthrough on YouTube ("<game name> playthrough (coop)") -watch at least 20 minutes, excluding skips, and skim full video).If the playthrough is a playlist, skip to the second video; If not, and If the playthrough is over one hour, skip the frst hour.The skips were made to ensure we skipped tutorials and frst interactions with the game when possible.In games with multiple modes of play, it was necessary to add "coop" to the Youtube playthrough search

Figure 2 :
Figure 2: Overview of the frst category captured in LFCG: Play Structure

Figure 3 :
Figure 3: Overview of the second category captured in LFCG: Player Context

Figure 4 :
Figure 4: Overview of the third category captured in LFCG: Forms of Cooperation

4. 3 . 3
Communication.The Communication category is further divided into Communication Expected By Design and Means of Communication.The frst covers how the game is designed in relation to communication between players, and the second describes the communication tools and mechanics employed by the game to facilitate it.
Communication can be further divided into the types the game implements: Voice Chat, Text Chat, Pings, Pins (i.e.typically in maps), Drawings, In-Game Movement/Actions (e.g.shooting a weapon on the ground to notify others to pick it up), Voice Lines and Premade Messages and Emotes.In Virtual Reality games, the afordances provided by mainstream head-mounted displays and their controls add others, such as Body Posture and Hand Tracking which can be leveraged to express oneself.

Figure 5 :
Figure 5: Overview of the last category captured in LFCG: Cooperation Design Patterns

Figure 6 :
Figure 6: Screenshot of the web app

Table 1 :
Overview of the top-level categories of LFCG 4.1 Play Structure Play Structure (fgure 2) groups the categories which defne the overarching structures of play.It encompasses the progression of the game, group formation, and goal structure.
can have multiple types of progression.Drop-in/Drop-out encompasses games where there is the ability for players to join in the midst of the gameplay and drop out at any point.
[28]unity progression is defned by the joint eforts of players in a larger community (e.g.guilds, factions, or even an entire player base) that, while not necessarily playing together, can contribute to typically shared consequences.Example:In Destiny 2[13], when a new raid is complete for the frst time by any player, the entire community unlocks new content.Server progression is defned by the existence of persistent mutable worlds that a number of players share.The action of players (i.e.cooperating or not) can impact the overall progression/evolution of the game world, afecting others.Individual progression is defned by individual choice and the individual impact of the progression.In-game activities can vary from individual to fully cooperative but progression afects the individual.4.1.2GroupFormation.The Group formation category describes the type of strategies and mechanisms the game ofers for players to join others before, during, and after gameplay, and takes inspiration from the design patterns proposed in Bjork et al. [9] associated with groupings (e.g., Dynamic alliances).These include Serendipitous formation, Party creation, Drop-in/Drop-Out, Looking for Group, and Organised Grouping, and may be available co-located or online.Games can have multiple mechanisms of group formation.Serendipitous formation happens in games where groups are not defned structures, and the gameplay itself (typically proximity) is used to group players.Example: In World of Warcraft[23], while the player is exploring the world, anytime they are in proximity with other players, they can take down enemies together with both benefting without formally creating a group.Party Creation encompasses all games where groups are defned by the players themselves prior to initiating gameplay, typically leveraging friend lists or co-located party creation.Example:In Fortnite[28], players can create a friends list within the game and invite their friends to join their party for multiplayer matches.Two players co-located can also join together.Example: In Rec Room [43] players queue up for certain game experiences and join another group of players before embarking, for example, in a cooperative dungeon crawling experience.Organised Grouping covers all features that establish groups or communities (e.g.guilds) within games, which typically Player Context (fgure 3) groups the categories that shape how individual players engage with the gameplay, and includes Player Identity, Relationships between Player Entities, World View, and Player View.Representation This category divides representation into a combination of two values: either single or dispersed, and either distinct or shared.Alternatively, players might have no representation in the gameplay.Single applies to any game where players have control of one single entity.
4.2.1 Player Identity.The Player Identity describes how the player is represented (i.e., player entity) and expressed within the game, as well as their ability to select and/or customise.Entities can be avatar-based (e.g.World of Warcraft), complex structures/groupings (e.g.nations in Age of Empires), or have no avatar representation at all.While a player entity may be expressed through a unique Identity in terms of appearance, play style, or both, this framework captures only Player Identities with gameplay consequences.It also details how an entity is Selected (Arbitrary, Pool, or Customisation) and how it Progresses throughout the gameplay (Static, Predefned, Customisable, or Switchable).A game may have more than one type of player identity.
Relations between Player Actions.This category describes the type of in-game actions in relation to the other players.