GAME REQUIREMENTS 251
CREATING THE PIPELINE
Carey Chico, Art Director
Pandemic Studios
One of the necessities of game development is a solid tools strategy. You must
have a core group of engineers who are dedicated to tools programming on your
team. They can enhance the proprietary tools that are part of your pipeline by
upgrading features, fixing bugs, and adding new features based on the game devel-
opment needs.
This is important because much of what we battle during game development is
tools not working or being too slow. Because efficient game production depends on
creating assets quickly, the developers are constantly thinking of ways to use tools to
speed up the asset production pipeline—especially if the same type of asset is being
created over and over. The longer it takes an artist to get an asset from source art to
an asset that can be seen in game, the less they want to deal with the process, and
the lower the quality.
The art director and technical director can work together to create an efficient
production pipeline for the art assets. There are several things to consider when
defining how the pipeline should work. For one thing, make sure that the pipeline is
not bottlenecked by a single component in the process. For example, if the process
is heavily dependent on 3DSMax, the pipeline is frontloaded for art, and everyone
will have to go through an artist to see something working in the game. All pertinent
people on the team must be able to access, manipulate, modify, and change the
content in the game simultaneously or equally. This spreads development risk and
provides multiple pipelines to complete the job.
The number of steps in the pipeline should be as few and bug-free as pos-
sible. Don’t have nontechnical artists doing lots of technical things in the pipeline in
order to get their assets working in the game. The artists are likely to make mistakes
and will need to go back and re-do the assets. This slows them down. The pipeline
should be focused on speeding up the development environment.
Make sure that the data going through the pipeline is manageable in a fast and
efficient way. If the pipeline begins with a nodule of data that has information added
to it as it progresses in the pipeline, figure out how mistakes can be corrected along
the way, instead of having to start the process from scratch. It also helps to limit the
tools used in the pipeline. For instance, don’t mix 3DSMax and Maya, pick one.
Additionally, keep the number of data conversions to a minimum.
Another key thing is a two-way pipeline. Anyone should be able to easily con-
vert from one set of data to another. For example, if an artist needs to create a
cinematic of two people walking around in a scene, he exports all the necessary
252 THE GAME PRODUCTION HANDBOOK, 2/E
15.6 DOCUMENTATION
As pre-production comes to a close, documentation must be completed for all
major elements of the game. This includes art, design, and technical documenta-
tion. If the documentation is not clearly written or doesn’t provide the desired
information to the target audience, people might not read it. If this happens on
your project, it is your responsibility as the producer to work with the documen-
tation writers to create something that is useful for the team. If the team is not
reading the documents because of some other reason—they don’t have time, or
they think they already understand how a feature works—you need to set aside a
time for everyone to meet and read through the documentation together.
Each development team will have a different format for design, art, and
technical documentation. The key is to have a format that is easy to read and
provides clear information about how the game works. There are several books
on game design that discuss how to format design documents in detail. These
same lessons can be carried over to art and technical documents. Game Design
Workshop: Designing, Prototyping, and Playtesting Games by Tracy Fullerton,
Chris Swain, and Steve Hoffman is a good resource to consult about writing ef-
fective documentation.
Consider having different document formats for different audiences. The
documentation needed by the development team must include all the details of
each gameplay feature. The idea is that any member of the development team
can consult the documentation for clear directions on how a feature is supposed
to work in the game. The design documentation is the definitive resource for any
game design questions, so if a feature design changes, update the documentation
to reflect this. Documentation for studio management should focus on the over-
all gameplay mechanics, key features, and how these all fit together to provide
the overall gameplay experience to the player.
art assets into AfterEffects, creates the scene, and then re-exports this back into
the game.
Finally, automate communication of when steps are completed in the pipe-
line. It might seem very simple to remember to tell the person waiting on your
data that you are finished with it and they can start working on it. However, com-
munication will break down because people are not effective at maintaining it.
People get busy and completely forget that someone else is waiting to be told
the asset is ready for them. Therefore, the more ways this communication can be
automated, the more efficient the pipeline is. If an artist checks something into
SourceSafe, an email can automatically be sent to the appropriate person that
states what was completed.
GAME REQUIREMENTS 253
Even if the feature has a working prototype, some type of documentation is
needed as a written record of how the feature works. For one thing, not everyone
will have access to the prototype or be able to get it working correctly, and if
there is documentation, they can read through it to understand how the fea-
ture works. Additionally, the QA department usually uses design documentation
when writing the test plan. For example, if an artist creates a working prototype
of the game’s UI shell and does not document the functionality, it will be diffi-
cult for QA to write an accurate test plan to check that all the buttons, boxes, and
screens are working correctly in the game. You cannot expect QA to load up the
UI prototype on a computer and then play through the game and compare the
actual game UI screens with the screens in the prototype. This creates additional
work for them, work that they don’t really have time for; they might miss a large
chunk of functionality if they forget to click on a button.
Design
The design documentation details how all the features will function in the game
including the following:
■
UI
■
Multiplayer
■
Character backgrounds and dialogue
■
Scoring
■
Mission designs
■
Control scheme
■
Player actions
■
Storyline
■
AI
■
Weapons, special objects, power-ups
■
Voice recognition
The documents need to provide enough detail that an engineer, artist, QA
tester, or another designer can read them and understand how to implement the
feature as designed. After the feature is implemented according to the specs in
the documentation, it can be play tested and adjusted as necessary. The docu-
mentation must be updated with any changes, as it is the central written resource
for the game design.
It is useful to create a comprehensive list of all the documentation and proto-
types that must be generated for the game. This list can be used as the basis for
the design tasks for the production schedule. Please refer to Chapter 16, “Game
Plan,” for more information on creating a schedule.
254 THE GAME PRODUCTION HANDBOOK, 2/E
Art
Art documentation is also necessary during pre-production. The types of art doc-
umentation created by the lead artist and/or art director are as follows:
■
Style guide
■
Asset list
■
Tools instructions
The style guide details the look and feel of the universe, the objects, and
characters that are portrayed in the game. It includes concept art, color palettes,
and other visual examples of what the finished game will look like.
The asset list is a comprehensive list of every art asset that must be created
for the game. This includes character models, levels, cinematics, textures, and
any other visual elements in the game. As with features, prioritizing the art assets
into three tiers ensures that the most critical art assets are completed first, and
then additional assets are added as time allows. The art asset list can also be used
as the basis for the art production schedule.
Tool instructions are technical documents that provide information on how
to use the art tools in the production pipeline, such as the lighting tool, the
WRITING DESIGN DOCUMENTS
Clint Hocking, Creative Director
Ubisoft
The best practice for writing useful design documents is to keep them short,
precise, and technical; like this sentence. Additionally, all design documentation
should follow the exact same standards and formats. This should be rigidly enforced.
There is a time and place for your artists and designers to be creative—within docu-
mentation is not one of those places. You have a cover page, a table of contents, and
three double-spaced pages … every page beyond that halves the number of people
who will read the document. If people are not reading documentation, a producer
or associate should first enforce document formatting to make sure that the docu-
ments are short, precise, and technical. If they are, and documents are still not
being read, they should gather people together into meeting rooms and read the
documents out loud to them. They will learn to read them on their own very quickly.
Finally, as far as getting people to understand what’s in a document … if it is short,
precise, and technical, and it has been read, then the designer and the implementer
need to communicate. Simple as that.
GAME REQUIREMENTS 255
Technical
Technical documentation is written by the lead engineer and discusses things
such as the following:
■
Coding standards
■
Technical design
■
Tools instructions
CREATING ART DOCUMENTATION
Carey Chico, Art Director
Pandemic Studios
The pre-production phase is a time when everyone can discuss the game design
and artistic vision and make compromises—many ideas can be explored and con-
sidered for concept art and prototyping. There are also several art tasks that must
be completed before full asset production can begin. The core art team should be
comprised of an art director, concept artist, and asset artist. The goal is for the art
director to envision what the game will look like and then have the concept and asset
artists create different sets of assets to support the vision. From these assets, the
final look and feel can be determined, and work can begin on the art bible.
The art bible details concept art and other references for the art assets in the
game. It demonstrates to the team and the publisher what the game is going to look
like. While the art bible is being created, art assets can be prototyped, added to the
engine, and viewed in the game. This process allows the art director to get a clear
idea of what works and what doesn’t work in the game. A large part of creating this
bible is research; if the game is set in World War II, the art team will want to research
locations, weapons, uniforms, and anything else that will evoke that time period.
The art director works closely with the lead designer to determine how to de-
velop the art direction around the story content. The story content will have a direct
effect on what the art director’s final artistic vision of the game will be.
Also during pre-production, the art director works with the lead engineer on
what features are needed for the art asset production pipeline. This includes mak-
ing decisions on what shaders will be used, what the polygon limits are, what type of
environments the engine will support, and so on.
level-building tool, or cinematics conversion tool. This documentation should be
written in conjunction with the engineers who are programming the tools.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.