Epic Games' design director Cliff Bleszinski profiles common developer behavior in this special Gamasutra feature.

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.