Interview with Dorian Richard (Atari)

I had the unexpected opportunity to chat with Dorian Richard, Atari’s external producer for Neverwinter Nights 2, the anticipated RPG from Obsidian Entertainment. We ended up having a long conversation about publisher/developer relations and the pitfalls of production, which I transcribed:

What do you feel distinguishes publisher (external) producers from developer (internal) producers?

As a publisher, you have a broader perspective; you work on a lot more titles than any given developer over a five year time span. The average developer has two teams, and it takes two years to make a game, so you’re looking at approximately five titles over five years. I’ve worked on nine titles over the past five years.

What are the most common challenges you face when interacting with developers?

There’s inexperienced developers, and there’s experienced developers. Inexperienced developers tend to lack staff with sufficient scheduling and managing experience. They might be good at certain development tasks, but they don’t know how to read warning signs and manage people, so they frequently fail to recognize when a big slip is looming. They don’t plan for likely emergencies, like a key team member getting sick or having a family emergency.

Inexperienced developers also tend to have trouble understanding why they are slipping. Is a team member consistently slower than they are expected to be? Is the technology more complicated than originally planned? Are team members failing to schedule time to polish features as necessary? Inexperienced developers often fail to identify and resolve problems like these. Failure to schedule enough “polish time” is an especially common problem. Polish can represent 40% of the total effort necessary to develop a given feature, but it’s regularly underestimated.

Inexperienced developers also have trouble capitalizing on pre-production. You really have to use that time to carefully schedule a project. You have to agree on realistic milestones for a complete game design — not a vague, undefined game. At the end of pre-production, you have to know where the development risks are, and you need to have backup plans in place. And you should evaluate each team member to figure out their strengths and weaknesses, and use that information to figure out a realistic schedule.

Inexperienced developers also forget to give themselves time to experiment and redo stuff that just doesn’t work. There will always be something that you eventually realize is going in the wrong direction, and you need to have time available to permit for fixing that. They also forget to schedule the really mundane stuff, like creating a rough draft of the game manual (which can take a designer a week of time for something like an RPG.) Or creating a casting list. These things always need to be done, but inexperienced developers frequently forget to account for them.

Even experienced developers occasionally underestimate how long it takes to tune and polish stuff, and some don’t take advantage of the pre-production process as fully as they should. But experienced developers are more likely to have backup plans in place, even if they sometimes fail to execute upon them when they should. Even then, experienced developers recover from problems much faster than inexperienced developers. To their credit, experienced developers are also much more able to admit to themselves when something is not working and cut features or change them as necessary.

It’s been really great working with Obsidian. This is one of the most professional studios in the business. Bioware is another great company — very professional.

Does undue pressure from publishers cause some of the scheduling problems you referred to earlier?

Yeah, sure. Publishers want to get it cheap and they want to sign the contract fast, so they are partially to blame for some scheduling issues. I’ve warned my colleagues in the past that they should be adding six months to any schedule suggested by a developer, because it simply isn’t going to happen. Developers always respond to publisher pressure by trying too hard to please.

What kind of mistakes do publishers make during the development process?

The publisher’s producer needs to be good at spotting red flags and should have a good working relationship with the developer so she can help them work through issues in a productive way. Publishers often find out too late that there’s an issue that can no longer be addressed. A good publisher keeps on top of that stuff, as long as the developer is being responsible and open with them. A bad publisher won’t take notice of problems until it’s too late. But again, the publisher really needs to work to establish trust with the developer (and vice versa) or none of this works.

How do you get the relationship off on the right foot?

Again, you establish trust. You have to be professional. You have to ask the right questions. You have to show that it’s OK to discuss certain issues that the developer might not be comfortable with. That’s where personal relationship comes into play. You have to be involved. You can’t swing through once a month and ask a couple questions. You have to really get to know the team. I don’t think there’s any magic formula — you need to have a good attitude and work for their trust.

But developers should be aware that no matter what’s happening with the relationship, honesty is always the better policy. Yes, the game might get cancelled in a really bad situation. But at least there’s some likelihood that the relationship will be preserved. We might be willing to work with an honest developer in other areas (where they’re less likely to struggle).

How often should the publisher’s producer visit the developer and spend time on-site with them?

At the very least, the publisher should try to be onsite towards the end of the project. Some developers would find it intrusive if the publisher is always around, but that can be addressed in part by, again, developing an open and trustful relationship. On-site time isn’t as important during pre-production, though you definitely want to be engaged then. Just not necessarily onsite.