P
RODUCTION CYCLE
In This Chapter
• Design Production Cycle
• Art Production Cycle
• Engineering Production Cycle
• Working Together
17.1 I
NTRODUCTION
W
hen pre-production is completed, you will have a clear idea of the
game that is being made, how to make it, who is going to do the work,
and how much time you have to do it. It is important to note that there
is not a definite point where pre-production ends and production begins. The
transition will be gradual. For instance, while art and engineering begin work-
ing on the features outlined in the core design documentation, design is still
busy designing the actual mission scenarios that appear in the game. Also, art
will begin production on some assets, while still prototyping others. Engineering
begins coding the game but might still be working on technical prototypes for
some of the minor features.
What’s important about production is that the team can start implementing
the plan and watch the game take shape. So even though some small details are
still being worked out, production can begin after the major aspects of the game
are defined and approved. The main tasks occurring in production are imple-
menting the plan, tracking the game’s progress, and finishing the game. It is the
Chapter 17
296 THE GAME PRODUCTION HANDBOOK, 2/E
producer’s responsibility during production to manage these tasks smoothly and
deal with any surprises or problems.
Every producer hopes that they have planned for every possible contingency
during pre-production, and production is where this plan is put to the test.
However, on a game that takes two years to develop, it is a bit optimistic to think
that a plan made in January 2007 will be completely valid 18 months later in June
2008. Games change and grow with time, and a plan made more than a year ago
might not take into account the hot new graphics feature that marketing wants
added to the game. This is why the producer must be constantly vigilant about
the game’s progress during production, so that high-risk areas are identified and
corrected, and that high-priority feature requests can be accommodated when
necessary.
During production, the producer’s day-to-day tasks will involve interfacing
with the leads and team on a daily basis, assessing the game’s progress, evaluat-
ing gameplay, working with QA, keeping management happy, providing assets
to marketing, working with external vendors, approving milestones, filling out
paperwork, and a host of other things. Each day will be different; on some days,
there may be several fires to put out, and on other days, you can spend your time
catching up on work. Whatever a day brings, be prepared to get the production
back on track so the game ships on time. Chapter 18, “Production Techniques,”
discusses some ways for producers to manage the production cycle.
Of course, the art, design, engineering, and QA departments are also busy
during production. Each discipline is working hard on their assigned tasks.
Individuals can complete some tasks on their own or with help from someone
in their discipline, but other tasks will require multiple people and disciplines
to complete. If the team is enthusiastic and has high morale, getting them to
work well with each other won’t be difficult. They will become involved in each
other’s work, offer feedback, and work together to make the game the best it
can be.
KEEPING THE PROJECT ON TRACK
Jeff Matsushita, Executive Producer
Activision
If a project is in trouble, you might not see any tangible evidence, such as missed
milestones or personnel burnout, until it is too late. By then the project might be in
such a desperate situation that it will take much more time and money to get it back
on track than if it was caught early. And, if ample time and money are not available
PRODUCTION CYCLE 297
17.2 DESIGN PRODUCTION CYCLE
By the time production begins, design has completed documentation for the
major parts of the game. They spend their production day implementing game-
play into the build, tweaking existing gameplay features, and providing feedback
to the artists and engineers on their work. In addition, a designer might be writ-
ing all of the dialogue for a game and working with the producer to organize the
voiceover shoot.
The design production cycle also involves a lot of iteration and feature
evolution. After a feature is implemented in the game as originally planned,
the designer will continue to tweak and polish the implementation until it is
to make these adjustments, and they rarely are, the quality of the game will likely
suffer.
Producers need to constantly evaluate the game’s progress at every level to
make sure that things stay on schedule and on budget. This requires the discipline
to focus on finishing the project, knowledge of good project planning, and the will-
ingness to stick to a plan. After a plan has been defined, it is essential that everyone
make a commitment stick to it. That is why it is valuable to work with the entire
team to help devise these plans. That way, if individuals are not meeting their own
self-defined milestones, prodding them back on track before they begin affecting
the overall quality of the project will be faced with less resistance. If the team is
not meeting deadlines because the plan was not a fair assessment of bandwidth, or
conditions have changed to make it obsolete, the plan must be redefined and the
process started again. It is common for this to happen several times on a project.
Having to redo it might seem like a lot of overhead, but an invalid plan is dangerous
because it creates the illusion that the project is better managed than it really is.
One way to evaluate progress is to encourage regular builds of the game. If a
team is unable to provide builds as expected, then something is likely to be amiss.
It could mean that they are not making adequate progress or that there is a lack of
understanding as to the value of the deliverable. In any event, it is important that
the producer find out what is stopping the build. In order to establish this discipline,
producers should consider implementing regular builds early in the development
process. Start by getting into the habit of making builds once a month with the
frequency of the builds increasing as production continues. At alpha, daily builds
should be the norm. Any less means that the team might not have the processes and
discipline in place to be able to iterate quickly and effectively enough to close out
the game in time. With frequent builds in hand, the producer will have a tangible
work product to evaluate progress over time.
298 THE GAME PRODUCTION HANDBOOK, 2/E
CONDUCTING PLAY TESTS
Clint Hocking, Creative Director
Ubisoft
You can do several things to create useful play tests. First, you need external
people to participate in the play tests who can look at the game neutrally. You also
need dedicated people to plan, schedule, monitor, record, and report upon these
tests. You need to conduct the tests regularly from first playable until you reach the
point where you don’t have time to implement anything your testing might uncover
anyway (which is literally at about the master date). You need to do the testing in
small groups of three to six players, and you need to do dozens of different tests.
You need to have each group test as much of the game as it is possible for them to
test, and the people running the test group need to know exactly what they can and
should test for in each test. They need to gather as much data as they can, and they
need to know how to construct questionnaires and how to compile the data they
gather into useful information. The information you get from 100 to 200 individual
players is absolutely invaluable in terms of improving the overall quality of your
title.
perfect. This includes how the controls work, scoring, dialogue, UI buttons, and
anything else that needs to be tweaked when a playable version is evaluated.
In some cases, a feature might be redesigned if necessary. A feature redesign is
not something to be taken lightly and will need to have approval from the pro-
ducer and leads before it is done.
Play testing is also a large part of the design cycle. As gameplay mechan-
ics start functioning in the game, the designers conduct play tests to deter-
mine whether a feature is fun or whether more work is needed. Ideally, there
are people outside of the development team who can be play testers, so that
the designer can get unbiased feedback. However, it is a good idea to involve the
team when possible, as this builds camaraderie and gives people more owner-
ship over the game. In some instances, publishers will conduct open beta tests
in order to get information directly from the target audience about what works
and what doesn’t work in the game. The feedback is useful to the designers, as
they are getting feedback directly from the players and don’t have to guess what
they want.
PRODUCTION CYCLE 299
CONDUCTING BETA TESTS
Erik Louden, Beta Tester
I have participated in more than 70 beta tests (both open and closed) as a beta
tester for PC games. I find this to be very rewarding because I get to play games and
offer feedback and suggestions for improvement before the game is released to the
general public.
The beta test process will vary for each game, but in general, the publisher
determines which games have beta tests and how many beta testers are needed.
They may decide to have a more free-form test where the testers do not follow a
test plan or answer a specific set of questions, but rather will go into the game and
play it under real-world conditions. In other cases, they might have a questionnaire
for testers to fill out so they can more accurately track their feedback on the game.
When I was a beta tester at Activision, forums were set up for the testers to write
comments and to discuss the game. Sometimes, a member of the development team
would respond to questions on the forums and would keep them updated on how
things were progressing with the game.
Before we were allowed to test anything, we had to be screened and selected for
the beta test and then sign an NDA. After we were approved for the test, we would
receive a build of the game. A few years ago, before broadband was prevalent, we
received builds of the game in the mail. These often included a pre-addressed return
envelope so they could return the build when they were finished testing it. Nowadays,
we usually download the build directly from the publisher’s secure FTP site.
The amount of time we beta test a game also depends on what the publisher’s
needs are. Sometimes, beta tests start about six months before the game is re-
leased; other times as long as a year (alpha testing). Alpha tests usually focus on
bits and pieces of the game since the alpha release is not completely functional;
feedback is requested on new or experimental features that are added to the game.
After the beta test begins, we usually continue testing updated builds of the game
until it is almost ready for code release. Testers are directly responsible for finding
and reporting bugs, and sometimes the developers ask that we test the gameplay
and make suggestions about features and playability.
Developers and publishers can do a few things in order to get the most out of
their beta tests. First, it is good to have two core teams of testers. One team can do
directed play testing, via a test plan, and the other team can do freeform testing.
The freeform team will not read the documentation but will jump right into the
game and start playing it. Often they will discover things that will cause problems
that could be overlooked during a more formalized testing process. For example,
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.