Tải bản đầy đủ - 0 (trang)
Chapter 7. Game Tools and Asset Management

Chapter 7. Game Tools and Asset Management

Tải bản đầy đủ - 0trang

commercial-release. To do this, a producer must ensure that there are flexible

procedures and encourage communication between the game's designers, the tools

programmers, and the artists.

During the pre-production phase, sit down with the designer and create a high-level

design for each feature set in the game (gameplay, weapons, units, character

interactions, movement, combat, and so on). Then identify the tools most commonly

needed for those feature sets. Then pair up a tools programmer with a

representative from the programming team responsible for tool programming to

ensure that the needs of the design team are clearly articulated. The tool should

have exactly the right features, no more and no less than what would make it

optimal for providing the right depth to the gameplay, with the ease of use to the

designer balanced against the development time. Then use the same procedure,

pairing up a technical artist and a tools programmer, to develop the required plugins

and add-ons for the art tools that are required to move the art assets into the game.

After that process is complete, run a few tests. Have an artist perform some tests on

the tools, exporting the art asset (a character or a unit) into the game engine.

Ensure that it works properly and efficiently. Check the exported asset for bugs and

document the process that was used to create the asset and then every step that

was required to get the art asset into the game. That is called the art pipeline

identification. After the art pipeline has been identified and documented, a producer

has a greater understanding of what steps are required to get an asset into the game

and how long it takes. From there, it generally involves some difficult math to do the

estimations on how many objects and art assets can be made over the course of a

development schedule. When this process is complete, you are able to determine

(roughly) how content heavy or light the design is. Then, you can move onto the

next steps and build a prototype.



Try to Get It Right the First Time

When building the prototype, it's extremely important to define the art pipeline as

soon as possible. For example, a team started working on a prototype for a game,

but started off with a badly defined pipeline. Hurrying through the development of

the prototype because of a short deadline caused other problems that cascaded

through their entire development cycle. Their level designer often had to do the

import/export process before getting the assets into the engine, artists were waiting

for assets to be approved before moving on, and they had problems with getting

their animations and rigs to work in the engine they were using. It was reminiscent

of rusty and worn-out clockwork gears being forced to work by physical force. All it

needed was some sharpening and a bit of oil. It didn't take long for the team to

realize how much time was being lost from not having a defined pipeline. They

customized the tools they were working with and spent two days polishing and

defining a working pipeline. From there, the development of the prototype was

smooth and they barely met the deadline.

The lesson learned was that it's better to spend the two days defining an effective

workflow and a pipeline so that everybody can do their work unhindered. The amount

of time each team member spends on trying to fix things one by one adds up to

days of work.

Note

A common scenario on game development projects with large teams comes

from a lack of communication. The designers often outline the best-case,

most-complicated feature they could possibly want—such as 200 futuristic



weapons with 1000 different weapons special effects, each for a special part of

the game. Players can even trade weapons, upgrade them, and their

effectiveness changes depending on the player's stats. Plus, this tool for

weapon customization needs to ship with the game so that the players can

use it as well. Then, the programmers go off to create this type of feature set

in the game's development. Only a few weeks later does it come out that this

type of design requirement might take a lot longer to develop as well as

increase the number of art assets required for the feature.

Finally, the producer realizes that this design element is going to take a lot

longer than expected and cost a lot of money. Does the game really need 200

different weapons and 1000 various special effects? Does the tool really need

to ship with the game? Does the design team actually need a special tool to

modify and create the best and baddest weapons the world has ever seen?

Well, probably not. The game will probably be just as fun with only 30

weapons instead of 200. Does the modability really add value to the game?

Will it actually sell more units? Maybe, but maybe not. Consider if it is worth

the risk of an added month or two of development time because the

programmers working on the tools are delaying working on the sound tool and

other asset integration tools, which can speed along the process of bringing

the game together.



Testing for the Tools You Need

As the project leads work on defining the game/art/tech design of the game, they

should also focus on how those designs will be implemented.

Many of the tools you will use can be bought commercially, whereas many of them

will need to be created by your programmers. Or, in a combination of the two, your

programmer could modify existing tools through the use of plug-ins. Both 3D Studio

Max and Maya support various plug-ins and have a highly modable architecture. Most

of the good commercial tools can be tested for an evaluation period. It's essential

you know your tool before deciding to use it on your game.

Use your team to test those tools well before making a decision. Building a prototype

might be the best way to do this. Use the development of the prototype to define the

pros and cons of tools. Document your needs and your successes well so your tech

team can start building the rest of the tools you need as soon as possible.

After the development is in full motion, it can be very costly to have subpar tools.

Designers need good world-building tools, audio designers need good tools to

implement their audio, and the pipeline for art needs to be smooth. A setback on any

of those can be extremely costly and might lead to an unmet milestone. Remember

that when developing a video game, it takes time to get the art assets into the game

world and running on the engine. The goal is to get that entire process—from

creation, to exporting, to integration into the game—to happen as quickly and

efficiently as possible. Game development projects often have thousands of art

assets that must all go through the same process; so, for example, if you can cut the

integration time for each asset from 15 minutes to 10 minutes with more than 3000

art assets that still need to go into the game, the added efficiency just saved more

than 15,000 minutes (or about 250 hours) of production time.

Much information is available from fellow development teams regarding how to

acquire the tools you need and which of those will serve your purpose best.



Create Use Cases

To define your software specifications, the design team should create frequent use

cases. Document every feature and every aspect needed to portray that feature. Be

very detailed in the use cases creation—the more detail, the better. Create diagrams

and documents for each feature. The designers and programmers then define the

specifications needed to make the game happen. It's very important to get this done

as soon as possible and be as detailed as possible. You want to create the tools you

need right at the start. You can then test and tweak those tools while producing the

prototype.



What Producers Need to Know about Tools

When it comes to selecting or creating tools for the development process, the

producer does not have to know every detail of each tool. The producer should

accept the guidance of his fellow professionals from each department. When

selecting game components and middleware, the programmers will know the nittygritty details of each solution. The producer only needs to know the basic function of

each program. Way too many programs and tools are available for the producer to

know the details of them all.

If you're working with a good team, rely upon the professionals. The audio

professionals know which audio tools to use, the programmers know the middleware

engines, and the artists know which art tools to look for. Instead of knowing all the

details about the tools, the producer should be working closely with the leads of each

department to establish a smooth pipeline for the tools that get selected.



Programming Tools

There are a lot of resources available to programmers. Here's a list of some of the

commonly available tools for programmers. Each section is divided into a "what the

producer needs to know" section, as well as a more detailed description of its use.



OpenGL ES—Khronos Group

OpenGL ES is one of the de facto graphic standards used today. Khronos Group

includes some tools that are useful in getting the most out of the technology.

What the producer needs to know

OpenGL ES is the standard 2-D/3D graphics API (Application Programming Interface)

for embedded systems.

More background

OpenGL has long been the industry-wide standard for high performance 2D/3D

graphics on devices ranging from mobile phones to PCs to supercomputers. OpenGL

ES is the version used for Embedded Systems (ES). Embedded systems are products

with microprocessor-based control systems. These systems are ranging from mobile

to automotive, communications, mil/aero, consumer, and even medical.

OpenGL ES provides a low-level API between software applications and hardware or

software graphics engines. This standard 3D graphics API for embedded systems

offers a variety of advanced 3D graphics and games across all major mobile and

embedded platforms.

OpenGL ES was awarded the Game Developers Magazine Front Line Award in 2003.



IncrediBuild—Xoreax Software

IncrediBuild is a powerful tool from the entrepreneurs at Xoreax Software in Israel.

What the producer needs to know

IncrediBuild is a development tool that dramatically speeds up Microsoft Visual C++

(6.0, 7.0, and 7.1) compilation and builds. This can decrease the time it takes to do

incremental builds. In crunch time, that's very important!

More background

Slow compilation time has always been one of the C++/C programming language's

weakest spots. Whether it's a few hours wait for a full product build, or 10 minutes

spent several times a day, waiting for an incremental build to finish on a developer

workstation leads to frustration, loss of productivity, and wasted time.

Now, for the first time, IncrediBuild offers a unique and effective solution. Through

the use of Xoreax's Distributed Compilation technology, the compilation speed of any

Visual Studio 6.0 or .NET project is boosted, without requiring any changes in the

code or project files. Through its seamless integration with the Visual Studio

development environment and a strong command-line interface, IncrediBuild makes

a natural enhancement to the Microsoft Visual C++ development environment.

In my experience, Incredibuild increased production efficiency significantly on several

projects. It allows the development team to create incremental builds for testing in

record time and with fewer errors in the autobuild process. Incredibuild's technical



support is also known for their responsiveness.



Microsoft Visual C++ IDE

Microsoft Visual C++ has been the backbone of commercial video game development

for many years.

What the producer needs to know

Microsoft Visual C++ IDE (Integrated Development Environment) is a standard IDE

for C/C++.

More background

The programming languages C and C++ are used for almost every commercially

successful game. The main reason for this is because they lend themselves well to

object-oriented programming (OOP). OOP works best for big programs and/or any

software built from a large amount of code. The reason for this is because OOP code

is extremely easy to organize and manage. It is not as fast as other programming

methods, so it's not as useful for smaller programs. But it is good for reusing code,

and any big software developer should always reuse code whenever possibe.

Out of the two languages, C++ lends itself better to OOP and is, therefore, used

more often in game development. One definition of an object in OOP is: "An object is

a software bundle of variables and related methods." This basically means that it's

like a real-world object except it has its state and all of its behaviors. Then, the

blueprint of the variables and related methods in the object are referred to as a

class.

A few IDEs for C++ are available. Microsoft Visual C++ IDE is one of the most

popular. This IDE has reached its seventh generation and has come a long way from

its first. Aside from it having all the compiling features you need, it now has many

methods to speed up the coding process and workflow greatly. If you want to code in

C++, a tool of this sort is a must-have.



Visual Assist X—Whole Tomato Software

Anything that helps speed up the coding process is a friend of the producer.

What the producer needs to know

Visual Assist .NET offers powerful editing features for Microsoft Visual Studio IDE that

speed up the coding process.

More background

Visual Assist is a Visual C++ plug-in that was developed to boost the productivity of

your C++ programmers using Microsoft Visual C++ IDE. Visual Assist introduces

powerful editing features that are completely integrated into the Microsoft

development environment. This plug-in was considered by many a "must-have" for

Visual C++ IDE versions 6.0 and lower. It is not as useful now because the features

of the plug-in have now been fully integrated into the IDE itself.

The most popular features of this plug-in are Enhanced List Boxes, which allow easy

access to member and completion list boxes while writing code, and a Suggestion

List, which offers good suggestions to the words you are typing. The Suggestion List

only needs one written letter to work—it then suggests a way to complete the word.

Enhanced Syntax Coloring makes the code easier to read and debug because of more



meaningful coloring. Goto allows you to move your caret to any symbol in your code

and press the Goto button to jump to the declaration or implementation of the

symbol. Underline Spelling Errors basically underlines incorrectly spelled words with a

squiggly line as you type. Auto Recovery frequently saves backup copies of the files

you modify. If the IDE crashes, this Visual Assist offers to use either the last backup

copy or the last manually saved file.

All the features of this plug-in are useful and increase productivity. However, its

features have now been implemented into the IDE itself, so it's useless for those who

are using the most current version of the Microsoft Visual C++ IDE.



VectorC—Codeplay

Specialized platform development tools are powerful tools for console games. While

most are proprietary, here's one that works for the PS2.

What the producer needs to know

VectorC is a powerful Vector optimizing compiler mainly geared toward PS2 game

development.

More background

VectorC is a vectorizing compiler. It allows for highly optimized compilation of both

PC and PS2 programs without having touse an assembly language. VectorC compiles,

optimizes, and vectorizes both C and C++ code.

VectorC {PC} Professional Edition is the full-featured compiler used for PC programs.

This version can optimize and compile for both C and C++, but the C++ function is

missing one feature—exception handling. VectorC does standard, nonvector, highperformance optimizations, as well as vectorizing optimization. VectorC {PC} PE has

been designed to integrate seamlessly into Microsoft Visual C++ IDE.

VectorC {PC} Special Edition is a version of the professional C compiler at a much

lower price.

VectorC {VU} is a C/C++ compiler that generates micromode code for the

Playstation 2 (PS2) vector units, VU0 and VU1. This is the only compiler available for

these components of the Playstation 2, which previously required assembly language

programming. VectorC {VU} is a Win32 compiler that works within CodeWarrior and

Visual Studio 6.

VectorC {EE} was mostly created to take full advantage of PS2's Emotion Engine

(EE). VectorC {EE} optimizes existing Playstation 2 software using software

pipelining, memory access reduction, and vectorization. You can recompile your

existing game engine using VectorC {EE} and, thereby, improve its performance. It

can also be used to write portable code that still gives maximum speed.

This program falls short in that although Codeplay promises the best vector compiler

on the market, there are not many who use it. This mean it's hard to know if they

deliver on all their promises. Detailed information about the compiler is hard to

obtain unless you're a registered PS2 developer.



XNA and DirectX

Every time a new version of DirectX comes out, there's a host of considerations and

updates that game developers must be aware of. Here's the scoop on XNA, which

was introduced to game developers at the Game Developer's Conference in 2004.



What the producer needs to know

XNA is the future development platform standard for PC and Xbox game

development. XNA includes a new and divided DirectX with the addition of the Xbox

Audio Creation Tool (XACT) and Performance Investigator for DirectX (PIX).

More background

For a long time, Microsoft has made industry-standard APIs for development on their

PC platform. They've made the low-level API standard for graphics and sound that

game developers have worked with for a decade. Now that Microsoft has joined the

console gaming race with their Xbox console, they have plans to create industry

standards for cross-platform graphics development.

Their newest product is called XNA. XNA was first introduced at the 2004 GDC. The

current XNA framework supports Windows, Xbox, and mobile technologies. In the

future, Microsoft hopes third-party developers will develop XNA for other console

systems, such as Playstation 2 and Nintendo GameCube. Whether Sony and Nintendo

agree remains to be seen.

XNA includes the latest version of DirectX with the addition of Xbox tools, such as the

Xbox Audio Creation Tool (XACT), which allows composers and sound designers to

create dynamic effects and apply real-time processing, and Performance Investigator

for DirectX (PIX), which has been available for Xbox development for some time but

has now been released for PC.

DirectX (an advanced suite of multimedia APIs built in to the Windows operating

systems) is one of those industry standards Microsoft has created in the past.

DirectX is a Windows technology that enables higher performance in graphics (fullcolor graphics, video, 3D animation) and sound (surround sound) when you're

playing games or watching video on a PC. With the introduction of XNA, DirectX will

undergo some changes. In the past, DirectX has been equipped with the following

components:

Direct3D. Graphics

DirectSound. Sound

DirectMusic. Music

DirectPlay. Networking

DirectInput. Input

Following are the changes DirectX will undergo with the next version of Windows,

Longhorn, and the introduction of XNA:

Direct3D will become the WGF (Windows Graphic Foundation) and will provide

the base for the Longhorn desktop.

DirectSound and DirectMusic will be replaced by XACT and Longhorn's API.

DirectPlay will have added Xbox live technology.

DirectShow will be replaced by a new media SDK.

DirectInput will stay the same.

Microsoft does not expect this new standard to be cross-platform for all the next



generation consoles, but the plan is to begin with all Microsoft platforms and slowly

move on to others. The expectation for this new standard is high, and if it delivers on

its promises, it might mean reduced costs for game development studios.



Interview with Luke Moloney

Luke Moloney is one of the founders of Relic Entertainment and is Lead

Programmer on Homeworld and Homeworld2. I caught up with Luke

between his business travels to provide this feedback for producers.

Q:



What is the one lesson or topic that you

value most highly?



A:



I think one of the biggest lessons a new

producer or engineer could learn is that

almost everything takes longer than you

think it should in video games. Too many

times I've heard veteran programmers

criticized as "lazy" when making time

estimates for tasks that sound overly

generous. When readjusted to be more

"realistic," these tasks inevitably end up

incomplete, or completed to a poor standard

of quality.



Q:



What is the most important trait a producer

can display: leadership, understanding,

flexibility, or even just how to ask clarifying

questions?



A:



All of those traits are important and must be

displayed in varying degrees. It's very

important that on any development team the

programmers are working together with

artists, designers, and producers toward

common goals. To this end, a producer must

work hard to ensure that programmers are

working on tasks that are directly in line with

what artists and designers need. Very often,

programmers like to work on features that

are "cool" from a technical point of view, but

are unusable or overly complex for artists or

designers. Having artists and designers do

mock-ups and clear demonstrations of what

they want can help programmers better

understand what they need programmers to

do. At the same time, a producer must make

sure that the requirements specified by the

artists and designers are actually going to be

used. Very often, artists and designers will

specify a technical requirement (such as

"environment mapping on all surfaces!") that

is difficult to implement and will only be used

on one or two cases. This is an inefficient



usage of programmer resources.

Q:



What recommendations do you have for

producers in how to be successful?



A:



I hinted earlier that some producers may find

time estimates from some programmers to

be overly generous. At the same time, a

producer should be wary of time estimates

that are too optimistic. This is a common

problem with less experienced programmers.

A good producer should compare time

estimates against actual time taken for all

tasks and develop a general rule to apply to

time estimates from each team member to

help ensure a more accurate schedule going

forward.

A producer and a lead programmer have

plenty of opportunity to interact, so use

[this] to build a positive relationship. When

the time comes and the lead programmer

wants to throw away and rewrite a large

portion of a game engine's code, use the

relationship to help explore if that is really

necessary. Such refactoring can be a good

thing, but usually takes a long time and

introduces many bugs if done to established,

tested code. The costs and benefits of such a

process need to be carefully weighed. If a

producer deems such a task to be too costly

or dangerous, it may be a difficult task to

convince a programmer without making him

or her very upset. Just blindly trusting the

opinion of a programmer in such a case can

be very costly.



Q:



What tools do you think producers

underutilize or should do more research

about that would make the programmers'

jobs easier?



A:



I've yet to work on a project that had a

decent task planning solution. I've used

Microsoft Project, Excel, Perforce's task list,

Outlook scheduling, File Maker, Test Track,

and others. In most cases, these tools are

only partially used, or are used in conjunction

with one or more other programs. I think a

producer could serve a team well by using

just one of these programs, and making a

central task list that incorporates bug

reports, development tasks, and progress

updates. Using multiple programs means



tasks will inevitably slip through the cracks,

unless a great deal of effort is expended

keeping the data in two tools in sync. Also try

to ensure that multiple tools don't assign

tasks to developers multiple times. "'I've

already fixed that darn bug; why is it saying

it's still open?" is a common frustration heard

toward the end of a development cycle.

Q:



What experience have you had in working

with producers and determining reasonable

schedules for a project, as well as tracking

the team's progress through that schedule?



A:



As I mentioned previously, it's a challenge to

determine realistic time estimates from the

estimates given by programmers especially.

Programming tasks are usually off by about

50 percent either too long or too short. The

challenge for a producer is to find out if they

tend to be too long or too short. Time

estimates must always be compared to

actual time taken to determine how a

developer tends to estimate. Also bear in

mind that this can be useful for identifying

exceptionally good or poor performers within

the team. Note, however, that poor time

estimation skills alone do not identify a poor

performer or vice versa.

Also, schedules usually need to be revised on

a per-milestone basis. An understanding that

the schedule will change is important as

otherwise one might be inclined to use a

scheduling tool that makes rescheduling

difficult. Don't be afraid to revise your

schedule. Keep the old versions around; they

might be handy when it comes to doing a

postmortem.



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Chapter 7. Game Tools and Asset Management

Tải bản đầy đủ ngay(0 tr)

×