col-lab-o-rate 1. To work together, especially in some literary,
artistic, or scientific undertaking. 2. 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”!