276 THE GAME PRODUCTION HANDBOOK, 2/E
One way to track tasks for simpler or more straightforward schedules is to
print it out and post it in the team rooms. As tasks are completed, they are
highlighted on the schedule; when the schedule is colored in, the project is com-
pleted. This is a strong visual aid to the team of their progress and can be a mo-
tivator to get all the tasks colored in a quickly as possible.
Figure 16.8 is an example of a spreadsheet that tracks the progress of the
levels produced for the game. This spreadsheet is a distilled version of the infor-
mation contained in the production schedule. It only presents the key deadlines
for completing a map, as opposed to the detail of a typical development sched-
ule, and can be quickly looked at to determine the progress. As a milestone is
completed, the cell is shaded in. Again, this is a strong visual cue of the progress
being made. So even if no one bothers to read the actual dates, they can tell at a
glance how much work is completed on each level.
If someone is falling behind on his work for a critical milestone, they need
to inform the person tracking the schedule as soon as possible. Most people are
aware of when they are behind schedule, but they always think they can catch
up to meet a milestone. Although this might be the case in some instances, it is
still important to know about any delays ahead of time so contingencies can be
prepared. Some delays are critical, meaning the large parts of the development
process comes to a standstill. For example, if the scripting tool is not completed
by the time the designers need to start scripting the levels, the scripting is on
hold until the tool is finished. This puts the design schedule at risk, and it needs
to be adjusted to accommodate this delay. In other instances, the delay is less
critical; the final art textures for a character model are delayed by a few days.
If you are aware of delays ahead of time, you can have a better chance of
coming up with a contingency plan that mitigates the schedule risk. For exam-
ple, a milestone is coming up, and the game is expected to be feature complete
with placeholder content. You find out a week ahead of time that Artist A thinks
he might not get his level completed. Since you know ahead of time, you can
assign an extra resource to help him get back on track or alter the testing sched-
ule so this map will be checked last in the testing cycle, buying the few extras
days that are needed to complete the level. Refer to Chapter 18, “Production
Techniques,” for more information on how to handle schedule delays.
FIGURE 16.8 Example of a level production spreadsheet.
O
N
T
H
E
C
D
Level Name Artist Scripter
Geometry
Complete
Art
Lockdown
Design
Lockdown
Sound
Lockdown
QA Status Notes
Justice Hall John Doe Jane Doe 1-Oct 15-Nov 22-Nov 22-Nov Playtesting completed
Villain's Lair Bob Smith Betty Smith 7-Oct 15-Nov 22-Nov 22-Nov To be playtested Oct 15
Original geometry complete date Oct 1, pushed to
Oct 7 because artist was sick for a few days.
LAST UPDATED: Oct 7, 2007
GAME PLAN 277
One thing is for certain—the schedule will not track itself. Someone will
have to follow up with each team member on a regular basis and keep the sched-
ule updated with everyone’s work. Schedule changes must also be added to the
schedule right away; otherwise, the person tracking the schedule will not have an
accurate picture of where people are expected to be with their tasks.
The person in charge of tracking the schedule can make the job easier by
communicating upcoming deadlines to the team. For example, emails can be
sent to remind the team of critical milestones on the project. Keep the emails
short and simple. This person should also follow up with each team member on
a regular basis (at least once a week) to check progress. If someone is routinely
missing deadlines, the schedule tracker should check in with this person on a
daily basis and assist him in organizing his work so he can learn to better manage
his time.
SCHEDULING FOR MULTIPLE PLATFORMS
Stuart Roch, Executive Producer
Activision
In my experience the best way to handle multiplatform releases is to
have 95 percent of the team focused on your lead platform with the re-
maining 5 percent trailing a couple steps behind the core team working on
platform-specific issues. The mistake many developers make is not assign-
ing development talent to the specific platforms, in hopes that some of the
superstars on the team can pick up the slack. In practice, this never works
out since your superstars are inevitably overloaded, and the secondary plat-
forms get less attention than your lead platform. If you can be sure to de-
vote specific team members to the secondary platforms, they’ll champion
their assigned platform and give it the love it needs.
Another aspect of a multiplatform release that is often overlooked is
investing in a tool chain that supports all of the platforms under develop-
ment. For example, if you can set up art tools that allow the artists to work
at the maximum level of detail supported by your most powerful console
platform and then have the tools automatically make adjustments to the art
assets to accommodate your weakest platform, you reduce a lot of special
case work. A little preplanning can go a long way in reducing the pain of a
multiplatform release late in your development cycle.
278 THE GAME PRODUCTION HANDBOOK, 2/E
16.4 BUDGETS
After the initial schedule is created, you can start creating the budget. The
budget must be within reason for the quality, scope, and schedule, so that the
game will make a profit when it is released. The publisher also watches the
bottom line closely to ensure that development costs are justified and that they
have made a profitable investment in your game. Ultimately, the producer is
responsible for managing the costs. If the game development is poorly planned,
it will require more time or more personnel, and thus cost more money, result-
ing in lower profit margins. If the game development is efficiently planned, it
is easier to identify areas where there is cost-saving potential.
To determine the likely profitability of the game, the publisher creates a
profit-and-loss statement (P&L). A P&L, which measures the overall profit and
loss of a game, is a spreadsheet that compares the development, marketing,
packaging, and distribution costs for the game against the projected sales. If the
projected sales numbers increase, the better chance there is of making a profit.
For example, if it is determined that 20,000 copies can be sold, the budget will
be smaller than for a game that is predicted to sell 500,000 copies. The P&L is
used to run different profitability scenarios to determine a reasonable balance
between costs and potential profits.
Because the schedule, budget, and staffing plan are dependent on each
other, the budget can change markedly depending on what your schedule and
staffing plans are. Therefore, when you create an initial budget, be prepared to
make adjustments to it and the other elements as necessary. After the budget
is established and approved, manage the cost closely so you don’t find yourself
grossly over budget.
There will be instances when unexpected costs arise—for example, you need
to buy three new computers and three copies of 3DS Max—so don’t panic when
this happens. You might be able to reallocate some money in the budget for
these items without increasing your overall budget. If that doesn’t work, you
might be able to reallocate actual computers from another project in the studio
and use them temporarily. Just remember to be as cost conscious as possible
when these things happen.
Creating a Budget
Budgets consist of all the costs associated with the project, including personnel,
overhead (rent, utilities, and taxes), hardware, and software. Determine all of
these costs up front so there are no surprises during the development process.
When creating the budget, refer to the game requirements and schedule
to determine what costs to plan for. These documents provide guidance on
GAME PLAN 279
how much you need to spend on certain areas of the game. Don’t automatically
assume that the cheapest item is the best solution, as this will ultimately affect
the quality of the game. For instance, if the game needs to be completed in one
year and be top-quality, you probably don’t want to cut corners on the personnel
and hire entry-level people. You probably want to spend money on more expe-
rienced people who can work effectively within the tight schedule. However,
if you have several years to complete a game, you might want to hire some entry-
level people and train them on the job so they can be experienced people for the
next project.
These types of decisions are best made by taking all of the game elements
into account. By this point, the major goals of the game are approved and the
requirements are defined, so you have a good idea of whether the game is a
budget title or a AAA one. Additionally, the game requirements indicate which
technology is being used, so you have an idea of what the hardware and software
needs are. The schedule defines how much time you have and how many people
you need. Of course, each project will have a different budget dependent on
the game requirements, but there are general things to be planned for in each
budget.
Start by creating a list of all the major line items that must be accounted for
in the budget—this includes both personnel and other major costs. Figure 16.9
lists some of these line items.
FIGURE 16.9 Major budget line items.
Personnel Costs
Art Personnel
Design Personnel
Engineering Personnel
Production Personnel
QA Personnel
Audio Personnel
Other Major Costs
Hardware
Software
IP Licensing Fees
External Vendors
Food
Shipping
Office Supplies
Overhead (HR benefits, insurance, office space, etc.)
O
N
T
H
E
C
D
280 THE GAME PRODUCTION HANDBOOK, 2/E
Next, just as you did with the major tasks in the schedule, break them down
into smaller line items. Use the information on the schedule to determine all the
personnel needs and the information from the requirements to determine all the
hardware and software needs. Figure 16.10 is an example of the personnel costs
broken down into smaller line items.
After determining all of the line items, create your budget. Figure 16.11 is a
sample budget for the personnel costs on a project. In this example, the number
of each type of personnel is indicated in the “Number” column, which is then
multiplied by the “Monthly Rate” and “Number of Months” needed on a project.
All of these costs are added for the grand total.
Art Personnel
Art Director
Lead Artist
Concept Artist
World Builder
Asset Artist
Animator
Technical Artist
Marketing Artist
Design Personnel
Creative Director
Lead Designer
Designer
Writer
Engineering Personnel
Technical Director
Lead Engineer
Networking Engineer
Sound Engineer
Tools Engineer
AI Engineer
Gameplay Engineer
Production Personnel
Executive Producer
Producer
Associate Producer
QA Personnel
Lead QA Analyst
Tester
FIGURE 16.10 Breakdown of personnel costs.
O
N
T
H
E
C
D
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.