[Note: This is a repost. I also published this on†my blog]
Background: The fall of 2008 I was working on a large project for Avalanche Studios. The project was canned in the wake of the financial meltdown and I ended up without work. Our son was 8 months at the time and I took the opportunity and left for a parental leave that lasted almost a year. I spent that year thinking back at my time in the game industry so far and I made many brutal realizations about my work. I saw a couple of apparent problems and started to think about how to deal with them.
A year later I started working at Pixeltales and stayed for about 6 months. During that time I was fortunate enough to be able to put some of the thoughts I've been having into practice. I worked on the design of a peculiar action puzzle game. It never saw the light of day, but I tried to deal with the design process in the way I had come to realize was the only honest way to do it. Before talking about what that is I want to †summarize what I had come to see as clear signs of bad design process:
This creates an accumulating "snowball" of problems, questions and unknowns that cause severe problems with the projects: delays, cuts, excessive crunch... you know the drill.
Now, there is unfortunately no silver bullet available that will make these production problems magically go away. But I believe we designers can do better. Much better!
I have seen a couple of articles lately (here's a good one) talking about industry wide disrespect for designers. I have heard the argument that "anyone can be a designer". I think I know why that is. It is our fault and it is up to us designers to do something about it. We need to evaluate what we are doing and how. Why? Because I believe that the following is true:
Designers are good at creating work (problems) for others. Designers are bad at providing the tools necessary for solving these problems.
In other words, the role of the game designer is not to create "ideas" for the team. It is to provide design. Those are two very different things. Design is not about dumping problems (the "ideas") on other people and force them to do the actual design work.
I have heard designers say things like "this move doesn't feel good, it has to be animated better so it feels right" - heck, I've said stuff like that myself! And you know what? That is a piece of utterly worthless feedback! If I work on a mechanic, I should know the purpose of it. If I can't answer why it is in the design, what its function is, how could I ever know what to look for during implementation? It is lack of understanding that leads me to blurt out vague statements like "this has to feel cooler".
It is my duty to properly drill into the designs. It is our job to sort out unknowns, find answer to questions and make sure that all those uncomfortable issues that appear during the drilling process are called out and dealt with. When our co-workers start to implement†the design that we have created, we should give them the answers and tools they need.
When a programmer needs diagrams describing the flows of moves and metrics for speeds, distances and timings, I should be the one to turn to.
If a level designer needs pacing plans and a library of blueprints for combat encounter set pieces - I should create those tools because it is my job to understand the game and answer questions.
Now you might ask yourself just how†to drill into design and how†to deal with these kinds of problems? Luckily, there are some very smart people in the games industry that has put a lot of thought into just that. I would recommend you start by watching the following two speeches by the brilliant Jonathan Blow:
Truth in game design
Designing to reveal the nature of the universe†(with†Marc Ten Boch)