[Kopernikanische Wendung]

"Hey Bob - how's it going at UberGameSoft?"
"Hey Tom - it's goingwell. I'm figuring out a neat HDR system, Jim's doing a cool physicsengine, and Frank's got some awesome post-processing effects."
"Cool. So you guys must be well into production by now, right?"
"Kinda,but not really. We still have trouble with the whole export pipelineand there's a lot of pain getting assets into the game."

At this point, I usually start yelling at people and preparing another ranty blog entry. And thus...

There'sa bunch of stuff that is neat, and it's geekily cool, and we asengineers all love to play with them and they generate some killer GDCtalks and suchlike. But they're all unimportant next to the stuff thatis necessary to ship the game. We're now looking at team sizes of 50-150 people for 2-4 years, and that's a lot of assets.

Youneed the smartest coders in the building to be making sure thateveryone else can work efficiently. And that means they're toolscoders. Yes, "tools" - don't look at me like I said a dirty word.

Theproblem is that at heart a lot of us are still bedroom hackers. Andthat's a great mentality to have - it keeps us honest. But at thosenumbers, you have to have some of the dreaded word - "management". Butwe're smarter than the average bear, so we can use geek management, notPHBmanagement. And it's not management of people so much as management ofdata. Good people who like the work they do and the people they workwith will generally manage themselves pretty well. The problems comewhen the data flowing between them sets up dependencies. Now obviouslythat's inevitable - but people can cope with obvious dependencies -like you can't animate a character very well until the rigging is doneor whatever.

The problem is dependencies that aren't as obvious.They're obvious to us coders, because we're the ones who write thesystems. And unfortunately the easiest way to write most systems is tohave all the source data available at once, throw it in a bigpost-processing hopper and out comes the DVD image, and then we shipit. Fairly obviously, this is a disaster in practice. So instead weneed to think carefully about the chain of dependencies and how we canisolate one person's changes from another, and allow people to work onrelated objects at the same time without getting stalled.

Thisis almost exactly the other big problem coders are facing - parallelprocessing. And we all know that parallel processing is really reallydifficult, so we put our smartest coders on the problem. And the sameshould happen with the tools - it's an even bigger parallel processingchallenge, and the problem is not as well-defined as "make the physicsgo faster" because half the time when you start a game you don'tactually know where you're going.

So I'm going to do some moreposts on some of the detailed aspects once I get them straight in myhead. But the big message is really that the old days of the hero-codersaving the day with leet gfx skillz are over. Shaders just aren't thatdifficult to write, HDR is a matter of detailed book-keeping, andshadows may be a pain in the arse but they're not fundamentally goingto make or break your game. Good asset management on the other hand canmean the difference between shipping and going bankrupt. That's whatthe new breed of hero-coder needs to focus on.

-- from TomF`s Tech Blog