Engineer Anxiety vs. Designer Freedom

Update: There were some formatting issues that caused this to copy over wrong from my old blog and it was missing some words. Fixed now!

Every team has its own interdepartmental relationships - some more dramatic than others - but something that has been an issue on every project I’ve worked on has been the way that Designer desire for implementation freedom, expressive tools, and power has conflicted with Engineer anxiety over what the hell Design is doing.

First, I want to say that I am ultimately sympathetic with the Engineers in these situations.

Engineers (when working most effectively) build systems, not content. And those systems have to be built to support the content before the content is built - meaning that there’s an inherent degree to which Engineers on games are never really sure what exact spec they’re building to.

• Design, on the other hand, has the freedom to mold and adapt their Designs after they’ve got the systems. Engineers can do that, too, but it risks messing up all the other stuff Design’s already built on their system, so it’s always an extremely risky, dangerous proposition.

Engineers get stuck holding the bag when Design’s shit breaks.

Engineers understand the guts underneath the abstractions they are presenting to Design, and know just how deep we can dig ourselves when those abstractions leak (super good article on leaky abstractions over at Joel on Software).

BUT I also know that there’s been pretty much a direct correlation between the quality of the games I’ve worked on and the extent to which the technology allowed the designers to directly implement their vision through powerful tools vs. being constrained by limited systems.

If I knew the absolute solution to this I’d be the most successful game director ever, not a designer. But I do know some things that have helped:

• Tons and tons of direct communication back and forth between Design and Engineering. The more a good Engineering team knows, the LESS they worry. One of the awesome design principles at Blizzard is to avoid the grand reveal - basically don’t work in secret and then show everyone else your work, after you’ve finished, with a big “tada!”. This is important among other designers, but it’s ALSO hugely important between the departments, and especially with engineering. They can think about how to make what you want to do work much better if they know what you want to do earlier.
• Engineers need to take the time to explain the “why” to designers, not just the “what”. One of the worst things you can tell a designer is “Don’t do that. That’s expensive.” The end result of that admonishment is usually the designer tries it out, sees that the framerate is fine, and assumes that you’re just being a worrywart engineer again.
  
  Instead, if you say (for example), “Overlapping collision is expensive because when the game has to do a line of sight check, the overlapping geometry makes the collision checks much more complex”, you give Design something to work with. A fundamental requirement of design is to work with what you’re given to come up with solutions - and given that information, the designer may say, “Oh! Well, it actually isn’t important that the collision matches so closely to the object. If we really simplify the collision geometry, can that help mitigate the problem?” Again, just as an example.
  
  Design doesn’t want to make shit run bad! It’s just that we rarely understand the complexities of why the stuff we makes runs like crap unless you tell us. And once we know the why, we can make good decisions in the future.
• Engineers should make systems, not content. Engineering time is crazy valuable. Designer time is less valuable. Good engineering work is elegant, robust and built to handle many cases and situations. Design work is by nature mostly one-off. Subtle bugs often never show up in design content (unless you’re making an MMO where that content is going to live for 9 years, but the general point remains).
  
  The end result being that Engineers should generally specialize as force multipliers by making systems that are bulletproofed, extensible, and used many times by many designers. Leave the specifics of what a given AI does, how the UI controls are laid out, etc. to designers. Engineers shouldn’t have to spend time touching that shit.
• Believe in Tech Designers - Engineers should find allies on the design team, who are either technically minded or have some sort of CS/Programming/Engineering background, and work with them to communicate things to design. Some of the best, most efficient teams I’ve worked on have leveraged highly technical designers to work in-between code and content to make frameworks for other designers.
  
  I’ll use an example from a game that I worked on for a while that was cancelled. It was going to have a really neat strategic layer that was mostly paper-designed out, and because of the team culture on that project was going to be 100% implemented in code. One of the most skilled gameplay programmers on the team worked for at least a month, maybe more on the system, only to be taken off of it to work on more critical features.
  
  Ultimately, the strategic feature never got implemented and the game was cancelled before any more work was done on it. Had that time been spent instead on implementing script features,  extensible, data-driven systems, etc. such that technical designers could have used those basic features to implement the specifics of the strategic game, the engineer work would likely have been reusable to make other aspects of the game better.
• Designers: Love the Design, not the Implementation. Sometimes, a designer’s implementation is good enough for 80%, but it needs some code refactoring and replacing design implementation with code to really shine. As long as the design is established and proven in prototype, feel free to get advice from code on how they can make what you’re doing more efficient and bulletproof.
• Designers: Learn from Engineers. Learn to read C/C++ at a super basic level, and sit with Engineers when they are debugging things. Learn the specifics of how the code actually works in sections that are critical to what you work on. This can be hugely helpful and really demystifies the kinds of bugs where everything looks like you set it up right in the editor but it just doesn’t work in-game.

Anyways, again, not perfect solutions but some things that have worked for me. Also, as a general rule, I’ve found that the best Engineers I’ve worked with want to nurture and enable designer creativity, and the best designers want to make things that are technically sound and are curious and interested in how the game actually works. So the departments are at their best when they are working together, not acting as stern parent and rebellious child.