PRACTICE: Do Designers Need To Be Programmers?

"I am half the designer I could be if I learned how to code," says Brenda Brathwaite – by way of a video Chris Hecker (pictured) showed at NYU’s PRACTICE conference. Yet the ability to code can also work against a designer, who when unable to code is forced to find other ways to express him or herself creatively; in the recording of a casual conversation, Brathwaite suggested that perhaps she might not have made her widely-lauded board game Train had she had the option of approaching the experience from a programming perspective. "The fundamental differentiator of games as an art form is interactivity," says veteran Hecker, who’s worked with Electronic Arts on Spore and is currently working on Spy Party. Interactivity is inherently systemic and technical – even in a story-driven emotional scenario, it’s still a machine entering code. And "all of it matters – as you try to increase the quality of the interactive experience, everything starts to matter… one frame difference completely revolutionizes the game." Given that in his view games are inherently systemic and that as quality increases every instruction matters, Hecker argues, "you want to close the gap between the implementation and the design," he says. The best way to create as tight a feedback loop as possible between the design and the programming is to have them in the same brain. As for BioWare Montreal senior designer Manveer Heir, he says from a young age he knew he wanted to make video games. In search of a practical skill that could lead him into that field, he chose to pick up his Dad’s programming books. As a gameplay programmer at Raven, he wrote systems – like a vehicle simulation for Wolfenstein that never shipped – until his colleagues observed he had a number of ideas about design they asked him to implement. Since then, luck and skill has made him a hybrid programmer-designer, he says. The ability to approach game development from both perspectives has benefited him, he believes. "I know game designers who only want to work on paper and in excel sheets, and they want that to go as long as possible. I want to implement something fast and start playing with it, because so much emerges when you actually implement a system," Heir says. "When you implement a system, there’s a thousand decisions to make that you never would have considered at that paper stage." "The dirty little secret is I don’t like to program," he says. "Programming is like the grinding quest I have to do to get that little piece of enjoyment and satisfaction that I like." "I don’t think you have to program your own systems, but … understanding the systemic interactions [in] our games, the more we understand them, the more we understand what I think is the ‘true nature’ of games," he adds. As a designer, why not have an extra tool in one’s belt, especially as it helps communicate with the programmers who build the systems? Heir challenged the room’s attendees to learn to program – and claimed he’d treat anyone who doesn’t become a better designer within a year to a dinner at one of New York City’s most expensive restaurants. Though he concedes he might be a better designer if he were a better programmer, Nick Fortugno says he wouldn’t take that challenge. "I’d be a better game designer if I were a better artist; I’d be a better game designer if I were… a lot of things. The question is, what will make me the most effective at my job?" He questioned the primacy of programming over all other skills that could enhance the designer’s role, and suggests the inability to program doesn’t reduce the role of the designer. "Game design is about systems thinking, but systems thinking is not a prerequisite of programming," Fortugno says. "I’m not interested in making a game by myself because I don’t think working in my own head is a way to produce good content," he continues, disagreeing with Hecker. "The fact that I have to have a creative tension with an implementer puts me into design situations that I think are interesting and challenging." The panelists extrapolated an interesting debate from the question of how close programming is to the essence of design: The role of friction in the design process. A designer who programs his or her own games has no friction or no gap in the feedback loop, as Hecker asserts. In his view, the faster that feedback happens, the quicker they can extrapolate meaningful feedback. He's passionate about programming as a core skill for designers. But designer-programmers are carrying multiple roles and may also over-value their self-sufficiency or end up working in small teams or even alone. For Heir, having colleagues to bounce ideas of off is critical. Fortugno strongly believes that friction is actively useful to the creative process, forcing frequent stops to assess meaning and visual design.