|
[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.
|
This app is effectively your real time editor for game content. The app is pretty light weight and works by simply informing the game that there has been a content update. If the update is small enough, it streams the data over via a network socket. If it's big, it compiles and dumps the data in a "compiled directory" on the console and tells the game to refresh the resource.
Then you don't need to worry about any sort of inconsistency on PC vs Console.
Lots of studios (including ours Hidden Path Entertainment) are doing that now and it's brilliant. We get real time updates on content while playing the game on PC and or Console.
It's also simple to add new data types and new values to tweak.
As we can see all over the software and all industry history, the way work is planned and the way the value of the done work is not "wasted out" is what matters for most when the question is quality and fast workflow. Sometimes just a good middleware improvement or a simple adding tool creation is enough solution for a very great change in how the work flows (not that work includes creativity and redesign).
it increases iteration (that's a good thing), but the good kind of iteration...making things more polished
and work better in the context of the actual engine. Iteration as a trial and error methodology really
describes a broken pipeline.
There are many reasons to want the most immediate feedback you can get from your tools, the biggest
being data parity. If I update an asset that is already stuffed into 40 levels, I want the engine to grab that
new asset and do the update. If you delay the updates you end up with stale data (assets ultimately are
just data) which will cascade through your production.