|
I've worked on both sides of the publisher-developer relationship. I've once been that heavy-handed producer who dramatically altered the vision of the game, and I've been a developer who has experienced how much damage a publisher with design-input can make. This article attempts to explain the thinking (or psychosis some might say) of why the publishing producer sometimes dictates and micro-manages the design.
Publishing Producers (aka External Producers)
Publishing producers' main responsibility is making sure the project hits its mark - both in terms of time and quality. They are
facilitators. They deal with money, marketing, licensing, legal issues, quality assurance and ultimately submission to manufacture. They manage a game contract with an outside expert developer. Their main point of contact with the developer is the studio or project lead. They usually only play the game in development to demo it or review a milestone build.
Publishing producers often have backgrounds in marketing, business development, quality assurance, or film or radio production. However they got to their position, they're not usually very skilled game designers, but they are gamers, or they wouldn't have sought out the job. It is however part of their job to review the design for purposes of hitting the quality mark. That's the rub.
Developers
If a publishing producer has done his job well in the vetting process, he'll have hired a developer that will make his job easy.
Developers are the design experts contracted to make the best game possible in the time alloted. The publisher is their client, but both have a vested interest in
ensuring that the project succeeds. In theory, developers don't make major mistakes that a publisher needs to correct. Ideally, the most a publisher does for the design is provide the focus testing report.
But you never really know for sure what will happen. Sometimes a developer will bite off more than they can chew. Sometimes that experimental gameplay originally envisioned just doesn't pan out. You don't really know until after the honeymoon period is over, and sometimes not until Alpha is fast approaching. How well the project rebounds depends on the relationship, and often its these problems that will transform the relationship.
WEAK Relationship - The Hands-Off Producer
The project often starts with a weak relationship. The relationship hasn't matured yet as people are still getting to know each other. It's the Honeymoon phase right after the contract was inked. The publishing producer is hands-off. He operates from the goals and deliverables set forth in the contract: he's just waiting for the developer to meet his expectations and deliver what they promised.
If all goes smoothly, the Hands-Off Producer will publish his game on time but the quality of the content will be purely up to the developer. Developers love hands-off producers.
If things go poorly, the Hands-Off Producer will either miss his date or get the project canceled or he'll transform their relationship to be more hands-on and start dictating changes. Developers at this point pay the price for having a Hands-Off Producer.
OVERBEARING Relationship - The Dictator Producer
Projects don't usually start with a publisher dictating design. Even if a publisher comes to a developer with an existing property, they don't dictate design except by very broad strokes which normally is translated into a vision statement and milestone deliverables. If your project starts day one with the publishing producer dictating minute design decisions, then he's probably confusing his role and overstepping.
If all goes smoothly, the Dictator Producer will have made a game that satisfies himself while the developer will have slipped into the passive role of doing whatever the customer wants. Unfortunately for the developer, he'll still take responsibility should the game miss its quality mark.
From my experience, projects that start off with a Dictator Producer rarely do well and often miss their date as he iterates on his vision by having the developer produce more and more throw-away demos. This overbearing relationship is unhealthy as it doesn't maximize the skills of the developer and it puts too much unchecked authority into the hands of someone who might never have designed a game before.
More typical, the overbearing relationship is what happens AFTER a project exhibits problems. While it's not the healthiest of relationships, the publisher has assumed the risk ($$) and has little choice but to make demands and fix the problems. Instead of working with the developer on a remedy, the Dictator Producer will make assertions and assume full control. At this point the trust is gone. The vision holder of the game is no longer the developer's creative director or lead designer, but the publishing producer. He or his minions will spend more and more time on-site making design decisions as alpha comes and goes.
Having been a Dictator Producer on one project I inherited, I can say that it's not ideal. I'd rather the developer step up and earn back the trust than deal with the stress of sitting on a developer. If you're a developer in this position, you're going to be very uncomfortable and you should do everything you can to earn back the trust to create a more balanced relationship.
BALANCED Relationship - The Modest, Goal-Oriented Producer
Somewhere in between the weak and overbearing relationship is the Modest Goal-Oriented Producer. His balanced approach doesn't assume he's a design expert but he's extremely analytical and capable of offering suggestions and ideas that would satisfy design goals. He's good at explaining where developers' ideas and implementations are falling short. He'll present problems without solving them, allowing the developer to recognize the issues and solve it themselves. A good publishing producer spots issues early by having established clear and comprehensive milestone deliverables up front. He'll have done the math to figure out how much of the game needs to be done by when to keep the pace and ensure the developer hasn't overestimated their abilities. He'll use focus testing to inform or bolster his opinions and demands.
If all goes smoothly, the game will have received input from all parties, will represent the passions of the developers and stand a better chance of hitting the quality mark.
If things go poorly, such as scope issues, delays, market pressures, experimental design going awry, poor implementations etc., the Modest and Goal-Oriented Producer will state his concerns and ask for the developer to address them. He'll ask for swift corrections and be prepared to give specific examples of what could be done better. He'll decribe how the implementation and/or interpretation of the design is falling short of the design goals. He will NOT tell them what to do, but suggest solutions. His hand-holding is short term, in hopes that the developer will recognize the issues and take corrective action.
If things continue to go poorly, more drastic action may be required and it's possible for the publishing producer to become more dictatorial and take over the design, with the overbearing relationship materializing as a strike team or similar on-site publisher representative taking over the design lead role. Even then, a more balanced approach would be less drastic - asking the developer to replace the lead designer and present a more satisfying design and a new build of the game for a make-or-break milestone.
Conclusion - Earning Trust
It's not always obvious that a design is lacking until it's implemented. Most publishers suffer a complete inability to convey realistic expectations or see past the smoke-screen of vagueness that developers often wield when securing the deal. Good design is not always obvious. It's very subjective and often takes iteration - something that modern budgets and time-frames don't account for. The publishers are gambling a lot of money and trust that the developer, the key vision holder for the game, knows what they're doing. That trust unfortunately has to be earned.
|
A little background: I'm a systems designer by inclination and a project manager (outside the game development industry) by professional experience. So I appreciate the value of both roles in creating properly functional systems on a budget and a schedule.
But if anything, this is why I'm annoyed every time I discover that some producer -- or worse, an executive -- is dictating design choices for a game. People acting in multiple roles tend to do none of them sufficiently well.
When a developer blog/chat/interview reveals that it's the producer who is determining core design elements, that suggests two things to me: firstly, that the producer is probably neglecting actual production-related tasks in favor of fiddling with the design. That's a bad sign for delivering a good product on time. Who's monitoring and managing the development process while the Producer is arguing with the Lead Designer that the game should be in third-person rather than first-person perspective?
And secondly, why the heck did they hire a Real Designer if they're not going to let that person do their job? A good designer needs the authority to specify the high-level systems of a game, and that creative authority needs to protected from producer encroachment -- if you're so concerned about the creative direction of a game, you need to fire that designer and hire a new one, because the alternative is a blurring of the vision for the game. When the designer does not have the power to enforce a consistent creative vision, when non-designers can impose their preferences solely because the org chart says they have the power to do so, you're likely to get an incoherent game that feels like it was designed by a committee... because it was.
Frankly, I think most producers are not equipped to be designers, and they should not try to fill both roles. If what you really want is to design, then demonstrate the courage of your convictions: step down as Producer and ask to be hired as the Lead Designer or Creative Director or its equivalent.
Finally, I note that this applies to both internal producers and publisher producers. Personally, I wouldn't want to sign a deal with a publisher that didn't include some text saying that final authority for creative decisions rests with the developer. (Naturally such a contract should also include a provision allowing the publisher to back out of the deal if they feel strongly enough that the creative direction is just too wrong.) I don't see any good in producers dictating design choices, whether those producers are part of the development studio or represent the publisher.
This does not mean that producers (or any other member of the development team) shouldn't be able to offer design ideas. Designers aren't perfect; sometimes it's helpful to hear what others think. What I'm arguing against here is allowing the Lead Producer or Senior Vice President in Charge of Whatever to *dictate* design choices simply because they sign the team's checks.
Bottom line: Power in a corporate hierarchy does not imply design competence. Let the designers do the designing, and let producers stick to producing.
Of course I recognize that this is wishful thinking on my part, and that producers of whatever ilk will continue to abuse their power by overriding the creative work of the people who supposedly were hired on the strength of their design abilities.
Doesn't mean I can't complain about it as a sub-optimal business process. :)
On the flip side of this coin, there's also several general developer types; the Superstar Divas who will not give a flying F whatever the Publishing Producer asks or instructs them to, usually because they have a hit or two under their belts and the deal was made by someone way higher up than the Publishing Producer, and who is convinced of the Superstar Diva developer's creative genius.
I've also worked with Conveyor Belt developers who were hesitant to write a single line of code without first asking for permission/approval, and relied 100% on the Publishing Producer to tell them exactly what to do, how and when.
And finally of course there's the vast majority of developers who end up somewhere in-between, but still often at some stages/aspects of the project display tendencies of both of the above extremes - just like most Publishing Producers display both hands-off and dictatorial behaviour depending on their particular passion - audio, graphics, music, A.I., story, etc.
This is a huge skill to learn, not only for a good producer, but for anyone making a suggestion to a designer. Having gone through QA and entry-level design positions, I can totally say that telling a designer to do something exactly your way rarely works.
The main difference between a Producer and someone lower on the totem pole is that a producer presents a problem while a design underling first has to convince the designer that there is a problem in the first place. :)
Great post!