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.
Subscribe to:
Post Comments (Atom)
1 comment:
I think the main problems are the non-technical inclination of most people with the designer title, and the entrenched belief that somehow designers are more qualified to make design decisions than other departments.
Most of the designers I have ever worked with have a very flimsy understanding of how the systems they are working with even work, despite having it explained to them multiple times and multiple ways. It's like they feel like the realities of the implementation don't (or shouldn't) affect their process.
The sad (for them) reality is that anybody can come up with ideas they think would be cool in a game. The real trick, as you say, comes from the ability to implement it.
On my current project (as well as those long past) I have seen time and again where someone with no actual ability will write documents and hem and haw endlessly about the strengths and weakness of various features, tossing aside valid suggestions from anybody who does not bear the title of Design. It's not as though being a designer means one is intrinsically better at designing games. In fact, I'd challenge that rather vehemently. I know some loudmouth designers with TERRIBLE ideas. I know engineers with terrible ideas as well, but at the end of the day, at least they have engineering work to fall back on.
Like you say, at the end of the day, it's the implementer who has the final say. I won't go as far as to say it's the engineer, because I have seen scripters do some remarkable things with the limited functionality given to them.
Perhaps it is just the inclination of non-technical people to constantly try to work outside their means. To not fully grasp the limits of the environment in which they are forced to work.
Either way, I very rarely see the design department approach things like game mechanics from a collaborative direction. It's always a designer dictating how a feature will work without ever expecting to work through any iteration.
I think the real revelation will come when we get rid of the loosely defined role of Designer, replacing the real design work with gameplay programmers and having them support an army of mission scripters... all with technical know-how.
Alas, I don't think this is a paradigm shift that is likely to happen soon as all the people in key positions still have their roots as Game Designers. I can't wait until that day.
Post a Comment