DEVELOPER AND PUBLISHER RELATIONSHIPS 83
VETTING DEVELOPERS
Jay Powell
Digironin Games
Vetting developers is not an exact science, but there are a few things I’ve found
that improve your chances of picking a reliable developer for your game:
■
Research the track record of the company as a whole; this is the key
to showing their experience on the platform. Give some leeway when
looking at their development experience—for example, if they have
developed a GBA title they can likely do a DS title.
■
What have they done? This includes what they’ve done as a group,
what the individuals in the group have done at other companies, and
also what the individuals have done at the developer you are talking to.
If a company is using game “x” as proof of their competence you want
to make sure your team members worked on that game.
■
Delve further into the developer’s softography. Find out who were the
individuals who worked on the games and what roles they had on the
project. If there are specific people you want working on your project,
call this out in the contract in order to avoid the bait and switch.
■
Check references. If company doesn’t want to give references that is a
red flag. Check the credits of their games to find out who the publisher
was. Try to contact someone the publisher who worked with them to
get information.
■
If possible, do an on-site visit to check out their offices. If this is not
possible, do phone interviews and try to get a feel for their production
process, work ethic, and reliability.
■
In some cases, especially with less-experienced developers, I may have
them fill out a document that details the team history, their experi-
ence working with other platforms, and anything else that gives a good
indication of how well they understand game development.
Keep in mind that developers need to do as much due diligence with the pub-
lisher they are working with. For example, the developer must understand the
publisher’s milestone approval process—including the turn-around time for accep-
tance and feedback, what types of deadlines the publisher requires, which the pro-
and payment schedule will be exactly the same, although the same types of de-
liverables will be expected throughout the process.
84 THE GAME PRODUCTION HANDBOOK, 2/E
During the initial pre-production phase, the publisher will expect to get de-
tailed design and technical documentation, a full budget, schedule, and staffing
plan, and a gameplay proof of concept. In some instances, these materials have
already been created and presented to the publisher in the initial pitch.
At this stage, the publisher may want further information on what produc-
tion processes will be used to track the progress of the game. This is a valid
concern since the publisher is making an investment in the game and wants to
realize a profit on this venture. If the PP is not confident in the DP’s ability to
manage the production process, the PP may become very involved in the day-to-
day production tasks being performed by the team. This is not an ideal situation,
as the publisher is not interested in running a development team—that’s why
the project was assigned to an external vendor in the first place. However, the
publisher will do whatever is necessary to protect the investment.
After full production has started on the title, the publisher expects to see
regular builds of the game. While reviewing the build, the PP will provide feed-
back and will request changes to the game. This is expected to happen within
a reasonable scope, and the additional feedback will likely improve the overall
quality of the game. For example, the PP might ask for a level to be rescripted or
for the game controls to be adjusted.
In some cases, the publisher will request a major feature change or for a new
feature to be added. When the DP receives these requests, he needs to evalu-
ate the request to see whether it fits within the agreed upon scope of the game,
as outlined in the documentation and milestone schedule. In some instances,
the request replaces a planned feature and, thus, might not impact the scope or
schedule negatively.
In other instances, the feature request will impact the schedule and resources,
meaning additional production costs are incurred by the both parties. When this
happens, the DP must immediately make the publisher aware of the impact: the
schedule may need an extension; the developer may need to hire more people; or
other features must be cut in order to accommodate the request. If any of these
changes happen, the DP and PP must renegotiate the milestones and payments.
A developer dealing with additional feature requests and feedback from the
publisher may get frustrated, but if a solid working relationship is established
with the PP, this frustration can be minimized. The PP is there to help the de-
veloper, and a good PP will work with the developer to deal with any unexpected
issues on the project.
ducer the team is working with, and so on. It is a good idea to ask other developers
about their experiences working with a publisher.
DEVELOPER AND PUBLISHER RELATIONSHIPS 85
WORKING WITH PUBLISHERS
Don Daglow, President and CEO
Stormfront Studios
Choose your publisher wisely and do your research thoroughly. Think of work-
ing with a publisher as being like going on a cruise—you pay for everything in
advance, and you can’t just turn around and leave if there’s a problem. Sometimes
publishers may ask developers to add more features to a game without being paid
more money, and a developer simply has to say, “I’m sorry, that wasn’t in the spec
and it’s not in the budget or schedule. What should we cut to make room for this
new feature?” Other times there will be good-faith misunderstandings that both
companies have to work together to resolve (e.g., “Wow, no one ever specified when
collision detection would be functional, and we thought it was March and you guys
assumed September!”)
If you find yourself in conflict with a publisher over game content or a mile-
stone approval, be firm and reasonable in your positions but don’t get too cynical.
Often, your publisher’s producer is fighting with his or her boss on your behalf in
order to come up with a fair and reasonable way to deal with a problem. In a perfect
world the producer you work with is a foil who brings out the best in your group,
just as good editors make good writers better. The best producers challenge their
developers and push back to get them to do their best work—this makes for better
games… and better royalties.
The following interview details the production model used at Large Animal
Games as well as how they manage the developer-publisher relationship.
MANAGING THE DEVELOPER-PUBLISHER RELATIONSHIP
Wade Tinney and Coray Seifert
Large Animal Games
We are a small independent developer, who makes games for the casual, download-
able games market. In the past, we would usually have six or so projects in development
concurrently, varying in production time from six weeks to six months. This model
was successful for us, but now that our catalog of original titles is earning royalties,
we are in the position of not having to do as many small projects. Our focus now is on
larger projects, with a six to eight month development cycle. We have both internally
86 THE GAME PRODUCTION HANDBOOK, 2/E
funded projects, like Rocketbowl, as well as third-party publisher funded projects, such
as Saints & Sinners Bingo, from which we also receive a share of the back end.
Publishers are a relatively new phenomenon in the downloadable game space.
There are only a few companies who are actively funding third-party development
at the moment.
Although we are not a traditional PC or console game developer, the relation-
ship we have with our publisher is similar. We work with them to create a devel-
opment plan at the beginning of the project, which defines the core features, the
milestones, and the payment schedule. However, the publisher we work with is
smaller, which means we have to deal with less corporate overhead and there is
greater flexibility in general.
Over the course of a six to eight month project, we usually have about eight
key milestones which include such deliverables as design complete, core feature
complete, and content complete. The publisher works with us during the develop-
ment process to ensure these milestones are delivered complete and on time. The
publisher provides some QA resources, produces marketing materials, and secures
deals with distribution partners.
We have a good relationship with our publisher. We speak with the publisher
about once a week, depending on where we are in project. When issues arise, we
may speak with them several times a day. Overall, if things are going well during
the development cycle, the publisher is not actively involved. But if the publisher
has some concerns, they are brought to our attention and we will address them. The
publisher gives good feedback, and it never feels like it is mandated; they trust us to
deliver a quality game experience.
For a small developer working in the downloadable games market, having a
publisher-backed product can have significant advantages. A publisher can really
help push your game to the top and secure a better deal and better promotions with
an online game distributor.
In the following interview, Jay Powell discusses development milestones and
contract specifics.
DEVELOPMENT MILESTONES
Jay Powell
Digironin Games
Publishers will include a termination clause in contact. For example, if a mile-
stone is “x” number of days late, or fails, the publisher may decide to terminate
DEVELOPER AND PUBLISHER RELATIONSHIPS 87
the contract. In order to enforce this, the contract has to be very specific on what
constitutes a milestone. So instead of saying that a set of tasks will be 50 percent
complete, the publisher will want a list of actual assets and tasks that are supposed
to be completed for a specific milestone.
While a Game Design Document (GDD) and a Technical Design Document
(TDD) are usually included as part of contract, these may not be fully fleshed
out before the contract is signed. In this case, the publisher will not require a
specific schedule up front, but will want to get a list of the milestone breakdowns.
A provision is included in the contract to add addendums with the specifically
defined milestone by a certain deadline. This allows the publisher and developer
to have some flexibility as to what should be included in a specific milestone,
but also gives the publisher something to check the milestone against when it is
delivered for approval. The contract will usually include a well-defined approval
process—for example, the publisher will have “x” number of days to review and
send feedback.
Once the publisher reviews the milestone, they will usually have feedback for
the developer on things they want changed. The developer needs to be diligent
about letting the publisher know when changes are beyond the scope of what is
asked for, and request a formal change request. The developer has to walk a fine
line, because sometimes a bunch of little things can really add up and impact the
scope of the project. On the other hand, the publisher will sometimes ask for small
changes that are within reason and don’t require change requests.
The process for change orders are defined in the contract. A change order is
completed when a publisher requests changes to a milestone that will impact the
scope of the project. This change order defines what needs to be done and is pre-
sented to the developer. The developer reviews the requests and comes back with
a plan that details how much money and time will be needed in order to make the
change. The publisher can then decide if these changes are necessary.
Publisher-Owned Developer
As stated earlier, the big benefit of being a wholly owned developer is that the
finances are guaranteed, which means the team can concentrate on making the
game, instead of worrying about getting their milestone payments in a timely
fashion.
In this type of relationship, the publisher is also more intimately involved
with the team during the development process, which means they can offer
more resources to the team. For example, the publisher can temporarily lend
the team experts from other internal projects, making it possible for the team to
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.