Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Get the latest Education e-news
  • Approaching The Challenges Of Team Design

    - Leszek Gorniak
  • 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:

    • having a single lead designer that always has the final word;

    • having each designer own only a particular area of the game.

    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:

    • Theme - what is the unifying theme of our game? Friendship? Death? Journey? Fear of unknown?

    • Overall mood - optimistic or pessimistic? Funny or serious? Surreal? Cold or warm?

    • References - which games to use as references in the design process? Which movies? Books? Paintings?

    • Target audience - what age? Hardcore or casual? Do we target a particular gender or not?

    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.


comments powered by Disqus