|
|
GDC 2004
By Kyle Wilson
Introduction This was the fourth Game Developers Conference I've been to. The conference has waxed and waned over the years. Back in 1998, when it was still CGDC, it was down in Long Beach because it had overflowed wherever it was the year before. There were parties on the Queen Mary and the expo floor seemed all abuzz with new games. In 2000, everyone was talking about how to make games for girls and Bill Gates was there in person to announce the Xbox. Last year, though, everything seemed pretty grim. The expo floor was only about half full, and that half was full of hungry middleware providers looking desperately for enough clients to stave off bankruptcy. There were a lot of talks on things like "How to Manage During Tough Times". Things seem to be bouncing back. The expo floor was bigger and healthier looking this year, with huge booths from ATI, Intel, AMD and Sony. There were fewer desperate middleware providers trying to grab any passerby who'd listen. A lot of companies seemed to be hiring. There aren't as many free t-shirts as there were back in '98, but really I have all the shirts I need. The people seem healthier, too. The industry looks like it's starting to grow up. There are more women in the halls at GDC these days, and more men who look like they wash and comb their hair (or shave their heads, which also seems to be a popular fashion choice for the modern cosmopolitan geek). There seemed to be a larger-than-usual Japanese contingent this year, probably because of the addition of a series of lectures by Japanese developers (simultaneously-translated for those of us who've forgotten what little college Japanese we ever knew). Unfortunately, the increasing maturity and respectability of the game industry wasn't reflected in the conference itself. Poor space planning left people sitting on the floor at almost every talk I went to. When I arrived at Will Wright's talk fifteen minutes early, the room was already so full that thirty or forty people were milling around outside the doors, unable to get in. Furthermore, the conference proceedings continue to look like an amateur production. The talks that have material in the proceedings offer only cobbled-together PowerPoint slides from game developers and rehashed tech reports based from academics. Worse still, most talks, presumably hastily put together between the proceedings deadline and presentation day, simply don't have any material at all. On the bright side, they do a good job of feeding you. After a week at Siggraph, I felt like I was near starvation. After a week at GDC, I felt like someone could make foie gras out of my liver. For a graphics programmer, this year was a caesura between last year's debut of DirectX 9 and next year's debut of the Xbox 2 and the PlayStation 3. There seemed to be more action on the production side this year. There was a lot of talk about licensing and movie tie-ins, about ever-growing team sizes, and about managing ever-larger budgets. Monday I spent Monday and Tuesday, the tutorial days, hopping back and forth from talk to talk. Monday I opened with Wolfgang Hamann's talk on Critical Stage Analysis. As I skimmed the notes while he went through his introduction, it looked like CSA--a process he invented which replaces "obsolete" postmortems--involves having each department write a Game-Developer-magazine-style postmortem every milestone, listing five things that went right and five things that went wrong. I wasn't quite sure how Hamann was going to get a full day's material out of that, and his unsettling preternatural perkiness didn't leave me inclined to find out. When he asked everyone in the room to find someone they didn't know for a "partner exercise", the Day 1 delegation bolted for the door. After that I tried a little of the class on Playtesting Strategies, mostly because one of the presenters was Michelle Gamboa, our tester at Microsoft for MA2, and I wanted to see the face on the other side of the bug reports. The talk was more about play balancing than testing, and so was more about tweaking stats than code. That didn't really hold my interest, so I moved on to the D3D Advanced Visual Effects talk. The most interesting part of that talk came at the end of the day when Gary McTaggart talked about the lighting model used in the Half Life 2 engine. They're doing some truly odd stuff, using high-resolution normal maps not to compute lighting directly, but to compute per-pixel blends between either three pre-computed directional lighting intensity values for static objects or adjacent vertex lighting intensities for dynamic objects. This lets them do something sort of resembling bump-mapped lighting with any number of lights in one pass, but it seems so hacky that I'm a little disgusted that it looks as good as it does. Truly the eye is a forgiving instrument of perception. Tuesday On Tuesday, I dropped in on Microsoft Game Studios' talk on Test Automation in Game Development. The talk was interesting less because of what was said than simply by the fact of its existence. It's remarkable to think that in our world of seat-of-your-pants game development, there are people working full time to build automated testing tools for games. I wish there were more of them. The most useful thing that I took away from the talk was the presenters' emphasis on data mining. The idea is that you have a core set of scripted test levels that never change, that get loaded and run as part of your nightly build. If you save data on memory usage and frame rate to a database, looking at graphs of that data over time is a powerful tool to detect when leaks and inefficiences have crept into the engine. You can learn even more if your test levels have measurable objectives. You can time, for example, how long it takes for a stronger opponent to destroy a weaker, or for a vehicle to cover some amount of distance. That kind of data will help you quickly recognize errors in game logic, physics and other areas when they occur. Although no one said anything explicitly, I got the impression that a weakness of Microsoft's approach to automated testing is the disconnect between the testers and the developers. The testers presenting talked about game code as if it were some foreign thing. I think most game teams would be better off having a single dedicated test engineer on-site and working on the game code directly than a whole corps of test engineers in another building working to support several games with common tools. DirectX Developer day included a variety of interesting stuff to look forward to in the next DirectX release (either 9c or Yet Another Summer Update, I forget which). The way D3D Effects work is changing (and looking an awful lot like our material system at Day 1, actually). Some new shader models are being added to tide us over until vertex and pixel shaders 3.0 finally arrive. And we got Yet Another Talk on Parametric Radiance Transfer. I talked about PRT some back in my report on Siggraph 2003. It makes for good demos, but it's just not useful for the vast majority of games. I'm not sure why GDC keeps hosting presentations on the subject. They all say exactly the same things that Jan Kautz and Peter-Pike Sloan said back in 2002, bringing nothing new to the subject except slightly different demos of objects being lit diffusely by environment boxes that swirl around them. Until someone can tell me how to use PRT to light a large specular hunk of metal surrounded by little streetlights, I've got no use for it. Wednesday On Wednesday morning, I went to Tom Forsyth's talk on Practical Shadows. There wasn't a whole lot new there for a regular reader of GD-Algorithms, though I found his method of generating and using multiple shadow frustums for depth buffer shadows interesting. Mostly it was just good to have a face to put with the name I so frequently see on the mailing lists, and Tom was an entertaining speaker.
To clear my head, I went to Game Design: Risk and Return, a simultaneously translated talk by Masahiro Sakurai, the designer of Super Smash Brothers. The simultaneous translation worked astonishingly well, and I'm really happy to see GDC bridging the communication gap with our fellow developers across the pacific. The talk was not, as I had expected, about the risks inherent in designing a game, but rather was about the risks and rewards experienced by the player playing the game. Sakurai made the point that a player only enjoys a game so long as he's in an envelope of risk, and the more skilled he becomes, the more risk he expects to undertake and the greater the rewards he expects to reap. After lunch I went to John Giors' talk on the camera system in Full Spectrum Warrior, less because I'm really interested in the mechanics of an automated camera system than because I think FSW looks really, really cool and I wanted to see more of it. The talk was the sort of thing GDC should have more of, an explanation of the various problems encountered and solutions devised in implementing a game system. Nothing in the talk would have made it into an academic publication, and a lot of the solutions were ad hoc rather than elegant, but that just made it more interesting for those of us who have to deal with these sorts of issues every day. I dropped by the Microsoft Game Studios party at their suite in the Hilton in the afternoon, where I found a couple hundred developers filling a moderately-sized hotel room. Most of the hors d'ouvres were out in the hall, for want of any space in the suite. I had the interesting experience of being asked by an MGS employee what, exactly, Day 1 had done on MechAssault. Ouch. I played a little bit of Sudeki, which looked cool, but isn't my kind of game. And I watched Mike Capps demo Unreal Championship 2, which is supposed to be shipping this fall, but already looks as slick and polished as most titles already on the shelves. Very impressive. After that, unfortunately, I only managed to catch the tail end of Kenji Kaido and Fumito Ueda's talk on the design of Ico. The final minimalist game, they said, was the result of a winnowing process from their original design. They wanted to create a world that was beautiful, detailed and real. So they identified as early as possible things that they couldn't do well, and cut them as it became obvious that they couldn't be done at the level of quality the game required. In the end, they were left with a boy, a girl, a castle, light and shadow, and a beautiful game.
Thursday I went to see Ray Muzyka and Greg Zeschuk's talk on managing the growth of Bioware. I don't ever expect to start a company with a handful of people and watch it grow to two hundred, but I'm impressed with Bioware's games and I'd heard that Ray and Greg were sensible guys. That said, it's really strange moving back and forth between the hard technical talks in the programming track and the soft and fuzzy world of the game design and production tracks. When you're writing code, you effect change by making a change, and it's done, it's there in front of you, and you see it in the game. The production world is all about soft power and persuasion. You effect change by sketching an org chart and hoping people follow it or holding a meeting and hoping people believe in your vision of the company at the end of it. That's a whole lot of hoping, and reliance on hope makes hard tech guys like me nervous. Ray and Greg said a lot of interesting things about the structures they have in place through which they steer Bioware--meetings, team arrangements, and so forth. But the core of their talk was about choosing values and building a company culture around those values. It's impossible to hear the two of them talk without being impressed by what stand-up, decent guys they are, and they've clearly tried to build a company that reflects those values. (Ray seemed genuinely taken aback when a questioner asked him if he ever tried to foster competitiveness between different internal teams.) Finally, the two get special kudos in my book for submitting an actual paper to the GDC proceedings that's clearly written and expands on the material presented on the PowerPoint slides during their talk.
Friday I opened Friday morning with Soren Johnson's talk on How to Maintain a Successful Franchise. Soren is a programmer/designer and is the lead on Civilization IV at Firaxis, just down the road, and I'm always interested in hearing what the neighbors are up to. What he had to say seems obvious, but people seem to get it wrong anyway: When you're making a sequel to a successful game, look at the original. Update the tech. Add a few killer features borrowed from the competition, from other genres, from new designers. Ruthlessly remove anything that didn't work in the original game, because it's important to keep the game from becoming more and more complicated in subsequent iterations. Keep your focus and make sure you don't lose what the fans of the original game enjoyed about it. The result should be a game that has all the fun of the original and more, is still as straightforward and easy to master, and looks better because of advances in technology. Firaxis's use of programmer/designers is also interesting. I don't think many game companies have designers who write code anymore, and I'm generally wary of any job role that calls for one person to do too much, but I can also see tremendous appeal in having a designer who can clearly express his intention in code, can tweak that code himself to get a desired effect, and can understand the limitations of what code can accomplish. That said, I think that kind of role is less well-suited to Day 1 than to Firaxis; I suspect strategy games have game logic that's more compact and well-encapsulated than all the game-level code in MechAssault. If we had designer/programmers, we'd probably want to limit them to working in small concept prototypes or script. As I mentioned earlier, I was unable to get in to Will Wright's talk Friday morning due to lack of room in the lecture hall. I'm looking foward to hearing that one on the GDC audio proceedings. If you work at a company that doesn't get the GDC audio proceedings every year, by the way, you really should. At half the price of a ticket to the conference for the audio to every talk, they're a tremendously good deal. Having been turned away from Will Wright, I listened to Thomas Engel talk about adding light scattering to Star Wars: Rebel Strike, and listened to the loud explosions of laughter and applause through the wall from Will Wright's audience. Engel gave an interesting talk, and the game certainly looked pretty, but since I read Naty Hoffman's earlier articles on the subject, I didn't get that much practically applicable out of it. Engel had some insightful things to say about how he fit light scattering onto Gamecube hardware, but if I ever implement it, I expect to be doing on a machine with pixel shaders 3.0, which I suspect could apply accurate light-scatter haze as a full-screen postprocess anyway. In the afternoon I went to my co-worker Noel Llopis's Software Engineering Roundtable. Roundtables and similar informal chatting are probably the best reason to go to GDC instead of just reading a book. I've learned, though, that bad roundtables are as excruciating as any experience you can imagine, and much harder to sneak out of than bad talks. Noel has a knack for moderating great roundtables, where most of the attendees actually speak and you wish it lasted longer than an hour. Read his notes and go to one of his sessions if he does it again next year. Finally, I went to Rich Geldreich and Matt Pritchard's talk on Deferred Shading. I almost skipped this one, having seen one less-impressive deferred shading talk already during the visual effects tutorial. I'm really glad I didn't. The hour available for the talk really wasn't enough to cover the material the presenters had, as they discussed shoehorning deferred shading into the Xbox and the PS/2. What I saw left me thinking that that Rich Geldreich is a mad genius and looking forward to seeing the next game from Ensemble (yes, the Age of Empire guys) which I expect to have more impressive graphics technology than Doom 3. Any opinions expressed herein are in no way representative of those of my employers. | |
|
|
||