8 THE GAME PRODUCTION HANDBOOK, 2/E
While the feature set is being defined, technology is researched to figure out
what works best for the proposed game. This includes looking at the hardware
constraints, exploring middleware solutions, and evaluating any suitable internal
technologies. In addition, thought must be given to what tools are needed to cre-
ate the game assets and the best way to establish a production pipeline.
As all of these elements become more defined, the team must create some
basic technical and design documentation focusing on the core aspects of the
game. As illustrated in Figure 1.2, games can be comprised of several produc-
tion cycles, so this documentation must focus on fleshing out the current pro-
duction cycle. The documentation details are added to the core features as
pre-production continues, so that by the time production begins, everyone has
the information they need to begin their work. Finally, conduct a risk analysis at
this stage to determine the game’s biggest risks so far.
When the game requirements are determined, all the decision-makers in the
process should review and sign-off on them. This includes studio management,
the publisher, and even marketing. Along with the development team, these
groups also have a stake in the project and want to make sure that their best
interests are considered during the requirements phase. As people review the
documentation, they will have feedback that will likely affect the constraints. It is
a good idea to centralize all the feedback, determine what can be incorporated,
and then send the revised plan for everyone to review again.
It may be difficult to get everyone on board with the requirements, espe-
cially if the groups are at different geographical locations. In cases like this, the
producer will want to schedule a time and place where everyone can meet to-
gether (either in person or via conference call) to come to a consensus and final-
ize the requirements. Please refer to Chapter 15, “Game Requirements,” for
more information.
Game Plan
The game plan is where all of the information is pulled together to show how
everything will be accomplished. The producer spearheads the effort to prepare
the budget, schedule, and staffing needs for the game, but he must work with
the team to determine them. If the producer does not consult with the core
development team, especially when it comes to schedule and staffing, it will be
hard to get the team members to buy into the game plan. This is especially true
if the schedule is extremely aggressive and the producer is counting on everyone
to work at their highest level of productivity. Refer to Chapter 16, “Game Plan,”
for details on creating budgets, schedules, and staffing plans.
When the budget, schedule, and staffing plan are assembled, the team re-
views them to make sure they can achieve the desired game requirements. If
not, the plan or the game requirements might need to be amended. In fact,
GAME PRODUCTION OVERVIEW 9
the game requirements and game plan are both updated whenever something
changes on the project. Don’t forget to conduct another risk analysis and have all
the stakeholders review the plan as well.
Pre-Production Checklist
Figure 1.3 is a pre-production checklist you can use to track your progress during
this phase.
PRE-PRODUCTION CHECKLIST Y / N NOTES
CONCEPT
Is initial game concept defined?
Are platform and genre specified?
Is mission statement completed?
Are basic game play elements defined?
Is prototype completed?
Is risk analysis completed?
Is the concept pitch ready for approval?
Have all stakeholders approved the concept?
Is project kick-off scheduled?
GAME REQUIREMENTS
Are "must have," "want to have," and "nice to have" features defined?
Are constraints defined and accounted for in feature sets?
Are milestones and deliverables defined?
Has technology been evaluated against the desired feature set?
Are tools and pipeline defined?
Is basic design documentation completed?
Is basic technical documentation completed?
Is risk analysis completed?
Have all stakeholders approved the game requirements?
GAME PLAN
Is budget completed?
Is initial schedule completed?
Is initial staffing plan completed?
Have core team members approved the schedule and staffing plan?
Have all stakeholders approved the game plan?
O
N
T
H
E
C
D
FIGURE 1.3 Pre-production checklist.
1.4 PRODUCTION
The production phase is when the team can actually begin producing assets and
code for the game. In most cases, the line between pre-production and produc-
tion is fuzzy, as you will be able to start production on some features while some
features will still be in pre-production. This start of the production phase is also
affected by any checks and balances that the publisher or studio management
has in place. For example, the team might be unable to begin full production
until a playable prototype has been created and approved.
10 THE GAME PRODUCTION HANDBOOK, 2/E
If everything is planned for during pre-production, the production phase
should have no surprises; of course, this is rarely the case. After your team has
started full production, there is a high chance that some feature or asset will need
to be added, changed, or removed. However, if you have a tiered implementa-
tion strategy that focuses on getting the core features and assets completed first,
it is easier to plan for unexpected changes.
The production phase is focused on content and code creation, tracking
progress, and completing tasks. In addition, risk assessment is ongoing during
production, so you are prepared for any unexpected events that negatively im-
pact the game’s production cycle. Production is loosely categorized into the fol-
lowing phases: plan implementation, tracking progress, and task completion.
Plan Implementation
Plan implementation requires the producer to communicate the final plan to
the team and provide them all the tools and resources needed to implement it.
Make the plan publicly available to the team in a format that is easily accessible,
such as a team website or designated area on the network. Include all the docu-
ments created in the pre-production phase, with the schedule and milestones
in a clearly visible place. It is also helpful to post hard copies of key deadlines
throughout the team rooms.
When the plan is communicated to the team, the producer must be vigilant
about keeping everything in the plan up to date. If a feature design, milestone
deadline, or asset list changes, it must be accurately noted in the game plan
and communicated to the team, studio management, and possibly the publisher.
Making these changes in a timely manner is important, because everyone is
using the project plan as the main point of reference. If the plan is not updated
throughout the production process, it is likely that features will be overlooked, or
the wrong features will be implemented.
Feature creep, when features are continually added to the project during
the actual production phase, often occurs during production because things are
changing on a regular basis. Someone will think of a great idea for the game and
will want to add it to the feature set without thinking of the impact this will have
on the game’s schedule or resources. Feature creep is not good for the project
as a whole because every time a new feature is added, more resources must be
allocated to design it, implement it, create assets for it, and test it. This means
that the resources already in use will be stretched to the limit and adding extra
features may cause the game to miss an all important code release deadline. If
feature creep is not controlled during production, the game will quickly run out
of time and resources. Of course, this can be avoided if you keep a tight control on
feature creep. Chapter 18, “Production Techniques,” has more information on
how to control feature creep.
GAME PRODUCTION OVERVIEW 11
After the game plan is implemented, art, design, engineering, and testing
are even more dependent on each other for completing tasks. If the artists are
waiting on design for the details of a specific level design, they may be in a hold-
ing pattern if this documentation is not ready. If the cinematics team is waiting
for final voiceover files from the sound engineer, it will delay their work and put
the final deadline for the cinematics at risk. As the producer, you are responsible
for working with your leads to quickly resolve any task dependencies. In some
situations, the cinematics team might be able to do other work while waiting for
the voiceover files, and so on. Tracking progress helps the producer, and leads
identify bottlenecks in the production process.
Tracking Progress
Tracking progress against the game plan is critical to knowing where the game
is at any given time in production. If you don’t have a plan to track against, your
game will quickly get out of control, and you will find yourself in an unpleasant
situation. If you, as the producer, don’t know how much longer it takes to com-
plete a feature, or how much of the feature is already completed, how can you
know whether the game development team is on track to meet their deadlines?
Progress tracking does not have to be complicated. In fact, the more com-
plicated it is, the more unlikely people will do it. For example, you might decide
to track the progress in Microsoft Project, and if you are an expert in using this
software, it will be very easy for you. However, if you don’t know how to use the
tracking features in Microsoft Project, you might avoid tracking the progress
altogether. In any case, you must implement a method that will work for you
and the team, as they also need to be aware of what progress has been made.
One simple way to do this is to create checklists or to track tasks in Microsoft
Excel. Chapter 16, “Game Plan,” has more details on how to track tasks during
production.
Task Completion
Task completion in most areas of game development is fairly straightforward,
especially when the work results in a tangible asset, as with art and design assets.
Determining when engineering tasks are completed is difficult, since there are
no hard indicators regarding when a piece of code is complete, especially when
bug fixes can always be made to the code.
Defining exit criteria is a good way for a producer or lead to more accurately
determine when a task is complete. Exit criteria are conditions that must be met
before a task is deemed finished. For example, a design document is complete
after it is written and approved; a character model is complete after the artist
adds the final texture to it.
12 THE GAME PRODUCTION HANDBOOK, 2/E
The exit criteria must be easily understood by everyone, especially the per-
son who is actually doing the task. For a task that is difficult to define criteria for,
the producer can meet with the appropriate team member and lead so everyone
agrees on the exit criteria. If you are an independent developer working for a
publisher, the exit criteria for the major milestone deliverables must be clearly
spelled out in the publisher-developer agreement.
Production Checklist
Figure 1.4 is a production checklist you can use to track your progress through
the production phase.
PRODUCTION CHECKLIST Y / N NOTES
PLAN IMPLEMENTATION
Is game plan clearly communicated to team?
Is game plan in publically accessible place?
Can plan be easily updated with changes by producer?
Does everyone on team have the necessary resources to do their work?
Is process in place for controlling feature creep?
Is risk assessment happening on a regular basis throughout production?
Is process in place for managing task dependencies?
PROGRESS TRACKING
Is there a game plan to track progress against?
Is process in place for producer to track all task progress?
Is progress posted in visible areas in the team rooms?
TASK COMPLETION
Does each task have clearly defined exit criteria?
Are these exit criteria publicly available to the team?
Are all stakeholders in agreement on what the exit criteria are?
FIGURE 1.4 Production checklist.
O
N
T
H
E
C
D
1.5 TESTING
Testing is a critical phase in game development. This is when the game gets
checked to ensure that everything works correctly and that there are no crash
bugs. Testing is on-going during the production process, as the Quality Assurance
(QA) department will check milestone builds, new functionality, and new assets
as they become available in the game. After beta, when all the game assets and
features are fully implemented, the main focus of the development team will
be fixing bugs and creating new builds for QA to test. The testing phase can be
considered as two parts: plan validation and code release. Chapter 22, “Testing,”
contains more detailed information on the testing process.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.