As I mentioned in an earlier post, I’ve been mucking about with Hammer, the Valve level editor. Doing so provides an interesting peek inside of Valve studios. When Daikatana came out in 2000, there was a joke about how the game was polished, but mired in the previous technological generation and old design philosophy. It went something like, “Diakatana: Best 1997 game released in 2000.” Well, Hammer is my favorite level editor of 1999.
Hammer was a perfectly fine level editor when they began work on Half-Life 2. But due to the long development cycle, by the time the thing came out in 2004 the editor was getting really, really long in the tooth. I heartily approve of Valve sticking to the 2004 graphics tech, but a side effect of that is that they are also sticking to their 1999 level editor, which is now woefully out of date. There is no two ways about it. I don’t care how brilliant their artists are or how familiar they are with the tools: This sucker is slowing them down.
Imagine you’re a sculptor. You’re making a statue in granite. Only, you can’t make cuts with your eyes open. You have to figure out what you want to do, then close your eyes and tap away with your hammer and chisel. When you’re done and you want to see the result of your cuts, it takes you five minutes to open your eyes. (Although you do have an undo / save system, which a non-hypothetical sculptor won’t have. Then again, a real sculptor never has to restart his chisel because the dang thing crashed again.) Yes, a good artist can still turn out phenomenal work under these conditions, and Valve has some of the best. A good sculptor will learn to make a lot of cuts and avoid stopping to look at their work until they really need to. As the Guitar Hero + Rubik’s Cube video proved, the human brain can be trained to do some remarkable things. But if you’re driven to produce work of high quality (which Valve clearly is) then a system that punishes the artist for iteration is painfully self-defeating.
The root of the problem is that the editor only gives you a vague notion of what the level will look like. The editor shows the world with flat directional lighting. No special effects, no fog, no shadows, no positional sources, no sunlight, no shaders of any kind, no bump mapping and no cube mapping. If you want to see your work in-game, you must compile the level and then alt-tab over to the game and load it up. (Note: do not even think about making levels unless your machine has the oomph to run several hefty applications at once without passing out.) This takes a long time, much longer than a comparable level might take in another game engine.
|What the level looks like in the editor.|
|What it actually looks like in the game.|
Look at the above pictures and note the stage floor. Black in the editor, glossy white in-game. This is because it’s “shiny”, and thus the editor is unable to show you how it would really look. There are a lot of unpredictable differences like that. If you were making that texture you would need to keep restarting the game every single time you made a change. I’m sure everyone reading this is aware of how long it takes to launch a game, load a level, and exit the game again. Ouch. If you were fiddling with the shadows and coloring in the above level you’d have to sit through a compile and a loading screen every time you tweaked things, just to see how it all looked.
People developing for the Unreal engine don’t have this problem. The editor shows you exactly what the game will look like, lighting and all. You only need to fire up the game when you want to test gameplay. You do need to rebuild / compile once in a while, but an UnrealEd compile is way faster than a Hammer compile, you need to do them less often, and when it’s done you see the results right away instead of alt-tabbing to the game, sitting through the loading screen, and then running around the level to see the parts that interest you. (For comparison, my one-room auditorium is a 15-second compile if you set it to “quick and crappy”. In Unreal, the rebuild would be a blink-and-you’ll-miss-it job.) In Doom3, the game IS the editor. Just open up the console and type “editor” (or something along those lines, it’s been a while) and “poof!” you’re editing the level you were just playing. The lights and geometry update in realtime, so you don’t need long compiles or loading screens. You just work and work until you’re ready to playtest. It’s completely WYSIWYG. I haven’t tried it myself, but reportedly the Crysis editor does this one better: You get seamless visual editing, and you can test physics within the editor.
(Also, the Hammer approach to BSP geometry is very, very old-school. Half-Life 2: Episode 2 looks like a current-gen game. It’s gorgeous. But under the hood they’re using optimization techniques that were out of date before HL2 even hit the shelves. It’s pretty technical, but if people actually want to read about how BSP tech has changed over the last decade I’ll take a stab at explaining it.)
This handicap wouldn’t be so bad for other developers. But given Valve’s high artistic standards and their near-obsessive approach to lighting and atmosphere, the limitations of Hammer must be positively crippling. I’m actually shocked they’re turning out episodes as fast as they are. I’ve fired up the new version of Hammer they’re using for Left 4 Dead, and it’s basically the same thing.
Valve is up against a wall here. I’ve said in the past that changing your tools is a painful move. To update hammer now would mean throwing out most of it and building a new WYSIWYG editor on top of the game engine itself, which is how most other developers are doing things. A programmer (a good, talented programmer, not some cross-eyed intern) could blow the better part of a year on a job like that. And then there would be upheaval as the thing was rolled out, and it would slow the work of all of your projects: Episode 3, Left 4 Dead 2, Team Fortress, and whatever other projects they have cooking. It’s very much a pay-me-now-or-pay-me-later situation. They have to pay this update cost sooner or later. On one hand, the old tools are adding a ton of friction to their development process. On the other hand, the fewer times you go through that in the life of your company, the better.
It’s a shame things they turned out the way they did. They don’t actually need 2009-level tools. But the leap from 1998 to 2004 was a huge one, and if they were using 2003 level tools (which would include WYSIWYG editor) they would be in far, far better shape.
Denuvo and the "Death" of Piracy
Denuvo videogame DRM didn't actually kill piracy, but it did stop it for several months. Here's what we learned from that.
A video Let's Play series I collaborated on from 2009 to 2017.
Bethesda’s Launcher is Everything You Expect
From the company that brought us Fallout 76 comes a storefront / Steam competitor. It's a work of perfect awfulness. This is a monument to un-usability and anti-features.
In Defense of Crunch
Crunch-mode game development isn't good, but sometimes it happens for good reasons.
Dead or Alive 5 Last Round
I'm not surprised a fighting game has an absurd story. I just can't figure out why they bothered with the story at all.