234 THE GAME PRODUCTION HANDBOOK, 2/E
that is refined in iterations, until it becomes a final working version that ships in
the game.
Other things to consider before beginning a prototype (especially a software
one), are the primary objectives and the target audience. For example, will the
prototype demonstrate a vertical slice of gameplay—which entails implementing
elements that provide a representative sample of the final gameplay experience.
This includes key gameplay mechanics with proper play balancing, polished art
assets (including UI, key character models, and a playable level), representa-
tive audio assets, and key demonstrations of technology innovations (for example
physics-based gameplay). A vertical prototype is strongly recommended when
shopping a game to a publisher.
Will the prototype be focused on a specific feature and only be viewed by
members of the development team? For example, is the lead engineer working
on a prototype of the new animation system in order to work out kinks in the en-
gineering and art pipeline? This type of prototype does not need the same level
of detail and polish, can be put together with placeholder assets, and can contain
functional issues that can be addressed later.
While the prototyping process can be roughly categorized into phases, these
phases may not have a distinct beginning and end, especially during iteration.
The process normally begins by defining what is being prototyped. Next, a low-
fidelity prototype is created, based on these initial requirements. The team will
iterate on this prototype. Iteration involves a cycle of specifying the require-
ments, designing something that meets these requirements, evaluating the re-
sults, and starting the cycle over again. There could be several iterations on a
single prototype; the amount is likely dependent on how much time there is in
the schedule.
Once the team is satisfied with the results, they may decide that the feature
or idea is not feasible and discard the prototype, or they may find a new idea they
want to prototype instead, or they may decide to move forward to the next phase
of creating a high-fidelity prototype. This prototype will also go through some
iterations until the team is happy with the results. Once this happens, the proto-
type specifications are frozen and a final version is built on these specifications.
Prototyping can occur at any phase in the development cycle, and the team
should plan to prototype as much as possible. Tight schedules and deadlines may
prohibit much prototyping towards the end of the production phase, so plan to
take advantage of the unscheduled blocks of time that occur in pre-production.
It is better to spend a day or two (or even a week) prototyping key features of
the game, than spending several weeks implementing a feature that ends up
not working as expected in the game. If this happens, there is little time left in
the development schedule to tweak or re-do the feature, and the game may end
up shipping with the feature as is. It is common to work on multiple prototypes
at once—some prototypes may be more complicated (such as a vertical game
GAME CONCEPT 235
slice), while others may be simpler. Don’t hold back from prototyping some-
thing, especially if there is time in the schedule. The prototyping phase is on-
going during pre-production and is headed up by the lead designer, or possibly
the producer.
CREATING PROTOTYPES
Tracy Fullerton
University of Southern California
One of the most important things a game prototype gives you is the ability to
understand the player’s experience immediately. A prototype also makes an idea
tangible and, therefore, creates something that is much easier for team members
to speak about and work on from their own perspective. People tend to butt their
heads together most when they are speaking in the abstract, so you will see design-
ers and programmers butting heads, and they might actually be saying the same
thing, but because they don’t have a prototype or something concrete to reference,
they don’t even realize it.
I am a strong believer in paper prototyping and don’t like students to write up
any game specifications until they have some form of prototype. From the moment
you come up with an idea, you can begin to model the core mechanics and the un-
derlying structures. Those early paper models—and you might have to build two or
three to understand all the systems—will be used to build digital prototypes. After
these are created, people can start defining specs.
Truly innovative design comes from asking wild and impertinent questions and
spending small amounts of time and money on proving whether these questions
will provide interesting and provocative answers. Paper prototyping is something a
dedicated designer can do on their own time. A designer can usually get complete
a prototype, enlist play testers, and make changes, all in a short amount of time.
It’s a fantastic experimental method for asking these kinds of interesting questions.
For example, right now I am working on a game where the central question we’re
trying to understand is “how can you make a game about the journey of spiritual
enlightenment?”
It is very important that the technology team be a part of the creative team;
but it is equally important that technology doesn’t drive the experience design. This
means the designer has to understand and respect the technical limits of the plat-
form with which they are working, but creatively they don’t have to live within those
limits the same way that technologists do. Designers need to understand the techni-
cal limitations well enough to work around them or to use them as a springboard
236 THE GAME PRODUCTION HANDBOOK, 2/E
for some type of creative twist that doesn’t restrict the game but actually makes the
game better. One of the best ways to do this is to have the technologists play the
paper prototypes. Again, when the idea is tangible, people can talk about it, and out
of the discussion comes the true essence of what the designer was trying to do with
that feature or technique. This means the technologists don’t have to just blindly
implement the feature; they are actually part of the process of discovering what the
feature is really about. Being part of the process makes it easier for the technologists
to implement the essence of the feature.
14.5 RISK ANALYSIS
Risk assessment is an ongoing process, and the producer must be constantly
aware of what the biggest risks are for the game, even after production begins.
Doing an initial risk assessment in pre-production, involving all the project stake-
holders, is a good way to identify and start preparing for risks.
Risks are things that could go wrong on a project, such as a key team mem-
ber leaving mid-project, not getting the graphics pipeline completed in time to
begin production, or an external vendor missing his final deliverable date. When
the risks are identified, prioritize them and plan mitigation strategies. Keep in
mind that all risks are not equal. Although some risks might have a higher prob-
ability of occurring, the impact may not be as severe as a risk that has a low prob-
ability of occurring.
Steve McConnell’s book, Rapid Development, contains an excellent chapter
on risk management and is recommended reading for anyone who wants to learn
more about this. As he points out in his book, a project utilizing risk management
is not as exciting to work on because there is little need for people to run around
putting out fires. Instead, everyone can focus on getting the game done, because
risks have already been identified and planned for in the schedule.
His approach is divided into two parts: risk assessment and risk control.
During risk assessment, the core team needs to do the following:
■
Identify risks that could impact the project.
■
Analyze each risk’s likelihood of occurring and the impact it has on the
project.
■
Prioritize each risk beginning with the ones with the most impact.
There are numerous potential risks on any given game that can affect the
ship date, the quality of work, the scope of features, and the cost. When doing
the risk assessment, brainstorm as many risks as possible and then prioritize
GAME CONCEPT 237
them accordingly. Your biggest risks are the ones that have a high probability of
occurring and will have the biggest impact on the project. Figure 14.3 is a basic
classification grid for four levels of risk. More risks levels can be added as ap-
propriate for your project. Risks that fall into categories 1 and 2 are considered
critical risks and must have solutions in place to manage them if they occur.
FIGURE 14.3 Risk classification grid.
The second part of McConnell’s risk management strategy involves risk
control. After the risks are identified and prioritized, the team needs to do the
following:
■
Create a management plan for neutralizing or removing the most critical
risks. Make sure the plans for each risk are consistent with the overall project
plan.
■
Implement the proposed plans to resolve the risks.
■
Monitor the progress toward resolving the known risks.
In addition, any new risks must be identified and controlled throughout de-
velopment by using the same process of risk assessment and risk control dis-
cussed previously.
Risk management is the responsibility of everyone on the team, although the
producer should spearhead the effort to identify risks and solutions. The initial
238 THE GAME PRODUCTION HANDBOOK, 2/E
in-depth risk assessment meeting should happen after some of the major game
elements have been defined. This way, there is a better idea of what elements
are risky. Spend one day defining the risks with the team, one or two days creat-
ing a risks resolution plan, and then publish this plan to the team. Figure 14.4 is
an example of a risk analysis spreadsheet.
FIGURE 14.4 Risk analysis spreadsheet.
Risk
Probability
of
Occurring
Impact
on
Project
Risk
Classification
Mitigation Strategies
Licensor who own
Justice Unit
IP may
not deliver feedback and approvals in a
timely fashion. If they don't approve
content of gold master, console
submission process will be delayed,
which may impact the ship date.
HIGH HIGH 1
*Schedule kick-off meeting with licensor early in pre-
production to review the project goals and schedule
constraints.
*Work out defined approval process that both parties
agree to.
*Deliver game assets on a regular basis in pre-
production to get feedback and approval before
production begins.
*Once playable builds are available, deliver builds on a
regular basis for licensor to review.
*If possible, include caveat in contract that if they don't
respond with written feedback in 10 days, the item will
be considered approved.
*Establish good working relationship with licensor
contact and try to include them in the development
process whenever possible - make them feel like they
are part of the team and have ownership in the game.
Design might be able to create a
workable gameplay system where the
superhero powers are balanced equally
against each other.
LOW HIGH 2
*Focus on prototyping the core superhero powers for
each character to limit the number of variables that
must be balanced.
*Work with engineering to get a digital prototype up and
running as quickly as possible.
*Create a system that allows variables to be easily
changed and tested in gameplay.
*Continue brainstorming ideas for superpowers until
the core features are prototyped and approved.
During the 2 year development cycle
some employees may leave the
company.
HIGH LOW 3
*Train at least 2 people to handle specific tasks on the
project.
*Schedule time for hiring and training new people mid-
project.
*Focus on creating a positive working environment to
increase employee retention.
*Be aware of any sudden changes in employee's work
habits so you can identify at risk people and improve
their job satisfaction before they start looking
elsewhere.
*Require everyone to document the work they are doing
and to check all assets into source control system at
the end of each day.
Initial game concept art may not
accurately depict what the
Justice Unit
characters will look like in the game.
LOW LOW 4
*Concept art will be based on character design bible
provided by the licensor
*Feedback from licensor can be quickly implemented
until they are satisfied with the concept drawings.
*Make sure the artists get all available character
concept art from the movie.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.