Alt.Ctrl.GDC is dedicated to games that use alternative control schemes and interactions. Gamasutra will be talking to the developers of each of the games that have been selected for the showcase

MAD - Mutually Assisted Destruction has players acting as the crew of an aircraft striving to take out bombers, each using unique information to communicate enemy attacks.

Gamasutra spoke with the team behind the game, talking about what drew them to make a game based around getting players to communicate, the challenges of knowing which information to split up between players, and the thoughts that went into creating the analog controls that would get players into a Cold War mindset.

Aircraft creators

Six people worked on the project, including four Game Designers/Programmers (Emmanuel Lataste, Adrien Dourgnon, Clément Amendola, and Sam Tunnell) and two Industrial Designers (Emile Chuffart and Nicolas de Castro). The former worked a lot on the initial game concept and the actual development on the game itself, while the latter brought a more practical, outsider’s view to the initial Ideation process, and designed and prototyped our physical interfaces.

As a group, we are currently studying in a Game and Industrial Design school in France, Rubika. We’ve all been making games of all kinds for a few years now, from strategy board games to 2D Dungeon crawlers to 3D mobile games to WarioWare-likes. We’ve also collectively been modding and tinkering in our respective favorite games for ages.

MAD - Mutually Assisted Destruction in a nutshell

A two versus two Cold War-themed game of search & destroy that relies on communication and asymmetrical analog interfaces to immerse you in a tense tactical experience. Alternatively, Battleship on steroids.

Mixing analog controls and tense communication

It came at first from our desire to create an experience around weighty analog controls. When we sat down to think about what sort of controller we wanted to create, ergonomics were our first concern. We enjoy games where the controller is an integral part of the experience and makes its presence felt throughout. We were thus very much drawn to cold war era analog controls, with weighty switches, satisfying plugs, and, of course, the ubiquitous big red button.

We also wanted a tense setting with a sense of consequence and unknown, and we were reminded very much of the multiple close calls of the Cold War, and how the individuals caught up in those incidents might have felt. We concluded that we wanted tense communication to be at the heart of our experience.

These two intentions combined into our rather fitting cold war aeronautical setting.

On the tools used to create MAD - Mutually Assisted Destruction

The game is scripted in C# using the Unity Engine, with a couple of plug-ins, notably Uduino, which allows for Unity-Arduino compatibility.

For the physical controllers, our terminals are crafted out of sturdy painted plywood, with a whole load of cables, diodes, Arduino cards, jacks and buttons sticking out.

Encouraging communication through controls

Our terminals serve to create an interdependence between the pilot and copilot. As the game’s primary goal is to find the enemy, our terminals separate the tools required to do so. On the one hand, the pilot has more immediate information available to him, and he can see the game grid in real time, and his plane’s location within it. His co-pilot, on the other hand, has the more impactful information, since he is alerted to any adjacent enemy presence, all while being blind to the crew’s actual location without good communication with his pilot.

This creates a constant information ping-pong between crewmates, where one must master one’s own controls, all while effectively communicating with one’s teammate, since one player’s information on its own is useless without the other’s input. It is this dynamic that our different terminals facilitate and accentuate through their actual physical controls.

Difficulties in separating information

The main challenge we faced in the creation of our terminals was conceptual. The core of the problem was balancing the amount of information the pilot and co-pilot terminals would give each player, as it directly impacts their possibilities to act in-game, as well as the weight of information they need to communicate with their teammate.

To find the best balance to this core issue, we’ve decided to have a very iterative approach to the project, through which we’d work closely with our designers to rethink different aspects of our interface to best correspond to the type of communication we want to create. This is necessary to us as the specific tools we give players will determine how they communicate.

The appeal of creating a game around making players communicate

We were intent on basing our game on communication from a pretty early stage of development, as we feel that it is practically a game unto itself. As designers, we very much enjoy and are inspired by games in which communications are integral to the experience, and in all genres, from strategy or military sims to party and co-op games. It adds an inherently engaging and challenging element that cannot be created artificially.

This very organic aspect of communication is what motivated us to build a game around it by riffing off of the simple principle of separating information between players. We might say that affected our design in that we know that our game is essentially a vector for tense communication, and must thus offer the most interesting context for it. This reflects our focus on the actual tools we offer the players, and the constant tweaking we’re in the middle of.

For example, in our initial vision of the game, each player would use a headset and communicate via microphone, with the option to plug-in his headset jack into a port dedicated to listening in on the enemy’s communication channel. Although this was very ergonomically satisfying, and made one somewhat giddy with excitement at being discovered by the enemy, it actually ended up making players communicate much more through hand gestures and secrets signals than through speech, which was not what we were aiming for. The solution we found was simply to remove headsets altogether, and move players within earshot of everyone else, adding to the sense of confusion and tension by creating a constant oral back and forth, on which the enemy can listen in on at any time

The rush of accomplishing things together

As we alluded to, communication is a gameplay element like no other. It introduces a clunky human factor within gameplay that no A.I. can replace. It is the sort of thing you craft your gameplay around, as adding it completely changes the design paradigm. We feel the draw of communication based games is related to a deep-seated need for cooperation. Accomplishing quantifiable tasks as a group is a real, physical rush, and one we don’t necessarily get to experience in our day-to-day lives. It is the inherent appeal team games and sports hold.

It is also, to our minds, what will make a given play experience unique from the perspective of the player, as each player will communicate differently, and communication thus becomes a great way for the player to affirm his individual character within gameplay.