GameArchitect

I’ve written before that at SIGGRAPH you starve while at GDC they stuff you like a foie gras goose.  No more.  This year there were no breakfast pastries before the lectures started.  There were no cookies at the coffee breaks.  Some lines ran out of lunches and sodas.  Perhaps CMP took a look at the girth of the attendees and decided that the average game developer would benefit from a diet.

The lean times extended to the recruiting floor.  It was obvious looking at the career expo that, despite rumors to the contrary, our industry is far from recession proof.  There looked to be about half as many booths as there were last year.

Recruiting aside, GDC looked as crowded as ever–which is pretty impressive considering that attendance last year was 18,000 developers.  Unfortunately, this whole paragraph from my write-up last year is still accurate:

GDC hasn’t managed to scale to handle its growth.  Internet connectivity was poor throughout the convention center…. proceedings didn’t become available at all until after the conference, and those in the form of a slim handful of PowerPoint decks.  The clever people have taken to bringing cameras to the talks and snapping pictures of each slide that goes up, which is distracting but understandable.  The state of the GDC proceedings is an embarrassment to the industry, but it’s one that I don’t expect to change unless CMP stops handing out Gigapasses to speakers who show up without their slides.

This year, even AT&T’s 3G network was overwhelmed.  I had to switch my phone back to the EDGE network to get any bandwidth.   18,000 geeks use a lot of bandwidth.

What’s hot:  SPU task profiles.  Screen-space postprocessing.  iPhones.  AI.  Larrabee.  Producers explicitly defending crunch.  Margaret Robertson.

What’s not:  Spherical harmonics (still).  Every mobile phone except the iPhone.  Scrum (it’s lost its New Process smell… crunch is the new scrum).  The 7 to 9 scale.  OnLive.

Read the rest of this entry »

“I always envied the guys who wrote the software that would power the PlayStation 3.”  (p. 58)

The Race For a New Game Machine, by David Shippy and Mickie Phipps, is a clumsily-written and frustratingly vague book, but game developers should read it anyway.

Shippy led the team that developed the PowerPC core common to the PS3’s Cell processor and the Xbox 360 CPU.  Although his subordinate Mickie Phipps is given equal authorial credit, Race is written entirely in Shippy’s voice.  Shippy was middle management, two levels up from the engineers designing the logic and circuitry of the processor and two levels down from the corporate VPs negotiating with Microsoft and Sony.  As a result the book mixes corporate politics and technical detail.  Unfortunately it rarely gives a satisfying dose of either.

“When the [Halo 3] player swings the joystick and levels a weapon at a charging alien beast,” Shippy writes in his introduction, “then presses the button and showers it with lead, splattering it straight back to hell, the quality of the experience depends less on the fancy code written by the people at Microsoft than on the processor brains in the chip inside the box.”  I’m a software developer, so my biases are obvious, but the primacy of hardware strikes me as a difficult argument to make.  There are plenty of games available for the Xbox 360 that most players would agree don’t come close to the “quality of the experience” delivered by Halo, though they run on the same platform.  And consumers voting with their money seem to think that Wii Fitness delivers a higher-quality experience than Halo does, on hardware with a fraction of the processing power.  I’d argue that hardware has been a commodity for some time, that game code is in the process of becoming a commodity, and that for a game to differentiate itself in the market today, it has to do so in the quality of its creative attributes:  art direction, story and game design.

Unfortunately Shippy has a habit of  resorting to purple prose at the cost of clarity and accuracy.  Consider his description of the history of electronic gaming:

Throughout the 1970s and 1980s the PC industry skyrocketed, too, providing the perfect low-cost platform for game developers.  They capitalized on each step up in the PC’s speed or bandwidth, each increase in the size of its memory or access time, and every decrease in power consumption.  Graphics engines (separate chips that could handle the graphics creation for the games) allowed the PC’s microprocessor to focus on the calculations to create characters that move and behave more like real people and environments that are more intense…. The rise in the PC games market dealt a near death blow to the game console industry.  By the early 1980s, even with new models still on the shelf, consumers were rapidly losing interest in the aging Atari game machine, and no heir-apparent was in sight…. It took nearly a decade, but the game console market suddenly bounced back from the dead with the launch of Sony’s Playstation in 1994…

In the space of a page, Shippy gives the impression that

• Consumer PC 3D graphics cards existed in the eighties
• PC game developers care about power consumption
• Gaming PCs with graphics and sound acceleration killed the Atari 2600
• The Nintendo NES never existed

Coming from a pair of engineers, such technical imprecision is astonishing.  The clumsiness extends to the authors’ use of language as well.  They “hone in on” solutions and “flush out ideas.”  Shippy interrupts a discussion of logic changes with the tortuously mixed metaphor, “In other words, there would be road construction to add new highways, and the traffic cop would have a lot more balls up in the air to juggle.”

But if a good copy editor could have helped the writers with their wording, he would have been powerless to correct their technical sloppiness.  For example, Shippy provides the oddest description of a game’s update-render loop that I’ve ever heard:

Although it may seem like magic to most people, game code is really quite simple.  It can fundamentally be broken down into three major options.  First it requires incoming streams of large amounts of data generated from a peripheral such as a joystick, controller, or keyboard.  This is called “read streaming.”  Second, that incoming data stream has to be processed by one or more numeric engines.  Finally, the data processed in the numeric engines has to be streamed back out to the video display to create the colorful graphics.  This is called “write streaming.”

I’ve worked as a software engineer on games for more than a decade, most of that in core technology, and I’ve never heard of “read streaming” or “write streaming” before.  Controller inputs provide a trivially small amount of data.  (That’s why networked real-time strategy games tend to sync inputs and run deterministic simulations instead of syncing all game state.)  Write streaming, or “rendering” as we call it in the biz, is more memory-bandwidth intensive, but Shippy confuses matters by blurring the line between operations performed on the CPU and operations performed on the graphics processor.

Whether Shippy intends “write streaming” to refer to the transfer of data from CPU to GPU or from the GPU to the framebuffer, it accounts for a small fraction of a frame.  Most of the CPU processing time for any game is spent marshaling data and performing general-purpose logic, with smaller portions of the frame devoted to number-crunching for physics, animation or graphics.  Or as Chris Hecker puts it, “graphics and physics grind on large homogenous floating point data structures in a very straight-line structured way.  Then we have AI and gameplay code.  Lots of exceptions, tunable parameters, indirections and often messy.  We hate this code, it’s a mess, but this is the code that makes the game DIFFERENT.”

You have to wonder if the difference between Hecker’s understanding of how a frame loop operates and Shippy’s is part of the reason why the PS3 contains a CPU optimized for stream processing rather than one optimized for messy game logic.  And puzzles like this are the reason why The Race for a New Game Machine is worth reading despite its flaws.  The book tells a story, and if it’s awkwardly written and frustratingly vague, it also offers occasional fascinating insights into how the consoles on which we develop were created.

As the book relates, the Power core used in the Xbox 360 and the PS3 was originally developed in a joint venture between Sony, Toshiba and IBM.  While development was still ongoing, IBM–which retained the rights to use the chip in products for other clients–contracted with Microsoft to use the new Power core in their console.  This arrangement left Sony engineers in an IBM facility unknowingly working on features to support Sony’s biggest competitor, and left Shippy and other IBM engineers feeling conflicted in their loyalties.

Race paints a striking picture of the different corporate cultures at Sony and Microsoft.  Sony comes across as a vast impersonal hierarchy ruled by the impulses of Ken Kutaragi, then head of Sony Computer Entertainment.  Most of the high-level innovations of the Cell processor are attributed to Kutaragi.  So are other  strange and whimsical mandates.  At one point Kutaragi demands that the Cell must have eight Synergistic Processing Units, rather than the originally agreed-upon six, because “eight is beautiful.”  IBM complies and produces a chip with eight SPUs.  (The book doesn’t mention that, as Wikipedia points out, the PS3 only has “six accessible [SPUs] … to improve production yields.”  It also never mentions that the 4 GHz core Shippy set out to design became a 3.2 GHz core in the shipping consoles, presumably also to improve yields.)

Microsoft is the agile hare to Sony’s tortoise.  Individual Microsoft engineers come across as having more initiative–and a certain cockiness to go with it–but their desires are less grandiose than Kutaragi’s and they seem to have a better idea what they want.  Microsoft is focused on software and services.  They want simpler hardware than Sony’s Cell processor and they’re flexible in cutting features as long as they make their intended ship date.  Because they’re developing a processor more similar to an off-the-shelf PowerPC chip, Microsoft is able to put development kits in the hands of game developers a year and a half before Sony.  Because they control their manufacturing risks, they’re able to put final hardware on shelves a year before Sony.

For readers who are more familiar with the design of software than hardware, The Race for a New Game Machine offers a window into a strange parallel world where much is intriguingly similar and some things are very different.  In the early days of development on the new Power core, Shippy describes junior engineers “chomping at the bit to dive into the detailed implementation” before the high-level design is done, an experience familiar to most experienced software developers.  But a few pages later, Shippy tells how a “junior engineer’s face lit up with enthusiasm” at the idea of getting a new idea patented.  Software patents are anathema to most game developers!  The technical work the book describes is a mix of logic design, which sounds familiar to anyone used to writing code, and physical layout, which sounds more like playing SimCity as the chip designers map that logic onto actual circuits on the smallest chip possible.  Finally, Shippy’s description of the brutal crunch engineers experienced in finishing the chip’s design will be all too familiar to anyone who’s shipped a game.

One of the unnecessary risks Sony took on in developing the PS3 was an attempt to build their own graphics processor.  Toward the end of the Cell’s development, Shippy writes, “the graphics chip designed by the Sony engineers was slipping schedule.  Sony had designed simple graphics chips in the past, but it was clearly not their area of expertise.  After many months of schedule slips, it became obvious that Sony could not deliver the promised graphics chip.”  This story raises as many questions as it answers.  Was Sony trying to develop a full GPU, or merely developing a rasterizer in the assumption that the Cell’s SPUs could handle vertex transformation?  If the latter, did the graphics processor fail to perform, did the SPUs, or could the platform not transfer data from SPUs to processor fast enough?

The story raises as many questions as it answers.  But if The Race for a New Game Machine hadn’t been written, we wouldn’t know to ask those questions at all.  We’re better off for having read the book.  It’s just a shame the book’s not better.