25.12.2012 Views

Ultimate Game Design : Building game worlds

Ultimate Game Design : Building game worlds

Ultimate Game Design : Building game worlds

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

C H A P T E R 4<br />

Camera problems, among many others, are why constant communication between<br />

designers and technical leads is so very important. If you’re going to start<br />

building environmental assets (like the wall pieces that form the deep corners), you<br />

need to agree on camera implementation early rather than late.<br />

CASE STUDY COMMENTS ON ACTOR<br />

LOADING AND CAMERA TUNING<br />

You now understand that actor loading (the process of importing characters, props,<br />

and effects into your <strong>game</strong>) is the pathway for constructing your <strong>game</strong>s. As such, it’s<br />

a vital part of the <strong>game</strong> assembly process. Most developers, as we’ve seen, build their<br />

low polygon characters, props, and items in Maya or 3ds max. We’ve taken a look at<br />

texturing, animation, and applicable lighting too. Now we have to export these out<br />

of a 3-D package and into our <strong>game</strong> engine (either licensed or custom-developed<br />

in-house at a <strong>game</strong> studio—also called proprietary).<br />

The software exporter (from Maya or 3ds max to our <strong>game</strong> engine) is a piece of<br />

tool code that reconfigures our assets to be set up appropriately to be “understood”<br />

by the <strong>game</strong> engine we’re using. Maybe our engine requires us to set up polygon<br />

faces a certain way, or orient animation joints a certain way. The software exporter<br />

will have to account for this fact, and sometimes try to adjust for this fact (with<br />

mixed results!).<br />

Frequently, our export tools are under development in parallel with the <strong>game</strong><br />

we’re making. This means that the software exporter may itself be undergoing a rigorous<br />

debugging phase while we’re attempting to build things using it. It shouldn’t be<br />

a surprise that this fact alone creates considerable challenges. <strong>Design</strong>ers need to provide<br />

quick and useful feedback to the tools programmer(s) to get the exporter working well<br />

enough to serve the <strong>game</strong>. Often, <strong>game</strong>-ready assets constructed using these tools are<br />

due to your <strong>game</strong>’s publisher at the same time the tools are under development.<br />

During many <strong>game</strong> development cycles in my personal history (and I won’t single<br />

any out; they share common factors), it wasn’t necessarily building <strong>game</strong> engine functionality<br />

that slowed <strong>game</strong> development and affected <strong>game</strong>play development goals—it<br />

was the tools. To be precise, it was the lack of tools. How do you start building up exciting<br />

play if you can’t get reliable assets into the <strong>game</strong> scene? You can’t.<br />

Many times, these software exporters fail. What looks perfect and functions correctly<br />

in your 3-D package of choice is destroyed in translation to the <strong>game</strong> engine.<br />

Consequently, you find that, for example, polygon faces are flipped, texturing information<br />

is lost, lighting information is missing or severely altered, animation data is<br />

99<br />

Actors, Props, Items, and Camera Details

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!