Thoughts on Being a (Game) Designer

Parenthetically “Game” because the first portion of today’s post applies to designers in general more than game designers in general. The second part of two is more specific. Regardless, these are thoughts I’ve had and discussed recently that I found interesting and potentially insightful.

One of the habits I’ve never been able to or particularly felt compelled to break is periodic (and frequent) bouts of self-reflection and evaluation. What am I doing, how am I doing, what can I be improving right now, and so on. Most recently, I found myself reflecting on myself as a designer in particular, with some interesting conclusions.

What Kind of Designer are You?

Greenberg would call this an area of specific competence. We’re not talking about kind of designer in the sense of what word you put in front of designer(game, graphic, interaction, interior, et cetera). Rather, what do you do best as a designer? There’s a lot of characteristics that make for good designers, and given that design is ultimately a cognitive art and there are as many different ways of thinking as there are human beings, there are a terribly large number of ways to approach design and a wide assortment of ways one can be good at it.

So we’re all good (or bad) designers in our own ways. I’d argue that understanding oneself in relation to a given activity is the basic path to real mastery and thus the question posed. Having an answer to these questions provides paths to questioning that answer and understanding it further, and so on. Understanding where our tendencies as designers come from allows us to form a path to improvement.

Speaking for myself, I began to think of the designs I’ve been coming up with lately. The thought process that led to my thesis project, a firm look at the last couple of game ideas I’ve been working on, that sort of thing. I started to recognize a pattern that suggested an area of design expertise that, to be honest, is amusingly ironic set against the thought process that got me to it.

As a designer, I have a personal talent and affinity towards decomposition and synthesis. Given a system or a design, it is my natural inclination to tear it apart and understand it. How is a given game constructed, what works in this film, why is this game great while this other one is awful, and so on. When developing my own ideas, most frequently they end up being a combination of things I’ve seen before put together in some new and interesting fashion. In the last few months, I’ve described nearly all my proposed projects in terms like “it’s the unholy union of A and B” or “basically X and Y had a drunken love child”. This, mind, is not a bad thing. Synthesis has a long and storied history of producing great progress over the course of human history. It is one of the primary ways we develop technology and culture. I’m also quite good with collaborative refinement—some of the best progress I make on designs is with a design buddy and a whiteboard being challenged to overcome issues in the design on the spot.

Daniel, one of said design colleagues, has posited the idea that the above is a result of my Engineering background. I don’t think there’s much reason to refute that suggestion. Before being trained as a designer,I was first trained as a software engineer. This lays a certain analytical stamp on one’s mindset and a desire to dig into the workings of everything around you and correlate bits of data together. it’s an interesting insight to consider.

Don’t be Afraid of Code

Brenda Brathwaite recently turned her attention toward learning to write code after years and years as a successful game designer, reminding me of my own reflections over the last year or so regarding the same topic. So it’s time to write those thoughts.

My father is a kickass programmer and I grew up in that kind of environment. I learned to write code pretty early in my life and fully intended on going into software development as a programmer for a long time. Then I ended up going to art school and feeling a great happiness in getting away from writing code. And then, last year, I ended up writing code again for the first time in years because I needed to prototype out a game design. Now a bit over a year later, I’m doing a lot of pretty heavy code work and actually quite enjoying it.

The reason why is the same reason Brenda gives for deciding to learn to write code in one of her posts on the topic—being a game designer that can’t write code is like being a painter that has someone else use the brush. It’s not a perfect analogy but it nicely encapsulates a large part of the argument and has a poetic ring to it.

My reasoning runs along similar lines. A designer should be able to experiment with ideas and understand the final product well enough to talk about how their design work is represented. For a game designer, this means if you’re not capable of writing some sort of code, you are at a serious disadvantage. What if you have an idea for some mechanics, and want to see how they play out? You can’t always do it in paper effectively, and you’re not always going to have a programmer available for what is essentially the equivalent of sketchbook doodles.

And those code doodles are super-important. One of our ITGM undergrads, Jonathan, came to school in the fall with some ideas kicking around for physics-based game mechanics. He could only do that because he’d spent the summer writing little chunks of code with Box2D in Flash. Because of that, he understood what was available to be designed around. More importantly, he knew in advance that such things could potentially work.

Prototypes are super-important to game designers and the iterative process. Waiting around for a programmer to get a prototype of some small chunk of game built so you can test it is incredibly wasteful of time and manpower. It holds up the designer, and it keeps the programmer from something else they could be doing. And to top it off, expects that the programmer understands exactly what the designer’s going for. Much better if the designer can just knock out a hackneyed proof-of-concept that a programmer can then refine into good code after the concept itself is solid.

This quarter, we’re really interested in the possibility space for the Kinect. In fact, there’s already a few ideas roaming around that we’d like to try out. Well, obviously, these could only be thought exercises without someone to write code, and we’d likely never see how well they actually work. But, since those involved are all designers with a reasonable comfort level where the code is concerned, we can actually push through, get something on a screen, and see how it all works out. the power in being able to do that is enormous.

So, the bottom line for game designers out there? Learn to write your own code. You don’t’ have to be awesome at it. You don’t have to write amazing code, or take a job from your programmers. But it’s essential. Learn something. Learn C, learn XNA, learn Flash—It doesn’t matter. Code is just another way—an essential way—to do more napkin doodles, and we all know how important those are already.