Times Have Changed

Could you imagine playing BioShock with a joystick?  “Thief: The Dark Project supported joysticks,” says designer Alexx Kay.  “There was this extremely vocal fan on Usenet who kept asking for joystick support.  Thief wasn’t designed to work with joysticks because they were on their way out, but a programmer decided to humor him.”

Blogs, Facebook, forums and search engines didn’t exist fifteen years ago, and the primary tool to communicate with your fan base was the local bulletin board system (BBS) or Usenet and newsgroups services.  “You could go through Usenet groups such as comp.sys.ibm.pc.games.rpg or rec.games.computer.ultima-dragons to find fans of your game,” remembers Kay.  “The web now is fragmented with dozens of places to find discussion about a specific product or subject.  Usenet provided a very specific location for fans congregate to talk about a product.”  Reading a long list of discussions and replies provided an experience similar to the on-line communities of today, but on a much smaller scale.

The tools to create games have changed dramatically in the last decade, as have the responsibilities and sizes of departments.  “Photoshop didn’t have layers when I started,” says Lead Artist Shawn Robertson.  “3D Studio was a program in DOS and no game required 3D acceleration.”  Most games at the time were still being done in 2D, but everything started to change with the releases of Wolfenstein 3D and Duke Nukem 3D.  This change accelerated rapidly with the release of 3Dfx’s Voodoo 3D graphics cards at the end of 1996, and glQuake in early 1997.  “As an artist I did everything when I started,” Robertson adds.  “I modeled, textured, animated, rigged, and did FX for those first games.  Now everyone is much more specialized and focused on a specific role. We shipped SWAT 4 with five people in the art department.  We now have over twenty-five artists working on Project Icarus and we are still growing.”

As games evolve, their budgets grow. They require more staff, more assets, and more time to complete.  “My first game was made for the astronomical sum of one million dollars,” Director of Product Development Tim Gerritsen remembers.  “It was considered a AAA title at the time and we had a staff of 12 people to work on it.  Many of us were kvetching over how unbelievable the development budgets and the team size were.”  It isn’t uncommon today for games to have staffs of well over 100 people working for two or three years on a single game.  “We had to change the way we worked and some of us had to become managers,” says Gerritsen on how growth has changed roles for people on the team.  “We had to learn how to be a business.”

It wasn’t long ago that games were shipping on 3.5” floppy discs.  “I worked on a game that fit on three floppies,” says Gerritsen.  “That is a whopping 4.32 megabytes of compressed data.  We’d have programmers working on fancy animation systems for weeks to cull every extraneous bit of data to fit our game into those 4.32 MB.”  For perspective, a typical mp3 file is around 5 MB.  Games today can ship on a dual-layer DVD holding 8.5 gigabyte (8,704 MB) and sometimes even using a 50 gigabyte (51,200 MB) Blu-ray disc.  The amount of data is staggering, and all that data needs to be processed to fit onto that disc.  “The build process on The Lost took about 20 hours to complete,” says Lead Programmer John Abercrombie.  “It was a ridiculous setup that included a script that automated mouse movement and button presses since the application didn’t have a command line interface.”  A build process involves taking all the raw assets such as models, textures and sounds, and converting them to a format the game understands.  Depending on the game, this could be tens or even hundreds of thousands of assets.  “There is nothing worse than going through a 20-hour build process to find a blocking bug once you load the game up,” says Abercrombie.

As the amount of data in the final game grows, so does the revision database.  “I had a meeting with the IT department to discuss how large our Perforce server should be for our first next generation game,” remembers Senior Technology Programmer Steve Anichini.  Perforce is a program that builds a database that stores every revision on every asset in the game.  “We estimated it would take one terabyte (1,048,576 MB), which at the time was unheard of.  The IT department was rather skeptical the project would need that much space, especially compared to games from the previous generation which were only a couple hundred gigabytes.  By the end of the project the Perforce database was well over two terabytes,” says Anichini.

As for my own experience … when I started as a game tester back in 1998, I had to write all my bugs on sticky notes, as the company didn’t have any extra computers for the testing department.  The sticky notes were handed to the test lead, who would then add them to the bug database — which at that time was an Excel spreadsheet.  Compare that to the 35,000 bugs written up on BioShock, which would span 1.5 miles if they were to be written out on sticky notes!