总结开发者在合作过程中的典型交流方式
作者：Cliff Bleszinski
到今年夏天，我从事职业游戏设计就到第20个年头了。我曾领导团队设计平台游戏、FPS、单机游戏、多人游戏等等。我曾和一些最令人叹服的程序师、美术人员、动画师、写手和制作人共事。这20年以来，我注意到创意人员经常使用的交流方法。
我知道虽然开发人都非常高明，但有时候他们并不敢肯定与同行相比自己能有多聪明。我曾看到开发者在留言板上对百万美元的游戏大作、独立游戏宠儿等过度分析、吹毛求疵。我们总想证明自己比其他人有先见之明，或者引用一个例子，说明那个创意已经被尝试了、能成功、会失败或行不通等。
开发者们为了“赢得”得谈话，经常会使用一些讨论、争论和辨论方式。本文要介绍的就是这些常用手段。
以下说法和绰号没有恶意地针对谁；事实上，有几个方法确实是因为有理有据才被使用的。例如，样式对比可以避免制作出派生产品；边界案例有时候可以抹杀可靠的想法。以下就是我所谓的交流“技巧”。
“样式对比”
这是指开发人为了否绝一个创意，立刻在他的头脑中检索他的游戏/流行文化库，然后找出最接近的想法作为比较对象（常常是糟糕的或失败的案例）。
以《阿凡达》为例，“你想制作一部关于蓝皮肤的人在丛林中对抗坏人类的军队和机器？什么，蓝精灵丛林大战外星人？”不恰当地类比，《战争机器》可以看作是80年代的低级恐怖电影《C.H.U.D》（游戏邦注：在电影《C.H.U.D》中有一种生活在城市底下的基因突变人，以食人肉为生，而《战争机器》中也存在类似的怪物）。
“边界阻塞”
这是指用一个边界情况来否绝可能很了不起的想法。例如，举出边界情况的人可以否定在《天际》中创造一个大世界的想法，因为担心玩家要走回原来的地方，且步行太老套。清楚明确的修改方法如“快速旅行”的可以轻易地解决这个大世界问题。
边界阻塞有变体：
“交际人”：这是指因为某个想法在边界情况或特定的合作模式中不成立就否决它——这是边界阻塞的变体。“《英雄本色》的慢动作怎么可能在合作模式中起作用？不可能！”
“完美主义者”：类似于边界阻塞。这是指开发者发现在某种情况下，一个很不错的设定可能看起来并不完美。比如，格斗动作有时候会导致角色发生微小的变化。
“从来没见过做得好的”
这句话的意思也就是“我以前从来没见过这种想法行得通或做得好的。所以，我们不应该这么做。”这是一种相当不言自明的论断，事实上，这也可能是为什么应该执行某个想法的理由。按这种逻辑，所有创意都只能是雷同的。
比如，在《战争机器》中设定了一种生活在地下的Locust人，这个设定行得通的原因有很多，但我们仍然对它持保留意见。毕竟，这个设定使该游戏从其他带有常规外星人的游戏中脱颖而出。
“故意唱反调的人”
为了保全颜面，大多数开发人经常故意唱反调，甚至在他们自己也相信这个想法时候。律师经常使用这一招。
“不过是X+Y罢了”
这是指开发者怀着酸葡萄心理贬低其他成功的作品，因为他可以轻易地看出其中的原理。事实上，正是因为游戏原理非常简单明显，才使游戏如此成功。
例如，《Words with Friends》：“不过是异步拼字游戏罢了。”是的，正是如此，所以它成功了。
“以后再说”
当开发者听到一个想法——无论好坏，就说这个想法很适合之后的版本或续作。这句话的真实含义是，“我认为这个想法不值一试，所以我们放弃吧，我说以后再说是为了让你不难受。”
tower of babe(from gamasutra)
“通天塔”
这是当开发者在一个本来很简单的设定上堆砌太多额外的小东西时，但这些小东西最终危及整个设定。这座“通天塔”是被自己的重量压跨的。
“雪崩效应”
之所以用这个方法否绝一个想法，是因为这个想法需要许多其他部门（游戏邦注：如动画、UI或美术）做更多工作。通常，有趣或值得尝试的特点都会牵涉到更多部门，因为涉及多个学科的知识。
“过度分析”
这个常用的词是指过分考虑某个想法，以致于一事无成。
“试什么试？”
换句话说，“我们怎么跟别人比？”因为在某个方面面临激烈的竞争，开发者就这么问，以免尝试。
“他们有N个开发者啊！”
当开发者说到某个竞争团队的规模有多大时就会这么说，说完这句话以后紧接的就是上面那句。为了高效地工作，Epic公司总是让最好的人从事同一个任务，用最好的工具。
“保守主义者”
“但是我们一般都是这么做的啊！”在娱乐行业，特别是与技术有关的行业，为了生存，创意和反思是非常必要的。自满和墨守成规必然导致失败。
在某个常规行业工作20年可能是个优势，但在技术行业，这可能会成为你的绊脚石。作为开发者，越要保持眼界开阔，要活到老学到老。
“但我们是XXX（“XXX”指工作室名称）
当工作室准备将自己的名誉押在某个项目的成功上时，就会发出这样的战斗口号，还自认为很强大。当工作室的人这么说的时候，你就知道这个工作室离内乱的日子不远了，因为更年轻的新员工满怀梦想，总是想取代老员工、创造新的辉煌。
“我们以前就试过了”
为了否定旧想法的替代方案（可能行得通），就提出以前尝试旧想法失败的经历。
“太先进了”
你的想法太棒了！事实上，这个想法太前卫太创新了。所以，我们不应该尝试，因为听起来挺费功夫的。
“按我们这行的话说……”
这是指，为了在争论中占上风，开发人抛出只有他自己专业的人才懂的术语，使不同专业的其他开发人不知所云。例如，程序员用代码的原理跟美术人员讨论，设计师用设计行话向动画师解释。
“部落首领”
当开发人固执地信仰自己的专业（美术、编程、设计等），而排斥工作室里其他专业的人的见解。
“不在范围之内”
“这个想法很好，但不在我们的项目范围之内。”很不幸，有时候，最好的想法不会在原本的计划之内。
“测试把戏”
开发人为了否绝某个新设定、新武器，就强烈建议“和谐”它，他的方法是在测试时变更它，这样游戏就按着他的思路设计了。有时候，人们为自己的想法付出了很多努力，结果却被别人破坏了，遇上这种情况，看开了就好。
“学舌”
这是指一类人，他们听到你的想法，反而像从来没听过似的，用自己的话把你的想法当成自己的说出来，还忘记自己是从哪听到这个想法。这从根本上说没什么大不了的，只要这个创意行得通就行了。
“长篇大论”
这类人用三页长的邮件回应设计建议或讨论。
每次都是这样，最终，你得为这个人设一个专门的文件夹。
e-douche(from gamasutra)
“邮件盲”
这类人在邮件方面似乎总像个彻头彻尾的傻冒，即使他们并不是故意的。
“哥拉斯”
因为主观地认定一个想法不好，这类人莫名其妙地就叫停所有进程，提出自己全新的想法，最终所有人都不得不重新开始。
“怀疑论者”
这类人没有任何明确的理由就拒绝一个想法，他们的说法是“对此，我不知道……”，却往往很管用。
the prophet(from gamasutra)
“先知”
这类人对一个想法怀有一时的冲动热情，但从未站在设计或其他学科的角度考虑它。这类人单纯地希望所有人都相信这个想法会成功，而不是根据它做出原型。这往往是年轻的、没经验的设计师的举动。
“亚哈船长”（游戏邦注：这是小说《白鲸》中的人物，固执地想找白鲸复仇。）
这类人拒绝承认某个想法行不通，同时不断地尝试，不惜浪费珍贵的代码和美术资源，妄想有一天，这个想法会成功。
“数据控”
这类人出现的情况是：“这个表格中的数据客观公正地表明，你的想法永远不会成功，你会使很多人不愉快，这个方向我们不能走。”
“精神期望”
这是指一个程序师拒绝理解被提出来的设想，直到这个设想以程序师自己想的方式被要求执行时。
“无视”
这类开发人有意（或无意）地忽略可能会成功的想法。
“事不关己”
这类设计师口口声声说想要创意，听了别人的想法后又默默地忽略任何不是他自己想出来的东西。
the gardener(from gamasutra)
“园丁”
园丁早早地种下了想法的种子，然后多次在会议上提起，甚至与他人闲聊时也不忘说上一句。最后，这个想法开始在其他人心里生根发芽，直到它成为游戏中的一部分，都没有人记得这个想法最初是从哪冒出来的。这确实是个实用的技巧。
“漏洞仔”
当进程中出现一个设定，设计师不考虑这个设定的目的或作用，只顾着指出明显的错误，而这些错误显然是最终能解决的。
multi boss(from gamaustra)
“多个头领”
当一个人没有明确的顶头上司，不知道该听谁的发号施令时，他往往会听从多个人的指挥。设计总监、执行制作人和董事可能各有自己的观点，让没有明确上司的员工感到困惑不堪。
“打包票”
这个词是指发言人向媒体承诺某个设定，让团队不得不按他放出的话来做。
“随大流”
创意人员看到最近游戏的游戏中有什么，他就采纳什么，心想这样就可以做出好游戏，也省了想法子创新。
总而言之，以上就是我这些年见识过的开发人的个性的交流“技术”。多谢了在Epic、ChAIR和People Can Fly的同行们为我提供的材料。我希望有远见的开发人可以意识到这些问题，并相应地改正。我也希望此文能让博得创意人员的会心一笑。
（本文为游戏邦/gamerboom.com编译）