Author: by Cliff Bleszinski

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.

"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.

Original illustrations by Juan Ramirez