|
In August, Epic Games design director Cliff Bleszinski submitted a list of "game developer flashcards" to Gamasutra -- a taxonomy of personalities and situations he's encountered over the course of his 20 year career.
"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," Bleszinski wrote. "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."
The article garnered a tremendous response -- 71 comments, as of this writing -- and after taking a look at them, we decided to round up the best into a second installment of the article. Below, you'll find a second set of "flashcards" contributed by the community, with fresh illustrations by Juan Ramirez, who provided the art for Bleszinski's original article.
Your Design Chocolate is in My Art Peanut Butter. When an artist is disagreeable to incorporate a meaningful player feedback device, such as a visible wall or some other element, because they fear its incorporation will upset the visual composition of their work -- even though both in concert should result in a superior gameplay experience. - Ara Shirinian
Agile in Name Only. The producer who misuses Agile terminology, but never uses Agile development. The project ends up with a traditional waterfall dev cycle, but everything is horribly mislabeled. - Matthew Henry
The Do Nuthin'. Someone on the team that does nothing other than pass along your reports. - Aaron Cassillas
That's Not What [Blank] Is! A designer who would disagree with a non-Newtonian gravity mechanic because that's not what gravity is. - Matthew Downey
Trust Me, I'm the ____. When an artist, programmer, or designer uses their superior knowledge within their own field to avoid adding an element that may grow the scope within their department. - Tyler Coleman

The Box Dweller. Someone who immediately dismisses an idea because it wouldn't work within some other (often easily changeable) current constraint in the game.
Example: "We could never let you throw more than one grenade! The explosion overdraw would kill the framerate!" - Aaron San Filippo
Responses to Cliff
Some of the comments, of course, built directly upon concepts introduced in the original article. The following four, in fact, describe personalities -- and their techniques -- that specifically counter some of Bleszinski's examples.
Dying on that Sword. The dev who refuses to back an idea, no matter what. Passively (or actively) works to prevent its success, even when the rest of the team is moving forward. Is often a response to ideas from The Prophet or The Gardener. - Curtiss Murphy
The Pesticide. The person who did not like The Gardener's idea in its earlier stages, and will now do anything they can to keep it out. - Tyler Coleman
The Anti-Prophet. The evil opposite of The Prophet who simply knows -- but has no reasons -- the idea won't work. If you ask why, (s)he'll reply with "You didn't think it through enough," when the truth is (s)he hasn't thought it through at all. - Matthew Henry
General Patton. The opposite of Analysis Paralysis. "A good plan violently executed now is better than a perfect plan executed next week." Though it's always good to think things through, too much thinking can be harmful. It's good to ask yourself: "Am I thinking about this aspect too much/little?" - Jan Stec

The Puppet. This particular developer has a role with responsibility to the game, but allows him or herself to be pushed around by people above them (who haven't played a game since Minesweeper.)
Their team implements designs that no one agrees are even the slightest bit decent. Sometimes they've got a hand so far up their ass the design team can't even suggest alterations to improve an idea without getting snapped at. - Sean Watson
|
And I still get the job done, somehow.
This would make me look like I am bragging right?
No, this only mean that I am pessimist and that I make very bad predictions, greatly irritating my producer that I always screw-up his schedule, and greatly irritating the director because I always make he believe that nice stuff cannot be done in time...
But at least they like the 10 minute part, and keep me around :)
I am also quite solidly a 'Let's Try It' in the design phase. Games are supposed to be fun, and the design phase is where you come up with awesome and fantastical ideas for features, art, scenarios, etc. Why do you need any more than the idea? If it doesn't work when you go to code planning, just drop it like it's hot.
I am a Kindergarten Teacher as well, but that's mostly because I see stuff like Real Housewives and Jersey Shore and just know there's no hope for humanity here. Do you think your average MTV-viewing high schooler is going to figure out a puzzle which requires a deep understanding of RGB color mixing or the Wheel of Fifths? No, if current gaming trends are any indication, they just want to shoot, hack and slash, or beat on stuff and hope it blows up.
Sometimes, I can Pull A Scotty - depends on how complex the feature is.
I have an issue with "The Deflector" I don't think that's entirely accurate.
Ok, say I'm responsible only for programming a game's engine. So the way the engine performs would be "my own work", and I have no problem taking responsibility for it - say there is a functional bug in the game, or some run-time exception. However, if the issue is based on a facet of the game's DESIGN (for which I am NOT responsible for, as I would get these specs from the designer(s), the producer(s), and/or otherwise "upper management"), if that "thing" does indeed degrade the overall quality of the game, then that's NOT MY FAULT, because I didn't come up with that idea in the first. I'm just the coder. Therefore, that is not a "deflection", but merely the plaintiff addressing the issue to the wrong personnel. That issue needs to be addressed with the designer(s), the producer(s), and/or otherwise "upper management". (Now, if I coded that "thing" incorrectly, then yeah, that's my bad, but if it's performing according to spec, then that's on them.)
I've done The Skull Build a few times also. ;-)
This article definitely reminds me of "The Game Studio Culture Dictionary":
www.gamasutra.com/view/feature/6504/a_game_studio_culture_dictionary.php
What also immediately came straight to mind is "How a Web Design Goes Straight to Hell", which could easily applied to game design also:
http://theoatmeal.com/comics/design_hell
_____________________
- Ziro out.