266 THE GAME PRODUCTION HANDBOOK, 2/E
Initial Schedule
An initial schedule is created in pre-production and communicated to the devel-
opment team in order to plan for key dates. Start the scheduling process by listing
all the major exit criteria for each area of the game: production, approvals, art,
engineering, design, audio, localization, QA, external vendors, and marketing.
More exit criteria can be added as development progresses.
After these criteria are determined, fill in estimated dates. Figure 16.2 is an
example of an initial production schedule. Major exit criteria are listed for each
phase of the game, and eventually deadlines are assigned to each one. Currently,
only the console manufacturer submission date is estimated, as this title must
Justice Unit
Estimated
Date Notes
Languages: English, German, French, Italian, Spanish
Concept Phase Completed
Requirements Phase Completed
Initial Game Plan Completed
First Playable
Alpha
Code Freeze
Beta
Pre-Cert Submission to Microsoft
Code Release Candidate
Certification Submission to Microsoft
Concept Approval
Requirements Approval
Game Plan Approval
License Approval
Console Manufacturer Approval
Deliverables Completed for Concept Phase
Deliverables Completed for Requirements Phase
Detailed Documentation Completed for Game Features
Character and Story Documents Completed
Voiceover Scripts Completed
Mission and Scenarios Designed
Mission Prototypes Scripted
Playtesting
Final Missions Scripted
Deliverables Completed for Concept Phase
Deliverables Completed for Requirements Phase
Prototypes Completed
First Playable Level Completed
Special Effects Completed
UI Completed
Cinematics Completed
Production
Approvals
Design
Art
GAME PLAN 267
ship at Christmas. So the overall goal of the game plan is to adjust the other
project factors (resources, features, and quality) in order to hit the ship date.
From this submission date, you can determine a general timeframe for the first
playable, alpha, code freeze, beta, and code release candidate dates, which can
help you better gauge the work to be completed for each milestone.
Although the initial production schedules provide a good guideline for the
overall development process, a more detailed schedule must be created as infor-
mation is confirmed. This detailed schedule contains subtasks for all the main
FIGURE 16.2 Sample of initial production schedule.
Final Movie Ready for Game
Marketing
Demo Build
E3 Build
Preview Code for Journalists
Review Code for Journalists
Sound Designs Completed
Sound Prototypes Complete
Placeholder VO Recorded
Final VO Recorded
Final Music Implemented in Game
Determine Localization Needs
Organize Assets for Translation
Integrate Assets
Functionality Testing
Linguistic Testing
Test Plan Completed
First Playable Testing Completed
Alpha Testing Completed
Playtesting Completed
1st Code Release Candidate to QA
Code Release
Audio
Localization
QA
Cinematics (External Vendor)
Deliver Initial Specs to Vendor
Storyboard from Vendor
Animatic from Vendor
Rough Cut from Vendor
Final Movie from Vendor (no sound)
Movie to Sound Designer
Deliverables Completed for Concept Phase
Deliverables Completed for Requirements Phase
Art and Design Tools Completed
Production Pipeline Completed
Engineering Prototypes Completed
All Major Game Play Features Implemented
Code Freeze
Engineering
268 THE GAME PRODUCTION HANDBOOK, 2/E
tasks listed in the initial schedule. The exit criteria for detailed tasks are based on
deliverables from the concept and requirements phases:
■
Tiered master feature list
■
Milestone deliverable lists
■
Art documentation
■
Design documentation
■
Technical documentation
These deliverables include detailed information on how many levels, charac-
ters, and objects must be created, what engineering features will be coded, how
much voiceover needs to be recorded, and everything else about the project.
In order to best determine all the little things to do, it is helpful to break down
these large deliverables and tasks into smaller ones.
Work Breakdown Structure
Work Breakdown Structures (WBS) are useful for breaking down large tasks
into smaller ones. By breaking down a large task into specific, incremental tasks,
a master task list is created. The WBS process initially involves the producers
and leads, with input from the team as needed. Here is a sample WBS process
for determining what tasks are necessary to create a shippable level:
1. The producer and leads meet and define the specific tangible steps that
are needed to create a level and mission from start to finish. All depart-
ments are involved—production, art, design, engineering, and QA.
2. During the meeting, the group brainstorms about every possible task to
be completed for a level. Describe tasks in the present tense, with an ac-
tive verb. For example, “design initial level layout.” This helps the group
determine the tangible tasks to be done.
3. The tasks are grouped together by department and then placed in rough
chronological order.
4. Durations are set for each task by the appropriate lead. (Art lead pro-
vides art estimates, and so on.)
Figure 16.3 is an example of a WBS to create one shippable level for Justice Unit.
Detailed Schedule
When the WBS is completed, have the team double-check it to ensure that no
tasks were forgotten. This task list is then added to the project schedule; de-
pendencies are added; and the actual team members are assigned their tasks.
They must assess the original duration estimated by the lead. Each task should
be no more than three–five days in duration. Ideally, each task takes one to
two days. If the task owner agrees with this estimate, the number stays as is.
If the task owner disagrees with the estimate, he provides an updated estimate,
GAME PLAN 269
Art Tasks (Villain's Lair) Duration
Create prototype 5 days
Implement prototype feedback 1 day
Create level geometry 20 days
Add placeholder textures 3 days
Fix first round of bugs 3 days
Create destructible objects 2 days
Add final textures 10 days
Create player reference map .5 days
Create special effects 2 day
Optimize level for budget constraints 5 days
Polish map 5 days
Fix final round of bugs 3 days
Design Tasks (Villain's Lair) Duration
Design initial level layout 2 days
Design initial mission scripting 2 days
Script prototype .5 days
Playtest prototype scripting .5 days
Implement prototype feedback 1 day
Script first pass of mission scripting 5 days
Script first pass of multiplayer scripting 2 days
Review scripting 1 days
Script second pass 5 days
Verify all supporting files are tagged correctly 1 day
Create localization tags for in-game dialog 1 day
Polish scripting 3 days
Fix final round of bugs 2 days
Sound Tasks (Villain's Lair) Duration
Create sound design 3 days
Implement sound design prototype 2 days
Implement prototype feedback 2 days
Complete first pass of sound implementation 3 days
Polish sound 2 days
Fix final round of bugs 1 day
QA Tasks (Villain's Lair) Duration
Playtest prototype 1 day
Test geometry and terrain navigation 7 days
Check textures 2 days
Test initial scripting 1 day
Test second pass scripting 1 day
Final test all level geometry and textures 5 days
Final test for mission scripting 1 day
Approvals (Villain's Lair) Duration
Approve initial layout 1 day
Approve initial art prototype 1 day
Approve initial design prototype 1 day
Approve sound design 1 day
Approve final level, scripting, and sound 1 day
FIGURE 16.3 WBS for completing Villain’s Lair level.
270 THE GAME PRODUCTION HANDBOOK, 2/E
which is added to the project schedule. This process gives team members more
ownership of their tasks, instead of feeling like they are just assigned an arbitrary
deadline that must be achieved no matter what.
If there is some difficulty in determining how long a task will take, the lead
should make an educated estimate based on experience. Don’t leave the dura-
tion for any task blank, as this will not give a true picture of the overall schedule.
Accurately estimating tasks is very subjective and improves with experience. It is
good to build some extra time in the schedule to accommodate any work that
takes longer than originally estimated. Some people like to add this extra time on
a per-task basis, although this is not recommended as it does not give an accurate
picture of the overall schedule. However, adding some slack at the end of the
schedule provides a good padding for accommodating any task overruns.
One technique to use for estimating tasks is called time-boxing. A time-box
is a fixed period of time during which someone attempts to complete a well-de-
fined task. The task should have each of its requirements prioritized from highest
to lowest, so that that most critical work is completed first. To use this technique,
assign start and end dates to a given task, assign someone to work on it, and then
measure how much is completed in the allotted time. After the agreed-upon pe-
riod of time is over and the feature is not fully implemented, assess the work that
is completed and determine whether further work should be done, whether the
work done already is good enough, or whether the feature should be cut because
the effort already put into it indicates the feature will take too long to implement
in the given schedule. This method can help you maintain more control over the
schedule, instead of just letting a feature continually run over schedule.
For example, if the lead engineer makes an educated estimated of three
weeks to implement normal mapping into the graphics pipeline, check with the
engineer on a regular basis to check his progress. At the end of three weeks see
how much normal mapping functionality is implemented. At this point, the fea-
ture might be good enough to ship, or further work might be needed. If you are
going to have the engineer invest more time in the feature, determine a new set
of feature priorities and define a new time box.
When durations are assigned to the schedule, add in time for sick days,
holidays, and vacations. You can’t assume that everyone will be in the office
every single work day. Also, don’t schedule overtime. This is a bad practice and
will quickly cause you to have an unhappy and, therefore, unproductive team.
Instead, limit the scope of the project so that everything can be completed in a
reasonable amount of time. In fact, all the task durations should be based on ac-
complishing about five to six hours of work during a normal eight-hour work day.
The other two to three hours per day account for time people spend checking
email, going to meetings, and dealing with general nontask related work.
Keep in mind that task dependencies and assigned resources can dramati-
cally affect a schedule. For example, if it takes several days to get the prototype
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.