"Regardless of what kind of game you work on, design leadership is at the center of success or failure," writes design consultant Phil O'Connor, whose credits include Far Cry 3 and Operation Flashpoint 2. Here are some of his practical tips to help you become a better design leader.
"Good judgment comes from experience, and experience comes from bad judgment." - Rita Mae Brown, Alma Mater
A few years back I was inspired to write an article, How to Hire Good Game Designers, which Gamasutra graciously published. The positive response it received was surprising and inspiring, so here goes some more advice -- this time to my peers in the design trade.
This is not an article about game design techniques, however -- that subject is so broad and personal to each designer that an article would barely scratch the surface. In addition, my fun is not your fun; everyone likes different things, and as a good designer, you should be true to yourself. Trying to make someone else's idea (or "formula") of fun is rarely successful. I guess that, in itself, is my advice on game design technique: do what you know, follow your instincts.
The real point of this article, however, is how to be an effective design leader in a development team. This is just a catalog of my personal observations over the years. It is neither a definitive pronouncement on the subject nor a standard that everyone should try to reach; it's just a collection of personal lessons learned over the years. Take them or leave them in whole or in part, ignore them, share them -- do as you will.
I have been designing games for most of my life and 16 years in a professional capacity. I have never really considered design itself difficult. What I mean by that is, coming up with gameplay ideas or concepts for a game has been the fun part -- the easy part, I guess. What has been the difficult part of learning my trade is how to work in a development team, and specifically work with the different disciplines in development.
As a designer, you don't work in a vacuum. Everything you do affects other people's work on the team, and learning to understand that effect and how to be a professional is the key to successful design implementation. This is a collection of my conclusions on the subject after over a decade in entertainment software.
Regardless of what kind of game you work on, design leadership is at the center of success or failure. Every studio has their own approach to managing design work, but these recommendations should apply in most cases.
The key to being an effective designer is understanding that you are at the center of a workflow that affects all the other disciplines. Design decisions affect art, sound, technology, production plans, budget, and marketing. Assuming you have good design instincts, fresh ideas, and a creative capacity, the key to being successful as a design leader is first understanding the high profile that your work has in the team.
The first thing that should come to mind when you realize this is to have respect, or humility, as Kim Swift put it in a recent article. You are in a tremendously powerful and sensitive position; you are going to have a major impact on the success of this project without necessarily having authority in the team hierarchy.
And even if you do have that authority, it should rarely, if ever, be used. Respect the other disciplines and their role in the project. They are not there to execute your ideas; you are going to work with them to create something fun, together. You work for them as much as they may work for you. Nothing turns off a team more than an arrogant and imposing designer who throws out his "vision" in vague public speeches or voluminous documents and expects them to turn into concrete gameplay.
Once a team has lost respect for you, there will be resistance -- even if not overt or obvious. A team that does not feel like partners in the design process will question every decision, will remain pessimistic about gameplay choices long after they have been implemented, and generally drag their heels throughout the project. This kind of atmosphere ends up hurting everything in the game; things take longer to make, features that had potential will get cut because they go over budget, and finally the greatest buzzkill: overtime is never far behind...
This is not to say that the designer is responsible for everything that can go wrong in a project, projects fail for many different reasons, but the central role of your work puts you in a position to affect the delicate relationships between all teams, so be mindful of this situation and always act with the intent of earning the team's respect and trust in a long term way. How do you earn the team's respect? Here are some ideas:
Be prepared. Whenever you are meeting with other disciplines to discuss implementation, make sure you are prepared with the latest information, updated documents, and a set of possible solutions from design. Developers don't like doing your job for you; if asked for information on how something is supposed to work, don't throw it back at them and ask them to figure it out. Have an answer, or work something out based on information they provide.
If there is a decision to be made, understand the options and the consequences for each option and make precise choices. That means you should be an encyclopedia on the project, and this is easier for you as the designer to achieve, because you have more contact with all the different disciplines. You are somewhat of a central repository for what everyone is doing, so use that position to share and communicate the current state of progress on the project. This leads to...
Make decisions. Artists/animators, engineers and sound designers work according to precise schedules and budgets. They must produce assets at a predictable rate and give regular constant updates on the progress of this work. Nothing can upset this more than failure to make design decisions when they are needed, or making vague ones.
Designers have to provide concrete and hard information when discussing the asset requirements for features with the team. No design document will ever provide all the information necessary for these teams to work independently of your input. You must interpret the design for them, modify it if necessary due to the myriad technical or production related limits, and provide a final say when it is necessary to have that precision.
If you need to make a decision on the spot, make it, record it (by email) and stick to it. Nobody expects you to be right all the time, or even to have all the answers, but they do expect you to make design decisions. When you fail to do this, you introduce uncertainty and leave things up in the air. It's better to risk making a mistake than to not make a decision at all. And you will make wrong decisions; all designers do. Which leads us to...
Don't worry about being wrong. Some things that you thought were cool won't be in the final cut, and that is part of development. Don't worry about your ideas not working out in the end; worry about the game as a whole. Some of your ideas will fail for reasons that do not invalidate the idea itself.
It could be due to scoping issues, or a technical issue no longer making it feasible, another feature rendering it obsolete... Don't sweat about your precious idea getting rejected after playtesting; games are created in an iterative process, and you can only find out if something is really going to work once it is actually prototyped. Until then, it is just theory, based on your design instincts. Speaking of theory...