Ultimate Game Design : Building game worlds

86
YOU
now understand the development sequence from previsualization
all the way up to starting to detail your levels and maps using
lighting, texturing, particles, and audio. Different map/level/mission/world builders
have different working styles and like to order their work in different ways. Your personal
work style needs to mesh or meld with your team style. After all, to handle the
complexity and scope of today’s games, you are normally working with a team to
build your game. Certain work elements that you depend on to complete your work
as a team member may be ahead of or behind the overall development schedule.
Usually, it’s the latter.
You may find yourself waiting for tools to be built or technology decisions to be
made. In such cases, a “dependency” exists—your own ability to do meaningful project
work is dependent on another variable, factor, or resource issue. You should use
this “dependency” time wisely, to further other team goals and solve or predict other
problems. For example, you might use this time to extend the functionality and stability
of your level or scripting software tools, or to document the tools you are currently
using. Maybe the model exporter tool, used to bring models into the game, is
not working correctly—don’t wait for a fix; move on to perfecting animations or
making better textures.
Personally, I concentrate first on functionality and flow. I ask myself, “Is this map
starting to look like it lives up to our gameplay intentions in building it?” I don’t
worry about lighting or texture details too much yet. That comes later. A large part of
building maps and levels involves problem solving of the following form: “How will I
accomplish this or that level goal?” Before you start to lock down more final lighting,
texture, and particle details, try to work on making sure that the map or level operates
mechanically.
During the building phase, many new assets are coming your way—new character
models, new props, new items, and so forth. A large part of the process at this point is
building in these new parts of the game. There are often multiple refinement loops
taking place simultaneously as the game begins to come together here.
As stated in previous chapters, often you have to use placeholder graphics to stand
in for game elements. For example, a cube becomes a placeholder for a fountain spitting
acid. When you get final art (model and animation) for the fountain spitting
acid, you replace the cube with this final art using file referencing. Again, you’re
still trying to lock down the operational features of your game at this point. Part of