Game Designer: Year 1

Today, I head to my third Game Developer Conference (GDC) in four years (I skipped one in Santa Cruz 2 years ago). This is one of my favorite weeks of the year from a totally self-absorbed career-oriented point-of-view. It's an annual reminder that in a small way, I've arrived and in many ways, I have a long way to go. Like many other people in the games industry, I playfully dreamt of one day creating the video games I played incessantly. I didn't really take that dream seriously until I was in graduate school many years later, unhappy in a world with little practical application but lots of paper writing. I came to an impasse where I had followed an academic progression I thought I was "supposed" to follow and I was ultimately miserable. Two years later, with some military service time, luck and late night elbow grease, I was making video games for a living. GDC is my annual opportunity to take stock of how my dream is progressing. I evaluate my career, set goals for myself, look for the best opportunity to achieve those goals, and try to find the right place for myself within this industry.

Of course, like a lot of industry veterans may tell you, game development and design aren't always joyful and frustration-free. We deal with people too after all. The job of game design is most likely not something you'd expect (I certainly had it wrong). On my more cynical days, I describe the job, game designer, as arguing for a living and writing documents that no one reads. On more positive days, I'd probably (more accurately) describe my job as:

• Championing the design vision to my fellow developers
• Helping our developers understand features
• Helping our developers identify challenges created by feature requirements
• Ensuring all features in our game have the highest level of quality possible
• Funneling and sorting the creative design ideas of other developers at the studio

Now, I've only been doing this job for a short time, but slowly I'm starting to discover alot of the skills someone needs to be a designer. Likewise, I'm coming to realize where I'm strong and where I'm weak at each of these skills. GDC provides me a great opportunity to reflect on my recent work as a game designer and the skills I think I need to have or improve on. So, in no particular order, here they are:

Patience
The one thing I've had to learn, more the anything else, is patience. As a designer, you need patience on a number of levels. First, your decisions are challenged on a regular basis. Everyone that works at a game development studio has some level of design ability, but not many opportunities to demonstrate those abilities. But many times, by no fault of their own, they don't have the same perspective as someone in a designer position. Designers spend a lot of their time in meetings with other departments talking about different parts of the game. They have to keep a game-wide perspective about everything and often times design decisions are influenced by this gamewide perspective. While it could involve how one shooting mechanic may interact with some vehicle mechanic, it might also be with respect to production costs and project scope. Regardless, a designer has to be prepared to be challenged constantly about their decisions and explain themselves on more than one occassion. In the end, we're providing that service to everyone else in the studio, so we need to ensure that we engage in that conversation openly and often with great patience.

A Broader Perspective
Before I was a designer, I was a programmer. I was constantly frustrated by design, because I didn't understand why they would make decisions about the particular area I was working on. Now that I'm sitting on the other end of the table, I have a better understanding of how a game (especially a larged complicated, "fully-featured" one like those I've worked on) can be a complicated web of dependent mechanics. Decisions made about one feature may have profound effects on another feature. As a designer, I have to keep this in mind at all times. Is this decision or feature consistent with our vision and furthermore is it consistent with decisions we've made about other features? Is this feature the straw to break the camels back adding unnecessary complexity to the game? David Sirlin recently wrote a terrific article about subtractive design. The basic concept is that we should be able to identify the essence of a game and remove everything else. I think this is important when evaluating and prioritizing features. Does this really support our game's essence or are we just really attached to it because we think it's cool? Big picture thinking is a definite necessity to avoid making a bunch of inconsistent decisions that result in a kludge of a game.

Debate
As I stated before, design will be and should be challenged on a regular basis. People usually feel passionate about the game they're working on so we're regularly going to be engaged in conversations about design decisions. First, as a designer, I shouldn't be attached to "my" ideas, I should be attached to the "right" ideas. My ability to identify the "right" idea amongst the pool of ideas is what either makes me a good or bad designer. It's ludicrous to think designers are the only ones who can manufacture good ideas when everyone has them and wants to share them. So we need to consider and evaluate all ideas, choosing the "right" one based on its merit. We then have to commit to trying to making that one work. If we're placed in a position where we have to defend an idea, it shouldn't be because we "like it best". It should be due to our research into other games, the synergy between this idea and another one, or it's alignment with the rest of the game. On several occassions, I've done research, analyzed alternatives, gathered feedback from several parties, and made the decision I've felt was the "right" one. The area I've been falling short on is debating my well-researched position after the fact. It's silly, because I've done my homework, but I haven't internalized all of that data and developed solid arguments against potential detractors. This is an area I really need to focus on in the next year and beyond.

A Humble Ear
I've gone through a lot of leadership training courses in my young life, stuff in high school, ROTc, active duty military professional development, etc. A common theme is always communication with an emphasis on listening. People can easily talk about themselves, their opinions, their problems, etc. It's not hard for me to go spouting my rhetoric to anyone who will listen. Anyone who knows me will tell you I can easily steer a conversation to my favorite topic: me. But it's tough to stop talking and to start listening to someone else and their thoughts. I mentioned before that I felt designers really need to funnel a team's ideas, and being a good listener is paramount to doing this well. Three things we were always told to focus on were:

Eye Contact
Looking someone in the eyes can be difficult for a lot of people, but it's really important for creating a intimate conversation. It shows you're engaged and focused on the things they're saying, not distracted elsewhere. Obviously you don't want to freak someone out with an eerie non-blinking always tracking goon stare. You should always break up direct eye contact occassionally so that the speaker has an opportunity to relax and feel they're driving the conversation.

Body Language
Even when you're not speaking, you're communicating. You're speaking volumes about how you feel about what the other person's saying. As a designer, what message do you want to send to the speaker? You want them to know that you value what they have to say. You're processing their idea and considering it against other ideas. This is demonstrated through a lot of your body language including posture and head movement. Are you slouching like you're tired of talking or sitting up straight to demonstrate you're actively engaged in the conversation? Are you standing there, towering over the speaker in some false position of dominance? Or are you sitting along side them as peers? Are you nodding your head to show you understand or staring at the ground like you just can't wait for this conversation to end? Being a designer requires engaging everyone at your studio and gathering all the ideas and opinions about the game you can.

Reflective Speaking
One tool the Air Force stressed was speaking reflectively when someone else was talking about an idea. Basically, let the developer explain what he's thinking, then repeat it back to him or her in different terms. It demonstrates that you understand their point and that you're actually listening. If I explain an idea to someone and they just respond, "Ok," then I have no idea on whether they internalized a single word I said. Speaking reflectively allows a one-sided conversation to become two-sided with the developer coming away from the conversation knowing you really have considered their idea and opinon.

Personal Detachment
One of my biggest challenges as a designer has been compromising my own strong feelings of ownership over anything I work on with ensuring that I make the "right" decision for the game. I could invest significant time documenting and detailing a feature that I personally love and want to play. But ultimately, someone else could point out that this feature just doesn't make the most sense for the game. I have to make sure that I discount my own personal attachment to the idea and keep the game's best interests in mind. Likewise, I can't get attached to something I've invested alot of exploratory time on. Consequently, I've then had to distinguish between my own personal feelings about what's "fun" and what's "right". For instance, as a gamer, I may be in the minority in terms of preference about a certain control scheme. I need to pick the "right" control scheme, not the one I "like." Otherwise, all of my design decisions will be suspect.

Organization
In my particular case, the game I work on is large and complicated. Our team is equally large and complicated. Keeping track of everything I need to do and everywhere I need to be requires more organization and scheduling than I really like to have. I like to just "see how it goes" but that's not going to fly when you have 80 co-workers ready for design direction and pulbishers giving you a multi-million dollar budget. People want to know there's a plan. People want to know that they aren't wasting their time and effort. People want to know that their issues will get addressed in a timely fashion. More than anything, this can be solved by a great production team (like ours). But as a designer, you need to cooperate with production and buy into their organization and structure. This isn't something I've ever been good at, so it's been an interesting challenge for me. However, I am trying, working harder to organize my schedule, set deadlines for myself and work hard at meeting them in a timely manner.

Communicating Every Way Possible
Once I started designing, the first thing I learned is that no one likes a wall of text (like the wall-of-text above this). I haven't written a design document yet that I simply handed off to a developer. I consider design documents to be conversation aides. They are a tool for me when I talk with a developer and a reference point for them afterwards. When I write a design document, I'm trying to provide brief bulleted points that we can review together. I try to provide quick visual reference that will communicate an idea far better than two thousand words. But most importantly, I try to include something they can come back to once they've forgotten what it is we talked about two months ago. While written and graphical documentation can be great down the line so a developer need not rely on me, ultimately, the idea will be best communicated to them directly in person. I need to be eloquent in expressing the feature or mechanic. I'm still working on being a clear speaker about abstract ideas, but I have found that I'd be a lot better if my Photoshop skills were more advanced.

Understanding Scope
One of the things I feel I really have going for me as a designer is that I've worked as a programmer in game development and to a much lesser extent I've worked as an artist and producer on amateur projects. As a result, I can empathize with the developers. I understand that adding the smallest feature can be a significant undertaking or lead to unpredictable results. Even the smallest change can have profound effects that adversely affect larger systems. Some times developers may be apprehensive about making a change because there are a tremendous amount of unknowns. I know firsthand that it isn't easy, so it's important to do our very best as designers before work is started to avoid making changes. But I also know that the best developers want challenges (especially challenges they're interested in tackling). Sometimes, the best features come as a result of matching the right challenge to the right developer. As designers, we have to understand what features are worth challenging our developers with and which just aren't worth it.

Whenever I write something like this, I reflect on 18-year-old Brian Holinka, who really thought he had it all figured out. It almost makes me reluctant to write something like this down. But now that I'm older, the only thing I'm sure of is that I don't know everything. I have a lot to learn. But I think I'm heading in the right direction. For the next 3-days at GDC, I hope to hear alot of other people's opinions about the skills and talents they think designers should have. Hopefully in a year, I'll be able to add (or delete) to this list and I'll be a better designer as a result.