78 THE GAME PRODUCTION HANDBOOK, 2/E
owned by the publisher. The basics of maintaining the relationships are similar
in each case—the publisher needs to be informed of the game’s progress, and
the developer needs resources and support from the publisher.
Ignoring this relationship can be detrimental to the development process. If
the developer does not communicate with the publisher on a regular basis about
the progress of the game, the publisher might become frustrated at the perceived
lack of progress. This frustration may cause the publisher to allocate needed re-
sources to another project, assign the project to another developer, or cancel the
project. If the publisher does not give feedback to the developer throughout the
production process, the developer might fulfill all the milestone requirements,
but the finished product may not be what the publisher thought it was getting. In
cases like this, the publisher might ask for additional changes after the fact, which
means additional costs and resources for both the developer and publisher.
This relationship is made more complex because both the developer and
publisher have a high stake in the game’s success and will do whatever they can
to ensure this success. Additional complexity is added because there are people
on both sides who have a say in how certain things will be in the game. For ex-
ample, publishers often assign their own producer to work with the developer,
in concert with the developer’s producer. This situation of having two producers
on the project might create some confusion if the two producers’ responsibilities
aren’t clearly defined.
The Publisher Producer (PP) is the publishing company’s representative and
will make sure that all sales, marketing, operations, and testing efforts are in sync
with the game’s production schedule. He is usually responsible for reviewing the
developer’s milestone deliveries and authorizing payment. Additional responsi-
bilities might include coordinating the marketing and localization tasks on the
game, dealing with license approvals, and acting as the developer’s advocate at
the publisher.
If the developer is owned by the publisher, they still submit builds for ap-
proval but have an advantage because they are on the publisher’s payroll already.
The developer’s payment is not tied to completing the milestone deliveries. This
does not absolve the developer from delivering completed milestones on time,
but it does provide them more flexibility regarding when these milestones are
reviewed.
The PP is not responsible for the day-to-day management of the develop-
ment team. This responsibility is the Developer Producer (DP). The DP is
responsible for creating the game development plan and making sure that this
plan is completed during the production cycle. The DP deals with any HR
issues within the team, equipment requests, and anything else that directly
affects people on the development team.
DEVELOPER AND PUBLISHER RELATIONSHIPS 79
DEVELOPER-PUBLISHER RELATIONSHIP
Tobi Saulnier, President
1st Playable Productions
The role differences of a producer in an independent and publisher-
owned studio are very different. In some respects they are the same; however,
in other aspects the whole relationship with the customer is fundamentally
changed.
For example, when working as an independent studio, each contract offers a
substantial business risk if any delays or other issues are encountered. You might
lose a lot of money and endanger your business; you might lose that customer and
endanger your business; and so on. Additionally, since your customers probably
each have their own unique processes and systems, for each project you will need to
translate between whatever set of processes and systems your customers are using
and the internal systems being used by your development team—bug databases,
forms, approval processes, and so on.
As a publisher-owned studio, you might incur the wrath of your boss if you
go late or over budget, but the consequences are much lower in that your studio
is unlikely to be closed (unless that is the only project you are doing, and you
have repeated performance failures). Also, there’s a lot more conformity within
an internal studio with respect to processes and systems. Because you only have
the one customer, all your processes with the publisher are consistent and can
be streamlined. However, your customer now has greatly increased visibility into
the project and has a lot more direct control of everything from features to the
development approach. For instance, instead of debating the price for a project
and providing a service that will cause them to choose you over other develop-
ers, you need to be able to justify your budget and negotiate a feasible scope
and schedule with your marketing department. So, as an internal studio, the
customer management aspect of the producer role is fundamentally different;
it becomes more management of organization hierarchy versus management of
customers.
In the following interview, Jeff Matsushita discusses how he keeps the devel-
opment cycle on track at Activision. He also discusses the developer-publisher
relationship.
80 THE GAME PRODUCTION HANDBOOK, 2/E
DEVELOPER AND PUBLISHER RESPONSIBILITIES
Jeff Matsushita, Executive Producer
Activision
Most companies have a formal method of overseeing the progress of titles in
production. In my current role at Activision, it is my job to use this kind of a process
to ensure that the development cycle is on track, that the product is meeting expec-
tations, and that everyone involved with the title is on the same page. Through this
and my previous experiences, I have had the privilege of working with many devel-
opers, both internal and external, and gaining some interesting insights into the way
developers and publishers work together.
Many factors affect the relationship between the developer and the publisher,
such as the terms of the deal, whether the developer is internal or external, and the
developer’s track record for shipping high-quality titles on time and on budget.
Another factor that influences this relationship is who brings the Intellectual
Property (IP) to the table. For instance, the publisher will feel more strongly about
a project when they provide the IP. In this case, the publisher will likely have more
feedback in the development process, since they want their license to be repre-
sented appropriately. In essence, the publisher becomes the developer’s customer.
On the other hand, if a developer brings an IP to the table, the publisher will focus
on working with the developer to ensure that there is a strong marketing effort to
support the developer’s vision of the game. These instances are rare as the devel-
oper must bring a strong established franchise and have a history of executing on it,
or they must have a high-quality game that is very close to completion.
Because of the increasingly larger budgets necessary to develop and market AAA
games, publishers are more cautious with unproven properties and with unproven
developers. In most cases, publishers will go only to proven developers with estab-
lished IPs. Additionally, publishers will prefer to work with an internal developer on
a new IP so they can have better visibility into the project and better assess risk.
The project is the result of the developer’s hard work—the program, the art,
the sound, and so on. The product is the final package that is advertised to the
media, shipped to the distributors, and purchased by consumers. In short, the pub-
lisher is responsible for taking the developer’s project and making it into a product.
The publisher takes the project, tests it, submit it for approval, creates a marketing
campaign, designs the packaging, puts it into the box, and handles sales and distri-
bution of the product. When the IP starts with the publisher, they may also fund
the development and provide the initial key creative elements. The key thing is
that the publisher takes the efforts of the developer and converts it into something
that produces revenue for everyone. In the most basic terms, it can be said that the
DEVELOPER AND PUBLISHER RELATIONSHIPS 81
publisher is in the business of selling games, and the developer has the job of mak-
ing games.
To facilitate this process, a publisher will assign a producer to work on the title.
This publisher-side producer is responsible for tracking the overall risk associated
with the development of the project, which includes making sure that the developer
is providing everything promised in a timely manner and is managing the develop-
ment team effectively. In addition, the producer works with the developer to help
them make the best game possible. The producer will deploy publisher resources
for focus-testing features and provide feedback to the developer. Finally, the pro-
ducer also continually herds all of the processes of production to make sure that the
development, marketing, testing, and localization efforts remain in sync.
The developer, on the other hand, is responsible for completing the project.
Unless there are specific IP-related assets brought to the table by the publisher,
this includes everything required to develop the software and is usually provided to
the publisher in the form of deliverables predetermined in the early stages of the
engagement. The decision on how to manage the project team is the developer’s
choice. The publisher does not necessarily have a say in how the deliverables are
completed so long as they are delivered on time. If, however, the deliverables slip,
are of marginal quality, or the developer is showing clear signs that they are suffer-
ing from other problems, the publisher will likely show greater interest in how the
project is being completed. This does not mean the publisher wants to step in and
take over, but they might demand greater visibility into the project to make sure that
the game is going well and that their investment is not at risk.
In order to minimize these kinds of things from happening, the developer
must provide as much information as possible when delivering milestones to pub-
lishers so as to shape expectations properly. For instance, a game rarely shows
well early in development. A prototype that has only basic scenes, basic controls,
basic visual effects, and so on will not likely impress too many people who have
no context in which to place it. When a developer provides these kinds of builds,
it is essential they spend the time to carefully set up the deliverables so that ev-
eryone understands why the materials are successful and how they show that the
development is proceeding with a minimum level of risk to quality, schedule, and
even sometimes, budget. The publisher wants to understand how such a limited
portion of the overall game fits into the development plan and how it will evolve
into a AAA title.
Another aspect of establishing context is for the developer to be clear about
what “done” means. If not explicitly defined, “done” can mean anything from being
viewable on a development kit with placeholder art, having basic features playable
in-game, or it is bug-free and ready to ship. Naturally, if the publisher is expecting
final quality and the developer only meant to provide first pass, people will end up
82 THE GAME PRODUCTION HANDBOOK, 2/E
arguing about the value of the build and inevitably begin questioning the progress of
development as a whole. But if there are details on what is included in the deliver-
able, for example, 10 percent of all animations are finished, polished, and viewable
in-game along with the list of animations completed, the publisher can gain a much
better understanding of what is included in the deliverable. Accordingly, the pub-
lisher can better assess the state of the game. If the publisher is looking at a deliver-
able that the developer says is done, and it is obvious that it is not done, the publisher
will lose trust in the developer, and the developer is not likely to understand why.
In order to help mitigate this, most publishers prefer that the developer spell
out the specifics of the milestones. In these cases, the publisher will not dictate what
the content for each deliverable is, but they may have milestone definitions of what
is expected at alpha, beta, first playable, and so on that map appropriately with the
state of development. The developer is responsible for telling the publisher when
the game engine, animations, art, AI, and so on will be completed and then man-
aging the project to deliver on these milestones. The only time the publisher gets
involved in the development process is if they don’t think things are getting finished
and their development is at risk.
In every situation, having a strong publisher-developer relationship with open
communication is important. The publisher and developer each have obligations to
fulfill in this relationship in order for the title to be successful. The most important
is to spend as much time as possible spelling out the specifics of deliverables. As
the only ultimate criterion for a successful development is whether or not a game is
fun—an abstract concept at best—it is important that in all other ways, communica-
tion is in the most concrete terms possible.
Independent Developer
Independent developers rely heavily on the publisher to provide the finances
for completing a game. In order for the publisher to select the best developer
for the job, they will conduct due diligence on the short list of candidates for a
given job. Conducting due diligence, or vetting, means that the publisher finds
out what they can about the developer’s ability to deliver a quality game, on time,
and within budget. Publishers will want to meet with the development team,
understand how the developer’s production process works, and are likely to get
references from others who have worked with the developer. It is important for
the development team to conduct due diligence on the publisher as well.
After a publisher has signed on a developer, they negotiate a delivery and
payment schedule for the project milestones. This schedule is affected by factors
such as the hardware platform, the scope of the game, terms of the contract, any
licensed intellectual properties (IPs), and other project variables. No delivery
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.