[In this art-centric article, originally published in Game Developer magazine, Bungie's Steve Theodore discusses visualizing game environments, and why 'an upgrade to your tool chain is a great opportunity to upgrade the relationship between artists and designers'.]

Hollywood doesn't have to reinvent the camera every time they make a movie. But they're even luckier that they don't have to invent hammers, nails, and paint either. They build all sorts of stuff -- sets, camera tracks, props -- but working with common tools like hammers and nails makes you part of an enormous well-served market.

When lots of folks need the same things you do, your needs will be more easily identified and met. The bewildering array of nails, screws, bolts, brads, tacks, rivets, staples, and other fasteners on display at your local Home Depot is proof of that.

Unfortunately, when the games business goes shopping for tools, it ends up at the mom-and-pop hardware store, not the giant big-box home improvement emporium. Despite our economic successes, we're still a niche business for tools vendors.

Even if you lump games in with Hollywood and TV production, the global market for full-featured 3D packages of the Max-Maya-XSI variety is still less than half a million seats. That might sound like a lot, but compared to the market for, say, Photoshop, it's a drop in the bucket.

Add in the fact that we're still smaller than the pretty-offline-render side of the 3D business. On top of all that, remember that our engines and tool chains are incredibly diverse. Is it any wonder that the order of the day is usually "you'll take what you get and like it?"

Enviro Artists

If games as a whole are underserved, the discipline that really bears the brunt of this tools drought is environment art. The sad fact is, you can find scads of good software for designing your own patio or managing your recipes, but there are only a handful of packages dedicated to our most unique and difficult art task.

Max, Maya, and XSI have all made gestures in the direction of supporting world builders, but none of them really grapple with the unique challenges of building game environments. And none of them really shine when it comes to managing huge volumes of data, organizing hundreds or thousands of materials, or traversing the huge physical scope of game worlds, either.

Walkthrough cameras and snapping tools are nice, but they aren't enough to turn software that's best for looking at single, highly detailed character from the outside into a tool for building big worlds from the inside.

When the market won't give you the tools you need, it's time to ask if you can make your own. One of the interesting side effects of the next-gen revolution (it's 2008 already; can we stop calling it next-gen yet?) is a renaissance in homegrown art tools. Content has become so expensive that studios are finally taking tools seriously, rather than trying to scale their output by simply tripling the size of the art team.

The popularity of .Net languages has made it easier for coders to build slick, professional applications. The relentless march of graphics hardware has made it possible for even homegrown apps to get decent 3D performance as well. After years of hoping that the major packages would save us, the hour of DIY tools seems to have arrived again.

We shouldn't overstate how far the pendulum is swinging. There are still plenty of studios that confuse "tools" with "exporters" and think merely getting polygons out of Max or Maya means "job done."

There are also, to be fair, plenty of engineers who respect tools development enough to know that a full-featured 3D app is a major engineering effort, and who shy away from trying to rebuild something so huge in the compressed frame of a game production cycle. Building your own tool is a major investment, they say, and it's safer to try to manhandle a regular 3D package into shape than to build and maintain a tool from scratch.

Tools may not make an artist, but they can certainly break one. Planning and advocating for the right tools is a critical job for every art department. It's also a difficult and delicate game of hot potato, as it can easily devolve into arguments about making other people work hard so we don't have to.

To negotiate effectively for tools that will help us do our jobs, it's important to have some good strategic principles that help distinguish "good for the team" from "good for me, but not for you, pal."

With that in mind, here are some of the key considerations when deciding how far you want to go down the road of custom tools.

Gameplay

The paramount factor to remember when designing your own world-building tools is the nature of the game you're making. This sounds like a truism, but you don't dare forget how intimately the choice of tools is going to affect your game's final character.

In particular, you'll have to decide just how to balance your artistic desires for precision, control, and detail with the ability to quickly and iteratively refine play spaces.

Max and Maya are very powerful and provide exact control. They'll empower you to fiddle with every vertex in your world till the cows come home. Unfortunately, that level of control may be more curse than blessing if you're working on a game in which careful calibration of the play spaces is a key to success.

If your game's success hinges on multiplayer action, for example, flexibility may be more important than precision. If moving a doorway is going to cost you days of retexturing, shuffling around UVs, or fiddling with sliver polys from bad Booleans... well, you're not going to move that door, even if it's adversely affecting gameplay.

If changing the slope of your terrain means manually rebuilding separate meshes for the render, player navigation and physics, you're going to be pretty leery about tweaking the subtleties of your terrain.

There's no pain like shipping a map you know is un-fun just because fixing it would take too long. It's no coincidence that so many multiplayer-heavy titles use CSG editors (Valve's Hammer, Epic's UnrealEd) or fast height field-oriented terrain editors like EA's Battlefield Editor, since neither of these require careful UV management or as much attention to vertex level detail as conventional art packages.

Of course, plenty of games aren't so dependent on delicately-tuned play spaces. A fighting game with a static stage or a fixed-camera game of the Resident Evil variety, for example, would benefit more from the per-vertex detail of 3ds Max or Maya than from the ability to quickly sculpt a terrain mesh.

Games with more confined play spaces and lower density environments don't stress the capabilities of the big two packages so severely either. Games with more formalized play spaces can strike a balance by assembling hand-built puzzle pieces to get a mixture of flexibility and precision control at the expense of some variety.

The point is not that traditional packages can't do environments well, it's that the definition of "well" includes a lot of assumptions about the role of speed and detailed management that you need to consider with care.

Engine Integration

If iteration is critical for some kinds of gameplay, it can also be important for getting the most out of all our fancy-pants rendering technologies. There's a school of thought -- exemplified by tools like Crytek's CryEdit -- that says the best editor for your game is the game engine itself.

EA/Crytek's Crysis

The advantages of tightly integrating your tools and your game engine should be obvious. For starters, you can build and texture your world with the textures and materials your players will see, so that artists get immediate feedback.

Having game controls and game physics running can also make it easier to see your level from the player's point of view, complete with animation and interactive behaviors.

Not only does this cut down iteration time, it's also a great corrective to the level artists' perennial temptation: worrying about how the level looks in the overhead view that only the author ever sees.

To round it all out, your game engine probably has better interactive performance than a standard app -- after all, it's optimized for the kind of content you're creating. At least, you'd better hope it is!

Making your engine and your game co-dependent can involve serious risks, however. Above all else, it's a strategy that demands rigorous commitment from the engineers, because a compromised engine can end up stalling the entire art staff.

It's also going to be a challenge if your game isn't destined for PCs. Creating an engine that really looks the same on a PC and a console is a serious challenge. But if you can't pull it off, the benefits of using your engine as an editor are lost.

It would be nice if there were some way to hedge against the risks of integrating world editing into your engine. For several years now the major 3D packages have been touting the ability to run your own renderer inside their editor windows.

This is a very attractive idea in theory, but in practice it may not be much protection from the risks inherent in the engine-as-editor strategy. It reduces, but doesn't eliminate, the dangers of engine breakdown or the divergence between PC and console rendering.

Maintaining good interactive performance within your package can also be a problem -- you're not getting much value from integrated rendering if your artists all work in wire frame to keep their frame rates up.

Politics

Of all the calculations involved in designing a tools path for your world editing process, the trickiest calculations are the human ones. Level building is a uniquely cross-disciplinary business. There are a number of very different models for the designer-environment artist relationships, and your tools should be a natural extension of your overall process.

In some companies, both jobs are handled by a single person: a "level designer" rather than a "level artist." At the opposite end of the spectrum are companies that have designers doing all their work on paper and simply presenting their maps to artists for implementation. In some places, the artists supply puzzle piece modules to designers, who snap them together to create missions. The varieties of artist-designer relationships are enormous.

Despite their variety, though, in every case that relationship has to be expressed in the tool chain. Studios using the "level designer" model are often inclined toward editors like Hammer or UnrealEd, which emphasize design flexibility and integrate game entity placement right into the authoring tools.

On the other hand, companies that have artists and designers who don't work in the same application tend to need designer-specific applications for placing things like player spawns, triggering volumes, and placing game objects -- the alternative, teaching a non-artist enough Max or Maya to let them navigate and place objects without breaking things, is a recipe for trouble.

When you sit down to plan your next set of level tools, think about both ends of that artist-designer relationship. Look how your artists and designers cooperate now, and consider whether that relationship would benefit from a shared editing environment. Obviously, no piece of software is going to magically build creative cooperation on its own, but an upgrade to your tool chain is a great opportunity to upgrade the relationship between artists and designers as well.

Costs and Benefits

If you're still wondering whether you ought to be designing your own custom world editing tool, that's good. Building a world-class world editor is not a slam-dunk proposition; it's a major undertaking that deserves serious thought.

At least we're fortunate that they confluence of graphics hardware and new development tools has made it a thinkable option. Nobody wants to end up like one of those workstation-era companies that were handcuffed to doomed hardware and software platforms.

When you do sit down to ponder the question, take the opportunity to ping your friends at other studios for more information as well. The industry does a great job of solving problems, but not so well at sharing solutions. Doing a little better on that score really is a slam-dunk.

[EDITOR'S NOTE: This article was independently published by Gamasutra's editors, since it was deemed of value to the community. Its publishing has been made possible by Intel, as a platform and vendor-agnostic part of Intel's Visual Computing microsite.]