主题：初到贵宝地,灌一点游戏开发的东东 -- foundera

游戏设计中的合作

本文阐述了在游戏开发过程中，在合作方面应该注意到的或者说应该做到的事情。也是我持之以恒寻找伙伴的原因。

1. 尤其是在从事某些文学，艺术或者科学性的事业

2. 和敌人合作

　　回顾电脑游戏工业的初期，一个开发队伍只有少数几个人的现象一点儿也不奇怪。随着游戏的规模和复杂度的发展，游戏开发任务现在往往由30－40个人分担。几个设计者共同为一个游戏工作已成常事。如何使这种合作奏效？尤其在游戏设计者们往往具有强烈个性的情况下。新的技巧是必需的。

　　我们做过的最好的项目是和其他人合作完成的。最差的，往往也是。当合作达到效果时，它们可以产生一种效果使得每个人都能创造出比个人独自工作时好得多的东西。当合作不奏效时，你会觉得自己处于恶梦之中。。。我们接下来会研究一些会使得合作失败的做法，以及建议一些增加合作成功的可能的方法，我们还会指出什么样的情况下你就该说不或者干脆离开这个项目吧！

　　从以往的经验中我们已经懂得合作设计时需要注意的五个基本因素。它们是明确分工，互相尊重，达成共识，相辅相成和好的流程。下文我们将会仔细的讨论这些因素，也作为我们在1997年CGDC的讨论的一份材料。

明确分工

　　为使合作者在一起工作的很好，每个人都必须对自己在项目中的角色有一个明确的认识。很不幸，管理者经常对这一点不够清楚。特别的，设计者的角色在一个互动游戏项目中往往是很有诱惑力的，因而某些管理者发现让团队中的很多人来共同扮演这一角色是颇为有效的办法，这样可以避免他们失望，从而失去兴趣。大家开始可能会很高兴，但是随着没有人知道究竟谁对某部分设计工作具体负责时，问题就产生了。在合作设计中，从一开始就要明确每个参与者的责任和权力，以免产生混淆。

　　有时这种混淆会在项目经理（制作人）和总设计师（总企划）之间产生。在实现设计思想的程序员和项目经理或者设计师之间往往会产生争吵。后两者可能会拥有有名无实的做出改变的权力，但这其实取决于实现功能的程序员。这种情况可以通过在项目开始时就确定每个人的角色来避免。有很多人参与设计过程往往是很好的事情，前提是要明白这些往往决然不同的看法该怎样有效的汇集在一起，否则肯定一团糟。

　　因而，确定谁拥有对设计的最终决定权是件好事。这项重任往往落在了项目经理的肩上。如果一个设计师就某个设计上的变化报告项目经理，后者缺乏足够的专业知识，但还是希望对项目有全面的控制，设计师可能会预估这一变化对项目的影响。项目经理可能同意在不影响预算和进度的情况下采取这一方案，他同时也拥有最终否决权。有时项目经理也是总设计师，从而简化了决策流程。在这些情况下，项目经理往往也有要对之负责的人：一个高级经理、另一个主管人员或者，唉，市场部门的头头儿。因此同样的设计决定控制权也必须明确。

　　设计决定权拥有者的确认使得项目里的其他人员在发生争吵时知道该找谁拍板。如果没有明确谁拥有这项权力，往往会导致美术人员和程序员会从都认为自己拥有决定权的不同的人那里收到截然不同的指示。 这会降低士气，也会影响进度。

　　另外一个处理方法是确定一个"监护人"。通常这个人是总设计师，但也可能是项目经理、程序员、编剧或者美术人员来最终做出决定。无论怎样，让项目中所有工作人员和相关管理人员全体认同某个人拥有这项决定权是确保良好合作的最重要的步骤。

相互尊重

　　即使决定了由谁来最终决定设计上的事宜，一个项目仍然需要设计者间的相互尊重才能进行良好。当团队成员可能在某些方面无法彼此尊重，他们也必须在合作相关的方面相互尊重。举个例子，如果一个编剧和一位著名游戏设计师合作，编剧应该尊重设计师游戏方面的知识，而设计师应该尊重编剧的写作能力。如果他们能找到共通点，当然很好，但这不是必要的。有可能出现这样的情况，例如编剧觉得游戏设计师是一个毫无希望的讨厌鬼，而设计师认为编剧粗俗下流，但是他们仍然可能合作得很好，仅仅因为他们尊重对方的专业能力。然而，如果他们中的一位对和另外一位协同工作毫无兴趣，这合作恐怕就得完蛋。当然了，除非这个人确实有我们需要的能力，否则为什么要跟他合作呢？

　　互相尊重的合作是很好的沟通。如果两个合作者不能彼此尊重，沟通就会被阻碍，他们也无法很好的告诉对方自己的想法。有规律的沟通是非常重要的，无论是通过面对面讨论，例行电话会议或者电子邮件。

达成共识

　　相互尊重是关键，但是要有效率的合作，他们必须对这个项目的方向达成共识。这个认识可能仅仅是种感觉，也可能是用50页的文件来详细描述，但是核心人员必须对它究竟是什么有个共同的认识。游戏的主题风格是一个重要的，并且需要达成共识的方面。如果一个人倾向于做一个喜剧味道很浓的游戏，然而另外一个人却古板的要命，那恐怕他们就很难同意对方的意见了。而且即使双方都同意要做一个喜剧，你还需要决定要做哪一种喜剧。。。Monty Pythonesque? Marx Brothers? Noel Coward? Oscar Wilde? Saturday Night Live? 猴岛小英雄1代和2代里面的对话和笑话是由三个设计师和一个很有名气的外部作者完成的。因为花费了大量时间在开会讨论游戏风格上面，他们可以达到统一的幽默风格。结果是一个天衣无缝的游戏。就最终产品所要达到的情感方面的影响达成共识是一个不错的开始。

　　另外一个极其需要达成共识的方面是决定这个游戏到底是怎么玩的。我们看过不少编剧和设计师就游戏故事和角色可以达成共识的例子，但是这离最终带给玩家什么样的游戏还差很远。举例来说，一个人可能彻底坠入了做一个指挥大军在地图上行进的游戏的想法，而另外一个人则需要一个实时战场第一视角的表现方式从而让玩家能更好的融入其中。先尽早地决定基本游戏结构，让所有的合作参与者都认同它，这一点是非常重要的。

　　但是在你开始实际设计之前，怎么能认同这些事情呢？可以采取一些方法。如果设计是基于已有的角色或者形势，比如一个特许授权开发的产品或者一个系列的续作，这些角色和形势会有助于提供一个共识的基础。在我们以前合作开发的Indiana Jones and the Last Crusade的项目中，已经有三部电影很好的刻画了主角的形象。我们都知道他会说什么，做什么以及不会做什么。如果是一个新角色，就多花些时间去构思他/她吧。创造一个架构宏大的故事，即使其中的大部分内容根本没有在游戏中出现。如果你想尝试一些新东西，参考现在的资料以便可以总结出一个可以用来达成共识的范围。例如，如果所有的合作者都喜欢电影，那么"它看起来会象Blade Runner，但是象Roger Rabbit一样敏感"这样的描述可能比较容易让大家达成共识。

相辅相成

　　回顾我们做过的众多合作性项目，我们已经注意到拥有可以相辅相成的合作者往往可以做出最成功的结果。有很多次两个具有相似专业技能的人在一起合作得很好，但是如果他们还同时能有各自擅长的领域，就会增强之间的互相尊重，从而促进更好的合作。另一方面，一次个人观念驱动的竞争性冲突可以被调和。当几种同一方面的具有很强创新性的理念碰在一起时往往是很危险的。越来越多的，编剧和设计师达成共识后，编剧主要负责故事架构和角色刻画，同时设计师集中精力于互动非线性的结构和游戏的玩法。

　　如果两个合作者具有相似的优点，因为他们可以更好的把握项目，从而可以高效地工作。这里可能存在的问题就是一定要确定他们不会有相同的缺点，否则由于缺乏监督，设计中很有可能会出错。具有类似的创造力的合作者可能会因为他们有相互补充的风格而彼此尊重，例如一个循规蹈矩，另外一个是个不停的冒出创新的主意的家伙。

好的流程

　　前面的四个关键因素讨论完毕，是时候看一下合作的流程了。这里有些事情可以使得工作变得高效而且充满乐趣。

　　公开的交流是非常重要的。很多项目失败的原因仅仅是参与人员各行其事，没有告诉其他人自己在做什么。定时召开例会是非常有用的，哪怕只是花上几分钟时间凑在一起聊聊，确认一切都进行顺利。

　　进行信息交互的测试过程是有效的。无论是范例，设计文档，美术作品或者代码，使用最新而且有效的工具来进行共享可以减少不少麻烦。不要以为每个人都能看得懂别人的文档。

　　明确分工带来的好处之一就是有一条清晰的具有互相理解的影响和责任的指挥链。在某一美术工作整合到项目里面之前由谁来验收？谁来检查对话和显示是否搭配正常？这不仅仅是项目管理的范畴，而是如果合作者们希望做到高效，就必须知道谁负责项目的哪一部分。

　　让一个人负责对外事务，一个人负责对内事务有助于好的合作关系。特别的，负责对外事务的人，往往是项目经理或者产品经理，将负责预算会议，市场，包装，和公司其他部门的日程安排冲突等等事宜。对内事务负责人，往往是总设计师（陈忾说：我好渴望这种情况在中国适时的运作起来），他的工作集中在项目本身，为实现某些功能而要做出权衡，游戏的玩法等等。在游戏设计合作中有时由不同的人担任这些角色，有时负责对外事务的人本身并不参与设计，但是在对内负责的人群里面将会有一个合作关系。怎样做都可以。

　　一定要确定合作关系得到了"管理的祝福"。我们讨论过的这些因素大部分都假定人们是真心愿意合作设计的。如果设计师多过一个的话就让大老板觉得不舒服，而且总是拉一个合作者过来讨论问题，只能造成紧张关系。

　　对争论的解决方法一定要达成共识。可以采用投票，或者设法使得整个团队都毫无疑义的认同，但是一定要在项目偏离正规太多之前让每个人都认同。有时由大家都尊重的第三方来仲裁也不失为一个好办法。

听从你内心的声音

　　现在还有一个最后的因素来确保你加入的所有项目都能合作良好。听从你"发自内心的声音"。在一个项目刚刚开始，还很容易脱身出去的时候，这一点尤其重要。如果你觉得合作者之间的气氛不大对劲儿，比如大家对项目的期望不尽相同，没有明确的监督人，成功的可能性微乎其微，或者仅仅是你自己觉得"这根本就行不通！"，这样的话你还是早早离开吧（陈忾说：很多人问过我：“为什么去了很多公司，然后又快速的离开？”我想，上面的就是答案了。你要想了解一个公司的开发目标，是无法从公司外的角度去看清楚的，需要具体地到项目中去，才有可能发现项目的问题。而一旦发现问题，你所能做的就很少了。因为国内还没有确定设计师引领项目开发的模式。所以，作为设计者，与其在一个注定不怎么样的项目里挣扎，不如去一个新的地方冒险。我相信，总会有实现梦想的地方。）。

　　另外一方面，如果直到项目已经开始你才注意到上述的危险，你就不得不做出判断，如果设法去修正这些问题，对于项目是好还是坏。在产品到了Beta版的时候你跑过去跟主程序面对面大吵一番可能会延缓而不是加速项目的完成。

　　如果，经历这所有的一切，你开始了和其他人合作设计，我们希望你会发现那句老话"人多力量大"在这里能派得上用场，而不是"每人都来添勺羹，结果乱成一锅粥"。

• 【西西河电子期刊】第11期（下）