Friday, October 21, 2011

On My Mind: What is a game designer?

While I'm still on my job search process, I've start to notice something really wrong with the games industry, and more specifically, how we define roles within the industry.

What is a Game Designer?

I've had this happen to me many times: relatives, friends, or other general acquaintances would find out I "make games", and I would go on and give them the 30 second explanation. It's often half assed, and just covers a general overview of what I could be doing, like "yes I make the stuff you see on screen" (WHAT THE HELL DOES THAT EVEN MEAN). I'm not sure if this post is trying to set the record straight (and I'm sure I'll get stuff wrong), but at least some of my observations (mostly anecdotal):

1) A Game Designer has to do everything and nothing at the same time

In a very broad stroke: A Game Designer has their hands in every point of the game development. They're the people that define the look and feel, the experience that the player interacts with, yet they also don't deal directly with any of the actual complexity that exists in the game. While it is true that great art and technology is what the players will first see or use, it's pretty much up to designers to make those first impressions last with a fun and interesting experience.

Depending on the size and scale of the project, a designer could be coming up with the overarching idea, how players interact with the game, the player experience, the general visual design, right down to the minor details of timing and visual feedback. Yet without programmers or artists to support and implement their ideas, they're just that: ideas. You put 5 designers together in a room, and at best is you'll have the world's greatest theoretical game idea. In this light, a game designer is very much like a project manager: ideas are like project requirements, and it's the designer's job to come up with new solutions to solve problems as they arise. Sure, it'd be great if they can predict all possible problems and avoid them ahead of time, but able to change course when problems happen is also a much needed, yet often not talked about skill.

You'll know you have a good designer when they appear to not do anything, yet get everything right in a game. A game can have great artists and great programmers working on it, but if you have lousy designers, no one will care how visually stunning or technically amazing the game is.

2) A Game Designer wears multiple hats at any given point

Most people outside of games think Game Designers is this fancy job where they sit around and just play games all day, which couldn't be further from the truth. However, the idea that all Game Designers do nothing but just come up with ideas is also pretty off-base. It's also interesting to note that this idea of what designers do isn't limited to people outside of games either.

It's interesting to note that the Japanese term for Game Designer typically is "planner", as their job covers issues like schedule management, bug tracking and workflow organization on top of actual game design. While the typical western design won't have to deal with scheduling (job of the Project Manager) or bug tracking (that's for QA), Game Designers still don't get a free pass in terms of just sitting around and coming up with ideas.

If there's one word that sums up what a Game Designer would do, it'd be this:


In addition to coming up with "the kick-ass" idea and the "nitty gritty details", the primary job of a designer should always be communicating with the rest of the team: relaying programmers concerns to the project managers that more time is needed to finish a feature; relaying artist's need for better tools to programmers, working out solutions to focus on certain features to satisfy manager's timeline, etc...

In this sense, a Game Designer would practically be a part of all the teams: they would need to be able to talk to programmers, understand a general sense of the code, and translate that back to the manager; or be able to talk to artists and understand how animation works and relay info back to the programmers. It's not just, "hey it'd be cool to have explosions here, here and here..."

3) Game Designers with the same title can mean different things in different environment

My last job title "Game Designer" was probably the most generic and boring titles out there, and it also doesn't tell people a whole lot about what I do either. This "problem" isn't specific to just "Game Designers" either: a quick search on what Level Designers do ranges anything from event scripting, stage and geometry design(level blocking), to even the visual design of levels. What's scary about this is if you as an professional puts down "Level Designer", you better be prepared to cover the entire spectrum of topics like level flow and movement, to path traversal, environment blocking, to even visual design or event/AI scripting within the topic of level design.

These can all be considered level design, so what's a level designer expected to cover?

This inconsistency potentially leads to many problems: A combat designer on a 3D action game (like what I did before) won't even share the same language and understanding as someone who's a combat designer in a FPS: both designers would be concerned about "timing", but their priorities and concepts won't directly translate to the other.

Where this annoys me the most, especially during my job hunt, is realizing that even if I say I've worked on combat design, depending on other people's understanding of it, could mean completely different things. It's quite possibly the only branch of game development that faces this issue: You ask programmers and artists what their title is, and you'll have a fairly good understanding of what their speciality is - an UI programmer's role and job description will never deviate as much as game designers; Someone who is a user experience designer on one game will wildly differ in experience to others with the same title.

4) Not all Game Designers work with the same scope

A full game production is a fairly large task, and there's a huge difference between different design scope. The above picture of SimCity and The Sims is a pretty good representation of how big the gap can be.

I recall a conversation once with a few designers on who works well with which scope, and I found that discussion very important in identifying everyone's strengths. Not everyone is going to be great at looking at the big picture of the game; nor will everyone be great at looking at the nitty gritty details. As an example, you want someone who understands the nuisances of ammo capacity and reload working on game balance than someone who doesn't understand it.

I'm not suggesting the idea that you pigeonhole someone strictly in their own specialty, but don't confuse idea contribution with idea implementation: everyone is entitled to ideas and opinions, but having a macro designer implement fine details and vice versa can only result in frustration all around. Someone who focuses on the Big Picture may just brush off minor details as unimportant, and would only suggest sweeping changes when things don't feel right; someone who fine-tunes details maybe over-specific on the big picture, which doesn't work well with the ever-changing dynamics of a game project.

?) A Game Designer "should" have a general understanding of all types of games

Here's one that I thought about putting down, but I don't know whether this is true at all. Personally, I think I try hard to "cover" as much ground as I can, but I know that I can't possibly know it all. I know I don't play enough RTS to say anything too meaningful in a development environment, so I wouldn't dive head first into it if I was given a choice. I feel that a good designer should always "know what they don't know, and know where to get help".

However, this also runs directly head-on against what a game designer needs to do in a production environment: be the person that has all the answers, ensuring everyone understands the direction even if it hasn't been determined. I hate to think what kind of projects have run into this issue, and what the results could have been.

Here's a thought experiment that I've repeated over and over: let's assume you as a designer was dropped into a project of X genre, how well would you fair? What kind of decisions would you make? How comfortable would you be with telling people your ideas? Here's an example:

With the recent launch of NBA Jam and upcoming NFL Blitz, what if EA said: "hey, let's get working on Wayne Gretzky 3D hockey" again (or better yet, Midway's "NHL Hitz"). What/how would you approach it?

Obviously, the quick and dirty answer would be: know the sport, know the history of the series, the expectation of the genre, what fans expect from it, and built upon that... seems to easy, right? Well, maybe not: How much rubberbanding should the AI have so that the game still feels interesting without feeling cheap? Is having power-ups within the game too "gamey" and not true to the sport? How much of a role should checking have in the game? As an arcade game, how much complexity should the control scheme have? Suddenly, a simple idea of a game balloons into something much more complex and much less defined.

Sure, personally I know what an RTS is, what mechanics are involved, etc, but I know I don't know enough to make a gut call on anything about people's design choices other than being the casual observer. I think I can say the same thing to many other genres, and I sometimes get a good chuckle from others who think they have all of it covered. As much as Miyamoto is an awesome guy who's done great things with games, I highly doubt he can make Halo. He can "make" an FPS, I have no doubt, but will it understand the nuances that people expect from shooters if he hasn't made one before (or is immersed within the genre itself)? There are reasons why certain dev teams dedicate themselves to a specific genre: you retain the people with the knowhow in that genre.


I'm pretty sure I've rambled on for too long, and I still probably wrote stuff that doesn't make sense. I hope I've clarified some of what I do (or did). Feel free to add comments or ask questions and I'll see if I can append to this.

No comments:

Post a Comment