The Bad
Every job has its good parts and bad parts. Game programming is no different. First of all, game programming is hard. I could easily argue that programming games is the most challenging form of programming there is. Bad things are a matter of perspective; some people find these things challenging while others find them burdensome. You'll have to judge for yourself.
Game Programming Is Freaking Hard
It's not uncommon for a game programmer to do something completely new without losing any time on the development schedule. I'm not talking about a modification of a data structure to fit a certain problem; I'm talking about applying experimental and theoretical designs to a production system that meets deadlines. On Ultima VII one programmer wrote a 32-bit memory management system that was based on a little known Intel 486 processor flag and hand coded assembly, since there were no 32-bit compilers. On Ultima VIII one of the low-level engineers wrote a multithreaded real time multitasker two years before Win32 went beta. On Ultima IX the graphics programmer figured out how to make a software rasterizer appear to pump 32,000 textured polygons per second on a first generation Pentium. Everyone knows what Ultima Online did. I can't even begin to talk about the innovation that had to happen there just to get this system to work.
It would be one thing if this stuff were all research, where results come when they may and the pressure is bearable. A game project is different because the schedule is relentless. For all the media press about how late games are, I'm surprised that you see some of them at all given the level of difficulty.
| A Tale from the Pixel Mines | Technology isn't the only thing that makes game programming hard. Game designers will push you farther than you ever thought you could go. I remember very well a conversation the senior staff at Origin had with Richard Garriott about the world design for Ultima IX. The team was pushing for a simple design that was reminiscent of the old Ultima games—the outdoor map was separate from the city maps. This was a simple design because each map could be loaded at once and no complicated map streaming would be required. Richard didn't go for it. He wanted a seamless map like Ultima VII. This was a much harder problem. We knew going into the meeting that if we couldn't convince Richard to use a simpler world design we'd have a hard time making our deadlines. We steeled ourselves with resolve, and armed with our charts and graphs and grim schedule predictions, we entered the conference room. Two hours later we all walked out of the room completely convinced that Richard was right, a seamless map was the way to go. I wish I knew how he does that! |
Bits and Pieces
Games are built from more than code. Go find any PC game you bought recently and take a look at the directory where you installed it. You'll find the expected EXE and DLL files, with a few INIs or TXT files too. You'll also find gigabytes of other stuff with file extensions that don't necessarily map to any program you've ever seen. These other files hold packages of art, models, levels, sounds, music, and game data. This data didn't just fall out of the ether. Every texture was once a BMP or TIF file. Every sound was once a WAV, probably converted to MP3. Each model and game level had its own file too, perhaps stored in a 3D Studio MAX file. Even a small game will collect hundreds, if not thousands, of these bits and pieces, all of which need to be cataloged and organized into a manageable database of sorts.
No other software project has this problem. The only thing that comes close is a web site, and there just aren't that many assets. After all, they have to get sent over the Internet so there can't be that many. Certainly, not enough to fill up a DVD, and a compressed one at that.
| Gotcha | Logistically these things can be a nightmare to manage. I've worked on projects where an artist wiped every file he'd worked on without even knowing it. Art files would get changed on the network but wouldn't get copied into the build, or even worse the artist would change the name of a file and it would get lost forever. When you have thousands of files to look though it's sometimes easier to just repaint it. Luckily there are some tools out there to help manage this problem. The situation is certainly better than when I started, where I think our best management scheme was a text file. |
That's Not a Bug—That's a Feature
Actual Bug: I was walking along and the trees turned into shovels and the Avatar turned into a pair of boots and then the game crashed. You certainly won't see a bug report like that working on a database application. Seriously, some of these reports convince you beyond any shadow of doubt that the testers have their very own meth lab. As hard as I looked, I never found it.
You might wonder why I put something so amusing in the "bad" section of working on games. There are plenty of funny bugs; stuff goes wrong in a game and has a bizarre result. Luckily Quality Assurance (QA) should find it because it will be funnier for you as a developer than it will be for a player whose crashed game just lost a few hard hours of play.
Beyond the funny bugs, there's a dark side.
One bad thing is just the sheer volume of bugs. Games tend to be rushed into testing and the QA department obliges the producer by writing up every little thing they see. That is, after all, their job. I think they hope that eventually the producers will get the point and stop sending proto-ware into the test department. They hope in vain because the pressure to call the game "testable" is usually too much for the project management to bear. It's too bad that there tends to be no solid definition of "testable" unless you work in QA. From that point of view, it's pretty obvious.
The heavy bug volume weighs on everyone, developers and testers alike. They end up creating a logistical nightmare. The graphical reports that get spit out by the bug database are watched like the stock market; where a steep upward curve tends to have a negative effect on team morale. The worst part by far is what happens when the team can't quite keep the bug count under control, which is most of the time. The project leadership gathers together in a locked office and "fixes" bugs without ever touching the project. The bug simply becomes a feature, maybe a weird screwed up annoying feature, but a feature all the same.
| Gotcha | There's nothing like having the rug pulled out from underneath you because of a bug that you intended to fix simply disappears. You might even have the code fixed on your machine, ready to check in for the next build. Instead, you get to undo the change. The final straw is when some critic on the Internet bashes the programmers for writing buggy code, and even points out the very bug that you intended to fix. Most programmers I know are perfectionists and take a lot of pride in their work, and because of that they lose sleep over bugs. The evil truth is that some bugs can't be fixed, even if they seem simple or benign. |
The Tools
Richard Garriott, aka Lord British and creator of the Ultima RPG series, once said that the computer game industry was a lot like the movie industry. He also said that at the beginning of every game project we start by inventing new cameras, film and processing techniques, and projectors. He said that ten years ago, and while there is some middleware out there for sound and graphics, most game projects end up writing their own development tools.
Almost every game development team will end up writing tools to pack their graphics and audio data into resource files of some kind. WAD files are a good example of this. These files act like efficient databases for all media assets and game data, and are usually pre-converted to optimize loading speed or memory space. These files don't just manage themselves, and no one that I know uses Microsoft's CAB files. You'll have to write a custom tool to build and manage these proprietary files.
| A Tale from the Pixel Mines | Most games have level or mission editors. When we developed the Ultima games we spent the first year or so of development writing the game editor—a tool that could import graphics, sounds, and models from all the third-party packages like Photoshop, Lightwave, 3D Studio Max, and others. Ultima IX's level editor was fully networked and used TCP/IP to communicate peer/peer to all the designers and programmers running it. They could even edit the same map at the same time, since smaller portions of the map could be locked out for changes. The editor could launch into game mode at the press of a button, so the designer could test their work. Ultima Online's editor was much more like the game than Ultima IX. UO already had a client/server system up and running and it used a special god client to change the map levels and add new assets to the game. |
Other games use a simpler strategy, a wise choice if you don't need twenty people building seamless maps and levels. The basic game level is assembled in a modeling tool like 3D Studio Max. A special editing tool usually loads that level and drops in special actions, dynamic object generators, and characters, almost as if you were playing the game. There's no need to have a complicated, multi-person aware tool if the levels are discrete entities as they are in most video games.
The first comprehensive level editors are starting to appear in middleware, most notably Criterion's Renderware Studio. Could the days of creating custom level and mission editors be over? I doubt it. These tools may give you a huge leg up, but you should expect quite a bit of customization in your schedule.
