Ultimate Game Design : Building game worlds

C H A P T E R 3
an asset exporter from a 3-D package into a game engine, either. It’s all about how
much control you have over these kinds of assets once they are running in a game
scene via a game engine. Designers are hamstrung by tools every day.
At this point, it’s important to understand that one of the critical design, layout, and
execution challenges faced by most game developers involves what I call “tools shift.”
This term simply refers to a present working reality in game development: you don’t
necessarily know what tools you are going to use to make this game for this platform,
versus what tools you are going to use to make another game for a different platform.
After you finish a game and move on to creating another game, you may need to rapidly
learn another toolset to support the current title you’re working on. You may even
be learning and exploring the toolset for the following project while you’re finishing up
your current project.
For most independent developers, creating a custom toolset is an expensive proposition.
It’s expensive to build, to support, and to document. Maybe the tool will only
have use in the creation of a single genre game, and you’ll be moving on to another title,
possibly in another genre, which may or may not be able to take advantage of the
tools framework you’ve created. Ouch! It happens all the time.
The tool you are currently using might be a large MEL (Maya Embedded Language)
script written into Maya. MEL lets you customize Maya in an open-ended and flexible
way to suit your own development needs. Then again, maybe you’ll use a MAXScript
written into 3ds max. There are similarities, and also striking differences.
Perhaps you will use a stand-alone editor written as a tool for a specific game engine—each
of these editors has performance and use nuances all their own. Each of
these possibilities (as well as others) contributes to tools shift. Tools shift can make it
extremely difficult to accomplish meaningful, hopefully powerful game editing on a
tight schedule with limited resources.
If you’re working in a constantly evolving development environment, my advice is
to get to know well one 3-D package, one FPS editor, and one RTS editor. It’s also important
to be able to move around between scripting languages that are C-based
(structured/object-oriented languages) or conditional (like Python or Visual Basic).
Many of the tools used to build games are quite complex and are not mastered overnight.
Mastery is often as elusive as those particles wafting away from an emitter. It’s
like trying to catch a flock of birds in the dark wearing handcuffs. Most of game development
is a gradual and sometimes excruciating learning process. If you are learning to
model low polygon objects, or learning to model environments, don’t beat yourself up
if you’re not building the Taj Mahal in 15 minutes during the commercials. Persistence
alone is omnipotent. Just like many crafts and disciplines, you have to stay at it to improve.
You will improve. It might not be according to the schedule you are demanding
from yourself, but you will see progress.
77
Lighting, Texturing, Particles, Effects, and Audio