Game designers vs. Tools designers

(I wrote this post in November 2010 and it was an important influence for my GDC2011 talk.  I’m finally posting it.  See the GDC slides/notes for much deeper discussion).

There’s a problem at many studios, I think, where our lead game designers are also responsible for designing tools and design workflows. A tools programming team is then responsible for implementing it. Where I’ve seen this done, I think it has been a catastrophic disaster, and I’m sure it is this way at many studios. This is a bad model for so many reasons. The right model is the ‘tech art’ model, which I’ll examine the pros and cons of more fully later.

Only designers know what they have to do, only engineers can explore what is possible
An engineer can only design or implement a mediocre tool if he doesn’t have a deep understanding of a workflow. A designer cannot see the big picture for issues outside of his workflow. I’ve seen tools developers be able to eliminate entire workflows by understanding not just how, but why something needs to be done, understanding how it ties into another area, and completely eliminating a workflow because it becomes redundant when harnessing that other area. Solving this requires a highly iterative development process, designers writing tools, or engineers embedded with the design team.

Game design is conceptual, tools design is technical
I am not game designer, so apologies if I’m over-simplifying. But I see game design as creating and implementing a vision. And while the best designers are both very conceptual and excellent technicians (as the best tools developers are), the technical skills are in support of a known end concept (or in support of figuring out what the end concept is). Tools design, on the other hand, is about identifying and fixing problems- it is not about creating and implementing a vision. While there can certainly be tools visions (like the object model pipeline!), that is at a comparable level to choosing a game’s genre- it is merely a framework for decisions and not a normal decision in and of itself.

Ignoring people’s strengths
Simply, if we accept that the relation between tools and game design is tenuous at best, you are ignoring people’s strengths by using the same person to head up both. Game designers should be masters of vision and tools designers need to be able to see how to execute the vision.

Competition for resources breeds adversarial relationships
If the people designing and using the tools are not able to manage their own resources and execute on their own needs, an adversarial relationship will develop between design, engineering, and people competing for engineering resources. Engineers will not be as invested in their work because they have no investment in it, and their closest mates have no investment in it. Design will complain about mediocre tools and trust engineering less.

Which breeds short-term thinking
If neither side truly understands the other, and neither side really wants to work with the other, phrases like ‘we won’t need to change that’ are uttered and believed much more often. Design is idiotic for thinking they won’t need to change something; engineering is idiotic for believing it. Design doesn’t ‘see the big picture’ and realize they will need to change it; engineering will ‘give them what they ask for’ because that is all they are supposed to do- they have no investment.

So what do we do about it?  We can adopt the Tech Art Team Model for the development of design tools.  More details in future posts.