on Apr 29, 2014
This week we’re talking about… you can read the post title, can’t you? Yeah. That. We’re talking about that.
Unreal Engine was my first experience with something that felt like a real toolkit and not a slapdash pile of utilites. When id Software gave their tools away, it was usually just some command line (DOS) program that would take in raw data and spew out a playable level. It was up to the community to make a program that could create that data. In comparison, Unreal came with a level editor. And not just a bare-bones level editor, but a real program with a proper GUI interface and a 3D rendering window that would let you build the scenery, texture map it, light it, set up switches and moving objects (like doors and lifts) place points for AI navigation, and fill it with weapons and enemies.
A lot of this comes down to the question of “How good do we make our tools?” For example:
Screw The Art Team
You can make a terrible, buggy system that requires a barebones 3D editor, two command line programs, and a couple of messy undocumented converters. The artists will hate this. It will be confusing and difficult and their workflow will suck.
Example workflow: Let’s say it’s sometime in the 90’s and you’re a level designer. You need to add some lights in the control room section of the level because it’s too dark. You add a bunch of geometry to form the light fixtures. This is fiddly and slow because the editor only shows the scenery in wireframe, and when the map is really full it’s hard to see what you’re doing and you can often end up clicking on the wrong things or accidentally editing stuff in the wrong area. Also, there’s a bug in the editor that if you happen to drag one cube over another cube and both of them are the exact same proportions, the editor will instantly crash. So when things get crowded like this you have to be extra-careful when you’re copy & pasting stuff. Once you’ve built the light fixtures (like: lamps or hanging lights or whatever) you place a couple of points that will generate the actual light. You can’t see how it looks because the editor doesn’t do lighting.
When you’re done with your edits, you save your work and exit the program. Then you type a command into DOS and the program begins chewing on all those polygons you built. It spews out a bunch of (to you, an artist) meaningless gibberish about culling and octree depths and branch nodes and whatever other mysterious crap is going on under the hood. After a minute that program is finished. You enter another DOS command to take the output and run it through another program that will do all the lighting calculations and figure out where the shadows are.
Once those are done you fire up the game. Sure, you’ve got a beefy computer, but you’re still launching a AAA game and this unavoidably takes some time. Even more so for you than for the eventual end users, since this version hasn’t been optimized yet. Once running, you load up the level and discover you forgot to give the lights a color, which means they are shining black light. Which is to say: No light at all. It’s a common mistake and the art team has been nagging the coders to have the lights default to (DUH) white but they’re all busy with other stuff and nobody is in the mood to fuss with the tools.
You can’t even get a sense for how good the light fixtures work, or if the support beams are casting dramatic shadows the way you hoped. So now you need to go back to the editor, make your changes, then run all those utilities again. And if the support beams don’t look the way you want, you might need to do this a half dozen more times in the process of fine-tuning things.
On the other hand, we could always just insist the programmers make us better tools because apparently…
Money is No Object!
Yes. Let’s have our rare and expensive programmers spend huge blocks of time building editing tools to make life easier for our cheap and plentiful artists. Of course, the time they spend on the tools will take away from the time they spend on the gameplay, meaning it will be that much longer before we can start iterating on the content. But someday when the programmers finish we’ll have a nice stable program for the artists to use, and they can see their artistic changes right away without needing to launch the game or muck about with external utilities.
These are the two extremes. Where each company fell on the spectrum depended a lot on their internal culture, and also on how long they planned on using the engine. If you’re riding the graphical bleeding edge, then you’re probably going to re-write half of this stuff before you make your next game. On the other hand if you’re less aggressive about graphics then you can put more time into tools because they’re going to be around longer.
So it all depends on you being a tech company or an art company at heart.
I can’t think of many companies more art-minded than Valve Software. And their tools are the worst I’ve personally experienced. Just shockingly bad. I last used Hammer (their level editor) back in 2011 or so, and it totally felt like a late-90’s tool. It’s shocking to me that they do such amazing work with such crude tools. I would HOPE that with their recent focus on user mods that they’ve improved their tools, but I haven’t investigated it.
Shamus Young is an old-school OpenGL programmer, author, and composer. He runs this site and if anything is broken you should probably blame him.