作者：Noah Falstein

在《韦伯斯特新世界词典》中，合作意味着：

1.共同工作，特别是在文学，艺术或科学事业领域。

2.与敌人协作。

在早前的电子游戏产业中，一个开发团队只包含少数几个成员是一种非常普遍的情况。但是随着游戏规模的壮大以及复杂度的提升，如今的一项任务通常需要细分到30至40个人手中。所以一款游戏的开发同时涉及好几名设计师也不再是什么新鲜事了。所以在这个时代里，我们迫切需要掌握一些新技能以帮助我们更好地融入这种合作中——特别是当参与者都具有强烈的个性时。

我们所参与的最佳项目是那些能够让我们与其他人相互协作的项目。但同时，最糟糕的项目也是这些需要与别人合作的项目。当合作发挥了功效时，它便能够衍生出一种绝佳的合同作用，并推动着团队中的每个人创造出比自己独立奋斗时更棒的效果。而如果合作不能发挥其功效，团队中的每个人便会陷入可怕的梦魇中。所以我们将在此明确一些可能导致合作失败的原因，想出一些提高合作成功率的方法。

在合作设计环境下我们必须掌握5大基本元素，它们分别是明确的角色定位，相互尊重，共同愿景，优势互补以及良好的流程。而我将在此进一步阐述这5大元素的细节内容。

collaborating(from core77.com)

明确的角色定位-—–为了更好地进行合作，我们有必要让每个成员明确自己在团队中所扮演的角色。不幸的是，很多团队总是为了更好地管理团队而忽视了这一点。举个例子来说吧，因为设计师这一角色是互动项目中很多人所梦寐以求的，而一些管理人员为了不让成员感到失望或产生偏见而将这一头衔让许多成员广泛共享。这么做的结果是，尽管一开始所有成员都会感到欣喜，但是随之他们便会开始产生疑惑，即不晓得自己或其他成员是负责设计中的哪个环节。所以在合作设计项目中，管理层最好能够在一开始便明确每个成员的权利和责任，以此避免之后的混淆。

这种混淆主要出现在那些处理日常工作任务的人员（游戏邦注：也就是我们所说的制作人，项目主管或项目经理之类的——但本文主要以“制作人”一词进行表述）或者项目设计师身上。程序员和制作人或设计师之间的关系总是备受争议，程序员拥有执行设计决策的权利，而制作人或设计师虽然能够主导任何特定的改变，但是在执行改变时却仍需要受制于程序员。而如果能够在一开始就明确每个成员的角色，我们便能够有效地避免这一问题。让项目中的大多数人参与设计过程虽然是件好事，但是除非你能够事先明确这些不同角色所具有的不同观点，否则你便很容易陷入混乱中。

所以明确谁拥有项目的最终创意控制权非常重要。基本上这一担子总是会落在制作人肩上。而如果设计师需要向制作人作出汇报，但是制作人却未拥有设计的相关知识，那么设计师便拥有项目决策的决定权，但是尽管如此，制作人也可以基于预算和进度方面行使否决权。有时候项目的制作人同时也扮演着首席设计师的角色，这也就简化了项目的决策结构。而在这种情况下，制作人通常还需要对上头的某些角色负责（游戏邦注：可能是制作总监，公司高管或者市场营销部门等）。这便解决了项目的创意控制权问题。

明确创意控制权也能够在团队出现争端时更好地解决问题。而缺少清晰的创意控制将会导致各种错将自己当成是项目主管的人给予美工和程序员错误的方向指示。而这终将破坏整个团队的士气并影响工作进度。

另外一种方法便是设立一个“愿景主导者”的角色。通常情况下都是首席设计师扮演这一角色，但是有时候制作人，程序员，文案写手或美工人员也可能主导着游戏最终的创意发展。不管被冠以何种称谓，只要这个人的创意控制权能够得到项目中每个成员以及整个管理团队的认可，这便是保证团队合作顺利进行的重要武器。

相互尊重——做出了创意控制决策后，设计参与者们就需要做到彼此尊重以推动项目的成功执行。如果团队成员在其它领域未能做到相互尊重，他们至少也应该在合作领域中做到这一点。例如，当一名文案与知名游戏设计师展开合作时，文案必须尊重设计师所掌握的游戏知识，而设计师也应该尊重文案的写作能力。如果合作者能够在对方身上找到共同点那就再好不过了（虽然这并不是必要的）。当然了，如果文案认为游戏设计师是个无可救药的人，而设计师也认为文案是个满脑子邪念的怪人那也没关系，只要他们能够彼此尊重对方的创造性能力也就能够建立成功的合作关系。而如果相互合作的双方对彼此的工作一点兴趣都没有，这便会让他们的合作显得更加吃力。除此之外，只有你真正欣赏对方的能力你才有可能与之共事。

相互尊重是一种很好的沟通技巧。如果合作双方未能尊重彼此，他们间的沟通就会受到阻碍，因为他们会逐渐过滤掉自己真正想要传达的内容。而对于合作者来说定期的沟通是非常必要的（包括面对面交谈或频繁的电话会议和邮件交流）。

共同愿景-—–相互尊重固然重要，但是为了推动项目合作的有效进行，成员们必须对项目的发展抱有共同的愿景。这种愿景可以只是短暂的感觉，也可以是长达50页的文件形式，而不管怎样都必须是经过合作双方彼此的认同。双方必须先协商好游戏的语调。因为如果一方主张创造喜剧游戏而另外一方更倾向于严肃的游戏，那么他们便不可能确立一个共同的愿景。而即使双方都认同了喜剧风格，接下来还需要定义是什么类型的喜剧——是Monty Pythonesque（游戏邦注：意指幽默的，奇异的和超现实主义的风格，来源于BBC电视喜剧节目“Monty Pythons Flying Circus”）？Marx Brothers（知名的美国戏剧演员）？Noel Coward（英国演员，剧作家，流行音乐作曲家）？Oscar Wilde（爱尔兰作家，诗人，剧作家，应该唯美主义艺术运动的倡导者）？还是《周六夜现场》（美国一个每周六深夜播出的综艺节目）的风格？《Monkey Island I》和《Monkey Island II》的对话和笑话便是由三名设计师加上一位著名的外部作家所创造出来的。因为他们投入了大量时间去讨论游戏的定义，所以他们能够清楚地根据游戏的幽默类型进行合作，并最终创造出这么一款优秀的游戏。彼此认同最终游戏所具有的情感影响将是我们迈开创作步伐的第一步。

达成共同愿景对于决定游戏玩法属性也是至关重要。我们在许多案例中发现，有些文案和游戏设计师虽然在故事或角色方面达成一致意见，但是在向玩家传达愿景的游戏结构方面却产生了分歧。例如，一方可能希望让玩家在地图上移动抽象的计数器组件而指挥一整个军队，但是另一方却可能要求以第一人称视角去呈现即时战场上的场景，让玩家拥有切身的游戏感受。所以开发团队必须尽早明确基本的游戏结构，并争得所有参与者的认同。

但是如果还未开始设计游戏又怎么谈得上同意与否呢？我将列举出一些方法帮我们进行判断。如果你的设计取决于现有的角色或情境（即可能是授权游戏或者现有游戏的续集），那么你便可以根据这些角色或情境创造一个共同愿景的基础。例如当我们与《夺宝奇兵》展开合作时，我们所面对的角色便是存在于3部电影中的现有角色，我们知道他将做什么或说什么（或者不做什么不说什么）。而如果面对的是新角色，我们便需要投入更多时间去定义他/她。创造一个广阔的背景故事——尽管大部分内容都不会出现在游戏中。而如果你尝试着创造一些新内容，你便需要寻找现有的且能够帮助你明确共同愿景的参考。也就是如果所有的合作者都喜欢看电影，你就可以用“这将拥有《银翼杀手》的外观以及《兔子罗杰》的感觉”这种表述去传达共同愿景，并以此获得成员们的认同。

优势互补——回顾我们之前的各种合作项目，我们发现拥有互补优势的合作者们总是能够创造真正成功的游戏。在某些情况下两个拥有类似优点的人总是能够很好地进行合作，但是如果他们在专业知识方面出现了分歧（也有一些共同点），他们也能够出于对彼此的尊重而推动合作的有效进行。但是在其它情况下合作双方也有可能受到自尊心的驱使而发生矛盾。当一些极具创造性的成员与一些固守成规成员共事时便很可能引发这种矛盾。但是现在越来越多文案和设计师找到了彼此的合作的共同点，即文案主要负责故事结构和角色发展，而设计师则关注于互动和非线性结构和游戏玩法。

而如果合作者实力相当，他们的工作效率也会大大提高——因为他们可以来回地处理项目，并因此更加有效地提高制作能力。但是这里也存在着一定的危险，即如果合作者存在着相同的弱点，他们就很有可能同时遗漏掉设计过程中的问题。拥有相同创造性优势的合作者会发现，如果他们刚好属于互补类型，他们就更需要尊重彼此，例如有一方非常有条理，虽然缺少创意但总是能够确保事情的运转，而另一方虽然较为暴躁但是却极具创造性。

良好的流程——当我们明确了以上四大元素后，我们便需要开始考虑合作的过程。以下我将列出创造出有效率且充满乐趣的工作环境的方法。

创造一个开放的沟通环境至关重要。许多项目都因为成员们过度沉浸于自己的想法中并从不跟别人分享自己的做法而遭遇失败。为了创造一个开放的沟通环境，定期召开会议非常重要，尽管有时候这些会议只会持续一两分钟或者只是在汇报任务的正常运行。

检测程序以推动成员间更好地交流信息。不论是纸上样本，设计文件，原图还是代码，只要你能使用最新且有效的工具去分享这些信息便能够帮你省下许多不必要的麻烦。不要以为所有人都会去阅读其他人的文件——你最好直接将这些信息呈现在他们面前。

拥有定义明确的角色就必须先拥有一个明确的指挥系统，能够深刻理解每个角色的影响力和责任。谁需要在将图像整合到项目之前好好审视这些内容？谁需要去检查视频片段是否配有适当的对话内容？这些都属于项目管理领域，而设计合作者们如果想要更好地进行合作就必须搞清楚是谁在主导着项目的每一个环节。

一个主外一个主内的模式能够创造出很棒的合作效果。很明显地，主外人员通常是制作人或制作主管，他们将处理像预算会议，市场营销，包装，与其它公司的行程矛盾等事宜。而主内人士便是设计师，他们将深入研究项目的核心内容，平衡游戏功能并解决游戏玩法问题等。有时候在设计合作领域也会出现一人分饰多角的情况，但是也有时候主外人士可能不具备任何创造性，这时候他就更加需要与主内人士进行紧密的合作。

确保管理层认可这种合作模式。我们之前所讨论的内容都是基于所有人都认可这种设计合作的前提下。而如果公司老板并不喜欢同多个设计师打交道，并且总是只挑选同一个人进行谈论，这便会在团队中形成一种负面的紧张感。

对于冲突解决机制达成一致意见。这个过程或者能像投票一样简单，或者会因为涉及到团队中所有成员的意见而变得非常复杂。但是不管怎样，任何团队都需要在项目走上一定轨道前明确这一机制。有时候利用相互尊重的第三方去解决争端也不失为一种好方法。

聆听自己的心声-—–确保建立成功的合作关系的最后一大要素便是聆听你自己的“心声”。在项目开始阶段这一点非常重要，但同时我们也很容易会忽视它。如果你感觉到合作关系出现了矛盾，或者所有的发展都违背了你的期望，合作关系中不存在明确的“愿景主导者”，你便会觉得项目不再可能取得成功，或者你将会认为“没有办法再继续这样工作了！”然后你便会想办法逃离这一项目（否则最终受伤的只会是你自己）。

反过来说，如果你在项目真正投入运行前不能意识到任何危机，你便只能尝试着去解决或完善任何内容以挽救项目。在最后的测试阶段与程序员发生冲突只会影响项目的进展而已！

不管怎样，既然你加入了合作项目中，你就需要始终抱着“人越多，越开心”，而非“人多手杂”的想法去适应这种合作关系。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Collaborating in Game Design – from CGDC 1997

by Noah Falstein

Webster’s New World Dictionary:

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 knowswho 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”!(source:GAMASUTRA)