JC Lau, Elaine Gusella, Ian Schrieber, Daniel Cook
If, as Sid Meier has famously said, “a game is a series of interesting decisions”, then a co-op game is a series of interesting collective decisions.
We define a “collective decision” as a situation where some kind of decision must be made by two or more players together, with each player able to influence the decision and the result is a shared outcome. Think of it as “decision-by-committee.”
When building multiplayer co-op games, designers encounter a wide variety of decision-making mechanisms that they can implement in their games. Yet there is very little written on the topic. Certainly one can find lots of real-world discussion on voting or election systems, but in practice these are rather rare in games. Game-centric decision-making systems don’t look like politics as taught in school; instead they look like how an adventuring party in an MMO decides which direction to walk or which quest to initiate.
We are intentionally limiting the scope of this paper to collective decisions among players in games. While collective decisions do exist outside of games (examples include political elections, deliberating on where you want to go for dinner, and making group decisions about the direction of the game that your dev team is making), and the lessons in this paper may very well have applications in those other areas, we won’t be addressing those at this time.
This paper is composed of three parts:
If you are making a cooperative game, you’ll be by definition including decision-making systems. These come in many different flavors, not all of which might be obvious at first glance to be a decision-making system. But they’ll be there if you look. Some systems include:
There are very few decision making systems that are purely norm-driven. Often what we see are naively designed mixed systems that have unexamined underlying structures that drive player behavior in predictable ways. This results in frustration or toxicity.
Why would you choose a mechanics-driven system over a cheaper-to-implement norm-driven decision-making system? Making decisions together is frustrating and designers can use explicitly designed mechanics to mitigate frustration and reduce churn.
In the Self Determination Theory (SDT) framework, players are intrinsically motivated when they can self determine their path in life. By contrast, frustration is the emotional state that comes with being blocked in our attempts to reach or achieve goals that we believe we should be able to attain. In the context of games, frustration arises when players cannot effectively make or act on the decision they have made due to a variety of barriers, such as limited time, insufficient resources, or other factors preventing them from doing what they have decided. Some versions of player frustration are:
Group decision-making forces individuals with non-aligned goals to interact with and depend on others. This inevitably creates a coordination challenge which can trigger various forms of self determination frustration. Or, as Sartre says, “hell is other people.”
Coordination is a great thing when it works! It is how groups of humans maximize resources in a zero sum situation. This is the basis of human civilization and is supported by a whole bunch of complex cultural and biological processes unique to humans. However, it isn’t easy. Individuals need to build trust, create a shared set of social norms around language, process and actions. This happens slowly, with repeat interactions, over time, within a small group.
A very common coordination failure is choice denial: Suppose you are given a choice within the group. You make that choice (exercising your autonomy), but then that choice is denied due to the decision of others (autonomy and relatedness invalidated). For example, if a player had a strong opinion about which boss to fight, but that desire was overruled by the rest of the group, that would result in that player being frustrated. Digging deeper into this example:
This failure is more common in low trust situations with open social affordances and poorly defined social norms. Notably, these are also the hallmarks of norm-driven or naively designed mixed decision-making systems.
Over time, as frustration builds, players engage in unhelpful corrective actions–that is, toxicity or problematic behavior. They may seek to enforce complex norms on new players. Or, they might ostracize or other players who aren’t meeting their individual goals or needs.
When players experience heightened levels of frustration (especially around interacting with other players), they are more likely to address this friction themselves by quitting the game. This decreases retention, kills your player population and puts the entire game as a business at risk.
Conversely, reducing friction in player interactions lowers frustration and the player bounce rate. Furthermore, money talks. Designing decision-making systems that lower player friction also means that other business decisions that hang on player engagement are also affected, such as projections based on daily or monthly active users (DAU and MAU). Simply put, the less friction players experience from other players, the better for both player engagement and the game’s business needs.
Our goal in this paper, then, is to offer heuristics and recommendations on designing systems that can reduce frustration. This will lead to better retention and overall better player experiences.
Within every collective decision, there exists multiple phases and subsequent choices within each phase. By naming and defining each phase, we can break down a complex decision-making system into its component elements. This is known as a ‘decision cycle’.
We call the model of decision cycle that we examine in this paper the DECIDE framework. The phases of this framework are as follows:
There are many generic decision cycles out there such as OODA and we’ve borrowed many of their features. The main benefit to the DECIDE framework is we can call out the key “tunable elements” that a designer can build their specific designs around. These are adjustable levers or dials that one should set to get some desired gameplay experience.
For example, when we consider the information that players have in making their decision during the Evidence phase, relevant factors might include:
Answer each question with specific game mechanics: Each of these elements can be addressed by specific designs with UI flows, affordances, rules processing, feedback loops, etc. But instead stumbling upon topics as you go, you can upfront step through a nicely laid out checklist and consider how you want your design to address the issue.
Where each mechanical system drives a designed player experience: Each element also has deep experiential ramifications. Limited information access plus open deliberation channels gives some players with information more power over others. They can reveal what is helpful to them while restricting what is not helpful to their goals. If you are making a game with the experiential goal of showcasing intrigue and politics, you can tune your information access and deliberation channels to support this.
We examine each phase in the DECIDE framework in greater detail in the next section. We should note at the outset that the tunable dials we have outlined are not intended to be exhaustive, nor do they apply to every decision. In fact, we believe that different types of multiplayer games lend themselves to different combinations of relevant dials. For now, the upshot is that, at a high level, each collective decision involves stepping through the DECIDE framework, and we will examine the specific design dials that get activated at each phase below.
For each phase in the DECIDE framework, we’ll cover:
Before a decision is even made, a set of conditions and constraints that we call Defining Pillars shape the decision-making environment. Think of this as the established structural environment your decision-making system lives within. Defining Pillars are often fixed ahead of the decision-making scenario arising, and may be set at the stage of determining your game pillars or player promises.
Shifting design elements in this phase have radical impacts on your design; you might as well be designing an entirely different game. For example, taking a game designed for 4 players and increasing the number of players to 16 would usually require reworking most systems from the ground up. Thus, the dials in this phase are something that designers need to keep in mind as they influence everything else downstream, acting as constraints and guardrails on the rest of the design of these decisions.
However, there is also a subset of interpersonal factors between the players that are not as easy to design around, such as how much players will trust each other, their perceived reputations, and their relative levels of power. If frustration arises in these cases, they are harder to mitigate, as they lean more on the social dynamics between players. We recommend leaning on existing interpersonal relationships (such as playing with friends), or designing more for prosocial multiplayer behavior.
Who gets to participate in making the decision? This is the most basic choice facing designers in the creation of a decision-making system. Many of the other design elements such as group size, trust and power are sub-elements of the group formation challenge and are tackled in more detail below.
If the entire population cannot be directly involved in the decision-making body, you can get them to choose a small group of officials. There are a wide variety of choice mechanics for doing this such as elections or random selection. Once selected, the representatives then make decisions for the larger group. As long as the broader population buys into the representative selection process, they will feel a sense of self determination with regards to the decisions reached. Admittedly this scales poorly with group size.
Incompetence can be managed by having decision making bodies that include multiple people. If there is only one person making decisions and they just so happen to be either deeply evil or an imbecile, you are guaranteed to get poor results. But if there are multiple people involved, the chance of them all being incompetent is lessened, and they are more likely to reach a “correct” decision.
You can examine metrics for a potential participant to see if they are likely to be competent. This leads directly to the need to design well validated metrics. A full discussion is outside the scope of this article, but consider vetting for evidence of the following attributes:
How many players are making this decision? Group decisions feel very different in a group of 2 versus a large group of 200.
Following Dunbar’s theory of friendship, most interesting social interactions that build social capital exist in groups sizes of 50 or less. Most intimate interactions that drive retention exist in group sizes of 6 or less. If you build a game for fewer players, you’ll increase agency, speed up trust formations and reduce communication logistics.
You can reduce the cost of norm formation by institutionalizing behaviors in the form of rules. One of the great powers of videogames is the automation of complex rulesets and algorithms. If you can identify what norms you want players to follow, what automated algorithms and UI flows would reduce or remove the cost of executing those behaviors?
If you are running into communications issues, you can reduce the cognitive load on players by simplifying their choices. Instead of open ended options, create simpler options that are easier to parse and easier to act upon. Now you’ve given players a few topics that are easy to talk about.
Large groups simply do not scale well across a wide variety of factors (such as the aforementioned trust, communication, and agency). One solution is to have smaller groups be responsible for specific domains of a decision and then feed a summary to other groups. The smaller groups gain the benefit of enhanced trust, communication and domain expertise, but the larger groups gain the benefits of simplified choices.
How well do the players know and trust each other? This can be impacted by group size; trust by default tends to be lower in very large groups. Trust may also be impacted around concepts such as Dunbar layers, where players might have higher levels of trust when playing with close friends, rather than strangers on the internet.
A common solution is to empower a single dictatorial leader who simply tells others what to do. It is very efficient, and it can be quite enjoyable for players. Witness small team games like Artemis where the captain role simply tells others what to do. It is a common structure in MMO guilds, sports teams, corporate structures and cults. Variations include a using hierarchy to have a small group of trusted members having authoritarian control over a larger group.
The main downside of authoritarianism is a distinct reduction in feelings of self determination. You also see inefficient information distribution since hub and spoke structures struggle to operate at scale.
Another approach is to limit decision-making coordination so that strangers participate in low coordination aspects of the process and high trust groups participate in higher coordination. A legislative structure where small congenial committees of experts generate laws that a larger group of lower trust members vote on simplified options is an example of mixing coordination complexity with participant trust level.
What are the power dynamics like in a group? Broadly, power is the ability to get something done and comes in several types: reward, coercion, legitimate, expert, referent and informational.
In your game, is everyone equal, or do some players have more power or influence than others? Decisions are particularly influenced by power dynamics and asymmetry. For example, when one individual makes a pre-selection, such as removing an option in a card game, or when an (elected) leader makes the final decision on behalf of the group, the leader typically holds more influence over the outcome than the rest of the group.
Power in video games can also consist of ‘virtual power’ such as improved weapons or abilities relative to others. These economic imbalances can drive social power imbalances.
If one group has power, create another opposing group that can limit the first group’s power. With Rock, Paper, Scissors oriented graph arrangements of various groups, you can avoid conflicts of interest.
You can break up collusion by randomly selecting members of each decision-making group from a broad pre-vetted pool. Sortition was one of the original foundational systems present in ancient Greek democracy (and is still used around the world, especially for topics like jury selection). These are just systems of dice, a game design tool we are skilled at wielding. Designing a full system of governance by sortition is an exercise left for the reader.
What individual and collective resources in the game are available for use, and what implications does that have for making the decision at hand?
One method of mitigating it to reduce or limit the spread of any virtual power that impacts decisions. The design can make it easy for players to reach a ‘floor’ of 80% of the capabilities of a max power group or individual. While this is harder in the real world (see Universal Basic Income), game balance is often as simple as changing some numbers. Giving all players the same number of votes is an example of this technique.
Scarcity can create conflict, so reduce the amount of scarcity. Games can easily invent non-zero sum resources so that if one player gets something, another player can still get the same resource. In multiplayer scenarios, double check each resource and ask if you are unnecessarily creating zero sum situations that provoke uninteresting conflict or tradeoffs.
Do players have an ongoing reputation within the group that can be built or damaged based on their behavior? If players will be making more decisions within this same group, their prior behavior will be taken into account–consider social deduction games like Mafia or Werewolf and how a player’s past willingness to condemn or forgive another player may make them more or less suspicious later on. Or consider how a player who consistently makes a lot of mistakes and is unreliable may be ignored or vetoed by the rest of the group.
Many games limit the scope of choices to a single game session and then swap in new players. Reputational effects become dramatically easier to balance. The downside is players don’t form friendships with one another which damages social capital creation and increases churn.
Hiding the identity of participants in a decision can help prevent both reputation formation and retribution. At the very least, you create plausible deniability. By giving players control over what they reveal about themselves (‘disclosure’ in the frame of friendship formation) you also end up increasing a feeling of agency.
While time is technically a subset of the resource dial, we think it is an important one worth considering separately. Are players under a time limit to make the decision? This feeds into a broader category of cognitive load; does the player have the mental resources including attention and interest to make the decision. In general, cognitive resources increase with less time pressure and fall in the face of increased time pressure.
If decisions are made under tight time limits and there’s a high chance of making mistakes, reduce the cost of bad outcomes. This will encourage players to play fast and loose within the safety net. In Mario Party, there are many cooperative games but the cost of failing is miniscule. This economic balancing fits the frantic social fun experience described in the product pillars.
Give players an opportunity to quickly try again with the knowledge that they’ve gained from the last decision cycle. This increases their feelings of mastery and competence. This can also reduce the risk of loss of reputation in a group, as players are more willing to forgive mistakes under time pressure if they know they’ll get another chance soon.
Cap the amount of time that a decision can take. What is too short? What is too long? Build those numbers into your tunable system.
Before a collective decision is made, groups navigate through a complex pre-decision phase of discovery and processing of all the knowledge, needs and parties involved. At this point, you’ve formed a decision-making group with all foundational pillars such as group size, resources, hierarchy, etc. But the world is a messy place and clarifying what a group even wants from a decision is sometimes the hardest step. The ultimate goal is to define a clear set of options to decide upon in the next phase.
For our purposes, we collectively refer to this as the Evidence phase. The following points outline key elements that shape this stage:
Much of the challenge in games comes from players learning to model systems of cause and effect. They engage in a learning loop where they slowly gain more predictive modeling capability and control over the game system with each iteration. over time. Limited information is a form of friction that slows the modeling process
Designers get to determine the complexity of the model of cause and effect that players are grappling with. If you are finding that players need too much information to make a decision, try simplifying your base model. For example, in early prototyping of the merge genre for Triple Town, designers had all sorts of rules for crafting new elements. But these were confusing, so we simplified the base model of cause and effect to be that 3 elements of the same type turned into 1 new higher tier element. This meant that players needed to understand a much simpler model which in turn led to a more management choice structure.
You get to design what information players see. You don’t need to show everything. Ask what information the players actually need. Surface that in your UI.
Players don’t need to make all the decisions; you can use smart defaults to automate many low stakes decisions. Ask yourself if the player is engaging in an interesting decision. If not, automate it.
How do participants deliberate? They need to share discovered information, prioritize concerns, and synthesize complex topics into simplified options that fit the constraints of their target choice mechanisms in the next stage.
You can streamline communication with tools like pings or emotes that quickly let players express contextual feedback relevant to the topic at hand. The simplest version of this can be thumbs up or thumbs down emoji, but with modern ping systems can contain voting or context sensitive chains of responses.
Ask yourself:
Having guidelines on how to communicate with one another and enforcement of those rules helps reduce prolonged dissent. You can do this through human moderation, which is highly flexible but requires skill and attention. Alternatively, you can do this through automated rules which the computer can run cheaply, but can be gamed and are more at risk of presenting unwanted edge cases. Some considerations include:
Humans are great at talking with one another when a situation becomes complex, especially in small groups with good actors who want to solve the problem at hand. Make sure you have escape valves in your process where humans can talk to humans to resolve things that your designed system is not well-equipped to solve. This could be text chat or voice chat. There are multiple benefits: You can’t predict every eventuality and humans talking to one another builds social capital within your community.
The perception of stakes, irrespective of their actual level, shapes player behavior and how they assess the importance of a decision.
The way a decision is presented and the context in which players are making it impact group members’ perceptions, attitudes, and actions by emphasizing certain aspects while minimizing others. The framing effect suggests that individuals often make decisions influenced more by the presentation of information than by the information itself. This cognitive bias leads people to prefer options that are framed in a more positive light, even when the underlying facts are the same. This selective framing can create a disconnect between the available choices and the group’s overall objectives. Language plays a critical role in this dynamic; framing a decision positively or negatively can influence how the group perceives it.
Presenting a choice as a reward instead is likely to be more enticing for players, encouraging bolder decision-making. In our budget example, imagine instead that you’ve entered a fresh round where you get to buy your upgrades anew. Though the choice is the same as the example given above, it feels much better to most players.
There’s a sleight of hand here associated with setting player expectations. In the ‘budgeting as a loss’ example, players expected to keep their abilities from round to round. In the ‘budgeting as a gain’, we set the player expectation that of course you start fresh each round. This gives us room to contextualize the choice as a bonus.
Of course, the making of the choice itself is at the center of the DECIDE framework. Insofar as games provide players with agency to create their own user stories and experiences, the choices they make with others will also impact their stories and experiences, both with the game and with each other.
There are many paths to making a decision collectively, and these will lend themselves to different flavors of “voting”. An analogue–although we do not wish to examine this too closely–would be to compare various political systems that may fall under the umbrella term of “democracy”. The upshot here is that there are different ways to make a collective decision, but they all count as choices of some stripe. We do not make any specific recommendations about the choice mechanisms that we discuss in this section other than making sure that they fit with the intended player experience they are being designed for.
What types of choices are you presented to a player? There are as many options here as there are types of problems to solve.
These formats exist on a spectrum of more freeform to more constrained. Smaller groups dealing with more complex topics often use freeform choices. While larger groups often work with more constrained and simplified choices. This is mostly driven by previously discussed trust and coordination factors.
It is worth nothing that all previous factors and frustrations come into play when designing your choices.
Often choices are presented with a clear information hierarchy: Start with easy to communicate summary labels. Next, highlight the trade offs. Finally provide an easy means of getting additional information that captures the nuance of the decision. Not every player will engage with all levels of information, but those who are interested can opt-in.
How is the result decided? Does the decision have to be unanimous, is it majority rules, does it simply need a plurality, or can it be overruled by one or more players (fiat)? This can often intersect with influence mechanics, but does not need to. For example, the players may have to decide by majority for the decision mechanics, but due to an imbalance in the power and influence between players (such as if a parent and a child were playing together), there may be cases where one player’s influence affects another player’s vote.
In hidden-role/social-deduction games (such as Werewolf or Mafia), trolling is an intentionally-designed core mechanic, where some players’ roles allow them to undermine a vote. If this is part of your design, lean into this to manage player expectations.
In Korean MMOs like Lineage, gaining undue influence is the whole point of the game. You ultimately want to lead a large alliance and shape the behavior of hundreds or thousands of players.
To mitigate for both trolling the vote and undue influence on a decision, and to promote a more equitable decision-making process, game designers can also implement various mechanisms that allow all players to influence or counterbalance more powerful individuals. Some effective strategies include:
Much of player behavior is influenced by clear social norms. Bad actors often do not understand current social norms around appropriate decision making behaviors.
Clearly signal the following:
DESTINY 2 LIGHTFALL How To Give COMMENDATIONS
Making these clear to all players will not necessarily prevent trolling or undue influence, but may reduce the likelihood of it.
Do all players have the ability to “vote” (influence the decision), or is the decision-making reserved only for some subset of players (e.g. those who spend resources, only those with a sufficiently high guild rank, or those who the group leader allows to have a say)? There might also be considerations insofar as opting in may be a default mode, such that it is assumed at the design level that all players have the ability to vote in some way.
Do all players involved have to have an opinion and influence the decision, or can a player abstain if they want to? If players do not have enough information/opinion to decide either way, can the Principle of Indifference apply here? Mechanically, this may look like a random vote or a dice roll. If players decide to opt out, do they have the option of opting back in later?
The Implementation phase is about executing the plan that the players have collectively chosen in the previous phases. This section assumes that players have the appropriate resources for implementation–this is a factor that would have come up in the Defining Pillars phase otherwise–and the focus here is primarily around the actions that players need to perform for successful implementation. In implementing the decision, the primary considerations are around how to execute, and in some cases the level of coordination needed to bring about the result of the decision.
Implementation can be individual or collective. In the case of individual implementation, we may all have decided to bring about an outcome but some or all of us have actions that we need to take in order to bring about the outcome. For example, the host of a multiplayer game kicking a toxic player out of the game may be a decision that can meet all the prior requirements of the DECIDE framework, but can only be implemented by the game host. In contrast, in the case of collective implementation, all the players involved in the decision would need to act to bring about the outcome (such as pushing a button at the same time).
Sometimes, frustration occurs where participants cannot perform the appropriate action required to bring about the decision. A decision may have been collectively made, with a desired and clear course of action, but the implementation of the decision can be frustrated at that point if there is no individual who can feasibly do the thing that is the subject of the decision.
For example, suppose that we are a group of mice being terrorized by a cat. We decide, collectively, that we should put a bell on the cat to alert us of the cat’s whereabouts and keep us safe. We may even decide this unanimously while successfully putting together the appropriate resources, making plans, and so on for how to put a bell on a cat. However, we are all still mice, and any attempt by us to put a bell on a cat results in the cat catching the mice who are executing the plan.
In gameplay, an analogue may be as simple as that we all collectively decide to skip a cutscene, but there is nothing in the UI that allows us (either collectively or individually) to skip the cutscene. We are therefore frustrated from being able to execute on the decision to skip the cutscene.
During choice definition, the game rules can invalidate any choice that is not feasible. For example, if players in Minecraft choose to craft a certain object, but don’t have enough resources, the UI invalidates that choice and by not making the intended object appear in the UI. We can pre-validate outcomes in our closed cartoon worlds and prevent players from making choices that don’t make sense.
Once a plan is selected, we can actively provide resources that players need to execute on their decisions. This can be as passive as ensuring that the UI isn’t broken or that economic balancing allows for most player actions. But it can be active as well where the system detects what the players want to do and then spawn necessary elements so that it is feasible.
Unlike the previous type of frustration where participants can not execute the plan, this case is where participants will not execute the plan. For example, if we agree to skip a cutscene but the host has to press the button to do so and fails to perform that action (because they decide not to) then we are frustrated because we cannot do the thing that we agreed to. As designers, this version of frustration in implementation is more challenging to mitigate.
Failure to act appropriately at an individual level also increases the risk of collective failure where our collective decision requires multiple actors to coordinate on their decision. Consider rhythm games such as Rock Band, where players have to play a song together but are each responsible for playing their own instrument. By this point, the players have collectively decided that they will play a song together, but they could be unable to implement their decision if someone refuses to play their part as intended, or plays wrong notes (either due to lack of skill or malicious intent).
To be clear, there is a difference here in the player’s intention in causing implementation to fail. To be bad at Rock Band because you lack skill is one thing, but to intentionally go against what we have agreed upon is an instance of voting in bad faith. In these cases, failure to act according to what we have agreed (thereby causing implementation to fail) may impact certain factors from the Defining Pillars, such as the level of trust, the power of each decider, and reputations in future iterations of decision making.
For multiplayer games, mechanics can also be added to allow higher-skill or participation players to cover for lower effectiveness players and save the team.
You may see some free-rider effects, though this is less common than might be expected by discredited by still popular Homo economicus ideologies.
If participation in executing the plan is optional, we can make non-participation just feel like the status quo. People voted to kill the big boss but folks were busy that weekend. No big deal. The boss remains unkilled and life continues on as before.
When players act in bad faith, we recommend that designers implement robust moderation tools such as player reporting, kicking trolling players, etc.
The group has come together to make a collective decision. The rules are in place, and the decision is made and then acted on. At the end of this chain of events, the players see the consequences of the decision. This is the Debrief phase, where the outcomes of the choice and the decision process come to fruition and the players retrospect on the path that led them to this point.
The primary action the players are taking in this phase is reviewing the decisions that have previously been made. Unsurprisingly, this is where a lot of frustration and pain points can happen, though the conditions that set up this pain happen much earlier in the chain.
Note that the debrief phase will happen whether it is intentionally designed for or not, so designers should err on the side of understanding some of the topics that players will be reviewing. Some considerations for designers are below.
Do you measure the results of the collective actions? Do the results match the intent? What is the source of the mismatch?
We see the most issues with freeform planning mechanisms that have a low degree of automation.
Many mastery or execution related verbs can be scored for performance. Your design can then choose to surface those results to players in a manner that positively frames their success or failure.
Once you can quantify the results, build corrective feedback loops that include the players who made the original decision. What if these comparative results were easily available during the next round of decisions made on the same topic?
It is worth noting that the entire field of governance is rather ancient. Many populist decision-making systems focused on maximizing participation and buy-in. This insight, wonderful as it may be, is a 400-year old improvement on a 2000-year old system. More modern systems, influenced by relatively newer fields of psychology (and the scientific method) wondered what happens if you frame decision-making through the lens of adaptive learning cycles. How can we iteratively improve the outcomes of our choices over time?
Do the results match player expectations? Delight or frustration can arise in the debrief phase due to mismanaged expectations of the outcome.
Negative outcome: For example, players usually decide on a course of action because they stand to gain something from it, be it loot in game, a way to progress the story, leveling up their character, or something else. Let’s call whatever the gain is G. If players take action expecting G but end up attaining something less than G then oftentimes, they are frustrated as we (reasonably) assume they would not have tried to attain G if they did not think that they would not be able to achieve it.
Positive outcome: However, sometimes this can also create a pleasant surprise! If the process to attain G results in less than G, but instead of having anything game-specific, players end up with good player stories, this might suffice to overcome the frustration or even create an even better experience. You can imagine this to be the case when players in a D&D party roll terribly, but even though they failed to attain G they still had an enjoyable time through their shared experience and storytelling.
Small groups of friends playing together at a D&D table with relatively equal power and autonomy are more likely to have factors that allow them to experience a pleasant surprise over a large number of strangers with low autonomy being told that they have not succeeded in a group task.
If the design successfully spreads feelings of self determination and participatory ownership across everyone impacted by the failed outcome, they may feel a sense of responsibility. If people start blaming the game or blaming others, you’ll know that players did not feel strong buy-in to the decision-making process.
Finally, we should account for how a decision changes subsequent collective decision making events. Consider this the Evaluate phase of the DECIDE framework, where after players have made a decision together, the features of that prior decision will impact future iterations of decision making.
With game development there are two classes of process improvement that occur:
Below are some considerations for designing a meta loop for collective decision making.
Decisions in social systems are path dependent, where every decision gives the players additional information about various factors (such as how other people deliberate, their odds of success, etc.). As such, we see that every subsequent decision has a “yes, and” element to it as it builds on the foundation of the previous decision. The following are all categories of path dependence:
We can use the pattern of hierarchical groups (from Phase I mitigations) to form service organizations that provide a long term knowledge store. Some examples may be:
You can limit how long people serve in a role. The optimal term limit answers the following questions:
In many judicial roles where you want people to focus on the moderation issue at hand, you likely want very short term limits, perhaps for a single case. In more complex planning roles such as laying out the flow of a factory or city, you may want longer term limits so players can see the large-scale holistic results of their work and still have time to iterate upon it.
As designers, we should be mindful of the impact of these and mitigate the impact of the Evaluate phase, especially if it causes the DECIDE framework to end on a sour note. Some mitigations may include:
In addition to the level of information (for the Evidence phase) that players will have, some of the factors we identified in the Defining Pillars phase will change when a subsequent decision is made. This is particularly pertinent to developer-driven changes.
In Helldivers 2, a small group of players engage in a chaotic PvE battle against overwhelming waves of enemies while trying to complete multiple goals within a time limit. A core pillar of the game was ‘Stupid co-op fun’ with overpowered weapons and ragdoll bodies flying in the air. It was a delight to fail.
Ragdoll Simulator | Helldivers 2 Funny Moments
The key decision making structures in the game are centered around what loadout to use in battle and how to tackle each encounter as mediated by pings and voice chat. This is a far cry from sclerotic multi-year elections, but a group decision-making system nonetheless.
After launch, the team heard from the community that their encounters were poorly balanced. The fundamental choice of how a group tackles a big enemy was broken. So, overpowered weapons were nerfed and others boosted. And overall the game became more predictable. Players knew what to do in each combat situation and how to win.
However, this invalidated the original sense of chaotic stupid fun. A key part of the original experience was being wildly outgunned and failing dramatically. So new overpowered weapons and unfair enemies were eventually introduced, thus changing the foundations of player decision making during moment to moment gameplay.
Here is a low drama operating procedure for managing community contracts.
Some participants are better at the decision-making process than others. A meta-decision is updating who gets to participate in future decisions based on past performance.
In Helldivers 2, players have multiple competing goals at the same time but on higher difficulties can only devote effort to one of the goals before time runs out. A key decision is which goal to focus on.
Suppose players have decided to focus on one goal but a player goes off and works on something else. This increases the risk of everyone collectively failing, and remaining players may change their perception of the player’s reputation and the level of trust they would put in that player’s commitment to deliberation. Players may decide to boot that player from the group or not play with them in the future.
In group / out group management is one of the trickier social systems to manage.
If you notice abuses, you can add digital mediation.
Now that we have examined the various factors that impact each decision dial in the DECIDE framework, let’s apply it to common examples of collective decisions found in games.
As a reminder, collective decision making in games come in various levels of complexity, so not all dials will be relevant (or even exist) for every type of game. However, it is important to consider the full framework anyway in designing games as a starting point, so as to not miss any potentially crucial aspects of the framework.
In many co-op action games, each player is responsible for their own movement, but in general the group is supposed to stick together, and players collectively decide which way to go next. This is usually quite informal, with players just flocking together without a whole lot of discussion or any kind of formal voting system. Occasionally, however, communication fails and players split up in different directions unintentionally, and this experience feels very different depending on how the game handles this situation.
Diablo 4 has a tether system for players in couch co-op mode, where if one player stops moving or is otherwise AFK, the active player can “drag” them as they move towards the next objective. If the player regains control of their character, they are no longer dragged. This is an application of the characters moving in a direction as a group that allows for the players to pick a direction and assent to it. There is also a degree of AI in player movement and traversal built into the tether system so that the “dragged” player character also will navigate the world without becoming stuck on obstacles (including being able to climb ladders and stairs).
How to Play Couch Coop (Console Only) ► Diablo 4
Compare this with the player movement in Gauntlet, where all the characters are uniquely responsible for their own movement, in the sense that the player is the only person who can move their character. Tethering is not a system in Gauntlet, so there is a higher degree of deliberation required for each player to decide where they want to go and how to get there.
However, in Gauntlet, the camera follows the center of where the four players are. This means that, for example, if one player walks left and another player walks right, the camera will stay between the two. Players are not allowed to walk offscreen, so if any player reaches the edge of the screen, it is treated as if it were a wall. Players can and do get stuck when they split the party, especially if one player ends up trapped in a corner behind a wall which forces the rest of the team to backtrack just so they can get out.This can lead to frustration among players–both the one who is trapped, and the rest of the team who needs to move back to free their teammate.
Now compare each of these to Sonic 2 (Sega Genesis) in its two-player mode. In this platformer, one player controls Sonic and the other controls Tails. These characters are treated differently by the game. Sonic is the main character and the camera is always centered on him. Tails can move freely, but nothing stops him from moving offscreen, and if he is out of view there is no indication of where he is or which direction he needs to move to get back (if Tails stays offscreen for too long, the game will automatically have him fly back in). As such, the Sonic player is in complete control of the camera, other than the out-of-game communication between the two human players. The Tails player can ask the Sonic player to move in a certain direction, but it is up to Sonic whether to listen (and Sonic may, for example, miss a jump that causes them to go down an unintended path anyway). In this system, the Tails player can be frustrated if Sonic either goes in an unexpected direction and leaves them behind (essentially removing them from the game for a few seconds) or goes down a path they warned him not to; on the other hand, Tails also cannot die, so there is less responsibility in that role–the Tails player doesn’t have to worry about poor play harming the team. For two players of uneven skill level and especially where the lower-skill player is sensitive to holding the higher-skill player back, this is a wonderful arrangement. However, for two equally-skilled players (or where the Tails player is much higher skill than Sonic), Tails can feel quite frustrated at his lack of agency over movement and survival.
Defining Pillars: In all three games the group size is small, and level of trust and reputation are high (players are playing together, generally with friends, in the same physical space). In both Diablo and Gauntlet, the power dynamics are equal (all players have equal say), while in Sonic the power is unilateral (Sonic player chooses, Tails player has to follow along). Time of decision is also subtly different between the three games: in Diablo there is no time pressure other than to alleviate the boredom of standing there; in Gauntlet there is a slow drain on player health that provides a mild incentive to keep moving; in Sonic there is a hard time limit per level, but the limit is so long that it doesn’t matter unless the players are stalling a lot.
Evidence collection: In all three games the availability of information is fairly high (all players can see the same screen and what directions are available). In Diablo, the levels are procedurally generated so all players are equally in the dark as far as knowing what dangers or treasures lie in which direction. In Gauntlet and Sonic, the levels are fixed, so one experienced player may have more information than the others about which direction is the best way to go, and that will influence the group. The Tails player in Sonic may also have less information than the Sonic player, as they may not have visual cues onscreen for where their character is.
Choice: This is a key area where the three games are highly distinct. In Diablo, all players have the ability to vote, and the option to “opt out” (a player who doesn’t move can still get dragged around by the rest of their party). In Gauntlet, all players can vote, but there is no opting out, since a player who refuses to move will eventually prevent the other players from moving forward. In Sonic, only one player effectively can vote and they can’t opt out. In all cases, the decision mechanics really come down to control of the camera – and you can see from above just how many words it takes to describe this (and as designers, the mechanics of camera control are what we would primarily focus on in this type of movement system).
Implement the plan: All players have to input the correct controls to move together on the screen. Diablo’s tether system is a great mitigation of the implementation problems where one player does not or will not put in an input. As discussed above, the Tails character in Sonic 2 will still have to do the same implementation, but will have different information in the Evidence phase which will affect their ability to meaningfully move (i.e. implement their decision).
Debrief the results: While the team is moving together, we may consider this as each player getting feedback and doing a series of ongoing, localized “debriefs”. Feedback such as “I am stuck behind this table” in Gauntlet is part of the debrief, as it informs what happens in the meta loop and future (ongoing) decisions for the group.
Evaluate the process: As moving together on a screen is an ongoing action, designers can view this as a series of persisting decisions, or an ongoing decision that is continually implemented until something happens to break the loop, such as players needing to stop moving to interact with objects, speak to a NPC, or so on.
In some multiplayer games, when players hit certain narrative beats or combat phases, they may see a cutscene. Oftentimes, when players want to skip the cutscene, there are two common ways that this happens:
We believe that this is a case where the genre and type of game influences the design of the “skip cutscene” to minimize friction. Local multiplayer games such as Rocket League or Duck Game seem to lend themselves more to collective skipping, whereas games that are networked have different player understandings about the host. Elden Ring is a key example of this, where the “multiplayer” elements are relatively restrictive and erring heavily in favor of the host, such as the host only being able to summon other players at certain points. With this in mind, having the host be the only player who is able to skip makes more sense, as the other players are already primed to see themselves as “visitors” to the host world.
If we go through the DECIDE framework and examine the design dials for voting to skip a cutscene, we may identify them as follows:
Defining Pillars: In both of the above scenarios, team sizes are usually no more than four, so they are relatively small, and players have high agency. In most cases, players have a high degree of trust with each other as well, if playing in cooperative environments with friends. Power dynamics are different in the two scenarios, as decision making is more collective and democratized in scenario 1 where everyone votes together, rather than in scenario 2, where whoever has the single voting ability can decide for the whole group.
One of the considerations here is that the time to decide may be short as at most the players would have the duration of the cutscene to vote to skip. The time is also not necessarily fixed as it would vary with the length of the cutscene. That said, depending on the length of the cutscenes players may not have time to sufficiently deliberate and skip the cutscene anyways rendering this point moot.
Evidence collection: The quality of information is relatively high. So long as players know that there is an option to input during a cutscene to try to skip it, they are sufficiently informed to make that decision. However, the critical information they might not have at the outset is which scenario they are in–a well-meaning player could accidentally skip the cutscene for everyone when they simply thought they were voting, leading to frustration and confusion in the group.
The deliberation phase may or may not exist in scenario 1, depending on the intended UI design of the system. Warhammer 40k Space Marine 2 shows a tracker at the bottom of the screen of how many people (out of the squad of 3) have voted to skip. In other cases, that information may not be available to the players, but they might be able to use voice chat to deliberate on whether to skip. However, in cases without voice chat or when playing with strangers, it may suffice as “deliberation” for players to input to skip the cutscene, but leave it to the group to see if the other players also assent to skipping the cutscene by also pressing the appropriate button. In either case, the players will know if they have executed successfully on their decision if the cutscene is skipped.
In scenario 2, what clearly changes is the method of deliberation, insofar as deliberation is not required when a single person makes the decision for the group. However, if a group of friends are on voice chat when the cutscene comes up, it’s likely that they will discuss whether to skip the cutscene, however informal. This may suffice as deliberation. In the case of playing with strangers or where players do not have voice chat or another means to deliberate, the level of agency for the non-inputting player is considerably lower. This effectively becomes a decision by a single player that impacts everyone else.
Choice: How the choice is made differs vastly depending on the specific mechanics of skipping a cutscene. In scenario 1, all players have the ability to influence the decision directly, but do not have the option to opt out–it is assumed at the game system level that they are part of that decision. In most cases for scenario 1, the decision has to be unanimous. It is also possible to design a system to skip the cutscene where a majority of the players have decided, but this seems less practical and lower return on the effort expended on the system than simply doing an “all or nothing” approach. Warhammer 40k Space Marine 2 goes part of the way there with a counter for how many players have voted to skip, but still requires everyone to agree to skip. It does mean that if one player is holding out, the remaining players can draw attention to this to force a decision.
In scenario 2, the only player who can effectively influence the decision is the one who can input to skip the cutscene. While other players can technically influence the decision through informal means (such as asking the deciding player to skip the cutscene or not), the decision ultimately rests with the skipping player.
Implement the plan: In scenario 1, players have to all input the same button at the same time (or close enough for it). Note that in this case even though the decision to skip is collective, all players have to individually input the button. This allows for the “lowest common denominator case” where if one player wants to see the cutscene, they get to.
Risks for frustration are not having enough time, or someone not executing as agreed (or within the window when everyone else has pressed the button). This may not necessarily be malicious—perhaps they weren’t paying attention, or there may be accessibility considerations here as well for how button input is designed in cases requiring time limits. Either way, the result would still be the same: players have to sit through the whole cutscene. At least in the case of accessibility, allowing the player to tap the “skip cutscene” button rather than have to press and hold would reduce the incidence of frustration caused by inaccessible inputs.
In scenario 2, where only one person presses the input to skip for everyone, players may experience frustration for the same reasons as scenario 1, if the person empowered to skip the cutscene cannot or will not do so. The inverse is also true: an impatient host might skip all the cutscenes, leading to frustration and confusion among the players who wanted to watch them. This might be particularly problematic in cases where some players are jumping into a game to help another player and don’t have the same context of the game or story as if they had been playing a campaign together all along.
An interesting mitigation to the implementation frustration is Star Wars: The Old Republic, where players could skip dialogue, but only if all the other players had experienced it before. This prevents the frustration from “context loss” where a new player misses information from a skipped cutscene, but also prevents frustration from other players who might be impatient to start playing, as they are functionally given an explanation for why they cannot skip the cutscene.
Debrief the results: if successful, the players will skip the cutscene. It is usually quite noticeable when the cutscene is stopped abruptly and gameplay resumes.
Evaluate the process: There will likely be more than one cutscene, so players can use the information about how they deliberated and the outcome to help them decide at the next cutscene. If players were not aware about the method for decision (i.e. which scenario they are in), they may also have additional information about that after the initial pass. This also gives players the opportunity to let others know that they want or don’t want to watch future cutscenes.
There is also a third possibility we have not discussed here for how players can skip a cutscene, and that is where almost all cinematics are totally individual, even in a group. For example, in World of Warcraft, players can decide for themselves if they want to skip the cinematic and keep playing while others watch it. The tradeoff here is that one player can skip the cinematic and keep playing while others watch it, and the players who watch the cinematic might be a bit behind on the gameplay if they watch the whole thing.
This may cause friction if a group needs to wait for someone who wants to watch the cutscene, but this can be mitigated by the length of the cutscenes. If they are relatively short then there is not as much for players to miss out on, while still giving them the choice of watching the cutscene or not. However, this may also have implications on the game design, if it is not feasible to have some players playing while others are still in the cutscene (such as at a boss fight).
We have not examined the case here because this scenario doesn’t meet the bar of a collective decision for the DECIDE framework. Each player chooses for themselves and it has minimal impact on the experience of other players. However, we note that this scenario seems to work for this specific genre; while there are cutscenes in World of Warcraft, players may be taken to have consented to going into constant combat by choosing to join a group. That implied social consent in the genre is mostly why it seems to work.
Collective decisions are highly prevalent in multiplayer games, but without understanding the anatomy of a decision and various considerations for players in how a decision is made, designers risk creating a player experience that is frustrating, confusing, or simply not engaging. The DECIDE framework presents a straightforward way for designers to understand the elements of a collective decision in a game context in more detail, leading to more robust and meaningful player decisions.
But, we have to go deeper. As we said at the start of a paper, a collective decision is not a singular event, but a series of events–each with a specific purpose–that contributes to an outcome, and which can impact the decision as a whole. We describe these smaller events as the phases in the DECIDE framework, and by understanding the purpose of each phase and what decision dials are included for, designers can make more nuanced design choices to avoid player frustration. For example, if there is a limited time for players to make a decision, why is it set to what it is, and can players influence it once they understand how it works? Or, given that we can only put so many guard rails on player interactions in a multiplayer game, how can we help them make decisions together where players will not frustrate each other given their existing relationships? Or, better yet, how can we design decisions so that players will keep wanting to make them together, through the Evaluate phase?
As we made our way through the various phases of the DECIDE framework, we highlighted common design dials for each, noting potential pitfalls and opportunities for mitigation for each dial. Even within the same decision phase, dials may operate differently for different games, depending on the intended player experience. The two examples we provide show that this can be true, even for pretty straightforward decisions. And while we have used common, simple examples to illustrate our point, we think that there is plenty more room for exploring how the DECIDE framework would apply for multiple complex, iterative, collective decisions.
Even if you have not looked at collective decisions before at this level of granularity, the goal here is not to throw out any existing design methodologies or lead you to despair. Instead, we invite you to reflect on what design dials you are holding fixed, reexamine which ones are dials that you can indeed tweak, and understand how the different phases of the DECIDE framework fit together so you can see what works best for you. Different genres of games will index on different parts of the DECIDE framework differently, so what we have presented here is not a singular, universal methodology with the nuance to solve every problem as it pertains to collective decision making, but rather, a series of dials that you can adjust as appropriate for your project.
We want to thank Natasha Miller and droqen for their extensive and insightful conversations around this topic at Polaris 2024. Some of their ideas have made their way into this paper, and we are grateful for their willingness to share their thoughts with us.