Foreword

By Warren Spector

Let me start by admitting a couple of things. First, I've never written a foreword for a book before. I've written books but never a foreword. Honestly, I usually skip right over these things when I'm reading a book so, odds are, no one is ever going to read what I'm writing here anyway. That makes it safe for me to move on to admission number two: I'm not a programmer. Never have been and, I fear, never will be, despite some valiant efforts on my part (if I do say so myself).

I've done okay despite not knowing a blessed thing about programming. I'm not looking for sympathy or anything but I am here to tell you that a day doesn't go by when I don't think, "Damn, if only I knew my z-buffers from my BSP trees!" If you're already a programmer, you've got a huge leg up on me, when I tried to get into the electronic game biz! (And if you're not a programmer, do as I say and not as I do—learn to program ASAP. Mike has some advice about how to do that in the pages that follow. Pay attention.)

Okay, so with those two confessions out of the way, I figure there's a fair chance any credibility I might have had is pretty well shot. Luckily for you folks, the guy who wrote this book has credibility to burn. Mike McShaffry (or "Mr. Mike" as he's known to most everyone in the game biz) is the real deal. Mike is a genuine survivor. He is a guy who can talk the talk because, Lord knows, he's walked the walk enough times to earn some talking time.

Mike's experience of game development runs the gamut in a pretty remarkable way. He was there when teams were a dozen folks and he's been around in the era of twenty, thirty, and fifty person teams. He's done the start-up thing, worked for the biggest publishers in the business, worked on "traditional" games and decidedly untraditional ones—everything from Ultima to Blackjack, singleplayer, multiplayer, online and off and just about everything else you can imagine. When it comes to PC games, he speaks with the authority of someone who's worn just about every hat it's possible to wear—programmer, designer, project leader, director of development, studio head…

And I've had the privilege of watching him learn and grow with each new project and each new role. I was there when Mike got his first game job. I was one of the folks at Origin who interviewed him back in the Bone Ages, back in the 20th century, way back in 1990, when he applied for a programming job at Origin. (Seems like forever ago doesn't it, Mike? Whew!)

He started out as "just" a programmer on Martian Dreams, a game I produced for Origin, but by the end of the project he was the engine that drove that game to the finish line. The game wouldn't have happened without Mike. His drive, dedication, love of games, knack for on-the-fly design, natural leadership skills, ability to combine right brain and left brain (to say nothing of his willingness to work crazy hours), drove all of us to work that much harder and ensured that the game ended up something special (at least to those of us who worked on it together—it sure didn't sell many copies!).

I honestly don't even remember if I ever gave Mike the title "Lead Programmer," officially, on Martian Dreams, but he sure deserved it. The guy was a machine, working longer hours than most people I've worked with (and that's saying something, in the game business). He also managed to do more and better work in those hours than any human being should be allowed to. It just ain't fair to the rest of us mere mortals. When Mike was on, there was no touching him. And he was almost always on—after Martian Dreams, Mike did it again and again, on Ultima VII, VIII, IX and a bunch of others. Scary really.

In retrospect, all those hours and all the hard work that seemed so necessary, back in the day, when we were all younger and more foolish than we are now, was probably an indication that Mike, like the rest of us, didn't have a clue about software development or game design or much anything else. (Okay, we had a pretty good handle on the effects of sugar and caffeine on the human body, but that's about it.) We had to work so long and so hard just to have a chance in hell of ending up with something worthwhile.

Reading this book, I couldn't help but marvel at how much Mike's learned over the years and wonder how much more Mike—and the rest of us—would have gotten done, how much better our games might have been, if we'd had the benefit of the kind of information in the pages that follow. There just wasn't anyone around back then who knew enough about games, programming practices, and software development. We were making it up as we went along.

Today, there are plenty of books out there that can teach you the typing part of programming. There are even some books that go a bit further and teach you what makes game coding different from coding a word processing program or a billing system for your local health care providers (or, as we used to call 'em, "doctors"). But even now there just aren't many books that combine hardcore game programming advice with equally hardcore development process, scheduling, debugging and team-building information.

Development process? Team-building? Who cares about all that? You just want to write code, right? If you're like a lot of programmers I know that's just what you're thinking. And, man, are you wrong. There might have been a time when coders could just close their doors and type, not caring about how their work fit into the big picture of a game's development. Maybe that was true ten years ago or more (probably not, but maybe…). Well, it sure isn't true anymore. With teams getting bigger all the time, with timelines stretching and budgets bloating, process and team issues are everyone's concern nowadays.

Mike gets that, something that becomes clear in the very first chapter, when he says, "Being the best developer you can be requires that you have intimate knowledge about the real demands of the industry." Amen, brother. That, in a nutshell, is what makes this book special. Most people think enthusiasm and talent are enough to get them into the game business and to ensure success once they land that all-important first gig. "I play games all the time," they say, "and I'm a kickass coder, so what more is there to know. Sign me up!"

Well, I'm here to tell you that there's plenty more to know and that's probably the single most valuable lesson this book has to offer. Games are insanely complex, and their creation involves a unique combination of art and science (some call it "magic" and they're not far wrong). Game development is demanding in a way that can only be appreciated after a stint in the trenches. At least, I used to think that was the case but that's where Mike comes in. Having been in the trenches, he can save you the trouble and pain and scars and relationship breakups and company failures that all too often go along with game development. No matter what you may think, it isn't all glory, fame, wealth and intense personal satisfaction (though there is a better than fair share of that last item…).

There's a ton of great stuff in Mike's book. Even if you're a non-programmer, you'll get something out of the introductory chapters and the section about "Professional Game Production." And I love all the insider bits found in Mike's tales from the "pixel mines."

Of course, there's plenty of nuts-and-bolts stuff for folks who are already programmers but want to know what makes game programming so special (and believe me, it is). But even programmers will benefit from the other ton of stuff that often gets short shrift in the typical programming book—all that Big Picture stuff that doesn't involve code samples.

What's a game team look like? How do you structure development? How do you cost out your part of a project and schedule it? What can you do as an individual to make it more likely that your team will make its milestones? And Mike does a really nice job of outlining the ways in which projects, project needs, team structures, and schedules change at various points in a project.

These are critical to being the most effective developer you can be, whether you're a programmer or not. This is all stuff you can't get just anywhere. You have to have lived through the process (and the pain!) a bunch of times. Or you have to find a mentor and spend years sucking his or her brain dry. Or you can stop reading this foreword and start reading this book.

What are you waiting for?

Warren Spector
April 2003