作者：Cliff Bleszinski

到今年夏天，我从事职业游戏设计就到第20个年头了。我曾领导团队设计平台游戏、FPS、单机游戏、多人游戏等等。我曾和一些最令人叹服的程序师、美术人员、动画师、写手和制作人共事。这20年以来，我注意到创意人员经常使用的交流方法。

我知道虽然开发人都非常高明，但有时候他们并不敢肯定与同行相比自己能有多聪明。我曾看到开发者在留言板上对百万美元的游戏大作、独立游戏宠儿等过度分析、吹毛求疵。我们总想证明自己比其他人有先见之明，或者引用一个例子，说明那个创意已经被尝试了、能成功、会失败或行不通等。

开发者们为了“赢得”得谈话，经常会使用一些讨论、争论和辨论方式。本文要介绍的就是这些常用手段。

以下说法和绰号没有恶意地针对谁；事实上，有几个方法确实是因为有理有据才被使用的。例如，样式对比可以避免制作出派生产品；边界案例有时候可以抹杀可靠的想法。以下就是我所谓的交流“技巧”。

“样式对比”

这是指开发人为了否绝一个创意，立刻在他的头脑中检索他的游戏/流行文化库，然后找出最接近的想法作为比较对象（常常是糟糕的或失败的案例）。

以《阿凡达》为例，“你想制作一部关于蓝皮肤的人在丛林中对抗坏人类的军队和机器？什么，蓝精灵丛林大战外星人？”不恰当地类比，《战争机器》可以看作是80年代的低级恐怖电影《C.H.U.D》（游戏邦注：在电影《C.H.U.D》中有一种生活在城市底下的基因突变人，以食人肉为生，而《战争机器》中也存在类似的怪物）。

“边界阻塞”

这是指用一个边界情况来否绝可能很了不起的想法。例如，举出边界情况的人可以否定在《天际》中创造一个大世界的想法，因为担心玩家要走回原来的地方，且步行太老套。清楚明确的修改方法如“快速旅行”的可以轻易地解决这个大世界问题。

边界阻塞有变体：

“交际人”：这是指因为某个想法在边界情况或特定的合作模式中不成立就否决它——这是边界阻塞的变体。“《英雄本色》的慢动作怎么可能在合作模式中起作用？不可能！”

“完美主义者”：类似于边界阻塞。这是指开发者发现在某种情况下，一个很不错的设定可能看起来并不完美。比如，格斗动作有时候会导致角色发生微小的变化。

“从来没见过做得好的”

这句话的意思也就是“我以前从来没见过这种想法行得通或做得好的。所以，我们不应该这么做。”这是一种相当不言自明的论断，事实上，这也可能是为什么应该执行某个想法的理由。按这种逻辑，所有创意都只能是雷同的。

比如，在《战争机器》中设定了一种生活在地下的Locust人，这个设定行得通的原因有很多，但我们仍然对它持保留意见。毕竟，这个设定使该游戏从其他带有常规外星人的游戏中脱颖而出。

“故意唱反调的人”

为了保全颜面，大多数开发人经常故意唱反调，甚至在他们自己也相信这个想法时候。律师经常使用这一招。

“不过是X+Y罢了”

这是指开发者怀着酸葡萄心理贬低其他成功的作品，因为他可以轻易地看出其中的原理。事实上，正是因为游戏原理非常简单明显，才使游戏如此成功。

例如，《Words with Friends》：“不过是异步拼字游戏罢了。”是的，正是如此，所以它成功了。

“以后再说”

当开发者听到一个想法——无论好坏，就说这个想法很适合之后的版本或续作。这句话的真实含义是，“我认为这个想法不值一试，所以我们放弃吧，我说以后再说是为了让你不难受。”

“通天塔”

这是当开发者在一个本来很简单的设定上堆砌太多额外的小东西时，但这些小东西最终危及整个设定。这座“通天塔”是被自己的重量压跨的。

“雪崩效应”

之所以用这个方法否绝一个想法，是因为这个想法需要许多其他部门（游戏邦注：如动画、UI或美术）做更多工作。通常，有趣或值得尝试的特点都会牵涉到更多部门，因为涉及多个学科的知识。

“过度分析”

这个常用的词是指过分考虑某个想法，以致于一事无成。

“试什么试？”

换句话说，“我们怎么跟别人比？”因为在某个方面面临激烈的竞争，开发者就这么问，以免尝试。

“他们有N个开发者啊！”

当开发者说到某个竞争团队的规模有多大时就会这么说，说完这句话以后紧接的就是上面那句。为了高效地工作，Epic公司总是让最好的人从事同一个任务，用最好的工具。

“保守主义者”

“但是我们一般都是这么做的啊！”在娱乐行业，特别是与技术有关的行业，为了生存，创意和反思是非常必要的。自满和墨守成规必然导致失败。

在某个常规行业工作20年可能是个优势，但在技术行业，这可能会成为你的绊脚石。作为开发者，越要保持眼界开阔，要活到老学到老。

“但我们是XXX（“XXX”指工作室名称）

当工作室准备将自己的名誉押在某个项目的成功上时，就会发出这样的战斗口号，还自认为很强大。当工作室的人这么说的时候，你就知道这个工作室离内乱的日子不远了，因为更年轻的新员工满怀梦想，总是想取代老员工、创造新的辉煌。

“我们以前就试过了”

为了否定旧想法的替代方案（可能行得通），就提出以前尝试旧想法失败的经历。

“太先进了”

你的想法太棒了！事实上，这个想法太前卫太创新了。所以，我们不应该尝试，因为听起来挺费功夫的。

“按我们这行的话说……”

这是指，为了在争论中占上风，开发人抛出只有他自己专业的人才懂的术语，使不同专业的其他开发人不知所云。例如，程序员用代码的原理跟美术人员讨论，设计师用设计行话向动画师解释。

“部落首领”

当开发人固执地信仰自己的专业（美术、编程、设计等），而排斥工作室里其他专业的人的见解。

“不在范围之内”

“这个想法很好，但不在我们的项目范围之内。”很不幸，有时候，最好的想法不会在原本的计划之内。

“测试把戏”

开发人为了否绝某个新设定、新武器，就强烈建议“和谐”它，他的方法是在测试时变更它，这样游戏就按着他的思路设计了。有时候，人们为自己的想法付出了很多努力，结果却被别人破坏了，遇上这种情况，看开了就好。

“学舌”

这是指一类人，他们听到你的想法，反而像从来没听过似的，用自己的话把你的想法当成自己的说出来，还忘记自己是从哪听到这个想法。这从根本上说没什么大不了的，只要这个创意行得通就行了。

“长篇大论”

这类人用三页长的邮件回应设计建议或讨论。

每次都是这样，最终，你得为这个人设一个专门的文件夹。

“邮件盲”

这类人在邮件方面似乎总像个彻头彻尾的傻冒，即使他们并不是故意的。

“哥拉斯”

因为主观地认定一个想法不好，这类人莫名其妙地就叫停所有进程，提出自己全新的想法，最终所有人都不得不重新开始。

“怀疑论者”

这类人没有任何明确的理由就拒绝一个想法，他们的说法是“对此，我不知道……”，却往往很管用。

“先知”

这类人对一个想法怀有一时的冲动热情，但从未站在设计或其他学科的角度考虑它。这类人单纯地希望所有人都相信这个想法会成功，而不是根据它做出原型。这往往是年轻的、没经验的设计师的举动。

“亚哈船长”（游戏邦注：这是小说《白鲸》中的人物，固执地想找白鲸复仇。）

这类人拒绝承认某个想法行不通，同时不断地尝试，不惜浪费珍贵的代码和美术资源，妄想有一天，这个想法会成功。

“数据控”

这类人出现的情况是：“这个表格中的数据客观公正地表明，你的想法永远不会成功，你会使很多人不愉快，这个方向我们不能走。”

“精神期望”

这是指一个程序师拒绝理解被提出来的设想，直到这个设想以程序师自己想的方式被要求执行时。

“无视”

这类开发人有意（或无意）地忽略可能会成功的想法。

“事不关己”

这类设计师口口声声说想要创意，听了别人的想法后又默默地忽略任何不是他自己想出来的东西。

“园丁”

园丁早早地种下了想法的种子，然后多次在会议上提起，甚至与他人闲聊时也不忘说上一句。最后，这个想法开始在其他人心里生根发芽，直到它成为游戏中的一部分，都没有人记得这个想法最初是从哪冒出来的。这确实是个实用的技巧。

“漏洞仔”

当进程中出现一个设定，设计师不考虑这个设定的目的或作用，只顾着指出明显的错误，而这些错误显然是最终能解决的。

“多个头领”

当一个人没有明确的顶头上司，不知道该听谁的发号施令时，他往往会听从多个人的指挥。设计总监、执行制作人和董事可能各有自己的观点，让没有明确上司的员工感到困惑不堪。

“打包票”

这个词是指发言人向媒体承诺某个设定，让团队不得不按他放出的话来做。

“随大流”

创意人员看到最近游戏的游戏中有什么，他就采纳什么，心想这样就可以做出好游戏，也省了想法子创新。

总而言之，以上就是我这些年见识过的开发人的个性的交流“技术”。多谢了在Epic、ChAIR和People Can Fly的同行们为我提供的材料。我希望有远见的开发人可以意识到这些问题，并相应地改正。我也希望此文能让博得创意人员的会心一笑。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Cliff Bleszinski’s Game Developer Flashcards

by Cliff Bleszinski

As of this summer, I’ll have been making games for 20 years professionally. I’ve led the design on character mascot platform games, first-person shooters, single-player campaigns, multiplayer experiences, and much more. I’ve worked with some of the most amazing programmers, artists, animators, writers, and producers around. Throughout this time period, I’ve noticed patterns in how we, as creative professionals, tend to communicate.

I’ve learned that while developers are incredibly intelligent, they can sometimes be a bit insecure about how smart they are compared to their peers. I’ve seen developer message boards tear apart billion-dollar franchises, indie darlings, and everything in between by overanalyzing and nitpicking. We always want to prove that we thought of an idea before anyone else, or we will cite a case in which an idea has been attempted, succeeded, failed, or been played out.

In short, this article identifies communication techniques that are often used in discussions, arguments, and debates among game developers in order to “win” said conversations.

These observations and monikers are not meant to be antagonistic; in fact, several of the approaches mentioned here are employed because of valid reasoning. For example, pattern matching can be a good way of avoiding making derivative products, and sometimes an edge case can, in fact, kill a solid idea. So here are my Game Developer Communication “Flashcards.”

“Pattern Match Dismissal”

This is when a developer immediately runs through his gaming/pop culture library in his head and finds the closest thing to compare it to (often, a bad or failed example) in order to shoot it down.

For example, in regards to Avatar, “You want to make a movie about blue people in a forest with a bad military and mechs? What, Smurf Ferngully Aliens?” The Gears of War franchise, pitched improperly, could be seen as the old ’80s schlock horror movie C.H.U.D.

“Edge Blocking”

This refers to using an edge case to block a potentially awesome idea. i.e., an Edge Blocker would shoot down the idea of having giant worlds in Skyrim because of a concern that you’d have to trek back to where you came from and that all that walking would get old. Obvious and clear fixes such as the gameism of “fast travel” can easily solve this issue, allowing for huge worlds.

Edge Blocking has variants:

“The Networker.” This is a way of shooting down an idea because it won’t work in an edge case or unique co-op situation — this is a variant of Edge Blocking. “How would Max Payne slo-mo work in co-op? Impossible!”

“Perfectionist.” Similar to Edge Blocking, this is when a developer finds one instance whereas a cool feature might not look absolutely perfect, e.g., an amazing melee move that occasionally will result in some minor clipping of characters into one another.

“Ne’er Do Well”

Or “I’ve never seen that feature done before, or done well. Therefore, we shouldn’t do it.” This one is pretty self-explanatory, and, in fact, can be the reason why an idea should be done. Following this logic only leads to “me-too” creation.

As a reference, a Locust population from the underground in Gears of War worked for many reasons, but we still had reservations about it. In the end, it helped differentiate the franchise from others that featured the usual aliens-from-above/space.

“Devil’s Advocate”

Most developers tend to use this technique, even when they believe in an idea, as a form of covering their ass. Often used by lawyers.

“It’s just X+Y”

This is when a developer dismisses another successful product, sour grapes style, because he can easily see the formula. The fact that the formula is so simple and obvious is often why said product is so successful.

For example, Words with Friends: “It’s just asynchronous Scrabble.” Yes, it is, and it’s brilliant.

“Future Release”

This occurs when a developer hears an idea — good or bad — and says that it will fit nicely into a later version or sequel. This is code-speak for “I don’t think that idea is worth doing, so we’re going to shoot it down by saying we’ll do it later in order to make you feel better.”

“Toppling,” a.k.a. “Tower of Babel”

This technique is when a developer adds too many bells and whistles to a feature that was pitched as simple, but ultimately jeopardizes the feature altogether due to these additions. The feature “topples” under its own weight.

“Think of the Children!”

This is otherwise known as “Cascading Dependencies.” The tendency is to shoot down an idea because it will cause more work for other departments, such as animation, UI, or art. Often, features that are interesting and/or worth doing have these sorts of ramifications as they combine all disciplines.

“Analysis Paralysis”

This is a commonly-used term for the technique of over-thinking things to the point where nothing is actually done.

“Why Even Try?”

In other words, “How do we even compete?” Intimidated by the immense competition in any given space, a developer asks this as a way of giving up before even giving it the “old college try.”

“They Have N Developers!”

This is a phrase that is often used by a developer to cite a competitive team and how large their staff is on their game, and is used as a way of leading to “why even try?” The Epic Way has always been to put the best people on a task, with the best tools in the business, in order to work smarter.

“Traditionalist”

“But this is how we’ve always done it!” In entertainment, and particularly in technology, innovation and re-thinking things is often quite necessary in order to stay alive. Becoming complacent and doing things the same way over and over again is a surefire way to induce failure.

Being a 20-year veteran of any regular business may be an advantage, but in technology, it can sometimes limit you. As a developer gets older, it’s crucial to keep an open mind and to always be learning.

“But We’re (Insert Studio Name)”

This is the battle cry of a studio that is ready to rest on its laurels due to a certain level of success and thinking they’re badasses. The moment folks at a studio start saying this, one can count the days until the studio implodes, because a younger, hungrier crew out there wants what you have and is willing to dream and make it happen.

“We Tried That Before”

Citing a previous failed attempt at an idea in order to kill a new (and potentially workable) permutation of said idea.

“Too Cool”

Your idea is great! In fact, it’s too cool and innovative. Therefore, we shouldn’t do it, because it sounds like a lot of work.

“Jargonating”

This is when a developer uses forms of jargon only native to his discipline in order to win an argument with a developer of a different discipline, e.g., a coder using code-speak to an artist, or a designer using designer lingo to an animator.

“The Tribal Leader”

This happens when developer believes in his discipline (art, code, design, etc.) over any other in the studio, so fuck those other guys.

“Noscope”

“That idea is great but isn’t within the scope of the project.” Sometimes, the best features are the fringe ones that sneak in under the radar and not on the original schedule, unfortunately.

“Playtest Grandstanding”

This is when a developer fails with a new feature or weapon and loudly suggests “balancing” it by changing it during a playtest, therefore often getting his way. Sometimes, people just suck with a sniper rifle and get destroyed by others, and that’s okay.

“The Repitcher”

This is the person who hears your idea, seems like they didn’t initially hear it, then re-pitches the same exact idea in their own words as their own, forgetting where they originally heard it. This ultimately doesn’t really matter, as long as the cool idea comes from somewhere and is implemented well!

“Filibuster,” or “TL;DR Guy”

This is the person who responds to a design suggestion or discussion with three-page emails.

Every time.

Without fail.

Eventually, you make a custom filter for this person.

“The E-Douche”

This is the person who almost always seems to come across as a total asshole in email, even when they don’t really mean to because, frankly, email sucks.

“Godzilla”

This is a person who somehow manages to shut down all progress on an idea and comes up with his own completely new pitch that is subjectively better or worse, essentially trying to make everyone start over.

“The Doubter”

Someone who rejects an idea without having any sort of clear reason why: “I don’t know about that…” Often useful against the…

“Prophet”

A designer who has a rush of excitement about an idea, but hasn’t thought through it fully in regards to its design and/or ramifications. Said designer simply expects everyone to have faith that the idea will wind up good instead of properly making the case for it. This is often common behavior with a younger, less experienced designer. Similar to…

“Captain Ahab”

This is when a designer refuses to admit that an idea just isn’t panning out, while endlessly iterating on it, using precious code and art resources, assuming someday, one day, it will be fun.

“Data Bombing”

This an argument used that goes as such: “This chart of loosely related and completely unbiased data shows how your idea will never succeed, you’ll offend lots of folks, and it’s a direction we cannot afford to go in.”

“Psychic Expectations”

This is a technique used by a coder in which said coder refuses to understand the pitched/desired feature until it is requested in the exact specific manner the coder wants to hear it.

“Ignorannihilation”

The developer who intentionally (or unintentionally) misses the obvious and starves a potentially good feature until it is cut.

“Not My Idea, Not Going to Do It”

This is when a designer takes input from others and claims to want a call for ideas, yet quietly ignores anything he didn’t come up with himself.

“The Gardener”

The Gardener plants the seed of an idea early and then brings it up again many times in meetings and in casual conversations with individuals around the office. Eventually, the idea starts to take root and grows on people until it becomes an actual feature in the game and no one can remember where the idea came from in the first place. This is actually a very useful technique.

“Obvious Bug Guy”

This is when a developer is being shown a work in progress feature and, instead of thinking about where the feature is headed or what it can do, feels the need to point out obviously broken things that will clearly get fixed eventually, like Z-fighting.

“Multiboss”

This when a person has no clear, obvious boss or chain of command, and is often told by multiple people what he should be working or focusing on. One’s design director, executive producer and president may each have varying opinions about what to do, leaving said staff member confused.

“The Promiser”

This term refers to a spokesperson who pitches or promises a feature to the media, which puts the team on the hook to actually code said feature once they’ve gone public with it.

“The Bandwagoner”

This is the term for the creative who wants to add whatever feature he saw in a recent popular game as a way of making the game better instead of trying other ways to innovate.

So, in conclusion, that’s the list of personalities and techniques that I’ve encountered throughout the years. Thanks to some of my peers at Epic, ChAIR, and People Can Fly for contributing to the list. I hope that aspiring developers can recognize these patterns and adjust accordingly, and I hope that established creatives are able to get a chuckle out of this.(source:gamasutra)