PRODUCTION TECHNIQUES 315
■
Assign time limits. Assigning time limits to each topic on the agenda keeps
the meeting moving forward and ensures that people don’t get bogged down
in discussing a topic ad nauseum. Obviously, some topics need more time
to discuss than others, but if you set a general time limit on the agenda, you
have a much better idea of how much material you can realistically cover in
the meeting. Be sure to include time at the beginning of the meeting to state
the goals to the attendees, and time at the end to summarize any decisions
made during the meeting. If you run out of time to discuss a particular topic,
either table it for another meeting, or continue discussing it and table the
other topics instead.
■
Start and end meetings on time. A lot of time is spent getting everyone
gathered together for a meeting, often the actual meetings begins 10 or 15
minutes because everyone comes straggling in. Make it a practice to start
meetings on time so some people aren’t twiddling their thumbs while waiting
for the other attendees to arrive. Ending meetings on time is good practice as
well—this makes is much easier for people to schedule things after the meet-
ing, and avoids the never-ending meeting when nothing gets decided.
■
Don’t combine information gathering and decision-making in one
meeting. Meetings can quickly get off track if you try to combine informa-
tion gathering and decision making into a single meeting. People can get
bogged down in the information part and never get to a decision, or they
want to make a decision quickly and don’t consider all the pertinent infor-
mation. If these topics are discussed in separate meetings, people are better
able to focus on the information.
■
Appoint a moderator. The moderator is a neutral party whose job is to
keep the meeting running on track. They control the agenda and will keep
people on topic so the meeting can start and end on time. They are not in-
volved in the actual discussion, but will re-direct the conversation if it strays
from the agenda.
■
Take meeting minutes. Minutes are a useful record of what was discussed
in the meeting and what decisions were made. This avoids the issue of peo-
ple forgetting why the meeting was held in the first place, and prompts them
to follow up on tasks that were assigned during the meeting. The minutes
should list who attended the meeting, the meeting goals, the agenda, key
points of discussion, key decisions, and action items. Action items should
be assigned to a specific person and have a stated deadline for completion.
As with the moderator, assign someone who is neutral to take notes, so they
don’t have to be actively involved in the conversation.
■
Follow up on action items. Action items are important by-products of
meetings, and are needed in order to come to a resolution on some of the
topics discussed in the meeting. Track these action items in the minutes, and
make sure they are completed by the deadline.
316 THE GAME PRODUCTION HANDBOOK, 2/E
18.7 RESOURCE ALLOCATION
From time to time, the game might not have enough personnel to complete
critical tasks on time. This could be for a variety of reasons: the work was under-
estimated; people are out sick or on vacation; more features were requested; and
so on. When trying to solve personnel issues, consider temporarily reallocating
resources.
One way is to pull people from non-critical tasks to help out with the critical
ones. In order to do this, you, as the producer, must be aware of everyone’s skill
set. Most team members are not utilizing all of their skills on a given task and are
more than happy to pitch in on other tasks when needed if they have time. For
example, a level artist might be familiar with how to use After Effects and can
temporarily help out the cinematics team, or a tools engineer might be capable
to help with coding UI.
When temporarily pulling people from their tasks, you must schedule start
and end dates so that they know when they must wrap up their temporary assign-
ment and get back to work on their main tasks. If you reallocate someone, and
it turns out that they are needed permanently on the new task, assign someone
else to pick up the old tasks.
Another way, if you are working in a large studio with multiple projects in
production, is to temporarily pull people from other project teams to help. The
other team might be impacted, but if they have more time in their development
schedule, they might be able to spare someone temporarily.
Finally, look at hiring external contractors. You do not want them on critical
path tasks, but if you have already reallocated internal resources to the critical
tasks, the contractors can come in to work on the noncritical tasks. This frees up
the internal team members to shift around where needed.
18.8 PREVENTING FEATURE CREEP
Feature creep occurs if additional features are added without adjusting the other
project variables (time, resources, and quality) to accommodate the additional
work. It’s something that developers are always fighting against, since feature
requests are made on a regular basis by the team, studio management, the pub-
lisher, marketing, the fans, and so on. If feature creep is not controlled, the
project is put at risk, and you might miss the ship date.
Some feature creep is a good thing, as it makes the final game more enjoy-
able to play. For example, if the control scheme is implemented as designed,
new feature requests to improve the usability might come in after people have
had a chance to play with them. Or after the UI is in place, some of the screens
PRODUCTION TECHNIQUES 317
and buttons might need to be redesigned to be more intuitive to the player.
Because of this, developers must not ignore additional feature requests.
On the other hand, some feature requests can be damaging to the
project—either they are completely unreasonable given the other project
parameters; they impact a lot of work already done; or they are so small that it
is not worth putting the project at risk to include them. When features like this
are requested, it is the producer’s job to diplomatically explain why this feature
cannot be included. This can be difficult to do, especially if you have to explain
to a senior vice president why his pet feature can’t be in the game.
A good method for explaining why a feature can’t be included is to illustrate
the impact that adding this feature will have to the game’s cost, schedule, and
resources. For example, if marketing requests that an online ranking system be
added, the producer can research how long the feature will take to design, imple-
ment, test, and who is available to do these tasks. Most likely, a feature of this
nature will take several weeks and several people to implement, requiring a shift
in the schedule and resources, which directly impacts the work already being
done on a project. Essentially, if someone asks for a new feature to be added after
the game is in production, a feature (or features) must be removed in order to get
the game finished without changing the schedule, resources, or quality.
PREVENTING FEATURE CREEP
Stuart Roch, Executive Producer
Activision
Feature creep is difficult to handle for many reasons. When a project is locked
down and supposedly content complete, a producer faces many challenges. For one,
the people wanting to get the extra features in post-lock are the most influential
people on the team. Sometimes the studio head is pushing for a feature he feels pas-
sionately about, and others such as the creative director might be lobbying for that
one last feature to make the game great.
Outside of the difficulty that producers face in saying no to key team members,
simply identifying the features can be a trick in itself. What to one producer is a fea-
ture being requested late in the project can be a polish tweak or even a bug-fix when
defined differently on another team member’s plate. Unless the project has been
managed well from the start, this is not a black-and-white problem. Some features
will inevitably have to be approved post alpha, and some tolerance will have to be
allowed. The best defense late in the project is to set up a feature approval pipeline
318 THE GAME PRODUCTION HANDBOOK, 2/E
Prioritizing Features
If you plan ahead for future feature requests, you might be able to get some ad-
ditional feature requests added to the game, without removing anything else that
is already planned. When someone makes a feature request, evaluate the feature
and prioritize it. Refer to Chapter 15, “Game Requirements,” for information
on prioritizing features. Then, examine the current set of features to determine
whether any tier one features can move to tier two, and so on. This way, the new
feature request can replace an existing feature that was already planned for,
thereby minimizing feature creep.
Change Requests
Formal change requests are another way to monitor and track feature requests.
Essentially, when someone requests a feature change or enhancement, they fill
out a request form. The form should ask for the following:
■
Description of request
■
Reason for request
■
Impact if feature not added
■
Recommended alternatives
■
Analysis of how this affects the project schedule, resources, and quality
■
What existing feature can potentially be removed to accommodate this
request
■
Who needs to be notified of the potential change
After the form is filled out, it is sent to the producer for review. The pro-
ducer will want to double-check the details in the form, particularly the proj-
ect analysis, to ensure that the correct people have been consulted about the
proposed feature and have given accurate estimates on how this affects their
work. After the producer reviews the form, he can discuss the request with
the necessary people, such as the project leads, studio management, or the
publisher.
with checks and balances to make sure that anything that gets added or rejected
from the game goes through the appropriate parties. The feature request pipeline
should include people like the executive producer, project director, and creative
director to make sure every feature request is handled with business, schedule, and
creative concerns in mind.
PRODUCTION TECHNIQUES 319
DEALING WITH FEATURE CREEP
Wade Tinney and Coray Siefert
Large Animal Games
If a project is behind schedule, we usually re-evaluate the design and figure out
what features can be scaled back. We might reduce the number of levels or char-
acters, remove a piece of music, or re-use assets from a previous title. This way, we
can preserve the core features and have something to add on to the next iteration
of the game. For example, on Rocketbowl, we originally planned for 10 levels, but
we ended up shipping with seven levels and then offered the final three levels as
downloadable content.
Game developers have to be proactive about addressing problems on a project.
This is especially true for Large Animal because we are a small developer whose
projects are typically completed in six to eight months. This means we can’t wait a
month or even a week to deal with any problems that put the ship date of the proj-
ect at risk. If we are two days behind schedule on the character art, for example, we
need to make up for this time by reducing art time on another aspect of the game.
18.9 ESTABLISHING APPROVAL PROCESSES
From studio management on down, many people are involved in the game de-
velopment process who need to approve certain parts of the game before pro-
duction begins. For example, they are paying the bill and want a say in how the
money is spent, or they are in charge of coding a particular feature and need to
make sure that the proposed design is doable with the technology. It is useful to
put approval processes in place in order to present everyone with all the neces-
sary information, track the approvals, and record the feedback. These processes
will differ based on the project size, how many people have approval rights, and
how much information needs approval, but there are three major things in com-
mon with any approval process: keeping it simple, defining and publishing, and
centralizing the tracking.
One person should be the main point of contact for approving or rejecting a
feature change. When a final decision has been made, all interested parties must
be notified. If the feature is approved, make sure that it is properly documented
and added to the project plan.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.