Challenges of Team Design

Have you ever argued with someone about the game you thought was really awesome while the other person found it mediocre at best? Probably yes. Did you succeed in making the other person change their mind? Probably not. When you work in a team with other game designers, you also disagree. But then you disagree over your own game. Team design is not a challenge to be taken lightly.

Disagreements over games are natural: we have different personalities, different preferences, and different gaming experience. We simply enjoy different things in games, and, whether we like it or not, that alters our approach to game design. The main problem here is that it’s very difficult to objectively determine whose solution is better than others. “Objectively” is a key word here, because, despite the fact that game design theory is much better researched and documented than it was some years ago, we still lack objective criteria in this field. To understand the problem better, compare the game development process to a car production process. When producing a car, we have lots of objective criteria and that’s because, as much as cars differ (but not that much) in their visual design, they are all expected to work in a very similar way. But games are completely different when it comes to expectations. I particularly like this quote by Daniel Cook, taken from one of his presentations on game design: “Imagine doing surgery [...], you don’t know what the disease is and someone’s blinded you.”

Undeniably, we have many tools that help us design better games (unifying theme, flow, interest curve, feedback loop, storytelling principles like Hero’s Journey), but devil is in the details, and on those details we will disagree! We will disagree on them often. And, despite our disagreements, we have to make a game.

In this post, I’d like to present three methods for facilitating teamwork and overcoming the aforementioned issues. A short disclaimer: there are at least two “easy” ways to seemingly eliminate such team disagreements and those are:

I will not be discussing those as, despite their obvious advantages, I don’t think they will allow us to fully embrace the power of the team as a whole.

Method #1: Set a “design compass” ASAP

Imagine a situation in a forge: two guys are alternately swinging their hammers, hitting a single, heated piece of metal placed on an anvil. They sweat and struggle for a long time, trying to forge a tool. They don’t seem to achieve anything — the piece’s shape just gets more and more random. Finally, they both give up.

“It’s not that easy”, one of them says, “I can’t make the horseshoe.”

“And I’m having trouble with the sword”, says the second guy.

That scene from a classic Polish comic book, “Tytus, Romek i A’tomek”, perfectly summarizes the pain of designing a game without a clear, consistent vision shared by all team members.

Surely, some things are usually well-known from the very beginning. We know the genre, the setting, the basic storyline, some core mechanics, etc. But when it comes to actual design details, there is VERY little chance that all designers in a team have the same game in mind from the start. Because of our previously mentioned differences in personalities, preferences, and gaming experience we all construct a different model of our game in our minds. We have certain, most likely different, expectations and assumptions. Also, the longer we maintain our model, the more difficult (and painful) it is to change it later. Therefore, in many situations the disagreement between designers is not even about being right or wrong, but about different perceptions of the same game (horseshoe vs. sword).

Considering all that, it’s extremely important to set a design compass very early, so that we all construct our models based on a single, solid and consistent foundation. The details of such a compass depend on a particular project, but, in my opinion, those four aspects should always be it’s vital components:

Those are the foundations. For efficient teamwork, our team has to agree on those as soon as possible. Then, as the project progresses, we need to develop the design compass. Documenting it would be a good idea as well. Of course, our design compass might change in time. As creating games is an iterative process, some agreements will change completely. That’s fine, as long as we ensure that when the design compass is altered, it’s clearly communicated.

Practical example: a nice negative (how NOT to do stuff) example is a shameful situation that occurred during the development of my game Astrohazard Solutions Ltd. From a very early stage our team knew that this game was going to be story- and dialogue-heavy. But, as a matter of fact, it was not until we had already been deep in the production that the storywriter and I confronted our mental models on the narrative aspect and found a huge incompatibility: I was designing and developing with linear dialogues in mind, while the storywriter was working on branched, non-linear dialogues. We ended up with linear storyline, but this is definitely something we should have agreed on earlier on and included in the design compass.

Method #2: First listen, then talk

In “The Art of Game Design” Jesse Schell writes: “The most important skill for a game designer is listening.” While in his book listening has many different meanings (listening to players, listening to ourselves, listening to the game itself) I’ll focus on a single aspect: listening to other team members.

The common mistake we make when we try to convince someone to accept our design idea is “fortifying” around this idea. As the discussion gets more heated, people tend to get less focused on what actually works for the game and/or player, and become more focused on defending their ideas and proving their superiority (which is difficult, due to the lack of objective criteria, the issue I mentioned earlier). On the other hand, by carefully listening to other team members, we get to know their way of thinking, thus creating foundations for a respectful discussion. In Method #1, part I mentioned models. Finding out that my model is different from someone else’s model is the first step towards a better understanding, a more productive discussion and, ultimately, a more effective teamwork. And to achieve that we need to listen deeply.

This “deep listening” is not easy. We need to learn to keep quiet and listen carefully. We need to be more sensitive to non-direct forms of communication, e.g. body language. We need to look for someone’s true motivation. In my opinion, deep listening is a must-have skill for a game designer, and we need to work hard to develop it.

Practical example: in one of my projects, I couldn’t come to terms with another team member about a certain design aspect. Then I made some effort to listen to him on a deeper level than just game design and I found out that he was actually emotionally and personally attached to this particular theme. Knowing that helped me look at our discussion from a different perspective, and, in the end, we found a consensus.

Method #3: Don’t give answers, ask questions

Let’s say someone is proposing an additional gameplay mechanics and you think it won’t fit in the game. You can say: “This won’t work. It breaks … and … principles we discussed earlier. It also complicates the … tutorial and will have unforeseen consequences for the game balance”.

The main problem with that kind of answer is that it might put the other designer on the defensive. In that case, the other designer won’t consider your arguments, but instead will focus on proving you wrong and defending the idea (I mentioned “fortifying” around one’s ideas earlier). Of course, an experienced designer will cope with such feedback and respond in a more productive way. However, the reaction might also depend on someone’s current mood, personal situation and so on. So why take the risk?

Alternatively, you can respond by asking questions:

This approach has two main advantages. Firstly, we put forward a valid problem statement. Defining a problem should always be a first step to solve it. Secondly, we don’t put other person on the defensive. On the contrary, we facilitate a team effort in which we all work towards a common goal: looking for answers and either solving the issues (perhaps we will find out that the proposed idea actually fits in) or coming to a conclusion (together!) that the proposed idea won’t work.

For this approach to work, we need to agree that the questions asked are valid. Fortunately, agreeing on that is much easier than agreeing on actual design and implementation.

This is one of my favorite team design techniques. I call it “question-driven design”. By answering more and more questions we get more detailed game framework which we might eventually group into topics and convert into a Q&A style game design document that is quite straightforward and easy to read.

Practical example: in one of the projects I took part in, we were having some issues with designing a combat mechanics for the prototype. I prepared a one-page list of unanswered questions, such as:

This approach helped us focus on actual problems and potential solutions and significantly enhanced the creative process.

Synergy

For the best results, the above methods should not be treated as separate, as they work most efficiently in synergy.

They are interconnected, forming emergent relations and dependencies:

As we learn to utilize the synergy of those three methods, we build another, way more important synergy, a team synergy. And, as Henry Ford said, “If everyone is moving forward together, then success takes care of itself.”

Thank you for reading.