Thursday, March 27, 2008

What's a Designer?

I've been following the recent drama with an old coworker of mine, Adam Maxwell, and the games industry at large. It's regarding the value of writers in the industry versus designers, and whether designers should be encouraged to write, or whether writers should be encouraged to work on games and elevate game stories.

I sort of think the whole conversation is somewhat pointless, but some of Adam's comments got me thinking about design a bit, and I figured I'd make a post about it so I don't forget. I really tend to assume no one reads this so I sometimes go off on little rants (guess I'm never working at Neversoft), but I'm going to try to be somewhat diplomatic here, possibly more diplomatic than Mr. Maxwell.

My point then, finally, is that the role of "designer" on a game team is just fucking awfully horribly and terribly defined as far as roles go. Everyone knows what an animator should do, everyone knows what programmers do, everyone knows what environment and character artists do, but what does a designer do?

Well he or she designs the game of course. Whoa... back up a second. What does that mean, exactly? Iterate on mechanics? Implement game features? Create Missions? Map out levels? All of the above? Manage an overall game vision? Write the story? Write Dialogue?

At the end of the day, depending on where you work, or even what project you work on, all or some of the above roles could belong to a designer. I think that means the entire idea of a "designer" at a game studio is somewhat useless. It's too ill-defined a role. I like the idea of a level designer, I like the idea of a mission scripter. I like the idea of a vehicle tuner (maybe, more on this later). I like well-defined roles that define jobs for people that they can actually do. I like giving people tasks they have a snowball's chance in hell of accomplishing.

Generally, in companies where I've worked, the role of "designer" tends to be given to people who's job it is, at some point or another, to make levels or missions. This then gets extended to include "designing" game features, whether they're mechanics, or window dressing around the mechanics. This tends to be done in the form of documents, whether they're short abstracts, or long, detailed descriptions, the role of "designing" mechanics falls to people who tend to be hired for skills having little or nothing to do with designing mechanics. They are then dropped into a role where it's basically impossible for them to actually design a mechanic.

You see, mechanics are designed in code. For better or for worse, love it or hate it, in the forseeable future, mechanics WILL be designed in code, or at least they should be. The initial idea should be implemented, iterated, and polished. This doesn't mean other departments don't have input, but it does mean, that at the end of the day, programming has control over the feature, or to be more specific, the feature is good to the degree that the person working on it has control over it, and that person is inevitably a programmer. You can give a data driven system to a non-programmer to "tweak" or adjust, and you can even sit this person down with a programmer to iterate with them, but at the end of the day, you're asking for frustration because the programmer is going to be the one who adds the feature that just makes the mechanic feel right. The "designer" on the mechanic is either going to dictate to a programmer who slavishly implements everything the designer says, in which case, will allow the designer to dig him or herself into a deep hole of not really understanding the guts of what's going on, or the programmer will just ignore the designer and do what he likes, in which case the designer rightly feels useless and undermined.

So why isn't the programmer the designer? Why are people in this industry reluctant to acknowledge the fact that at the end of the day, the programmers are in charge of the game features because they have the most control of the features? Are they afraid programmers will get big heads? (Maybe my head is already too big, I mean, look at this post).

We need people to layout maps and script missions and design game encounters and situations. We need people to provide feedback, Write stories and dialog, and generate content, but the job of "designer" is usually going to be a content creation job, and programmers are going to be the ones who actually "design" the mechanics of a game, at least until such time as the art is advanced enough so a non-techincal person can start to take the reigns of a more advanced feature. This means lead designers and project directors should be interviewing gameplay programming candidates as if they actually were designers, and vetoing those they deem unfit, and lead programmers are going to have to go along with this to some degree.

The guts and mechanics of a game are among the most important attributes to a game. A game with weak mechanics is going to be a bad game, no matter how good the engine or how nice the writing is. I think it's important to acknowledge and understand who is ultimately in control of this.