Sponsored By

Producers Of The Roundtable: Getting Coders and Artists to Communicate

In this new roundtable interview, conducted in association with GameProducer.net, producers from developers including EALA, Bizarre Creations, and Gas Powered Games discuss the best practical ways to get programmers and artists working smoothly together.

Juuso Hietalahti, Blogger

December 26, 2007

10 Min Read

[Gamasutra is partnering with GameProducer.net, a game production resource, for a series of Q&As named 'Producers of the Round Table'. The Round Table is a place for producers who work in game industry to present their opinions in response to questions, and the first article in the series dealt with 'practical scheduling for games'.

In this installment, which deals with programmer and artist communication, participants include Peter O'Brien, Producer at Bizarre Creations, Ben Gunstone, Production Director at Stainless Games, Harvard Bonin, Senior Producer last at Electronic Arts, Frank Rogan, Producer at Gas Powered Games and Amer Ajami, Producer at EALA.]

How do you get coders and artists to speak the same language?

Peter O'Brien: Get them in the same room and start a dialogue. This might be a meeting, it might be a seating plan that is permanent or flexible. It can even be an email - either way, get it started. Another way to make this happen is to use technical artists... you know, the rare breed that can write scripts, shaders and tools to help workflow. Most importantly, don't block the communication because you are a control freak.

Bizarre Creations' Project Gotham Racing 4 for the Xbox 360, on which Peter O'Brien worked as producer

Frank Rogan: There are many tactical things you can do to break down these walls:

  • Regular team meetings and team events.

  • Cross-disciplinary teams that tackle discrete segments of the project (e.g. a "character" team made up of artists, animators and engineers).

  • Agile production methodologies that zero in on daily and weekly blockers, which are most often the result of cross-discipline dependencies communication breakdowns.

  • Open office layouts that foster hour-to-hour communication. In the best places I've ever worked, most everyone sits in one giant room, making for always-on working conversation.

  • The usage of production assistants as the team's "expediters" that swallow up thankless, repetitive tasks and ensure that every blocker is either dealt with immediately or brought to the attention of the producer who, face it, can't be everywhere at once.

  • Identifying that rare breed of technical artist that can truly build bridges between art and code and help set up effective pipelines, and fostering the careers of those people.

Is it important to have some people in the team (technical artists, artistically inclined coders) who can translate?

Peter O'Brien: Technical artists can be an excellent addition to the team. They are your sweeper, able to focus on areas for any time the job requires. They can act as a conduit to executing critical workflow improvements and can be critical throughout the project if utilized.

I don't think the word "artistic" is the correct term to use from my perspective. I know that I work with creative coders and artists; the most creative individuals inspire, or maybe just influence, one another to get the best solution. I'd say a lot of the success I see in the studio is down to coders who think creatively to empower either designer or artists. Vice-versa, the designers and artists should respect the code by understanding how it works. Understanding leads to further creative use or solutions to the system.

Ben Gunstone: Artists versus programmers -- it's an old one, but it's a goody! To be honest, it's an issue that can occur anywhere in a team, and it's always down to poor communication. The communications can be improved by all the people you list above: a technical artist, a designer and a producer. It can also be handled by the Lead Art or Lead Code position.

If you have professionals of both trades, then there should be a certain amount of respect for each other in the team. Both sides need to understand the wants and needs of the other side. Again, with good communicatons and planning in place, this should be an easy task.

Or is that partly the job of the designer -- how do the designer and producer fit in there?

Peter O'Brien: Does the producer actually have to be the conduit here to understand the different working styles? As stated earlier, designers and producers can get in the way. The best use of Designer and Producer is as catalyst and arbiter. Communicate the vision or establish a process. Put simply: Know what needs to be achieved and see it through.

Harvard Bonin: Generally, I believe, producers endeavor to hire talented, good artists and designers, et cetera. Our job is not to move the hand of the artist or designer, but rather, to make sure they know the direction that the company wants to go. In other words, provide a direction, point, and then trust in them. And then make sure they don't violate that direction. Yeah, yeah... that's philosophy.

At the same time, our job is to guide. They are being paid for a job... and so are we. We try to understand the objective and then help people achieve that. We are no good in our job without fantastic people to help us all get there.

 

Does the producer actually have to be the conduit here to understand the different working styles?

Peter O'Brien: Producer as arbiter is one of the least respected roles. Often only seen as a facilitator, a producer's role can be critical when things are not going as expected. If it's not the producer, it's often a good designer or area team manager doing it. Equally, if they are doing well, it's your job to make sure people know it is.

Ben Gunstone: The bottom line is that, as the producer, it's your job to make sure that everything is in place to reduce any kind of art versus code issues. If the operational stuff is done and issues still arise, then it leaves personnel issues, and that's a whole different can of worms.

Your job as a producer is to make sure [communication] does happen. Regular team meetings and physical team layout is conducive to communications (but not idle chit-chat). It's identifying a unifying team member, and if one doesn't exist, stepping up to the plate yourself (or hiring one in!) Don't rely on email; get the team talking to each other.

Frank Rogan: As Ben states above, this line of questioning is indeed an age-old one. But it's also not at all unique to the games industry. I'm sure you could walk into any working situation and find that the guys in charge of sorting the widgets think the guys in charge of counting the widgets are a bunch of morons, and vice versa. I had a rather nomadic working career in college. In every restaurant I ever worked, the cooks hated the servers. At every newspaper I ever worked, the journalists despised the ad sales guys, and the editors thought all the writers were drunks. Heck, I even worked at Disneyland, and the guys from Adventureland knew, just knew, that all the guys from Tomorrowland were idiots.

What I listed before were tactics, not strategy, and it's important to understand the difference. Strategy involves identifying the breakdown at the source, and that's always going to be the nature of the people involved, and the nature of how their work is measured and rewarded.

  • Build your team with chemistry in mind. Have cross-disciplinary interviews and annual reviews.

  • Recognize good communication when it happens and reward the hell out of it.

  • Recognize bad communication when it happens and confront the hell out of it. If a coder hates the artists and would rather go sit in a cave, make it clear to him that you'll be happy to find cave work for him, but that he will never, ever get to leave the cave. (Now, some people might be happy with that, but at least you'll know.)

 

Or are these worries unnecessary, and they're just human beings who can work perfectly well together?

Frank Rogan: Make software tools and pipelines a priority. Usually when an artist says the coders "don't speak the same language," it means the artist couldn't get the coder to do what he wanted him to do, and the coder couldn't explain to the artist why that would be difficult or time-consuming or distracting or solved through some other means the artist didn't think of. Screw that. Solve the problem once and for all by providing the artists with the tools they need to do their jobs the way they want to do them. And then reward the hell out of the coder that provided the tool (or the new feature, or the right bug fix) and make damn sure everyone knows what happened and why you, the producer, think that's just the bee's knees.

Amer Ajami: Peter, Ben, and Frank all hit on what I believe is the key to improved communication, not just between artists and engineers, but across all disciplines: collocation. Yeah, you need a team that speaks the same language and has great chemistry, and yeah you need guys on your team who will walk over to an engineer or an artist and solve problems on their own, without any oversight. But nothing knocks down the barriers of communication easier and moves development along faster than putting all your key guys in a room together and letting them run wild.

We have a physical setup at our studio that's not entirely conducive to a productive environment that promotes a lot of communication. The guys at Ubisoft Montreal did it right -- they basically sit in a giant warehouse with little to no walls separating a majority of the team. It's similar to the floor of any newsroom, for example. The energy level at their studio always seems high, and productivity doesn't seem to be a problem.

Amer Ajami served as associate producer on EA's Battle for Middle Earth 2

Our team here at EALA, on the other hand, sits in cubicles with 5 foot walls, and key people are often spread across the entire floor, sometimes separated by literally hundreds of feet. Obviously, not the ideal setup for making a game. The way we get around this communication barrier is to collocate certain members of the team (including engineers and artists) into a single space during key inflection points of the development cycle. We jokingly refer to these as "rooms of pain", but they're actually incredibly productive, and quite fun.

Having key engineers sitting literally face-to-face with key artists, with clear access to each others' monitors, cuts down on ambiguity, confusion, and miscommunication. These "rooms" only run for 1-2 weeks at a time, and are focused on hitting a specific milestone or delivering on a certain feature of the game, all while minimizing the impact on the rest of the team, which is ostensibly still doing its thing on the main floor.

If many of us had our druthers, our entire floor setup would be configured in a completely open space. But failing that, these "rooms of pain" are a great way to cut down the barriers to communication between all disciplines and drive the project forward at important times during development.

The opinions expressed by these producers are their own and do not necessarily reflect the opinions, plans or positions of the companies where they work at. If you are interested in being added to the interviewees for Producer Of The Round Table, please contact GameProducer.net.

Read more about:

Features

About the Author(s)

Juuso Hietalahti

Blogger

Juuso Hietalahti is a game producer and the owner of an online multiplayer games company Polycount Productions (http://www.polycountproductions.com). He has co-produced several indie games, published indie game production articles in websites, magazines, books, and is the author of daily game producer resource gameproducer.net (http://www.gameproducer.net).

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like