There are plenty of factors that make game coding a fluid and unpredictable task. The design of the game frequently changes drastically during development, motivated by many factors inside and outside the development team. Mounting schedule slippage and production pressure leads to the legendary "crunch mode" so prevalent on many game projects. Dependant software tools like DirectX change constantly, challenging software teams to keep up. Unlike many software projects, games frequently must support a wide variety of operating systems, graphics APIs, and platforms.
Most industry software projects are carefully designed and planned. Systems analysts study customer requirements, case studies of previous versions of the software, and prospective architectures for months before the first line of code is ever written. Ultima VIII's architecture was planned by seven programmers in a single afternoon on a whiteboard.
Architecture notwithstanding, you can't design "fun." Fun is a "tweakable" thing, not something that exists in a design document. You hope like hell that the original design will result in a fun game, but the first playable version frequently leaves you with the distinct impression that the game needs some more chili powder and a little more time on the stove.
|A Tale from the Pixel Mines|| |
Ultima VIII's map design had a hub and spoke model. The hub was an underground dungeon that connected every other map. We released the game to QA and word came back that it was completely boring. The culprit was a sparse central map that wasn't much more than an underground maze with a few bad guys hanging out here and there. It wasn't good enough. Two designers worked day and night to rework the central map. Puzzles, traps, monsters, and other trickery finally added a little spice. The central map ended up being one of the best parts of the whole game.
Sometimes, the entire design is reworked. Ultima IX's architecture and game design changed no less than three times in development. I was there for two of them, and didn't stick around for the third. When a game is in development for multiple years, it's easy for new hardware technology to blaze past you. In Ultima IX's case, 3D accelerated video cards were just coming into their own as we were putting the finishing touches on what had to be the finest software rasterizer anyone ever wrote. It never saw the light of day.
Every now and then you end up at a technological dead end and have to start completely over. I was brought into the late stages of a Mattel project that was supposed to be in the test phase in about two weeks. I took one look at the code and realized, to my horror, that the entire graphics engine was using Windows GDI. Unless someone out there knows something I don't, the GDI can't texture map polygons. In less than five weeks the entire project was rebuilt from scratch.
Those five weeks were really more like fifteen weeks. The tiny development team worked late into each night and dragged themselves back each morning. There were no weekends. There were no days off. I'd estimate that we worked 90 hour workweeks on that project. You might think that unreasonable, and that nobody should have to work like that. That project was only five weeks. It was nothing compared to the pixel mines of Origin Systems circa 1992. Back then Origin had something called the "100 Club." The price of entry was working 100 hours in a single work week. The last time I counted there were only 168 hours in seven days, so the folks in the 100 Club were either working or sleeping.
|A Tale from the Pixel Mines|| |
To facilitate a grueling schedule the teams built bunk beds in the kitchen. Company kitchens are no place for bedding. My office was unfortunately located right across the hall, and I observed the kitchen/bedroom was getting higher occupancy than the homeless shelter in downtown Austin. After about a week I began to detect an odor emanating from across the hall. It seemed that the brilliant organizers of Hotel Origin never hired a maid service, and that an unplanned biology experiment was reporting its initial results via colorless but odorous gasses. Origin management soon liquidated the experiment.
It's not uncommon for companies insisting on long hours from salaried employees to provide meals. These "crunch meals" were usually ordered out and delivered to the team. Origin was able to get a local deli to bill them instead of requiring a credit card, so they began to order from them almost every night. Months went by, and everyone on the development team knew every item on the menu by heart, and knew exactly which bits of food were most likely to survive delivery intact. Ten years later I can still tell you what's on the menu at Jason's Deli, and even though the food is good, I rarely eat there.
Computer games are a seasonal business. They sell like crap in the summer, and profits soar at Christmas time. Of course, they only soar for your project if you're not still working on it. This puts a significant amount of pressure on development teams. Sometimes the pressure begins before the team begins working. Every game contract I signed stipulated specific schedule dates simply to make sure the boxes would have enough lead time to get built, shipped, and on store shelves.
This lead time varies from publisher to publisher. A big company like Microsoft has a huge manufacturing pipeline that includes everything from Bicycle Casino to Windows XP. Bicycle Casino was one of mine. I'll bet that if you were standing on the assembly line you'd be hard pressed to notice the brief flash of dark green as 50,000 boxes of the casino game whizzed by. You shouldn't be surprised to see a publisher like Microsoft requires you to finish your title by mid-summer in order to make the shelves by the holiday season.
Other publishers are more nimble, and they might be more accommodating if you've got a AAA title coming in hot and steep as late as November. You won't get the best sales if you release after Thanksgiving, but even getting out the week before Christmas is better than missing the season altogether. It's always best to have everything in the can before October if you want to see your game under Christmas trees.
Basically, Christmas is only merry if you're game is done.
Microsoft Excel doesn't need to support full-screen modes and it certainly doesn't need to worry about whether the installed video card has hardware-accelerated transform and lighting (also known as hardware T&L). That's one of the reasons that games get some special dispensations from Microsoft to qualify for logo compliance. Logo compliance means that your game exposes certain features and passes quality assurance tests from Microsoft. When your game passes muster you are allowed to display the Windows logo on the box—something that is good for any game but especially important for mass-market games.
The Microsoft projects we developed had to pass QA testing for Windows 98, Windows ME, Windows 2000, and all versions of Windows XP. By 2002 Microsoft wasn't supporting Windows 95 anymore, which was a good thing. It was hard enough building an old box for our Windows 98 test machine. The OS that required the most tweaking was Windows XP, mostly because of the new requirement that the "Program Files" directory was essentially read/only for non-administrator accounts. Most games store their dynamic data files close to the executable, which will fail under Windows XP Home.
There are so many of these annoying changes and differences from one operating system to the next that I've included a whole chapter in this book about that. The hell doesn't even stop there—some games choose to write graphics engines that work under DirectX and OpenGL. Some graphics middleware supports this natively, so you don't have to worry about it. Why would you bother? Performance.
Most video cards have DirectX and OpenGL drivers, but it's not guaranteed that you'll achieve equal performance or graphics quality under both. The performance differences are directly proportional to the effort put into the drivers, and there are cases where the OpenGL driver beats DirectX soundly. Of course, there are mirror cases as well, where DirectX is the way to go. Even better, the quality of the drivers change from operating system to operating system. The result of all this is a huge increase in effort on your side. Even if you choose one particular graphics API you still have to support a wide array of operating systems. This increase in effort simply widens the market for your game. It doesn't make your game fun or provide a deeper experience. It just keeps it from misbehaving on someone's computer.
I almost forgot, what about Linux? What about Mac? They are still tiny slivers of the gaming market. Linux is growing quickly and there are people out there with Mac computers. The question about writing a cross platform game for these operating systems is more logistical and financial than technological. Most game projects can be ported to similar platforms with a tolerable dose of programming hell.
Moving games to very dissimilar platforms can be nigh impossible, such as a direct port of a PC game to a console. The lack of a keyboard, lower screen resolution, and tiny secondary storage preclude some games from ever appearing on the console. That doesn't even begin to address the inherent design concerns that differ sharply from consoles to desktops.
The game industry, for all its size and billions of dollars of annual revenue, is not the most stable employment opportunity out there. You can almost guarantee that if you get a job in the industry you'll be working with a completely different set of people every two years or so, and perhaps even more often than that.
|A Tale from the Pixel Mines|| |
Every year at the Origin Christmas party, employees were asked to stand up as a group. Everyone who had worked there less than a year was asked to sit down, followed by second and third year employees. This process was repeated until only a handful of people were left. This was usually by the fourth or fifth year. In my sixth year, I became the twelfth most senior person in the company by time of service, and Origin had hundreds of employees. This is fairly common throughout the industry.
The stresses of incredibly short schedules and cancelled projects have chased many of my friends out of the industry altogether. Whole studios, including two of my own, take root for a while and then evaporate or get bought. Your boss today will not be your boss tomorrow, especially if your boss attempts to do something crazy, like start their own game studio!