When I started in the video game industry working on 5 to 8 person teams was the norm.  There was no "game designer" role.  Producers were often the lead visionaries, but sometimes too were the lead programmer or artist.  Everyone shared in the responsibility of game design.  In sharing our thoughts, we listened as much or more than we spoke.

But over the years, as games and teams grew larger, the tasks of documenting the design, entering data and creating game levels made it necessary to specialize.  Game design became its own role. That I fear is where the disconnect occurs as the design no longer automatically benefits from discussion with peers. 

Suddenly this person was declared "the expert".  More than any other team member they were expected to know the ambiguous and subjective nature of what makes a game fun.  At the time there was no degree program in game design.  Designers either knew their stuff or they thought they did.  They were often hit with a barrage of criticism from other team members who had their own ideas and felt somewhat out of the loop.  Designers had to develop a thick skin of conviction if they wanted to get anything done.  Others countered by developing a chip on their shoulder that grew into a mountain when their game actually sold well.  When it didn't, you better believe that designers took the brunt of blame.

Today there are degree programs in design, though the best judge of a designer is still by his work.  Designers now have two sub-specialties, "level designer" and "scripter" with game designers relegated to documentation and game balancing.  It's the latter that I want to talk about - the game designer who doesn't do anything but write specs and tweak numbers.  To that person, I give this letter.

- Tim Ryan

Dear Game Designer,

There is a big need for your skill in any game development team.  You have a way with words and your knowledge of games is encyclopedic.  Your imagination churns up new ideas constantly.  You get giddy just thinking about ways of fucking with a player or maybe giving the player a unique experience.  You're inspired by many of the games you've played, and you want to recreate and enhance the same joys you experienced.

But what if you're wrong?  What if you can't come up with anything unique? What if your eloquence and inspiring confidence aren't enough to cover up the fact that you are leading the design astray?  What if your idea of fun isn't enough to set the game apart from anything you've played before?  Before it's too late you should take that chip off your shoulder and listen, really listen, to your team members - just to be sure you're not making a mistake.

Listening means accepting criticism.

You have to learn to take criticism.  That doesn't mean you should be a tool: you can have conviction in your ideas, but you should be prepared to debate those ideas.  You also need to learn when to accept when an idea isn't working.  Sometimes it takes a while for an idea to prove itself, especially if it's waiting on technology to fix a detractor.  Yet more often than not it can become clear well before polish stage that an idea will never be fun.  To weed out bad ideas, you should seek out criticism early on in the prototype phase (when changes are cheap) and even earlier in the specification phase (when changes are cheapest).  If you get enough compelling criticism against an idea, then drop it.

Listening means taking "I" out of design.

Stop putting your name on the design doc.  Its THE design doc, not YOUR design doc.  When you write up specifications, you are reflecting ideas from many sources - yourself, your team members, your publisher.  Good ideas can come from anywhere, and its the game designer's job to take them all and communicate a cohesive vision.  Seek out input.  Invite people to brainstorming sessions.  Vote on ideas and by all means publish the results.  Getting people's input into the design not only strengthens the design but it improves the team's morale.

Listening means addressing concerns.

Lastly, listening means carefully considering other concerns before giving an opinion.  When starting the project, certain goals and restrictions were put on the design.  These created the box within which the design ideas must remain.  These concerns can be technical limitations, game genre definitions, story restrictions, user expectatiions or marketing goals.  You need to listen to these concerns.

Designers are human.  We make mistakes.  We do better when we listen.  Remember, it's a team effort.

Sincerely,

A Fellow Designer