I'm looking into becoming a games designer and I would love to hear from one of your guys. I Summon You Into The Deep Depths Of The Trendy Forums!
What you should remember --
1. Technical proficiency is not optional :: There is no such thing as an 'ideas' only guy in the games industry -- and even if that basically was your role, you wouldn't be able to do it without a really firm grasp on how realistic and achievable an idea was. The better you are at programming/scripting, the better off you'll be. The better you understand the inner workings of your engine, the faster you can track problems and the less likely you are to break things.
2. Communication is key :: Chances are, at some point, a GD has to articulate his ideas to others. If you're really bad at this, its going to waste a pretty colossal amount of your time.
3. My pillars of game design are:
a -- Problem Solving -- The heart of design is problem solving, identifying an issue with a design and creating solutions to resolve that problem (ideally without creating new ones you can't solve)
b -- Embodiment -- A game designer looks at a system or theme and asks the question "What's cool about this?" and then tries to create systems and interactions that capture or emphasize that.
c -- Foresight -- The ability to recognize problematic elements of a design long before its built. Sometimes the exact nature of these problems needs to be witnessed to be understood however.
d -- Proactivity over Reactivity -- It's generally better to be taking action in design -- putting forth and trying out new ideas, then it is to be in a constant state of reaction. Reactive design tends to create a chain reaction of new issues that also require reactive design.
e -- Elegance / Simplicity -- The more complex your design gets, the less likely it is that its achieving the results on the player you want. All designs grow in complexity by nature, but you need to be able to step back and recognize where complexity can be reduced. Once you've added enough complexity to create the depth you want, you need to remove the complexity and retain the depth.
f -- Agility -- It's better to do ten prototypes that fail, then to do one completed system that failed. The faster you can translate ideas from your head to a system you can manipulate and experience, the sooner problems become apparent. The issue is often in the root of a concept, not in the execution -- but you can't generally see this until you can witness the execution.
g -- Failure -- Game design generally has to get it wrong before they can get it right. There *are* happy accidents, but they're very very rarely a product of coordinated genius. The vast majority of the time, GD will design something that doesn't quite work. This isn't just part of the process -- it is the process. Making mistakes *is* how you design games.
h -- Permutations Matter -- When you build something, you need to see how each component of the system affects the system as a whole. Trying turning things off, trying doubling values, try the clearly unwise. The more you learn about the dynamics you've actually built, the faster you can dispell notions that the system will work "they way its supposed to" (it never quite does by the way). Permutations in design generate insight.
i -- Perspective Matters -- It's easy to get too engrossed into a project to see flaws, and usually the ones you miss are fundamental flaws. Sometimes you need to get some distance of separation from your work, or you need to completely flip your perspective to see those flaws. Sometimes you need to throw out fundamental assumptions and rebuild them from scratch.
How did I get to where I am --
Well after my first son was born, I decided to stop mucking around and get a real career. I ended up attending the Guildhall at SMU, where I certainly learned a lot about development from a wide pool of talent. It should go without saying though, that my inauguration into design began long long before that, even if I didn't really realize how or why.
To begin with, I've been playing pen and paper roleplaying games, probably since I was 8. I was never content to just play the games though. These glorious constructs of logic and math were pretty fascinating to me. I owned roleplaying sourcebooks, probably for more than a dozen tabletop RPGs that I never even had the opportunity to play. I would read and digest the rules, I'd run scenarios in my head, create characters just to build them. I didn't realize it at that age of course, but I was assimilating myself into the architecture of these systems. It wasn't that long either before I started running tabletop campaigns, and then ultimately designing pen and paper RPG systems from the ground up, and running successful and well enjoyed campaigns in them. By the time I started undergraduate, I'd designed at least three board games I can remember, a massive Battletech style tactical campaign game, and at least five distinct pen and paper games. This background helped me cut my teeth on the fundamentals of game design and system design.
I'd always been big on playing with editors, although I'd never really built any finished products. In undergraduate I got sucked hardcore into text-based MUDs, and pretty soon I was programming and doing admin on some them. I stayed in that world for a pretty long time (until MMOs and fatigue with the human politics MUDs tend to create pulled me out). Doing work on MUDs gave me background with working with complicated systems, taught me more technical proficiency, and taught me community management, teamwork, and human skills I might not have otherwise learned. Finally, when I got pulled into MMOs (I played WoW, City of Heroes, and DDO) I somehow naturally ended up at the top of those leadership structures, and I sure learned a hell of lot about teamwork and team management from living in that world for three or four years.
I decided to go to Guildhall because they had a Level Design program, and it sounded like a perfect fit for me. I felt I had all the background and experience that would make me successful there. When I started at the school, I had this image in my head that I'd be a minnow amongst sharks, that everyone there would blow me away and I'd have to struggle to keep up. A bit to my surprise, I was one of the oldest students in my class and everyone was often looking to me for advice and guidance. The school really gave me a choice to change myself for the better, to fit the role well, and to learn the technical skills I needed and give me a frame of reference for how to succeed in the industry.
I ended up at TimeGate after I graduated, working on Aliens. Not to go into excessive detail, but one of my instructors at Guildhall told me I'd probably learn a lot more from working on a total disaster than working on a shining success. That's probably true. After about five months on that project I moved to working on an internal project -- a free to play shooter called Minimum that TimeGate announced shortly before legal issues destroyed the studio. I did a huge amount of level design, and highly technical design work on that project -- tons of prototyping, experimentation, and exploration. I got to work through the whole process up and down. When TimeGate imploded, it happened that Trendy was in need of a designer who did exactly those things, so now here I am.
