Des and I have officially kicked off the redesign of our game. The original design suffered from a lack of clarity; we were interested in something new for first time players, multiplayer as an on-boarding technique, a narrative-first experience, and at least a half dozen more aspirational like-to-haves that we Katamari'd over the course of the project's first 9 months.
Since then, we've established interdependence as one of our design pillars. I personally feel very attached to interdependence as the framework for our multiplayer experience because that is an aspect of teamwork I personally value. I can't think of many "cooperative" activities that I've done that has been more rewarding or satisfying than being an officer on a warship. There, everyone on the team is reliant on each other. As a command, we were a single unit; each of us integrated into the execution of the mission while at the same time, individuals, having to exercise our own judgement, feelings, and relationships. So, how might we go about successfully evoking a sense of interdependence between our players?
Being, if nothing else, a product of my Navy and engineering training, one of my current areas of obsession is process. In grad school, there was a strong emphasis on bottom-up design, which makes sense. It is a font of creativity, affording interesting admixtures of ideas, and has the upside of allowing you to have the freedom to follow the fun before you get married to any ideas. Consequently, that's the process that I'm now most (or near exclusively, tbh) familiar with. However, for this project, it isn't for us. We've already got ideas, play contexts, and themes we're wedded to, and so now we find ourselves heading down the "other" path. And like any process I undertake, I felt like I and it would benefit from examination.
I stumbled across the Practical Creativity GDC talk from 2014 by Raph Koster, author of Theory of Fun for Game Design. The talk is focused on an approach to thinking about the quantum elements of mechanics, and practical approaches to avoid inadvertently recreating existing designs without meaning to. About 40 minutes in he says of designing from the top down, "You might start at the experience end. Think of a cool, interesting, complex thing that you want say from an experience point of view... The risk here is that you drill down into the same mechanics as always. Odds are that if you do that, you're going to undermine the message because the mechanics that you'll be using probably map to other things in people's minds already. If you want to be really successful at getting across a point, you want to find mechanics that cleave closely to the same point as your theme."
And here lies the core of our challenge: what mechanics can we use to evoke interdependent cooperation while avoiding undesirable baggage? We don't have any complete solutions as of yet, but here are a few things that we've discovered.
Working Together Is Not Enough
We played A Way Out for nearly an hour before the internet decided we couldn't play together any more. For those unfamiliar with the game, A Way Out is a split-screen cooperative multiplayer game that follows the story of two inmates turned partners and the adventure of their escape and subsequent run from the law.
The game is heavily reliant on quick-time events (QTEs), with players alternating or sequencing their inputs to advance the plot. This system is at its best when players are waiting for their prompt to contribute to the action. It keeps players alert and focused on the game; a big challenge in a multiplayer game where the game has to compete with the other player for the attention of the first.
I want to point out that there are a number of things that A Way Out does really well, but I didn't feel like we were working together. When I was sneaking passed guards that Des distracted, it felt like we were playing our part in the game's story, as opposed to fulfilling roles in a team. When we were taking turns punching and dodging our way through fight sequences, I felt more like I was playing a game alongside someone than with someone. Though the game did a good job of holding our attention, it did so in a way that made me feel less aware of the co-inhabitant of that magic circle.
Plenty of modern games have used them to good effect, but QTEs are a means of engaging players during scripted experiences by inviting interaction. What does it say about the nature of our teamwork when, under the hood, the message from the mechanics can be reduced to, "do what you ought when we say so"?
Being Dependent Is Not Enough
Early in our thesis process, we played Spaceteam: a game where players are reliant on their teammates to keep their ship and the team alive. It's a fast-paced networked mobile game with much shouting, repeating of the thing you just said, and naked unabashed frustration. I personally thought it was fun, but it was definitely not everybody's cup of tea.
The mechanics of the game are set up such that each player, on their phone sees a prompt for what needs to be done to save the team's ship with an accompanying timer for how long until failure results in the team's death. However the ability to do said thing only exists on their teammate's phone. Seemingly, all at once, everyone is trying to simultaneously shout orders while listening for instructions relevant to the actions available for them to perform on their own device. Each player is strictly reliant on their teammates, and the design made that clear under no uncertain terms.
Though the game had the structure of strict literal dependence, it didn't evoke a satisfying version that I know to be possible. Our tasks were random, our actions were meaningless, and the proper execution of the gameplay loop only invited another prompt. Unlike A Way Out, I definitely felt that I was playing with my team, but at best I felt like I was participating, and at worst I felt like I was holding the team back.
Stakes and emotional investment aside, the Spaceteam approach seemed inappropriate for our design goals because the play accentuates only mono-directional aspect of interdependence. You feel the need to be heard, and the desire for your teammate to do what you need them to do, but you never have the time to consider that you are needed by others. Maybe it's because your actions are dictated to you as opposed to being something that required a level of participation that would create a sense of ownership of your role. Also, their needs and desires only serve to hamper you in your ability to communicate your own needs, so any opportunity to feel good about being needed is lost.
Lessons Learned (LL)
We haven't settled on our complete mechanics set quite yet, but some things have become pretty clear.
LL1 - Top-Down Is Slow
Firstly, a top-down approach has the double problem that each mechanic and resulting dynamics cannot simply be good, but must also be appropriate. Appropriate in its dynamics, in the feelings that it evokes, and in how it relates to the theme. That may seem obvious, but it was a challenge that I had underappreciated. On the other hand, it is great exercise in the study of mechanics. Raph Koster, in the linked video, proposes that, "Mechanics are usually games. Games are built out of smaller games... Learning to see things this abstractly is actually an enormous help... What it does is help you build a library [of common, small game mechanics]." And that's what this exercise has helped me to do: to not only do the work of cataloging multiplayer mechanics, but also to examine them in a way that I might not have otherwise.
LL2 - Look At Dynamics
When examining a mechanic's suitability, it should be examined on all levels. In our case, because the pillar is relationship-centric, it's about how the mechanics frame the relationship between the players. Approaching mechanics with a checklist of keywords didn't help. The way I think about interdependence is that it's cooperative, but the cooperation in an assembly line is not the same as in moving heavy furniture with someone. Interdependence is a two way road, and it's possible to mechanically accentuate one direction over the other. That is to say nothing of the combinatorial dynamics from mixing and matching one set of rules with another.
LL3 - No Shame In Going Back To Basics
Given the length of this project, and the number of incarnations and forms this game has taken on, I found myself overwhelmed from trying to juggle all of the ideas that we'd amassed. The progress that we've made lately has been in no small part due to going back to basics. None of what I've written feels groundbreaking, but when my heads in the clouds sometimes what I need is to be able to see the obvious to get my feet back on the ground.