2010

2002.05.03

Perhaps it was from the lack of REM sleep. Perhaps it was because I had been working as a project manager at a San Francisco game-development office for twelve hours straight, every day, for the past nine weeks. Perhaps it was the accumulation of espresso brownies, Mountain Dew, and Fritos coursing through my bloodstream. For whatever reason, as I tabbed around the Microsoft Project file, the lines of dry data began to convolve and intertwine; tasks were resources, April was May, alpha was beta. As my sight blurred at the edges, my head slumped forward and fell through the space between the B and the N keys on the keyboard, parting them like double doors, opening a chasm of gray-blue light inside my desk. I could see clearly for the first time in months.

What I saw was the future. Game industry pundits love to preen and postulate about their versions of it, ponderously proposing which console or which genre will be hip in twelve months. What I saw was not the future of the market, but my future, our future, as individuals and as members of the game-making profession. I teleported cleanly into the year 2010, wandered the show floor, and caught up with you and the rest of my old friends.

It's not peachy in 2010, but we're still making a living. Practically everything about the game-making process has changed. I'll lay it all out for you, but unlike the bearded lady with the tarot cards I won't invent a Hollywood ending in the hope of scamming an extra dollar out of you.

In 2010 there is exactly one way to get a game of any significant magnitude financed and developed, and that is through the publisher system. Top-quality game budgets are pushing fifty million dollars and there are only six publishers worldwide with pockets deep enough to take a game to the top of the TRSTS charts. All remaining game publishers, the ones trying to contain costs to ten million or under, have been bought out or are in the process of being bought out. There is an underground independent scene of game developers, but the publishing suits consider the scene to be an ironic joke, and one incapable of making money. Given the existence of the system they've created, the suits are mostly right.

Game development professionals in 2010 tend to be thirty-five or under; anyone over forty years old who works in videogames is considered to be a fossil. Two years ago, in 2008, a few designers got coverage in some trade magazines with a class-action lawsuit against several game publishers. The designers claimed age discrimination. The suit went nowhere.

Except in indie circles, the concept of a game designer is passé. Every publisher employs an executive producer for each game project, and the executive producer makes all the necessary creative and business decisions for that project. The best EPs have personality elements of a Hollywood director and a Latin-American dictator; he can be your best buddy or your most ruthless enemy. More than a creative visionary, more than a product manager, the EP is a slave-driving rock star who can navigate his game project through the political swamps of fan-mag previews and exec-staff reviews, constantly protecting his budget and his staff from getting downsized or reallocated. When he's not giving press interviews or demonstrating the latest build to upper management, a prudent executive producer spends much of his time playing other games and deciding exactly which design elements to steal for use in his own games. A high degree of originality is a liability for a well-placed EP. An EP must be able to defend his game development decisions in management review meetings by referring to top-selling games with the design elements that he's ripped off for his own game. The EP is always smack on top of the latest TRSTS data and is ready to quote the latest numbers at any time. He lives his life in crunch mode and will work eighty-hour weeks automatically, obligating his staff to do the same. The EP demands the highest caliber of work from his staff, both quantitatively and qualitatively, and he pays generously in exchange for it.

(The male pronouns are correct. In 2010, the game industry is still run almost entirely by men. Four small development houses, all run by women and all dedicated to making games for girls, have cacked in the past fifteen years.)

Before an EP can get the funding to make a game, the EP has to create a prototype. The word carries a very different connotation in 2010 than it does today. In 2010, prototypes can cost two to three million dollars and employ a dozen people for six months to a year. A prototype is a five-minute game experience that sells the game development project, both within the publishing company as well as to retailers and to the press. The prototype is high on flash, high on polish, and high on hype. The majority of game development projects still get eviscerated at or before the prototype stage, so there's great incentive to make this prototype as tony as possible. The EP refines his pitch to go with the timing of the prototype sequence: "Look, the skin quality is right up there, best we've ever done. We want to give this title an A-plus treatment. We're figuring two million sell-through in North America, but focus tests say the Japanese are really going to go ballistic over it, two million plus there." Technical design documents still exist, but only the engineer that writes them will ever see them. In 2010 they're a bookkeeping formality, and the proof the game can be done is in the prototype.

Building a prototype represents guaranteed money to small game developers, and so there's plenty of competition between developers for a prototype contract. Developers ostensibly compete based on reputation and their library of finished games, but a few developers finance proto-prototypes out of pocket in order to get an edge during their bids. Developing a prototype also usually means that a developer will receive the contract to develop the game. However, this isn't always the case; the publisher retains all rights to any source code created in the development of the prototype, and if the prototype is accepted, the EP may decide to simply airlift the prototype code and assets to another developer or to an in-house team for completion.

If a prototype game project is approved, a development team must be bulked up to build the actual game. A typical high-profile game project in full swing employs around 100 full-time artists, programmers, and effects people. Because of the sudden and radical demands for headcount, in 2010 the majority of game artists and programmers are now contracted for a specific game project, and not hired as full-time employees. Movie people have worked this way for decades, but in 2010 many older game industry types have found it hard to make the shift to being project employees.

All game engineers and artists in 2010 are highly specialized. There are fire-effect engineers, insect AI engineers, 3-D audio spatialization engineers, and bicycle physics engineers. There are texture artists, lighting artists, camera artists, and character artists. Because recent development experience is highly prized in 2010, it's dangerously easy to become stereotyped into a specific development role after working on a game project.

In 2010, the larger size of development projects has forced the adoption of some new project management principles. Bug fixes and game design changes are all lumped in together into generic "change requests." An assistant producer maintains a database of change requests for the current game design: "More smoke in level two," or "The gremlin AI needs to respond better to the player hiding behind a corner," or "The game crashes when you go to the inventory screen." A continuous build process monitors all game code and art changes. If an artist or an engineer happens to check in a change that introduces a crash bug, their change is automatically backed out and their supervisor receives a warning via e-mail. Otherwise, the EP is automatically notified when a change request is claimed to be present in the most recent build. He may rubber-stamp the change request as being to his liking, or, more likely, he'll recycle the request with comments, precipitating another round of change requests. Art assets are tracked as scrupulously as code assets, and software enforces a design-implementation-review sequence before a modified character model appears in the latest game build.

Scheduling and budgeting this development style in 2010 requires a Zen sort of mathematics in which you project the completion dates, not based on any design document, but rather on previous trends and measured rates of work completion. The terms alpha, beta, and final, holdovers from an oldthink software development model, still remain in use, but they have new meanings in 2010:

al-pha (adj.): 1. The time at which the lead programmer does not want to make further changes: "Jordan finished the level loader four weeks ago, so I think it's probably alpha by now."

be-ta (adj.): 1. The time at which the executive producer does not want to make further changes: "We won't want to touch the physics system after it goes beta."

fi-nal (adj.): 1. The time at which the executive staff does not want to make further changes: "Why hasn't that game gone final? We need it at Wal-Mart by Thursday!"

It follows, based on these definitions, that different parts of a single game could go alpha, beta, or final at different times. In 2010, this conclusion is not perceived as inherently self-contradictory.

In 2010, no single engineer or artist has ultimate responsibility over any specific area of the game. After years of dealing with touchy art types and technocratic programmers, game publishers have more or less commoditized these peoples' services. If a programmer is lazy or unreliable, he is summarily replaced by another contractor with minimal impact to the schedule, and if necessary the offending programmer's changes are backed out. Despite the so-called wisdom of the last century, in 2010 adding programmers to a late game project speeds it up, or at least it provides that impression to the publisher's exec staff.

One particular aspect of the industry hasn't changed in the past twenty years. From reading the trade magazines in 2010, you would think that you could build a game by buying off-the-shelf software components and art assets, and simply duct-tape them all together into a first-class game. You can buy pre-made libraries for fluid modeling, human-body movement, monster AI, flocking, and facial animation. You can also pay a couple hundred bucks for stock-library motion-capture files of common physical activities, and they claim to run on any game platform and "let your team concentrate on gameplay." Few industry people take these advertising claims seriously in 2010. The best artists still tweak motion-capture data by hand, and the best programmers still bash registers in order to get the best performance when rendering NURBS surfaces with lattice deformers.

If you have talent, and you're willing to spend the extra time drumming up new business, it's still possible to make a very comfortable living in 2010 by building videogames. The work is irregular, but the high pay rates for the busy periods help to compensate for the slow times. Many talented older industry people, comfortably employed back in 2002 but disfranchised by the sea changes in the development process, have left the games industry to find more boring careers with steadier paychecks.

The sound of my computer haranguing me, beep-beep-beep-beep. Wisps of gray-blue light filtering through the windows beside my desk. I unwedged my nose from behind the space bar, half-expecting to see the sun rising over the Bay Bridge, but it was only the neon ghost-glow of the Sony Metreon.