Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
Cooperative gameplay is growing in popularity. Based on extensive research, prototypes, and metrics, here is a design lens and framework for designing prosocial games that build trust between players.
Today I want to share with you a design framework that I’ve been working on for a couple of years now with a team at Google’s Advanced Technology and Projects (ATAP) group, led by Aaron Cammarata. We call it “The Trust Spectrum,” and it’s a practical design lens for designing multiplayer games, particularly ones involving co-operative play.
Aaron led the charge on this project; he formed a group devoted to games that could enhance social connection, and asked me to help out on the game design mechanics side of things. He spent several months reading deeply into psychology and sociology to learn what the latest science said about human connections and social behavior.
In Aaron’s research on social structures, a few things popped out rather quickly.
Play is fundamentally social. Science used to believe that the reason play existed across the entire mammal kingdom was because it served as a form of practice for skills. But it turns out that if you separate and prevent tiger cubs, say, from playing, they grow up quite able to hunt, fight, stalk, and so on (this is from a study by Tim Caro cited in Play: How it Shapes the Brain). They pick up these skills in other ways. What they don’t learn to do — and can never learn — is how to get along with others of their kind. (This doesn’t mean that play doesn’t help skill-building; there’s plenty of science on that too). Play is fundamental to learning social skills, and social skills are a key survival trait because they are an evolutionary benefit; teams working together can accomplish things that individuals working alone cannot.
Humans have a pattern to their social relationships. Simply put, it falls into a pyramid: around 5 really intimate friends, 15 that are less so, around 50 that are more distant, and then an average total of around 150 social connections. This 150 figure is known as Dunbar’s Number, and to be clear, there’s a lot more nuance to it than “you can only have 150 friends.” (Christopher Allen has some excellent writing on misapprehensions of what Dunbar’s Number means, and I’ve discussed social graphing several times on my blog). This kind of increasing intimacy has been found by Dunbar himself in a large study of tens of millions of phone records; and also by those studying games, such as Nick Yee and Nic Ducheneaut in their examinations of guild subgroups in World of Warcraft.
The variable here is trust. Human relationships progress through a set of stages which are pretty well understood. We start out tentative, trying to see what we have in common, then we gradually start relying on one another, and eventually come to trust one another. This is called “Social Penetration Theory,” by the way, and comes from actual experimental data. One thing that the data showed is that high trust doesn’t necessarily mean high trust in every facet of a life. Which leads to the fourth point:
Trust is domain-specific. Just because you implicitly trust your trapeze partner with your life doesn’t mean you trust them with, say, your finances. Social Penetration Theory uses the words “breadth” and “depth” to refer to the spread of domains in which you might have trust versus the degree of trust you might have. It’s a mistake to assume that we might build a game that requires incredibly high trust in your teammates, and that therefore the players of the game will come to trust one another with, say, their children’s well-being. (In fact, a huge portion of the social mechanics that I curated into my talk of that title are in fact ways of dealing with a lack of domain trust).
I’ve written about trust at great length on my blog before. Most of it, however, was focused on the dynamics of large groups, the sorts of structures that emerge when trust is absent. The Trust Spectrum is about the opposite: it’s about trusted groups, and how you design for them.
Why? Because there’s a critical fifth finding, one that sits uncomfortably with the way we live our modern lives:
Mediated communications don’t work as well.
Those five highly trusted individuals? You have to talk. Using your voice. Synchronously. See them. In person. Face to face. Maintaining high trust relationships over phones, over texts, over chats, over Facebook or Twitter -- it just doesn't tend to happen, and the more mediation in the way, the harder it is. Oh, there are confounding variables around things like how long-standing the connection has been, and the aforementioned breadth and depth. But basically, online friendships that lack the synchronicity and personal contact tend to go broad, not deep, as evidenced by Facebook (which has been shown more than once to make people less happy and damage relationships per Tokunaga). Face to face contact has been shown to reduce depression (Teo et al). Social integration improves survival odds (Julianne Holt-Lunstad et al). Happier people spend more time in substantive conversation and less time alone (Matthias R. Mehl, Shannon E. Holleran, C. Shelby Clark, Simine Vazire). We're social animals, in the end. A huge amount of the communicative bandwidth when you are talking to someone lies in things that simply do not translate over the virtual: not just things like tone of voice, but eye contact, body movement, pheromones, and more. (I’ve written before about how having better controls for body language in MMOs would likely improve socialization).
Virtual social bonds evolve from the fictional towards real social bonds. If you have good community ties, they will be out-of-character ties, not in-character ties. In other words, friendships will migrate right out of your world into email, real-life gatherings, etc.
-Koster’s Theorem
Now, I’ve worked for my whole adult life with online communities, and I know that deep trusting relationships definitely do form online. But they also, as is even enshrined in the Laws of Online World Design, migrate out from the virtual setting to the personal (it’s even called “Koster’s Theorem,” and no, it wasn’t me who named it). There are plenty of studies on this going back quite a ways. We’ve seen countless guilds start to have real life weddings, in person gatherings, and much more. You can climb the ladder of trust remotely, but to get to the most trusted relationships, and keep them alive, you need to meet in person.
OK, so how do we turn this into useful design rules?
As we were nearing the end of my time working with Google, Dan Cook published an article on Lost Garden (and later again on Gamasutra) that was the output of a workgroup at Project Horseshoe. It has enormous overlap with what you’re reading, uses many of the same scientific sources, and is very complementary — I highly recommend reading it. Even though Dan and I talk game design when we can and often say very similar things, we didn’t communicate at all on this topic! Dan’s checklist for “Game design patterns for building friendships” looks like this:
Proximity: Put players in serendipitous situations where they regularly encounter other players. Allow them to recognize one another across multiple play sessions.
Similarity: Create shared identities, values, contexts, and goals that ease alignment and connection.
Reciprocity: Enable exchanges (not necessarily material) that are bi-directional with benefits to both parties. With repetition, this builds relationships.
Disclosure: Further grow trust in the relationship through disclosing vulnerability, testing boundaries, etc.
All of these pieces of advice are dead on. Most of them are about moving from strangers to friends; in other words, moving from the “orientation” stages to “exploratory affective,” from outsider to within the 150. Dan has many examples of specific mechanics that accomplish these things, in his article. Our objective, however, was slightly different from the workgroup’s. We wanted not a catalog of mechanics, but something we could measure, ways to deeply break down a game and target it precisely at an audience. Ideally, you’d be able to assess a game, and give it almost a “trust rating,” or perhaps even a spread saying “this game works from this level of trust to this level.”
We did in fact arrive at tools to do that, but I am going to walk you through the process we used to get there, because it’ll probably help understand to it more deeply.
The goal here is to design games that fit with how humans actually interact socially. This means two things:
Designing multiplayer games that make sense for particular levels of trust. In other words, a game might fail if it calls for very high trust, but people tend to play it with strangers or in large groups. Think of the issues that so many players have with pick-up groups in MMOs; think of the endless articles out there on whether to play Diplomacy with your best friends.
Designing games that move people up the trust spectrum. You have to be cautious about this; we started out thinking that we were going to basically make people into better friends via game design, but because of the domain-specific nature of trust, we came to realize that you have to start by building trust within the game’s domain, and from there work outwards — doable, but a much more indirect process. Plainly put – no matter how good a MOBA team we make, I’m not giving you my credit card number. Most games won’t have domains that are broad enough to really shift people’s friendships around, and the ones that do are things that turn into serious commitments: tabletop RPG campaigns, MMOs, and sports teams. And above all, it makes very little sense to try to forcibly push a relationship up into the affective range of the spectrum; odds are excellent that the game is too narrow in breadth, and if the game is broad, that the players in question already have some deep relationships. You can’t ask them to drop a best friend to make room! In many cases, it might be better to instead design a game to work with the trust level that is already there. Or to effectively work on maintaining it. At the very least, the game should only invite intimacy rather than force it.
So, one would think we could just start putting game mechanics into tiers, and indeed that was how we started out, with a list of over 200 game mechanics that we tried to sort into buckets. We used “vulnerability” as our basic sorting function, since trust is driven so strongly by the level of implied risk if trust is broken. We also just started designing games that were meant to go at different levels.
It didn’t work.
The design problem with breaking game mechanics into trust levels is that virtually all games are actually played at all levels of this spectrum; meaning, you can play competitive games with friends or strangers, a bidding system or supply chain system may exist at any point on the spectrum, etc.
Games designed specifically to leverage elements from different levels of the trust spectrum do have different sorts of characteristics, though. So a more fruitful approach is to ask, what games cannot be played unless at a given level of intimacy or trust?
For example, games exist wherein there is an implicit level of trust that permits good play. All team coordination games are of this sort. In many, there are implicit trust maneuvers which can only be carried out by the assumption that the team member will be positioned correctly in order to assist. Examples might include doubles tennis, or volleyball, particularly two-person beach volleyball. “Blind” moves where trust alone completes the pass is one of the most common features of high end team play in sports: the initiator of the move passes the ball to empty air, and simply trusts that the receiver will move into position at the exact right time.
At the highest levels of trust exist games of complex coordination involving physical risk, such as that trapeze example, or certain forms of dance, where a failure in trust will result in a significant loss. Think of ice dancing and pairs figure skating, where you have bodies in motion on hard unforgiving surfaces, literally throwing your entire body weight onto someone else who is precariously balanced on moving sharp blades which sometimes swing close to your eye. Heck, sometimes you have to grab said moving sharp blade. Talk about trust falls!
Similarly, there are games where deep knowledge of other players’ thinking patterns and knowledge base permits better play. Examples include games of limited communication, such as charades or bridge. Limiting communication allows people who know each other well to communicate using shorthand of various sorts.
A lot of these games rely on rote “plays” or extensive repetitive training, so that players are used to being in their appropriate positions and roles. This is something that turned out to be a powerful idea – subgames where people have to practice certain maneuvers, but when connected with other players’ maneuvers, they result in a beautiful dance.
A different level of trust is that manufactured purely by fixed roles, where the game effectively implies a sort of economic exchange between players. Many team games have this sort of thing going on – one thinks of soccer, for example, or basketball. These do feature implicit trust moves and blind passes and the like so they stretch to high trust. But they are functional (meaning, you can play at all) at much lower trust levels, because the role is almost parallel play, and it’s a lower trust exchange. Examples here include stuff like throwing in the ball from the sidelines in soccer.
An additional interesting observation is that in practice, most advanced social mechanics are actually about working around a lack of trust among participants. For example, LARPing systems must involve elaborate consent mechanisms and conventions; large-scale economic play in MMOs involves contracts and supply chains and other such things that are meant to ameliorate the fact that trust does not, and cannot, exist at large scales.
Using this as a rough rubric, then we started to classify some broad groups of mechanics as higher or lower levels of trust. As source data, we surveyed gamers of all sorts with the assistance of Quantic Foundry, including several types of digital gamers as well as tabletop players. Quantic Foundry is a market research company focused on gamer motivation. They have developed an empirical model of 12 gaming motivations based on research from over 350,000 gamers. We teased out similarities and differences in play patterns across casual games, lightweight party games, pen and paper RPGs, online multiplayer shooters, clan-style mobile games, MMORPGs, and more.
Some of the findings that are worth mentioning:
People are actually pretty wary of “games about trust,” at least when described that way.
There are clear gender differences in the survey data. Self-reported women are considerably more wary than men are.
Women prefer social fun to conflict, and men are the reverse. But these are not the inverse of one another. You might think that conflict with your friends and light social stuff would be contrary impulses, but they’re not. Social connection happens either way, and appeals either way.
But either way, cooperation is not a huge driver. In board games, for example, cooperation was dead last as the main motivation for playing, for men — and “winning” was on top. It wasn’t dead last for women, but the percentage of women interested in it as a primary driver was around the same (and they liked winning just as much, but they likes accessibility and social fun more).
People prefer, in order, competing with friends, co-op with friends, competing with strangers — and then, trailing way behind, co-operating with strangers. And the first three were clustered pretty tightly. Meeting new people was of less interest than deepening existing friendships, and trusting new people on your team was right out.
There’s a strong correlation between frequency of play and social motivations. The more interested in community, competition, excitement, and destruction a player was (using Quantic Foundry‘s terms here), the more likely the player was to want to play frequently.
10-30 minutes was a sweet spot for game session length, but longer was fine. And 3-4 people was a sweet spot size.
There were also a few clusters that appeared that gave a new lens on “casual” and “hardcore” via social trust.
In digital we saw
A group that plays more hours, tilts male, tilts towards competitive and aggressive games, and that were more willing to try co-op with strangers.
A group that tilts female, and is just less enthused about social play in general, and tilts towards games where you complete things.
In analog we saw something with striking similarities and differences, which likely speaks to the culture of online games:
A group that plays often and regularly, often with strangers, tilts towards deeper strategy games and conflict, and start to tilt older.
A group that plays opportunistically and less often, likes social fun and luck, drift a little bit towards games that have only two players and have shorter sessions, and are less fond of social manipulation, deep strategy, and conflict.
Everyone likes immersion, everyone likes winning and being competitive. As Emily Greer has pointed out, the definitions of casual and hardcore, or genre preference, are often presented as gendered when playstyle preference isn't. But it was pretty clear that trust is a very important component in whether someone plays games casually or more as a hobbyist, and that it’s an important element in thinking about games with friends versus strangers, particularly for women playing online.
Using the types of features people preferred, the play patterns and audiences for specific game types, and the demographic information on the players, we ended up with a rich data set that let us start to draw empirical conclusions at a high level that cut across every sort of game regardless of platform or physicality. As examples:
Low trust games tend to feature solo activity and parallel play, the mechanics tend to offer verification (think contracts, exchange, bidding), and they focus a lot on identity systems and status. Obviously, competitive games tend to fall in this range. The game of Diplomacy actually relies almost entirely on the idea that contracts aren’t enforceable.
Acquaintance games start to offer low end co-operation. Classic party games like Charades, Pictionary, Apples to Apples, Cards Against Humanity, and the like are all about getting to know other people and how they think; they offer specific roles that players take on that make boundaries very clear. Players help each other, though competition is still a feature. Teams may be a requirement, but teammates don’t need to practice much. Instead, simple reciprocity is all that’s called for. And in many games we see contracts, supply chains, light touch economic interdependence, elections voting systems, and other forms of mediated trust. This is where all that social architecture in Star Wars Galaxies lived, for example. Rock Band is a great example of a game that sets up roles with tight boundaries, limits how much damage you can do to your partners, and basically sets up contracts between players.
Games that call for friends start demanding you to know your partners well indeed. Non-verbal communication, incomplete information, blind moves, synchronous coordination, and so on. Bridge is a an excellent example among card games. Actual musicianship calls for this, when playing in a group; unlike Rock Band, you don’t have a handy screen telling you what everyone else is about to try to do. You start getting games where an individual’s failure means the team fails. Here is where something like Overwatch is thriving.
True high trust games start featuring permadeath mechanics (the closest we can get to physical risk in a non-physical game), prisoner’s dilemma, self-sacrifice for the good of the group, and so on.
Diving deeper into these makes us realize that what we are seeing is actually several complementary axes. For example, awareness of game state is something that seems to pretty cleanly map on an axis correlated with trust. The less visibility you have into what your team is doing, the more trust that is required. This is a better way of thinking of the issue than trying to fit “fog of war” and “1st person camera” into a rubric. So a higher level of abstraction was needed.
From the PARC PlayOn paper “Alone Together?”
We took the step back and realized that we needed to define some terms that would help us think more clearly about all this.
Let’s start with the notion of parallel play. There are two common usages of this, and they both basically mean the same thing.
Parallel play as playing alone together. In early childhood education, we speak of parallel play as a developmental phase that children go through, usually around ages 2 to 3. It has echoes in the notion of “playing alone together” that was so widely discussed around the launch of World of Warcraft. In hindsight it can be seen that part of the reason for WoW’s success is that it is more playable at low trust levels that the other games of its time were. That is also where criticisms of it as a less social MMO came from; at every stage of the game until raids, it demanded less trust from teammates. This is a huge amount of what is meant by “soloability.” Dependence on others has a host of effects that can boil down to trust. Can I trust my teammate to do what I need? Will they even show up? Will they devote two hours to our mutual enjoyment? Yes, grindiness and difficulty are of course the other key factors in whether a game is casually approachable, but in any multiplayer setting, trust has to be seen as equally important.
Parallel play as players playing two sessions of the same game simultaneously and then being measured against one another. In the game grammar design lens, we speak of parallel play in more formal terms. The 100m dash is an example of a parallel game: each player is actually racing against physics, their own body, the weather, and of course, the clock, as much as they are racing against one another. But importantly, what one racer does does not impinge upon what the others do, at least not directly. If you can or cannot see the other racer, there’s almost certainly some amount of emotional component which will affect your performance… but let’s speak in slightly less rigid terms and say that the racers do not directly impinge on one another’s outcome.
But in games of trust, we’re talking about a range of games where competition is only at the lowest end of the trust scale. At higher levels of trust, we are discussing players on the same team playing with varying degrees of parallelism. In short, parallel play in the childhood education sense is pretty low trust; the footrace is lower still, because it’s actively competitive. The higher you go in the trust spectrum, the less parallel play you see — though as designers, we should be careful never to eradicate it altogether, because if you do, you lose that casual accessibility.
In order to get less parallel play, we have to take the standard terms for symmetric and asymmetric games and apply them to the players on one team. Essentially, symmetry is what permits maximal parallel play. We can think of it as whether players have identical or different capabilities.
In regular head to head games, symmetry and asymmetry are easy to see. Go, Chess, Checkers, Monopoly, Scrabble: all symmetric. And indeed, this is by far the commonest mode in tabletop games. Fox and Geese is asymmetric; there’s one fox on the board and a bunch of geese, and the two sides have different win conditions. Hnefatafl is asymmetric. In videogames, we see the reverse thanks to one of the players being an AI; Pong is symmetric, but in Space Invaders you play against a computer who marshals very different resources from your own.
In team-based games, we have to start thinking within the team.
Think of a basket of verbs. In the case of our hypothetical footrace, all racers have the same basic verbs they can perform: running, breathing. We have symmetry at the verb level (though not at the statistical level — players all have different speed, aerobic capacity, etc — and not at the tactical or strategic level, and of such things is the contest made).
Contrast this to a game of soccer or hockey, where we immediately see that players are not symmetric; we have positions on the team. The goalie in soccer is allowed to touch the ball with their hands; nobody else on the team is, so there’s an example of a unique verb (“catch”) that only one position has.
Asymmetry is complicated. Because there may be quite a suite of verbs available to players as a whole, and some verbs may be available to only one, to several, or to all of the players on a team, we have to think in an abstracted way about symmetry as well. Further, many games — think of soccer again — might actually have the same verbs available to people who are playing different positions, and therefore serve a different purpose on a team.
We landed on two terms. A role was defined as a strategic approach to play. This is the difference between a defense player and a striker in soccer; they have the same set of verbs available to them if you think in terms of verbs as only being “things you can tie to outputs” in the low level sense that I usually use in game grammar. A defense player and a striker can both run, they can both kick the ball, neither are allowed to use their hands.
But games are fractal, made of games. If you “pop the stack” a little, and think about the game one step out from the verbs you input, at the level of dynamics, if you like, you can see that “attack” and “defend” are also verbs, they just exist at the tactical level. (Side note: this is actually how I encourage people to use game grammar diagrams; mapping down at the verb level is an extremely useful tool for detailed analysis, but most structural problems with games are at the tactical level, not the verb level).
A role is distinct from the other term in extremely common use, which is class. A class is best thought of as a fixed basket of player abilities. Goalie is a class as well as a role. A cleric or a paladin are classes; but either one may take on the role of healer. Classes are way less common in sports than in other types of games such as tabletop or digital, because of course human bodies tend to all have the same affordances. Any classes in sports therefore have to be created by the game’s rules. In baseball, for example, pitcher is a class, catcher is a class. They have special “abilities” no other player on their team has.
Classes, roles, and parallelism give us ways to look at the spectrum of interaction in a cleaner way; but there’s one last thing that we have to account for, however, which is that many types of coordination problems involve resource allocation. And again, it’s best to think of this in abstract ways. Two defenders in soccer are allocated different areas of the field to cover; in soccer, physical space is literally a resource pool to consider. In a relay race, each racer is actually allocated a segment of the race. In other games, it might be how many potions are in the guild bank, or some other sort of limited resource.
Now, as you might guess, looking at each of these gives us differences in trust based on how much of that feature is present. Lots of parallel play, few roles, no classes, independent resources, and you’re down in low trust land. Start adding many roles but keep the other factors the same, and you don’t hugely affect the trust level, but you broaden the game’s audience (more roles equals more playstyles which equals broader appeal). Push roles all the way to classes, and you have reduced accessibility because it means the game isn’t playable without a full team — which is hard to get coordinated but also means the team has to practice with one another to feel competent.
On the other hand, if you did add those classes, but made it so they actually served a smaller number of roles, and the things the roles could do had lots of overlap, then you’re basically enabling trust to exist at either level. Medium trust players and maybe even low trust players could form ad hoc teams and have lots of duplicate role coverage on the team. This reduces the amount of trust they need to have in one another. Advanced teams might actually choose non-overlapping specialists, which means tons of dependency on your teammates. It also means that the game likely has a higher skill ceiling, meaning there is depth there for players to master. So you can ameliorate some choices by pushing one of the other variables in the other direction. It’s the interaction of all of them that ends up shaping the trust level for the game.
In short, you end up with some sliding scales.
Parallel play basically means “ability to play without dependencies.” This is a scale from “completely” to “not.”
Asymmetry means “how different are the teammates from one another?” This is also a scale from “completely” to “not” and subsumes two different kinds of ways to be different:
A role means “how many strategic objectives or ways to play are there?” This is a scale from one to many.
A class means “how are the verbs allocated across the team?” This is a scale from everyone sharing verbs in common to nobody sharing verbs in common.
Resource pool sharing means “how are team resources allocated?” and might range from “independent” to “completely shared.”
That’s all very abstract. Let’s get concrete with some examples of well-known games.
Lots of shoot-em-ups let two players fly their ships at the same time. Raiden is one classic example.
The degree of parallelism is high; little you do impinges on the other player. There are very few things done in coordination. Critically, each player “can play the whole game” without the other.
Players have exactly the same verbs: fly and shoot and pick stuff up. There are pickups that let them adjust their weaponry, but these aren’t formal classes where abilities are unavailable to the other player.
Players can negotiate roles. Pickups let them actually add some strategic verbs to their arsenal; for example, one player might have a wide spread shot and the other a powerful narrow one. This lets one player play defense and the other offense.
Most resource pools are independent: score, lives, etc. The principal shared resources are pickups, which appear in a shared pool on the screen before being allocated; and actual screen space itself.
All in all, Raiden evaluates out as pretty low trust. The presence or absence of another player doesn’t make that big a difference to you as a player, and what synergies arise from teamwork are entirely optional.
Gauntlet adds some much more rigid stuff into the mix, such as classes. But when we look at the verbs, we find that the classes aren’t that significantly different from one another. All four classes in the original game have melee, ranged, and magic attacks, so there are no verb differences. Instead, the real differences are statistical: movement rates, damage taken, damage dealt, magic strength, and so on. Again, there are pickups on the field, the most important of which is health (since all players are on a constant timer ticking down). However, a number of subtle design choices make a massive different to the trust spectrum.
Parallelism is lessened, because roles are strongly pushed by the statistical variances and the actual layout of the corridors.
Though players have the same verbs, the stats differences mean that some players are simply better at some actions than others. These are the same sorts of differences that can cause a human player to be assigned different positions in a team sport. Only one real ability difference exists, which is that the warrior can’t shoot through diagonal gaps because their shot (the axe) is too wide.
The result is that the game has classes that are mostly cosmetic, while still offering varying roles. In fact, you could make a case that using the lens of available verbs, there are actually only two classes: “players who can shoot through diagonal gaps” and “the warrior.” Everything else is statistical differences.
The roles aren’t rigid — instead, anyone can do anything, but not at all times. This sort of difference eventually led us to the notion of role actions which could be exclusive, non-exclusive, or redundant, about which more later.
The resource pools are interesting! Remember, space to move is a resource. By not providing enough physical space for players to proceed four abreast, and by having varying movement rates, players very naturally fall into soft roles of tank, rear guard, long-distance nuker, and so on. The various pickups offer more help to some of the classes than others; as we all know, the “Wizard needs food badly.”
I’ve mentioned trapeze multiple times here, and as you might guess, it’s very high trust.
The degree of parallelism is pretty low — each performer can do quite a lot of moves by themselves. But a huge amount of the moves are actually tandem moves.
There are some verbs that are designed in pairs — “jump” and “catch” being the most dramatic. These are exclusive to one another; the player who jumps cannot catch, at least on that particular move.
It’s pretty common for the roles of jumper and catcher to alternate or switch off in some fashion. This implies they are roles, not classes. And indeed, classes are, all things considered, relatively rare in real world sports.
Of course, the big thing is the shared resource pool. Each player has one life, and they basically hand custody of it over to the other player.
A key thing about trapeze, then, is that it doesn’t really have much of an on-ramp. It’s hard to find low-trust trapeze! (Well, more than once anyway…) This may be why traditionally it’s been done by families, where high trust relationships already exist.
This is what makes games like soccer so interesting. Soccer is one of the most democratic games in the world. Its variants range from street soccer played with a ball of twine or tied up t-shirts, with a couple of rocks serving as goalposts, all the way up to the sort played in stadiums. At the low end, street soccer is often played one on one, with no team at all! Garage doors make for a great goal that provides a “crossbeam,” if you decide to play two on one; one player acts as goalie in front of the garage door, and the other two try to score against them in a two-team asymmetric game. And of course, there’s the common sight of a host of smaller kids who haven’t learned team coordination “playing alone together” and all chasing the ball around on a larger pitch.
Soccer therefore has a very low trust on-ramp for players who want to start learning basic skills. But at the high end of play, soccer exhibits a whole bunch of high trust traits.
Played well, soccer has low parallelism. The score is common to the team, not to each individual. Goalies aren’t even measured the the same yardsticks as strikers; it’s far more important for them to block goals than it is for them to score them.
Soccer does have actual classes. Goalies can use their hands. None of the other players can except in tightly defined circumstances.
It also has roles — a lot of them — and because of the size of the pitch, these roles really matter. You have to allocate responsibility over very large physical areas to individual teammates simply because travel time is long. Compare this to basketball, where the relatively small field of play means that “role swapping” can be done in a few long strides, and often is. Soccer at a high level of play means subsuming your fun to the team’s success, because you spend a lot of time standing around hoping that your teammates will make use of you, unable to move away from your position and area of influence lest a need for you there arise.
Because of this, moves that happen in soccer are often high risk: “blind passes” where one player kicks the ball not to where their teammate actually is, but where they are supposed to be in fifteen seconds. A failure to coordinate in this way almost certainly means loss of possession, and may well mean far worse, up to and including things like own goals, where you score a point for the opposing team.
There are many sports that exhibit some of these characteristics. Basketball, volleyball, and American football all rely on the same sort of blind passes. It’s worth thinking about why soccer is the most popular of all of these, worldwide, and some of the answer may rest in the game’s breadth across the trust spectrum (as well as the simplicity of the equipment required). Football has far more rigid roles in the mix — one reason why it’s fundamentally a less accessible game. Football is harder to play without a larger group, because of the dependency on specific roles — for example, at the moment of hiking the ball. Volleyball actually can’t function without high trust because it’s so dependent on blind passes (which call for a good amount of skill to boot), and the roles are way more rigid. In volleyball and basketball, there are rules that basically affect how long an individual can maintain control of the ball, which forces coordination and therefore trust (one-on-one basketball may or may not bend the rules here a bit, and of course, the NBA itself has progressively bent the traveling rule over the decades, reducing the amount of teamwork required in the game).
We might therefore plot all these games on a chart and see that they have a trust range to them.
One exercise we found helpful was actually to map individual features onto this range. It is capable of showing you a potential design flaw which none of the above games have — a broken line. See how soccer stretches seamlessly across a range? How other games have narrower ranges, but still cover a gamut? Well, it’s entirely possible (we did it, by accident) to create a game that has a set of low trust features and then one or more high trust features, and nothing in the middle. And if you don’t have the stuff in the middle, then the game is actually effectively broken. There’s no way for players to move through the levels of trust formation with teammates if there aren’t game features that let them do that.
Some basic things this suggests as rules of thumb, and which we were able to compare back against our research data and validate:
Your audience size is strongly driven by how low your game can go on the trust spectrum. Low trust is simply more accessible.
High trust games almost certainly have higher skill ceilings and depth. Other players and the coordination problems they present create this depth.
A pure low trust co-op game will retain worse. It won’t tend to drive the same sort of community formation as ones that develop trust between users and therefore social bonds, unless it also has just really great mechanics with a lot of depth to them (fighting games come to mind here as an example of really rich low to no trust games that do this… but it’s hard to find other examples).
The awesome ideal team game would have a seamless ramp of features from no trust all the way through high trust. This, it turns out, is rather hard to design well.
This, however, while useful, is still not detailed enough for us to really start designing with. Just as an example, one of the classic challenges in co-operative game design is what is called the Quarterback Problem. This description from BoardGameGeek is a good overview of it:
Many coop games are superficial, in reality being nothing more than a single-player game under the management of a group. As a result, there is plenty of space for the dominating player who knows the game best to become that single-player, orchestrating their plan – like a puppet-master – through the rest of the group.
Pandemic is an example of a game that is often criticized for being vulnerable to this design problem. As one might guess, football itself is of course a poster child for it; the roles played by most of the team don’t have many interesting decisions to make. The trust spectrum above doesn’t (yet) give us the tools to address that issue. And yet games ranging from Killer Queen to Spaceteam don’t seem to have it.
In looking at the ways those two large axes of parallelism vs asymmetry and shared vs individual resources manifest even in those examples above, we see that we need to break the framework down into even more detail.
There’s a basic spectrum for parallel play (playing alone together) through extreme asymmetry via classes that have fully exclusive roles.
Once you are asymmetric at all, you can layer on the question of resource pools, and whether they are shared or not. We can term this risk. Note that time is a resource pool, and therefore we see slow games and especially turn-based games tend to live at the lower end of the trust spectrum, and high-speed actions often reside on the higher end. Relying on a partner’s tight execution is typically a time problem.
Agency is a new spectrum that appears as subsidiary to role exclusivity. This is the spectrum on which the Quarterbacking Problem lives at the bottom end — it’s best defined in these terms as “individual agency is low.” At the high end, every player has high agency, but you may be allowing other players to make decisions for you at times that are very high risk. We can think of the agency scale as moving from “unwilling surrender of agency” through “has individual agency” to “willing surrender of agency.”
The information horizon affects both individual agency (the quarterbacking problem can’t rear its head if you don’t even have time to talk) andalso imperfect information. Not having all the information about your teammates is where blind moves and other such high trust moments come from. Time pressure also escalates the information problem.
Success metrics, and whether they are shared, symmetric, asymmetric, and so on, also affect trust. There’s a boomlet in players having secret objectives in co-op tabletop games; this calls for less trust than a game where everyone is in the same boat.
These all start arising organically from one another, as you can see, but they are deeply intertwined and mutually dependent. You quickly end up with a table sort of like this:
No trust
Forms of parallelism and asymmetry | Teams | Probably don’t exist | May exist, ad hoc | Exist |
|---|---|---|---|---|
Roles | Everyone can do the same things | Overlapping roles let players supplement one another | Increased dependence | Classes or other forms of high dependency |
Agency | Control over self | Can cooperate | Connected moves, combos with other players | Moves made on behalf of other players |
Success metrics | Individual metrics | Mix of individual and shared metrics | Shared metrics only | Self-sacrificing success, where teams win but individuals may suffer |
Types of shared resources and liabilities | Risk | Light or no loss from a trust fail | Lose incremental status only; relatively painless | Tough penalties for trust fails |
Information | Perfect information on stats and resources | Imperfect information | Imperfect info and/or time pressure causing cognitive load | No information on shared pools and resources, nor on teammate status |
Exchange | Secure trade, code-verified systems | Gifting or other altruistic actions, to drive reciprocity | Synchronous exchanges | Blind giving of one’s own critical resources without knowing recipient state |
Time | Low time pressure for coordination, asynch gameplay | Escalating time pressure | Synchronous real-time play | Synchronous, in-person play, often with high time pressure |
Further, we can take some of our example games and look at them using this rubric, and see exactly how they play out:
As expected, the detailed breakdown shows why Raiden can spread across low trust and no trust at all. The two player version is a lightweight introductory game suitable for people who don’t know each other well, and there’s only so much you can do to coordinate.
No trust | Low trust | Medium trust |
|---|---|---|
Forms of parallelism and asymmetry | Teams | Ad hoc |
Roles | Overlapping roles let players supplement one another | |
Agency | Control over self | |
Success metrics | Individual metrics | Mix of individual and shared metrics |
Types of shared resources and liabilities | Risk | Light or no loss from a trust fail |
Information | Perfect information on stats and resources | |
Exchange | Secure trade, code-verified systems | |
Time | Escalating time pressure |
Here we can see that soccer supports more than one trust level to play at within the same axis, which is what gives it such accessibility and a high trust range. You can play soccer with teams or without, and the teams might be high trust and high investment things like playing for Barcelona, or might be a pick up game in the street. You can play in ways that ignore other players, or play at high levels of coordination. You can pay more attention to your own stats, or to how the team does. And so on.
No trust
Forms of parallelism and asymmetry | Teams | Probably don’t exist | May exist, ad hoc |
|---|---|---|---|
Roles | Overlapping roles let players supplement one another | Increased dependence | Classes or other forms of high dependency |
Agency | Control over self | Can cooperate | Connected moves, combos with other players |
Success metrics | Mix of individual and shared metrics | Self-sacrificing success, where teams win but individuals may suffer | |
Types of shared resources and liabilities | Risk | Tough penalties for trust fails | |
Information | Imperfect info and/or time pressure causing cognitive load | ||
Exchange | Blind giving of one’s own critical resources without knowing recipient state | ||
Time | Synchronous, in-person play, often with high time pressure |
Well, it’s basically terrifying.
No trust | Low trust | Medium trust |
|---|---|---|
Forms of parallelism and asymmetry | Teams | Exist and tend to persist |
Roles | Classes or other forms of high dependency | |
Agency | Connected moves, combos with other players | Moves made on behalf of other players |
Success metrics | Self-sacrificing success, where teams win but individuals may suffer | |
Types of shared resources and liabilities | Risk | “Permadeath” style penalties, calling for perfect team coordination |
Information | No information on shared pools and resources, nor on teammate status | |
Exchange | Blind giving of one’s own critical resources without knowing recipient state | |
Time | Synchronous, in-person play, often with high time pressure |
As you can see, these detailed breakdowns line up very well to the high-level trust ranges that were in the earlier trust range image.
If you’re just aiming for a game at a particular trust level, the advice is easy:
…should mostly be limited to parallel play, and symmetric mechanics. Of course, all solo play mechanics fit here too.
Opposition or co-op doesn’t matter, really. The main thing is that activities are transactional. For example, the classic game of tossing eggs back and forth, as played at fairs, is really sequential challenges that one player poses to the other; there’s relatively little coordination required beyond the basics.
Because of low trust, exchanges of in-game economic nature are verified in some fashion (contract, supply chain, etc). Identity and status systems are important to support at this stage.
Games may include teams, but ones where all team members are on equal footing in terms of capabilities and verbs. Games may be last-man-standing or otherwise about individual success.
Games can leverage plenty of intermediate achievement status, persisted progress, etc.
…start including non-parallel play. Now the players perform inside of linked systems. Asymmetric mechanics start to rear their heads.
Games can be a mix of co-op and oppositional; when oppositional, you should lean towards teams. When co-op, you should learn towards roles. Particularly useful are roles that shift, such as tools you can pick up that change how you play (like Raiden’s weapons). These let players build trust up gradually.
Roles that are broken out but are overlapping. A midfielder can also strike and score a goal. There’s healers but also potions. This reduces the trust dependency on any one other player. (As an example, the Spaceteam card game has generic symbols that are requirements that could be met by anyone; the Spaceteam mobile app is higher trust because each task can only be met by one other person).
Games with the ability to help (e.g, an exchange of in game economic value, information, even emotional support, but with no quid pro quo). Reciprocity should be enabled.
By and large perfect information about teammates or co-op player state should be available. Where imperfect information is used, it may be used against opponents.
It’s worth pointing out that this is the range in which the Quarterback Problem tends to manifest. It can be mitigated by increasing time pressure or decreasing information horizon.
…should be premised heavily on “blind moves.” The design definition here is a move where one player executes a move or task that is a vitally required element to success, but only provides half the requirement but cannot see that the other player is there to “catch it” and execute the second half. The other player executes the other half, but must have made preparatory moves of some sort that enable them to be “in position,” and the first player can’t see this.
Another core mechanic of these games should be the idea that other players have information that the player does not, and she has to rely on interpreting their actions in order to perform her move.
Play where both players must execute actions in tandem, falling into synchrony. Merely matching is good; playing “harmony” is better.
Play where you can only make moves for other players, and they can only make moves for you, or only specific sorts of moves. Player roles where the actions performed are asymmetric – roles cannot easily supplement each other, to increase the mandatory dependency on the other player, and the higher risk if the one player fails to provide.
Games where there is tightly limited information that flows between the players, and they must rely on their knowledge of the other player. Imperfect information in general fits here, but critically, cases where the information about other players on your side is imperfect.
Success states here may be about your friends succeeding, not you.
…should add escalating challenge where failure results in starting the task over from scratch or having no intermediate gains. No incremental stuff – this means that a failure to coordinate perfectly stings. Basically, permadeath mechanics of some sort.
They also can up the ante on the structure used for friends for coordinated moves, by not providing feedback on what move the other player actually chose for a coordinated move. In other words, the imperfect information gets even cloudier.
Making a high trust game isn’t hard. Here’s an example. Let’s say you have a fast-paced game where your health always goes down. You can’t raise it yourself. What you can do is give some of your own health to someone else. Let’s also say there is stuff to pick up that adds health back. But there’s also something hunting you — a doppelganger that instantly slays you if it touches you. And you can’t fight back. A teammate can easily dispose of your doppelganger by touching it, but the doppelganger respawns fairly quickly. But every player has a doppelganger too… and dying puts you out of the game entirely. If all the stuff to pick up is grabbed, you all go to the next level, and all come back into the game. If even one item is left to collect when the last player is touched by their doppelganger, you all lose.
What we have is a system where
You can’t defend yourself, but you can defend others (shared pools)
You can’t even keep yourself alive, but you can keep others alive (shifting roles)
You all have a selfish motive, but if you don’t allocate resources you will each die from health loss (shared pools again)
There’s a powerful feedback loop when someone gets knocked out from a level (high risk)
I could go on… this is a high trust game, and can be amazing to watch and terrifying to play. You can already picture the moment when a player with almost no health left throws themselves in front of a doppelganger to sacrifice themselves, allowing the last player to just barely touch the last required item to beat the level. Self-sacrifice for the good of the team, altruism, tight coordination under time pressure… it’s all there. I know, because we built a couple of games very much like this, and they were fun almost immediately, generating all the sort of social responses we wanted: cheers, groans, emotional support when someone was caught in a tough situation, valiant self-sacrifices, recriminations when a teammate let you down, and all the rest.
But a pure high trust game is also incredibly inaccessible, because a novice team will screw up quickly and perish in ways they don’t even understand. In fact, one of our prototypes was so fragile that adjusting the size of the map broke it completely, because it increased time pressure to the degree that we couldn’t even play effectively.
So yeah, it’s easy to design a high trust game, once you are in the mindset. What’s hard is designing for high and low trust at the same time. Something like soccer, a game that has an incredibly wide spread, starts introducing real complications precisely because you are working with multiple trust levels at once. You have to supply mechanics that work in roles or solo, classes and parallelism, shared and individual success.
The solution to this is to be very very careful and analytical about your interdependencies. Here are some rules of thumb we uncovered through prototyping:
Have classes and roles with unique abilities. Prevent a player from being good at the totality of the game with any given class. This is a tricky line to walk, since you want the game fully playable with any one class. But you have to also aim for a low player efficiency. This player shouldn’t be able to crush the game, not by a long shot. If anything, as they hop around classes or roles, they should start to gain an appreciation for the varied roles other players would play in the ecosystem, and start to crave their presence (this echoes old lessons from MMO game design in terms of weak ties and asynchronous play).
Design your game with different roles, but don’t make those roles overly hardcoded. Instead, design for strategic roles – dynamics, rather than mechanics. Aim for roles that players can take on, given the unique skill set they may have either via their own preferences or hardcoded roles. Think of it as role vs class. Design four classes, say, with hardcoded capabilities; but design five or six roles, such as “defense,” “scorer,” “striker,” “quarterback,” and so on. Then make each class capable of performing more than one role.
But make sure that there are some abilities held in common across everyone, and that these are parallel play abilities. In fact, make this the easiest way to play the game. Have the easiest strategic role in the game be something adequate and easy to master that any player can take on anytime. Allow it to be something that can “play” the entire team game solo, just poorly or not very effectively. This allows for varying skill levels in the game at once, and allows arbitrary sized groups of players. This role should be either available to all classes, or players should be able to switch to that class readily on the fly.
And make it so that ability can aim at a shared success metric.
This gives you the equivalent of little kids all chasing the ball and kicking for the goal in soccer.
In our case, rigid roles prevented the design from achieving both the high end and the low end on the Trust Spectrum. By having truly rigid roles, the need for player cooperation was driven up, which meant access for low trust groups was limited. But it also meant that players couldn’t easily innovate on the high end of play, creating unique trust-based dynamics that reward extremely high levels of skill and reliance upon teammates.
Supporting a variable number of players doesn’t work well with firm roles either. Rigid roles force each key position to be occupied; not having enough players means that some roles effectively need to become optional, which then means they will likely start to fail to meet other goals (such as fun factor, depth, or trust). For accessibility purposes, it will be important to allow variable size groups, the ability to drop in and out of the game, and so on. Loose roles only assist with this.
Have a careful spread of statistical variation across the roles and classes.
Some faster, some slower. Some more accurate, some bigger. Find at least two stats across the roles.
Have inverse ramps across the roles. For example, favor speed and accuracy in the striker, but size and strength in the goalie.
Ensure none of these preclude being able to hit the aforementioned success metric, just with different tactical choices.
This lets players find niches and roles, and gives them an on-ramp towards specialization. The inverse ramps mean that you can develop tactical pairings of roles based on complementary attributes.
Ensure that every role is fun in its own right, with its own reward loop and success metric. The shorthand for this is “every role should be a full game.” A good enough goalie could in theory win a soccer match by herself. Each role must feel like a fun and viable game to play in its own right, or else the role feels very passive. Ideally, it has its own skill thresholding, high skill ceiling, secrets to uncover, and so on.
But provide linkages between roles where there are designed dependencies. Goalies and defenders work together in soccer. Goalies also work with midfielders, when they serve the ball forward. Midfielders feed strikers. Strikers need midfielders to guard. Examine every pairing of roles. They don’t all need to have a pairing, but the more the better.
Allow these roles to be “soft” despite your class limitations; permit a midfielder to act as a striker if the circumstance arises.
This creates the opportunity for high level coordinated play, without mandating it. The statistical differences between players who tend to play striker versus goalie will also make for emergent group strategies.
This creates yet another way to pair — instead of it being by attribute, it’s by combo.
Use a mix of high time pressure and low time pressure within the same game.
Larger play field, territory allocation, and travel time help provide space in soccer, but also create “fog of war.” It is very hard to have real situational awareness for what is going on with another player if you also have a game to play. If your activity peaks are frequent and the troughs brief, it’s very likely that the player will be unable to scan the playfield for what’s going on. But you’ll likely push for frequent peaks in order to keep each class or role engaging. So architect in pauses in each class or role’s play.
Don’t require a player with high activity or cognitive threshold to also pay attention to another player. They won’t have the bandwidth. A given role must be pretty absorbing, or it will be passive. So instead, you need to rely on players to call out for help somehow, or for the visibility of another player being in trouble to be dramatic and interrupting of the cognitive flow of the player. Obviously, this could be done with a class whose role it is to pay attention to others, but you’ll need to ensure that they don’t have long droughts of gameplay.
Extremely rapid accurate play is demanded periodically, but it ebbs and flows.
This allows high pressure play to manifest only when the players themselves are capable of it.
We built prototypes that proved these rules of thumb out too. But we also found that it was quite a tough design challenge, and as we worked on it, it was easy to break the intricate relationships. Among the mistakes we made:
Having no commonly shared way to avoid loss. Imagine if only the goalie was allowed to steal the ball or step in front of the goal. Imagine if little kids couldn’t all rush the ball and have a fun time.
While also having “key positions” which if left unfilled or played poorly result in everyone’s loss. Imagine if only one striker were allowed to score goals. Imagine a baseball team with no pitcher.
Having high pressure all the time, which means execution risk is always high and there is no gradual learning ramp with less pressure. Trapeze artists start low to the ground and with lots of nets.
Having a very few long combo chains across roles, rather than many small ones that are just pairings. This leads to rigid strategies, low skill ceiling, boring roles, and high execution risk.
So, these days, of course, there’s metrics systems. All this stuff you’ve been reading seems highly… theoretical. Is there a way to actually measure these behaviors? It’s easy to measure things like conversion, retention, or number of friends or even time spent playing between a given pair of players. But that doesn’t give you actionable things you can apply to the design; as we have seen, any number of things in the game may end up greatly affecting where the game lands in terms of trust. What we would need are objective metrics that we can apply so that we aren’t looking for the why of things, but instead the how.
The challenge is that different games can build radically different sorts of trust mechanics; ultimately, each game’s developers must make a judgement call as to which metrics fall into which buckets for the purposes of data gathering.
Here’s one way to measure all the foregoing, with simple tags that should slot easily into existing game metrics systems. I’ll give a list first, then explain them all:
Action | Description | Data |
|---|---|---|
Assistance | When a player helps another | Both player ids, type of assistance (heal, gift, possibly including gift id), timestamp. |
Exchange | When a player trades help with another | Both player ids, object exchanged, timestamp. |
Coordination attempt | When a player tries to coordinate | Both player ids, coordination type (pass, combo name, etc), timestamp, and an ad hoc event id. |
Coordination completion | When coordination succeeds | Event id it completes, time elapsed to completion |
Non-exclusive role action | When a team player performs an action only someone in their position could do | Id, action tag so you can identify different actions |
Redundant role action | When a team player performs an action only some team players can do | Id, action tag |
Exclusive role action | When a team player performs an action only they could do | Id, action tag |
Betrayal | When a team player performs an action against the team | Id of betrayer, id of betrayal target if it exists (e.g. friendly fire), ids of everyone on the team who was betrayed, action tag |
Played with | Logged when you engage in multiplayer play with another player | Id pairs, session length |
Team fail | Logged when a definite action such as scoring a point is logged against a team | Ids of all players on the team, action tag |
These metrics are chosen because they are most easily detectable in code without being bypassed by verbal communication (a form of coordination we cannot capture). Note that the boundaries of these events must be policed fairly tightly, as there is the possibility of overlap.
Once you have these basic metrics, it’s easy to start building a layer of more sophisticated ones on top by tracking history. For example:
If you see Buffy betray Billy, and then Billy betrays Buffy, you can log that as an example of a “revenge” metrics event.
Repetition of “assistance” events can be seen as a sign of a generous player, or as them performing their role. However, repeated assistance between pairs of ids to the exclusion of others can serve as a way to measure cliquishness or favoritism.
If you see excessive time elapse after a coordination attempt, with no subsequent completion event, or can tie it to other game logs such as ball possession, you can see things like intercepted passes. You can use this to create a metric around someone’s competence at team play.
During development and testing stages, you can measure play and see if there’s a high number of exclusive role actions and no non-exclusive ones, or other similar patterns, to gauge where on the Trust Spectrum your game is falling.
Tracking repeat incidence of ids together in sessions will tell you the social graph of your game using simple cluster analysis.
The core concepts used in these are the notion of a player’s statistics versus actions.
Statistics here are broadly defined to include actual values on a player object, plus all objects or equipment in the player’s possession, etc. A player’s health, ammunition, or gear all count as statistics.
Actions are defined as commands a player gives to the system. This may include state changes on the player, such as receiving a ball in a pass – and it of course include actions such as initiating the pass.
Some actions are deeply contextual, and may be hard to identify. For example, a defender blocking a shot on goal is performing a “defend” action. It is up to the game developers to attempt to identify when this action has occurred.
Other actions are explicit commands, such as “shoot the ball.”
Roles are defined as collections of actions that can be performed by a player. Roles really come in two flavors: players may be equipped with a set of commands that are explicit commands, and these might vary by player.
If the action is something that any other given player on the team would be able to do if they were in that position, then it is a non-exclusive role action. If the action can only be performed by this player because of the player’s intrinsic capabilities, then it is an exclusive action.
In the example above, any player can interpose themselves between the goal and the ball. This is a non-exclusive action; any player, thanks to their location, may be in the role of defender, and “defend” is an available action in that position.
Conversely, only the goalie can catch the ball in their hands. This is an exclusive action; no other players are allowed to touch the ball with their hands.
In an RPG, a mage is capable of an exclusive role action: they can cast a spell. You might have multiple mages, however. In this case, you have one other distinction, which is redundancy. A very tightly defined team may have no role overlap whatsoever. A less rigidly defined team might have role overlaps.
There is one more type of action, which is an action that any player can perform at any time whatsoever, regardless of circumstance. These sorts of actions do not need to be tracked for trust spectrum purposes, but you might want to log them as universal actions, just so you have a baseline to compare the other sorts of actions against.
Teams are defined as formal, code-recognized groupings of players. They may not feature in free-for-all games at all, or may form briefly and on the fly (for example, in a game of tag, there are two teams at all times, but membership changes during the game).
Assistance. Assistance is defined as any direct use of an in-game ability to affect the statistics of another player or the objects under the control of another player, or objects held in common by their team. Examples would include healing another player; healing their pet; buffing someone; repairing the base, etc. Note that this does not include any cases where there is a mutual exchange of any sort. This event is defined as pure generosity or altruistic action, and requires no coordination on the part of the recipient.
Exchange. Exchange is defined as any case where two players affect each other’s statistics or abilities, but the event requires mutual agreement. A secure trade system would be one example of this, or a purchase of an item from another player. If anything in the system enforces mutuality, then this is an exchange.
Coordination attempt. Unlike the preceding two, coordination is not premised on exchange of statistics. Instead, it is about performing coordinated actions. If one player executes an action whose success relies on the action of a second player, such as initiating a pass, we record a coordination attempt.
Coordination completion. This simply measures the completion of the pass. In many games, identifying coordination between disconnected moves may well involve additional tracking; organic “combos” such as one player performing a setup move followed by another player going in for the kill may need to be detected via timers and the like. Explicit chained moves are much easier to detect.
Non-exclusive role action. A non-exclusive role action is any action performed by a member of a team that could also be performed by any member of the team under that circumstance. For example, a defender blocking a shot on goal. In other words, it’s not about hardcoded abilities.
Redundant role action. This is an action that is limited to only certain types of players, but there are multiple players on the team who have the capability. In an RPG party with a Cleric and a Paladin, either one could heal, but it is not a generally available ability. If either one heals, we log it as a redundant role action because more than one person could do it.
Exclusive role action. This is an action that can only be performed by the specific player, because there are hard-coded limits that prevent anyone else on the team from doing the action. If the RPG party only had one person with heal ability, or if the sole Necromancer in the party resurrects someone, that’s exclusive.
Betrayal. This is an event that occurs when a player commits an action that redounds to the benefit of the opposing team. This may not have been performed intentionally. An own goal, a pass to the wrong player, friendly fire in a team shooter, and so on, would all qualify.
Team fail. This is when a “goal” is “scored against you.” The nature of this is of course fairly arbitrary per game, and if there are multiple victory conditions, you may have more than one type of victory point to log.
Played with. This basic metric is necessary for tracking trust between two individuals, and captures each time you engage in a play session with a specific other player id (the id is logged). The goal is to identify groups who play regularly together. Cluster analysis on these links, with edges weighted by frequency, should quickly identify social groups.
If you take a game and just note the expected frequency or necessity of these actions, you should end up with a decent sense for where the game will fall on the Trust Spectrum. A preponderance of exclusive role actions and high expectation of coordination completion will mean that you are demanding a high trust level. You should even be able to see well-functioning teams versus ones that haven’t gelled, based on completion successes, low betrayal, and low incidence of team fails.
Using this, you can then actually tune your game or its marketing, in order to best match up the play and the audience. You can also provide a better matchmaking system, grouping players that track to similar levels on the Trust Spectrum, or teams that function at the same level.
Designing games for trust is also designing games for human fulfillment. It is designing for happiness. It’s designing in ways that are #good4players and their relationships. Play is Love. We hope that these tools help you go out there and bring more of it into the world.
Aaron Cammarata will be giving a short, ten-minute talk, scheduled for 11:37 on Monday morning (3/19/2018) at GDC 2018. It’s part of the Innovation and New Platforms section of the Google Developer Day. It will be streamed live: https://events.withgoogle.com/google-gdc-2018/live-stream/#content
Building a better multiplayer
Join us for a fresh look at multiplayer game design. We introduce the Trust Spectrum – a design lens developed at Google that unlocks the potential to create meaningful human experiences. Based on decades of social science, it helps you build great games that support healthy connection, friendship, and trust.
The topic of cooperative play has been quite an active subject in the last few years in game design circles. In particular I’d like to point you at
The 2008 Project Horseshoe report on multiplayer skill atoms. This is explicitly about applying game grammar style loops to multiplayer structures.
The more recent Horseshoe output written up by Dan Cook as “Game Design Patterns for Building Friendships.”
At GDC 2018 there will be a brief session by Aaron Cammarata walking through some of the findings in this article.
There’s far more than I can possibly point to on the psychology and sociology of all this. Dan’s article has an excellent reading list. Several papers and sources were already linked throughout the article. We also have this list of fairly accessible entry points into the enormous literature on play and social behavior:
Special thanks are due: this (massive) article would not have been possible without Aaron, who shared his vision for games that brought people together, identified the core problems, built a team to tackle them, and provided the space for us to all work on this problem for an extended period of time; and of course, to Google who made that possible.
Three separate development teams (HookBang, 20after1, and Schell Games) created prototype games demonstrating aspects of trust spectrum design with the able assistance of Aaron’s team at Google and Massive Black, and in particular I’d like to call out the folks who were in on the project early and helped define the core attributes of trust spectrum play: Brian Clark, Jason Leung, Noah Falstein, Justin “Coro” Kaufman, Melissa Lee, Frank Roan, and Christina Davis. The early wrestling with nitty-gritty trust spectrum design in prototypes fell heavily on (in rough chronological order) Tony Morone, Sean Vesce, and Justin Leingang. We had invaluable research help from several sources, and I want to specifically mention Nick Yee and the rest of the folks at Quantic Foundry, who helped us in our analysis of extant games out in the world that we used as source data to refine our model.
Read more about:
Featured BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)