Collaborating in Game Design

Class #165
Computer Game Developers Conference
1997

Webster's New World Dictionary:

col-lab-o-rate

To work together, especially in some literary, artistic, or scientific undertaking.

To cooperate with the enemy.

Back in the early days of the computer game industry, it was not uncommon for the entire development team to consist of only a couple of people. As games grow in size and complexity, tasks are now divided amongst 30-40 people. It is not unusual to have several designers working together on a game. New skills are required to make these collaborations work, especially when those involved have strong personalities.

The best projects we've worked on were those in which we collaborated with other people. The worst, most disaster-filled projects were also those in which we collaborated with others. When collaborations work, they can create a wonderful synergy in which everyone creates something much better than could be created by the individuals working alone. When they don't work, you may find yourself stuck inside a nightmare... We're going to examine some of the ways that collaborations can fail and suggest ways to increase the likelihood of success, and point out which signs may tell you when it's time to say "no" or to run!

There are five basic elements that we've learned to pay attention to in collaborative design situations. They are Well Defined Roles, Mutual Respect, Shared Vision, Complementary Strengths, and Good Process. This Proceedings article will cover these elements in some detail, as a companion piece to our talk at the 1997 CGDC.

Well Defined Roles

In order for the collaborators to work well together, it is necessary for each person to have a clear understanding of their role. Unfortunately, it is occasionally in the interests of management to leave roles ill-defined. In particular, the role of designer is often a coveted one in an interactive project, and some managers have found it useful to spread this role among many people on the team to avoid disappointment or alienation. While the team may be happy at first, problems arise when no one knows who is responsible for each part of the design. In collaborative design the specifics of each collaborator's authority and responsibility should be clearly defined from the beginning to avoid confusion.

Sometimes this confusion arises between the person handling the day to day work assignments (might be called a producer, project leader, or project manager–we'll use "producer" in this article) and the designer of a project. Often there is dispute between programmers who have the power to implement design decisions, and producers or designers who may have the nominal authority to specify changes, but are at the mercy of the programmer when it comes to implementing them. This can all be avoided by spelling out what each person's roles are at the beginning of a project. Having many people on a project with input into the design process is often a very good thing, but unless it is understood how those disparate views are woven together, chaos is likely to result.

Consequently it is a good thing to establish who has final creative control on a project. Ultimately this tends to rest on the shoulders of the producer. If a designer reports to the producer and the producer wants overall control but has little design expertise, the designer may make the first call on what goes into a project, but the producer can have veto power, and agree to exercise it primarily over matters affecting budget and schedule. Sometimes the producer of a project is also the lead designer, which simplifies the decision structure. In these cases the producer usually has someone else they are accountable to, either a director of production, another company executive, or (groan) the marketing department! So the same question of creative control must still be resolved.

Establishing who has creative control gives the rest of the people on the project someone to go to when disputes arise. Lack of clear creative control often results in artists and programmers receiving conflicting direction from the various people who consider themselves in control of the design This can ruin morale and destroy schedules.

Another way of looking at this is to establish a "Keeper of the Vision." Usually this is the lead designer, but sometimes a producer, programmer, writer, or artist is the final authority on all matters that affect the overall creative flow of the game. Whatever it is called, having everyone on a project and its management team agree on who it is that holds this ultimate creative control is the single most important step to ensuring smooth collaboration.

Mutual Respect

Once the creative control decision has been made, a project still needs mutual respect among the design contributors to flourish. While the team members might not respect each other in all areas, there must at least be mutual respect in the area of the collaboration. For example, if an established writer collaborates with a well-known game designer, the writer should respect the designer's knowledge of games and the designer should respect the writer's ability to write. It's great if the collaborators can find other areas in common, but not necessary. It's possible, for example, for the writer to think the game designer is a hopeless nerd, and for the designer to think the writer crude and dirty-minded, but for them to still have a successful collaboration because they respect each other's creative abilities. If, however, one of the pair has absolutely no interest in the work of the other, it's likely that the collaboration will be rocky. Besides, why work with someone else unless you appreciate what they bring to the table?

Hand in hand with respect is good communication. If two collaborators don't respect one another, lines of communication will become obstructed as they begin filtering what they are willing to tell each other. Regular communication is essential, either through face to face meetings or frequent, regularly scheduled phone meetings and email.

Shared Vision

Mutual respect is key, but to collaborate effectively on a project, there must also be a shared vision of what the project is to become. The vision can be as ephemeral as a feeling, or as concrete as a fifty page document, but the key collaborators need to agree on what it is. Tone is a critical area to agree upon up front. If one person is bent on making a comedy game and the other is deadly serious, it's unlikely there will be a vision both can share. And even if both agree it's to be a comedy, you should define what type of comedy... Monty Pythonesque? Marx Brothers? Noel Coward? Oscar Wilde? Saturday Night Live? The dialog and jokes in Monkey Island I and II were written by three designer plus a well known outside writer. Because so much time was spent in meetings defining the game, they were able to approach it with the same style of humor. The result is a seamless game. Agreeing on the desired emotional impact of the final product can be a good place to start.

Also critical to arriving at a shared vision is the decision of the nature of the overall gameplay. We've seen a number of cases where a writer and a game designer had a shared vision of a story or characters, but were far apart on what kind of game structure would bring that vision to the player. For example, one person may be completely swept away into the fantasy of commanding an army by simply moving abstract counters on a map, and the other may require a first person view of the battlefield in real time to get the same degree of emotional involvement. Deciding on the basic game structure early on, and making sure all collaborating parties agree is essential.

But how do you agree when you haven't begun the design? There are several things that can help. If the design is based on pre-existing characters or situations, perhaps a licensed product or a sequel to an existing one, those characters and situations will help provide a basis for a common vision. In the case of our collaboration on Indiana Jones and the Last Crusade, the character was already well established in three movies. We all knew what he would and wouldn't say or do. With a new character, spend a lot of time up front defining him/her. Create an extensive back story, even if most of it never appears in the game If you're trying something new, look for existing references you can use to nail down a shared vision. For example, if all collaborators enjoy movies, stating "It will have the look of Blade Runner but done with a Roger Rabbit sensibility" may convey the shared vision sufficiently to allow agreement.

Complementary Strengths

In looking back on our various collaborative projects, we have noticed that having collaborators with complementary strengths often resulted in the most successful ventures. There are cases where two people with very similar strengths worked well together, but if there are some separate areas of expertise as well as some shared ones, it can encourage the mutual respect that is so important to a good collaboration. Otherwise, a competitive ego-driven conflict could be triggered. This can always be a danger when several strong creative types with similar "home territories" come together. Increasingly, writers and designers have found common ground, with the writer taking primary responsibility for matters of story structure and character development, while the designer focuses on interactive and nonlinear structure and gameplay.

If two collaborators have similar strengths, it can also be effective because they can hand projects back and forth, effectively doubling their productivity. The danger here is to make sure that they don't also have similar weaknesses, with certain elements slipping through the cracks in the design since neither is watching out to catch them. Collaborators with similar creative strengths may find reason for mutual respect if they have complementary styles, e.g., one is the organized partner and keeps things on track, while the other is the manic energy partner who provides a creative spark when the other is flagging.

Good Processes

Once the four key elements discussed above are covered, it's time to look at the process of collaboration. Here are some of the things we've found make for effective and fun working conditions.

Having open communications is critical. Many projects have gone awry simply because the people involved went their own ways and neglected to tell the others what they were doing. To that end, having regularly scheduled meetings is important, even if sometimes you simply get together for a minute or two and agree that everything's running smoothly.

Testing procedures to allow exchange of information is helpful. Whether it's writing samples, design documents, artwork, or code, using up-to-date and effective tools to share them can save many headaches. Don't assume that everyone will be able to read everyone else's files–find out.

A corollary to having well-defined roles is to have an explicit chain of command with mutually understood areas of influence and responsibility. Who needs to look at a piece of art before it's incorporated into the project? Who checks to see if the video segment has the proper dialog attached? This is more of a project management area, but design collaborators need to know who's in charge of each piece of the project if they are to be effective.

Having one person with an outward focus and one with an inward focus can make for good collaborations. Specifically, the outward-focusing person, often the producer or director of production, will deal with concerns like budget meetings, marketing, packaging, schedule conflicts with other company divisions, etc. The inward-focused person, often a designer, will look at the guts of the project, the tradeoffs necessary to implement features, the gameplay issues. Sometimes in design collaborations you'll have one person in each of these roles, other times the outward-focused person will have no creative role but there will be a collaboration among inward-focused people. It can work either way.

Be sure the collaboration has the blessing of management. Much of what we've discussed so far assumes people committed to collaborating on design. If the big boss is uneasy about having more than one designer and consistently picks one of the collaborators to talk to about issues, it can create tension.

Agree on a mechanism for conflict resolution. This can be as simple as a vote, or as complex as requiring unanimous consensus from the team, but it's important that everyone agree on it before the project gets too far along. Sometimes agreeing on a mutually respected third party to resolve disputes can work well.

Listen to Your Inner Voice

There's one final ingredient necessary to make sure all projects you join have successful collaborations. Listen to your "inner voice." This is especially important at the very beginning of a project, when it is still relatively easy to extricate yourself from it. If you sense that the chemistry between the collaborators isn't right, that expectations are different and irreconcilable, that there is no clear "keeper of the vision", that success seems impossible, or you just hear yourself thinking, "no way is this going to work!" then you may want to walk (or run) away from the project before it runs over you!

If, on the other hand, you don't recognize the danger signals until the project is well underway, then you'll have to decide whether trying to fix things will help or hinder the project. Having a major confrontation with the lead programmer while you're in the final stages of Beta may slow things down rather than smooth things out.

If, after all this, you embark on a collaborative design, we hope that you will find the adage "the more, the merrier" is appropriate, and not end up thinking "too many cooks spoil the broth"!