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.
1 Introduction
Playing with others has the benefit 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 efforts in formalising cooperative games. We argue that to analyse, ideate, and consolidate knowledge about these games and their effects, there is a need for a shared language to describe the structures of cooperative games.1
Previous efforts 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 efforts 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 reflecting on how LFCG can be a shared language to study the effects 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 efforts.
This paper contributes with a framework by which to define and understand the structures in cooperative games, including an interactive web deployment to support its use.
2 Related Work
In this section, we discuss 1) formal structures; and 2) the understanding of cooperative behaviours in digital games.
2.1 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 fictional, imagine world” [51]. Quoting Hunicke et al. [42], in their foundational paper, the researchers highlighted how we can “analyse the end result to refine implementation and analyse the implementation to refine the result”. Without a rigorous definition 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 affected by context and the player. Still, pre-determining the most likely experience and effect will make our design choices more purposeful.
Games can offer a diverse array of experiences, but not all games impact the player in the same way. Different 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 affect 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 classification 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.1 Design Patterns 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 difficult to distinguish. This is seen throughout the literature as patterns and mechanics are defined in many different ways [67], often overlapping.
Game patterns were first 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 fields [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 differ in scope and point of view, the first 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 different 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.
2.2 Understanding Cooperative Behaviours in Digital Games
Prior work on cooperative games looked into identifying and exploring how specific design choices and mechanics (e.g. asymmetry, interdependence, communication) affect social outcomes (e.g. connectedness) [17], performance and engagement [8]. Other approaches have focused on examining behaviours that unfold in specific 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 identified a set of cooperative mechanics) and was informed by game design patterns research [9, 10, 40] including cooperative patterns within board games [86]. Specifically, the work by El-Nasr et al. [66] analysed 14 games to identify and model specific 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 reflective communication) and analysing verbal communication.
All prior approaches sought to identify commonalities and patterns across games, pre-define structures to guide design and development, study the effects of cooperative games and their mechanics, or provide a common language to support game designers.
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 specifically focused on characterising cooperative play. The review highlighted how research has been scattered across dimensions, making it difficult 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 field, 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 field, going beyond case studies and also providing comprehensive design frameworks.
3 Methodology: Understanding Cooperative Games
Figure 1:
Figure 1: Overview of our methodology
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 figure 1. We first 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) define coding template; 5) apply to further data and iterate; 6) and produce the final template [12]. We adapted the final 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 first iteration, that was later reviewed by another senior researcher. We describe this last step in the section Validation & Review, followed by the resulting framework.
3.1 Search Strategy
We sought to create a pool of games that were 1) highly rated, 2) included games of the last five 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 first 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 specific 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 filtered 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 filters) and all which were already selected from Metacritic. This led to a diverse pool of 118 games3, 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 Offensive), and others with multiple play modes (e.g. Age of Empires).
3.2 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.
3.3 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);
(2)
Read the top-level review (if available, filter 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 first hour. The skips were made to ensure we skipped tutorials and first interactions with the game when possible. In games with multiple modes of play, it was necessary to add "coop" to the Youtube playthrough search
Coders had to fill out a review template for each game assessed, described in the following section.
3.4 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 flexibility 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 defined, it is applied to the data, iterating as much as necessary. Finally, it recognises that a template is never truly “final”, and further engagement with meaningful data might extend the template.
The first 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 identified 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 classification.
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 fields for generic game information (e.g. play description, multiplayer modes), all the pre-identified codes from related work, each with a field 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.
Table 1:
Category
Summary
Subcategories
Play Structures
The overarching structures of play
Progression Structure, Group Formation, Goal Structure
Player Context
How players engage with the gameplay
Player Identity, Relationships Between Player Entities, Game World, Player Viewpoint
Forms of Cooperation
How games support player cooperation
Arrangement, Synchronicity, Communication
Cooperation Design Patterns
How games promote cooperation
Dependencies, Affecting Others, Resource Sharing, Asymmetry, Relations Between Player Actions
Table 1: Overview of the top-level categories of LFCG
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, first in a round where each coder analysed a set of 10 different games, meeting, and further refining 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 define and understand cooperative games, seeking to guarantee that the resulting structure accommodated all the identified patterns and relevant features. During the sessions, one researcher acted as a moderator, using the whiteboard to focus the discussion on specific groupings, defining 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 affect collaboration by design? Is there an overlap with a previous category or value? Can we define it objectively? How is it defined, 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 first 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.
3.5 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 first 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 different games assessed in this work4. This phase allowed the team to reflect on how the framework accommodates the different 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 fields 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” field to support identifying new values. Lastly, the form had two additional questions about the difficulty 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 clarification. The third researcher, with over 10 years of experience in the field, 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 in-impromptu meetings throughout two months, leading to the framework detailed below.
4 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 different forms of cooperation; and Cooperation Design Patterns, capturing specific 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 simplified 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 different stages of the experience.
4.1 Play Structure
Play Structure (figure 2) groups the categories which define the overarching structures of play. It encompasses the progression of the game, group formation, and goal structure.
Figure 2:
Figure 2: Overview of the first category captured in LFCG: Play Structure
4.1.1 Progression structure.
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 effects. Games can have multiple types of progression.
Community
progression is defined by the joint efforts 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 first time by any player, the entire community unlocks new content.
Server
progression is defined 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, affecting others.
Example: In Valheim [70], after each type of boss is killed, every player who is part of the server gains access to a new passive power. Moreover, every time a player builds something in the world, it instantly becomes accessible to others.
Party
progression results from the contributions of a group of players that opted to play together, where part of the progress is solely associated with that group (not shared with the rest of the server or community).
Example: In Overcooked 2 [29], players are a group of chefs that travel from kitchen to kitchen together, facing the new challenges of the level. New levels unlock for the group to tackle together depending on past success.
Individual
progression is defined by individual choice and the individual impact of the progression. In-game activities can vary from individual to fully cooperative but progression affects the individual.
Example: In Gunfire Reborn [27], players unlock achievements, weapons, and modifiers individually, and after each play session the individual accumulated points are spent however a player wants to progress their overall class and abilities. This progression bears no impact on the other players’ experience other than a stronger teammate if they play together again.
4.1.2 Group Formation.
The Group formation category describes the type of strategies and mechanisms the game offers 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 defined 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 benefiting without formally creating a group.
Party Creation
encompasses all games where groups are defined 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.
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.
Example: In Brothers: A Tale of Two Sons [75], each brother is controlled by half of the controller, and players have to complete puzzles coordinating actions. If a new player joins, each player starts to control a single brother.
Looking for Group
happens when there are grouping mechanisms that allow players to formally look for and create a group/party. This is typically achieved through matchmaking or looking for group queues.
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 persist across different gaming sessions and may have defined roles and/or hierarchy.
Example: In Squad [46], each team is composed of squads. Each squad has a leader that has abilities to organize squad members. One of the squads can also be responsible for organising the team.
4.1.3 Goal 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 specific 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 Conflicting, 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 different 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.
Conflicting
goals are also observable in some cooperative games, where typically, players compete in certain sections that do not affect the overarching goal of the game. While no semi-cooperative games were observed, in these types of games, conflicting goals can also be mixed with shared goals.
Example: In A Way Out [72], players encounter various mini-games where they try to outperform each other (e.g., playing darts).
Independent
goals define individual goals that do not directly interact with other players, typically different 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.
4.2 Player Context
Player Context (figure 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.
Figure 3:
Figure 3: Overview of the second category captured in LFCG: Player Context
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, Predefined, Customisable, or Switchable). A game may have more than one type of player identity.
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.
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.
Example: In Age of Empires IV [77], players control armies of multiple soldiers.
Distinct
means that each player controls a different entity or set of entities (Distinct Locus of Manipulation [76]).
Example: In Rayman Legends [57], each player has full control of their character
Shared
applies when input from multiple players directly translates to the actions of one playable entity. It is informed by the constructs "Shared Characters" [66] and "Mutual Locus of Manipulation" [76].
Example: In Octodad [41], players control the main character’s limbs, each working a set or a single limb.
No representation
refers to games where players do not have control of an actual entity within the game.
Example: In Keep Talking and Nobody Explodes [32], some players are responsible for interpreting, working with a written manual and relaying information without any sort of representation.
Selection
This category divides Selection of Player Identity into one of three values: Arbitrary, Pool of characters and Customisation
Arbitrary
means that, if a selection exists, it is merely an aesthetic choice; All player entities are equal in their ability to act upon the world.
Example: In Unravel Two [48], players start with one of the two characters (only distinguishable by their colour), based on the assigned player number (first or second player).
Pool
describes when players are given an array of playable entities to choose from (e.g. characters, nations, class). These have predefined 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 benefit different play styles, by giving players buffs (e.g. melee damage) and incentivising specialisation in one of the different available classes.
Progress
While selection describes how the entity first 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.
Predefined
describes when progress is strictly linear, with no player choice (e.g., dictated by the storyline, predefined upgrades or progressing through switching entities).
Example: in Trine [26], the characters unlock new mechanics at defined 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 defines 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 different characters from level to level and can switch between a pool of characters during the actual level.
4.2.2 Relationships between Player Entities.
Relationships between Player Entities capture the types of connections that exist and are formed between players’ entities within the game. It is divided into: individuals, sidekicks, teammates, allies and competitors. A game can have multiple player entities’ relationship types as well as the transition between them during play.
Individuals
describes when players’ entities have no relationship with each other, which affects gameplay.
Example: In Portal 2 [81], players are two distinct individuals that cooperate to complete the levels.
Sidekick,
a second (or third, etc) player, will take the role of a different entity with typically a subset or complementary skills anchored on the main entity of the game attributed to the first player.
Example: In Child of Light [58] the first player plays as the protagonist Aurora in turn-based RPG combat, and the second plays as the floating orb, which can debuff enemies, light pathways and other smaller tasks.
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 finish 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).
4.2.3 Game World.
The Game World category extends the "Asymmetry of Interface" construct proposed by Harris et al. [39] and details if players share the same game world or not (Distinct) and if so, if they have the same representation of it (Shared), or if that representation is unique (Unique). A game may have more than one type of game world.
Shared
world views apply to a game when players have access to the same world.
Example: in Overcooked 2 [29], all players share the same world and level, and co-exist in a singular game instance.
Unique
world views correspond to the players having access to the same world but having unique perspectives on it (e.g. the different fog of war across teammates is a simple instance of a unique world view).
Example: Savage 2: A Tortured Soul [30], one player has an overhead view of the world while others play in first person.
Distinct
world views correspond to the players having access to entirely different worlds, and thus different perspectives and instances of them.
Example: in Keep Talking and Nobody Explodes [32], players have completely different views and interfaces as one player has access to the bomb and is able to manoeuvre and inspect it, while the other only has access to a physical or digital bomb manual.
4.2.4 Player Viewpoint.
The Player Viewpoint category describes the view each player has (i.e. how they perceive the game environment) and their control over it. It has three values, inspired by similar denominations in related work [66]: Shared, Split and Distinct. While we use the term view and examples where the differences between players are exemplified visually, it is equally possible to have differences between players by changing audio and haptic feedback of the world. A game may have more than one type of player viewpoint, and at times it can be mixed (e.g. distinct camera view, but HUD with same world information).
Shared
is when both players share a single viewpoint. Typically, this happens when players are co-located. All Shared Player Views are, by definition, in Shared Game Worlds.
Example: in Rayman Legends [57], players share the same screen, which affects 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 different game areas from the perspective of the other player. Similarly, this usually happens in co-located experiences with a single physical screen.
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.
4.3 Forms of Cooperation
Figure 4:
Figure 4: Overview of the third category captured in LFCG: Forms of Cooperation
Players can cooperate in different 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 figure 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 fluidly transition between different arrangements and synchronicity, with interactions across the whole spectrum (e.g. complex MMO Boss fights).
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 specific 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.
Coupled cooperation,
players take on different tasks that somehow intertwine and typically contribute to a shared outcome.
Example: in Sea of Thieves [61], navigating the ship requires coordination with the gunner to align the shots.
Coincident cooperation,
players are accomplishing the same task together.
Example: in Cuphead [44], players take on the same task, which is to shoot the enemy boss, until it is defeated.
4.3.2 Synchronicity.
Synchronicity describes how in-game actions are done in relation to other players with respect to time, and it varies between sequential, concurrent, and asynchronous. 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 different 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 different 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]).
4.3.3 Communication.
The Communication category is further divided into Communication Expected By Design and Means of Communication. The first 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 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 specific 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 specific 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 effect).
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.
Means of Communication
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 affordances 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.
4.4 Cooperation Design Patterns
Cooperative games employ a variety of patterns and game mechanics that promote cooperative behaviours by their players. In this grouping (figure 5), we identify what dimensions from the previous sections we construed as conducive to cooperation5. The following list is not a comprehensive list of patterns, but a first 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 identified. 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.
Figure 5:
Figure 5: Overview of the last category captured in LFCG: Cooperation Design Patterns
4.4.1 Play Structure & Player Context.
The game structure can be designed in a way that promotes cooperation. Of the structures defined, we consider a sub-set conducive to cooperative play. While these play structures do not enforce cooperation, nor do others prevent it, their implementations are typically aligned to do so.
Cooperative Play Structures: Progression [Community, Server, Group], Group Formation, Goal [Shared, Intertwined].
Cooperative Player Contexts: Identity [Shared], Entities Relationships [Sidekick, Teammates, Allies], Player View [Shared View]
4.4.2 Dependencies.
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 Difficulty, and Scaling Difficulty
Task
refers to gameplay tasks where at least one player is dependent on another. These can force players to coordinate to be effective 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 affect both players. For example, ensuring action concurrencies or timing.
Example: in Portal 2, both players need to be press two different buttons at almost the same time to complete some of the puzzles.
Fixed Difficulty,
when games purposefully do not adapt the difficulty 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 difficulty to do it in. The easier difficulties are solo-able for the average player. However, as the difficulty 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 Difficulty,
most games that support a varied player count adapt the difficulty 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.
4.4.3 Affecting 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 affect others unidirectionally. All of them, depending on the context and implementation, can be altruistic (i.e. without any benefit to the player) or non-altruistic (i.e. with direct or indirect benefits). 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 benefit of other/s (i.e. note that the player can have indirect benefits 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 specific 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 specific mechanic, where one player’s performance can be leveraged for others to bypass challenges. This mechanic was identified 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 affect and/or interact with each other, incentivising them to collectively negotiate how to manage and utilise them. We distinguish between five 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 effect (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 effect of the unlockables may or may not be shared (it might affect 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 affect 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 modified as an interactable, but also consumed to complete the recipes). Interactables are shared when their state and attributes can be affected 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.
Playable Characters
refer to every entity within the environment whose actions are controlled by player input. As mentioned before, the locus of control may differ 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 different 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 defines the various places in the environment that a player can occupy and interact with. Space is shared when its utilisation is affected 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 different 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] are where one player can do things another player cannot. In games where these actions synergise or are complementary, it allows for cooperation.
Example: in Magicka, players can cross their magical beams together to form new, more powerful spell effects.
Usefulness
happens when a certain resource or information (shared among multiple players) is more valuable to one of those players. It can promote cooperation and coordination to maximise player performance/enjoyment.
Example: in Borderlands, loot of any kind can drop for your characters. However, some item effects only apply to certain classes, and if it is of one of your teammates, it can create an incentive for you to share.
4.4.6 Relations between Player Actions.
This category describes the type of in-game actions in relation to the other players.
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 battlefield in different ways, from characters with strong areas of damage attacks, to others with crowd-control abilities.
5 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 efforts in wiki6 and other website structures7 that can provide the flexibility 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.
Figure 6:
Figure 6: Screenshot of the web app
5.1 Interactive Framework
The web app (see figure 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.
5.2 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 benefit from it. As such, the web app enables users to author new game reports through a guided process, which includes: 1) defining the type of report (i.e., analysis or specification), 2) choosing a framework version (i.e., LFCG or a community authored), 3) selecting which game to report on (i.e., using IGDB9 for unique identification) or none if specifying a new game, 4) providing additional details (e.g., game mode), defining the analysis level (i.e., Game Analysis (Macro) or Specific Moment (Micro)) and possible value identification (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/specification, difficulty 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 specifications.
5.3 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. specific sections, such as a boss fight 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 effectively. The analyst has to be aware and decide if the goal is to identify which values exist, or which values are significant 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 significant values when evaluating experiences and specifying all values and their significance 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 define at a macro level the intended experience to be created. It can also be leveraged to promote ideation by prompting designers to critically reflect on how their designs fit or not the dimensions described or how they could include new features to elicit specific 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, defining clear design variables (e.g. variations of Player View Point), while controlling co-variables that arise from the creative process of developing games. Thus contributing to addressing reproducibility issues [35], that arise from a lack of common design specifications. 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 defining the concepts and capturing the space of design possibilities, future research is equipped with the means to understand better the effect of specific implementations of cooperative play on the player experience.
To summarise, we recommend that, when using the framework, one clearly defines the goal, the level of analysis, the significance level for the identified values and the purpose of the game report (i.e. analysis or specification).
5.4 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 affects 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 flexibility to create custom framework versions (i.e. including simplified 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 definitions are broad enough that they can result in many different implementations of the same pattern with potentially different effects. While this facilitates encompassing and finding similarities across games, we also risk generalising concepts that cannot be generalised. We expect that these values can be further specified into particular implementations.
The framework is a first 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, clarifications 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-defined, 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 first codebook, and through the analyses by multiple researchers, we slowly structured the LFCG presented in this paper. This enabled us to rigorously define 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 efforts in systematising game design.
6 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 efforts to create a tool that accommodate the community’s evolving needs. In this section, we reflect on possible avenues to study the effects of design choices and the pursuit towards modelling and consolidating game research knowledge.
With LFCG, we believe it is possible to define 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 significant efforts 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 efforts in the pursuit of understanding other design decisions that can instead have positive outcomes. Cooperative games and their structures are great candidates to explore effects 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 effects 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 specific potential effects. 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 benefit from first departing from LFCG in its efforts 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 effects of game design decisions.
In this paper, we use “cooperation” and “collaboration” interchangeably for the same meaning: working along with someone else where the outcomes of their actions are aligned.
Espen J. Aarseth, Solveig Marie Smedstad, and Lise Sunnanå. 2003. A multi-dimensional typology of games. In DiGRA ’03 - Proceedings of the 2003 DiGRA International Conference: Level Up. Digital Games Research Association (DiGRA), Netherlands, 48–53.
Sultan A. Alharthi, Olaa Alsaedi, Zachary O. Toups, Theresa Jean Tanenbaum, and Jessica Hammer. 2018. Playing to Wait: A Taxonomy of Idle Games. In Proceedings of the 2018 CHI Conference on Human Factors in Computing Systems (Montreal QC, Canada) (CHI ’18). Association for Computing Machinery, New York, NY, USA, 1–15. https://doi.org/10.1145/3173574.3174195
Jakob Bardram. 1998. Collaboration, Coordination and Computer Support: An Activity Theoretical Approach to the Design of Computer Supported Cooperative Work. Ph.D. Thesis. Ph. D. Dissertation. Aarhus University. https://doi.org/10.7146/dpb.v27i533.7062
Gökçe Elif Baykal, Eva Eriksson, and Olof Torgersson. 2023. Collaboration in Co-Located Collaborative Digital Games - Towards a Quadripartite Taxonomy. In Extended Abstracts of the 2023 CHI Conference on Human Factors in Computing Systems (Hamburg, Germany) (CHI EA ’23). Association for Computing Machinery, New York, NY, USA, Article 72, 6 pages. https://doi.org/10.1145/3544549.3585760
Anastasiia Beznosyk, Peter Quax, Karin Coninx, and Wim Lamotte. 2012. The Influence of Cooperative Game Design Patterns for Remote Play on Player Experience. In Proceedings of the 10th Asia Pacific Conference on Computer Human Interaction (Matsue-city, Shimane, Japan) (APCHI ’12). Association for Computing Machinery, New York, NY, USA, 11–20. https://doi.org/10.1145/2350046.2350051
Staffan Björk and Jussi Holopainen. 2005. Games and design patterns. In The game design reader: A rules of play anthology. MIT press Cambridge, MA, England, 410–437.
Virginia Braun and Victoria Clarke. 2023. Toward good practice in thematic analysis: Avoiding common problems and be(com)ing a knowing researcher. International Journal of Transgender Health 24, 1 (2023), 1–6. https://doi.org/10.1080/26895269.2022.2129597 arXiv:https://doi.org/10.1080/26895269.2022.2129597
Joanna Brooks, Serena McCluskey, Emma Turley, and Nigel King. 2015. The Utility of Template Analysis in Qualitative Psychology Research. Qualitative Research in Psychology 12, 2 (2015), 202–222. https://doi.org/10.1080/14780887.2014.955224 arXiv:https://doi.org/10.1080/14780887.2014.955224PMID: 27499705.
Mark G. Chen. 2009. Communication, Coordination, and Camaraderie in World of Warcraft. Games and Culture 4, 1 (2009), 47–73. https://doi.org/10.1177/1555412008325478 arXiv:https://doi.org/10.1177/1555412008325478
Teresa De la Hera, Eugène Loos, Monique Simons, and Joleen Blom. 2017. Benefits and Factors Influencing the Design of Intergenerational Digital Games: A Systematic Literature Review. Societies 7, 3 (Sept. 2017), 18. https://doi.org/10.3390/soc7030018
Ansgar E. Depping and Regan L. Mandryk. 2017. Cooperation and Interdependence: How Multiplayer Games Increase Social Closeness. In Proceedings of the Annual Symposium on Computer-Human Interaction in Play (Amsterdam, The Netherlands) (CHI PLAY ’17). Association for Computing Machinery, New York, NY, USA, 449–461. https://doi.org/10.1145/3116595.3116639
Ansgar E. Depping, Regan L. Mandryk, Colby Johanson, Jason T. Bowey, and Shelby C. Thomson. 2016. Trust Me: Social Games Are Better than Social Icebreakers at Building Trust. In Proceedings of the 2016 Annual Symposium on Computer-Human Interaction in Play. ACM, Austin Texas USA, 116–129. https://doi.org/10.1145/2967934.2968097
Igor Dolgov, William J. Graves, Matthew R. Nearents, Jeremy D. Schwark, and C. Brooks Volkman. 2014. Effects of Cooperative Gaming and Avatar Customization on Subsequent Spontaneous Helping Behavior. Computers in Human Behavior 33 (April 2014), 49–55. https://doi.org/10.1016/j.chb.2013.12.028
Nicolas Ducheneaut and Robert J. Moore. 2004. The Social Side of Gaming: A Study of Interaction Patterns in a Massively Multiplayer Online Game. In Proceedings of the 2004 ACM Conference on Computer Supported Cooperative Work (Chicago, Illinois, USA) (CSCW ’04). Association for Computing Machinery, New York, NY, USA, 360–369. https://doi.org/10.1145/1031607.1031667
Lina Eklund. 2013. Family and Games: Digital Game Playing in the Social Context of the Family. In Multiplayer: The Social Aspects of Digital Gaming. Routledge, USA, 162–171.
Christian Elverdam and Espen Aarseth. 2007. Game classification and game design: Construction through critical analysis. Games and culture 2, 1 (2007), 3–22.
Julian Frommel and Regan L. Mandryk. 2022. Daily Quests or Daily Pests? The Benefits and Pitfalls of Engagement Rewards in Games. Proc. ACM Hum.-Comput. Interact. 6, CHI PLAY, Article 226 (oct 2022), 23 pages. https://doi.org/10.1145/3549489
TT Games. 2022. LEGO® Star Wars™: The Skywalker Saga. Digital game [Windows]. https://www.lego.com/en-gb/kids/games/star-wars/skywalker-saga-90e9ff128edb48d3a936b6bfcb9ac0e4
Kathrin Gerling and Max V. Birk. 2022. Reflections on Rigor and Reproducibility: Moving Toward a Community Standard for the Description of Artifacts in Experimental Games Research. In Extended Abstracts of the 2022 Annual Symposium on Computer-Human Interaction in Play (Bremen, Germany) (CHI PLAY ’22). Association for Computing Machinery, New York, NY, USA, 266–267. https://doi.org/10.1145/3505270.3558360
Kathrin Maria Gerling, Matthew Miller, Regan L. Mandryk, Max Valentin Birk, and Jan David Smeddinck. 2014. Effects of Balancing for Physical Abilities on Player Performance, Experience and Self-Esteem in Exergames. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Toronto, Ontario, Canada) (CHI ’14). Association for Computing Machinery, New York, NY, USA, 2201–2210. https://doi.org/10.1145/2556288.2556963
David Gonçalves, Pedro Pais, Kathrin Gerling, Tiago Guerreiro, and André Rodrigues. 2023. Social gaming: A systematic review. Computers in Human Behavior 147 (2023), 107851. https://doi.org/10.1016/j.chb.2023.107851
John Harris and Mark Hancock. 2019. To Asymmetry and Beyond!: Improving Social Connectedness by Increasing Designed Interdependence in Cooperative Play. In Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems - CHI ’19. ACM Press, Glasgow, Scotland Uk, 1–12. https://doi.org/10.1145/3290605.3300239
John Harris, Mark Hancock, and Stacey D. Scott. 2016. Leveraging Asymmetries in Multiplayer Games: Investigating Design Elements of Interdependent Play. In Proceedings of the 2016 Annual Symposium on Computer-Human Interaction in Play (Austin, Texas, USA) (CHI PLAY ’16). Association for Computing Machinery, New York, NY, USA, 350–361. https://doi.org/10.1145/2967934.2968113
Jussi Holopainen and Staffan Björk. 2003. Game Design Patterns. In DiGRA ’03 - Proceedings of the 2003 DiGRA International Conference: Level Up, Vol. 2. Digital Games Research Association (DiGRA), Netherlands, 181–193. http://www.digra.org/wp-content/uploads/digital-library/05163.15303.pdf
Robin Hunicke, Marc Leblanc, and Robert Zubek. 2004. MDA: A Formal Approach to Game Design and Game Research. AAAI Workshop - Technical Report 1 (01 2004).
Studio MDHR Entertainment Inc.2017. Mario + Rabbids Kingdom Battle. Digital game [Nintendo Switch]. https://www.nintendo.com/store/products/mario-plus-rabbids-kingdom-battle-switch/
Aki Sakari Järvinen. 2009. Games without Frontiers.: Theories and Methods for Game Studies and Design. Number 701 in Acta Electronica Universitatis Tamperensis. Tampereen Yliopisto, Finland.
Mark Keith, Greg Anderson, James Gaskin, and Douglas L. Dean. 2018. Team Video Gaming for Team Building: Effects on Team Performance. AIS Transactions on Human-Computer Interaction 10, 4 (Dec. 2018), 205–231. https://doi.org/10.17705/1thci.00110
Ian J. Livingston, Lennart E. Nacke, and Regan L. Mandryk. 2011. The Impact of Negative Game Reviews and User Comments on Player Experience. In Proceedings of the 2011 ACM SIGGRAPH Symposium on Video Games (Vancouver, British Columbia, Canada) (Sandbox ’11). Association for Computing Machinery, New York, NY, USA, 25–29. https://doi.org/10.1145/2018556.2018561
Olsson Carl Magnus, Bjork Staffan, and Dahlskog Steve. 2014. The Conceptual Relationship Model: Understanding Patterns and Mechanics in Game Design. In DiGRA ’14 - Proceedings of the 2014 DiGRA International Conference. Digital Games Research Association (DiGRA), USA, 1–16. http://www.digra.org/wp-content/uploads/digital-library/digra2014_submission_93.pdf
Bonnie Nardi and Justin Harris. 2006. Strangers and Friends: Collaborative Play in World of Warcraft. In Proceedings of the 2006 20th Anniversary Conference on Computer Supported Cooperative Work (Banff, Alberta, Canada) (CSCW ’06). Association for Computing Machinery, New York, NY, USA, 149–158. https://doi.org/10.1145/1180875.1180898
Sanela Osmanovic and Loretta Pecchioni. 2016. Beyond Entertainment: Motivations and Outcomes of Video Game Playing by Older Adults and Their Younger Family Members. Games and Culture 11, 1-2 (Jan. 2016), 130–149. https://doi.org/10.1177/1555412015602819
Christian Reuter, Viktor Wendel, Stefan Göbel, and Ralf Steinmetz. 2014. Game Design Patterns for Collaborative Player Interactions. In DiGRA ’14 - Proceedings of the 2014 DiGRA International Conference, Vol. 8. Digital Games Research Association (DiGRA), USA, 16 pages. http://www.digra.org/wp-content/uploads/digital-library/digra2014_submission_39.pdf
José Bernardo Rocha, Samuel Mascarenhas, and Rui Prada. 2008. Game Mechanics for Cooperative Games. In Actas da Conferência ZON| Digital Games 2008. ZON, Portugal, 73.
Magy Seif El-Nasr, Bardia Aghabeigi, David Milam, Mona Erfani, Beth Lameman, Hamid Maygoli, and Sang Mah. 2010. Understanding and Evaluating Cooperative Games. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Atlanta, Georgia, USA) (CHI ’10). Association for Computing Machinery, New York, NY, USA, 253–262. https://doi.org/10.1145/1753326.1753363
Kiley Sobel, Arpita Bhattacharya, Alexis Hiniker, Jin Ha Lee, Julie A. Kientz, and Jason C. Yip. 2017. It Wasn’t Really about the Pokémon: Parents’ Perspectives on a Location-Based Mobile Game. In Proceedings of the 2017 CHI Conference on Human Factors in Computing Systems(CHI ’17). Association for Computing Machinery, New York, NY, USA, 1483–1496. https://doi.org/10.1145/3025453.3025761
Philipp Sykownik, Katharina Emmerich, and Maic Masuch. 2018. Exploring Patterns of Shared Control in Digital Multiplayer Games. In Advances in Computer Entertainment Technology, Adrian David Cheok, Masahiko Inami, and Teresa Romão (Eds.). Springer International Publishing, Cham, 847–867.
Ensemble Studios, Big Huge Games, Robot Entertainment, Relic Entertainment, Hidden Path Entertainment, Forgotten Empires, World’s Edge, Tantalus Media,. 2021. Age of Empires IV. Digital game [Windows]. https://www.ageofempires.com/games/age-of-empires-iv/
Zachary O. Toups, Jessica Hammer, William A. Hamilton, Ahmad Jarrah, William Graves, and Oliver Garretson. 2014. A Framework for Cooperative Communication Game Mechanics from Grounded Theory. In Proceedings of the First ACM SIGCHI Annual Symposium on Computer-human Interaction in Play(CHI PLAY ’14). Association for Computing Machinery, New York, NY, USA, 257–266. https://doi.org/10.1145/2658537.2658681
Amy Voida, Sheelagh Carpendale, and Saul Greenberg. 2010. The Individual and the Group in Console Gaming. In Proceedings of the 2010 ACM Conference on Computer Supported Cooperative Work (Savannah, Georgia, USA) (CSCW ’10). Association for Computing Machinery, New York, NY, USA, 371–380. https://doi.org/10.1145/1718918.1718983
Amy Voida, Sheelagh Carpendale, and Saul Greenberg. 2010. The Individual and the Group in Console Gaming. In Proceedings of the 2010 ACM Conference on Computer Supported Cooperative Work(CSCW ’10). Association for Computing Machinery, New York, NY, USA, 371–380. https://doi.org/10.1145/1718918.1718983
Bingqing Wang, Laramie Taylor, and Qiusi Sun. 2018. Families That Play Together Stay Together: Investigating Family Bonding through Video Games. New Media & Society 20, 11 (Nov. 2018), 4074–4094. https://doi.org/10.1177/1461444818767667
Jing Wen, Yong Ming Kow, and Yunan Chen. 2011. Online Games and Family Ties: Influences of Social Networking Game on Family Relationship. In Human-Computer Interaction – INTERACT 2011, David Hutchison, Takeo Kanade, Josef Kittler, Jon M. Kleinberg, Friedemann Mattern, John C. Mitchell, Moni Naor, Oscar Nierstrasz, C. Pandu Rangan, Bernhard Steffen, Madhu Sudan, Demetri Terzopoulos, Doug Tygar, Moshe Y. Vardi, Gerhard Weikum, Pedro Campos, Nicholas Graham, Joaquim Jorge, Nuno Nunes, Philippe Palanque, and Marco Winckler (Eds.). Vol. 6948. Springer Berlin Heidelberg, Berlin, Heidelberg, 250–264. https://doi.org/10.1007/978-3-642-23765-2_18
There are many interesting situations which can be described by anN-person general-sum differential game. Such games are characterized by the fact that the strategy of each player depends upon reasonable assumptions about the strategies of the remaining ...
AAMAS '10: Proceedings of the 9th International Conference on Autonomous Agents and Multiagent Systems: volume 1 - Volume 1
Cooperative games provide an appropriate framework for fair and stable resource allocation in multiagent systems. This paper focusses on monotone cooperative games, a class which comprises a variety of games that have enjoyed special attention within AI,...
The design of cooperative games is challenging due to the requirements of cooperation between the players. The major need of the design is to provide an environment that enables players to achieve the game goal in a cooperative fashion. The game ...
Pedro Pais, 
Manuel Piçarra, 
João Guerreiro, 
André RodriguesAuthors Info & Claims
