Write a blog, get a free book!

I knew this blogging thing would pay off. I was just sent Game Coding Complete by Mike McShaffry and all I have to do is write a review of it, something I usually have to buy the book to do.
A quick visit to MobyGames shows that "Mr. Mike" has some serious titles under his belt, and in this one case, the adage "Those Who Can't Do, Write" is disproved. (Good thing, otherwise I'd be in trouble.)
First off: I wish I read this book a year ago for the advice on page 560: how to archive your final build. It would have saved my team several man-days.
Second off: this book, like no other I've read, captures what it's really like to be a professional videogame programmer, covering not just some of the basic coding practices unique to games but also hitting asset control, directory structure, resource management tools, middleware, testing, and scheduling. For someone just starting at a game company, it would be a really good way to prepare for what they're about to experience.
Third off: Mike develops games for the PC. If you develop games for the PC, I'm pretty sure this book should be in your library for Chapter 11 alone, where he covers the requirements for getting your Windows Logo. (If only someone could do the same thing for the console manufacturers' technical requirements without getting sued.)
His advice is particularly suited for PC development, but not suited so well to developing for consoles: he's big into templates, and STL, and writing your own memory managers, and cacheing resources, and although he warns against the use of inheritance he dives right down and uses it anyway. All of these things are things which you can (usually) get away with on the PC, but you need to think long and hard about using when you're developing for a console.
Reading this book I can almost imagine why Ultima VII and VIII turned out the way they did; they're imbued with Mike's personality. (Or he's imbued with theirs?) These were incredible, ambitious games, way ahead of their time. But you needed a top of the line machine to run them, and even then you'd encounter occasional performance problems, and bugs. You could just tell, somehow, playing these games, that they were using C++, that the various objects in the gameworld were instances of C++ classes, and there was inheritance and polymorphism going on, and the games both benefited from this practice and paid a price for it.
My favorite setions were the "Tales From The Pixel Mines", where Mike tells war stories from titles he's worked on. Some of them were educational - so that's how Origin used to do things - and some of them were nostalgic. (In particular one on page 449 involving Borland's 3.1 C++ compiler. After reading it, I had to go share it with someone, but I couldn't find anyone around actually old enough to remember that compiler.)
There's a spiel from project management I never get tired of reading. It goes something like this: "Almost all projects come in late and require egregious overtime, but if you plan in great enough detail and schedule thoroughly, you can avoid this." Chapter 13 is Mike's attempt at the spiel, and of course I found myself nodding my head and saying, "Speak it, brother." Then I snapped out of it. Only clones and ports and casino games (I did a casino game once, too, and shipped that one on time also) can really be planned in this manner. If you're making an original game, your plan will not survive contact with the enemy. Mike knows this, and even points out that despite having a schedule, Ultima VII still came in late.
I'm sounding like one of those chaotic, seat-of-your-pants developers right now, and I'm not. A plan is good. A schedule is necessary. Mike's advice in this chapter is all very sound (except when he suggests using Project instead of Excel to do your scheduling) and mirrors the advice of Eric Bethke and Joel Spolsky. (All three of these developers point out that the worker needs to estimate their own schedule. I concur. That makes four of us.) On my project, we're not currently scheduled with the same rigor Mike suggests...but I may just up the ante after reading this.
And some final, random, last comments: he's got a technique for a pseudo-random traversal of a set that's very cool. Pete and Don did this on Magic Candle II to make a sparkly Star-Trek-like teleporter effect and I never understood it. I still don't understand it, but now I have sample code. On the other hand, he's got a template for an "optional" variable for building validity right into a variable that I don't like at all. I'd much rather write a brittle system - fail if someone uses it wrong - or use what he calls the "first dumb method to return an error code" (although I'd have it pass to a pointer instead of a non-const reference. Steve Maguire doesn't think is so dumb) then use his Optional class. On the gripping hand, (yes, I'm a geek) he describes how a resource management tool should ideally work, and I wish ours worked in just that way.
So that's that. Free book earned. If you're making PC games, read the book. If you're making console games, it wouldn't hurt to take a look at it.

Up in San Luis Obispo this weekend, visiting old college friend Lewis Call. His girlfriend recently got a job at Oddworld so she showed us the place and took us to a barbecue thrown by some of the Inhabitants. Had to sign an NDA first, so I'm not going to divulge what I learned. Me, personally, I haven't yet played Abe or Munch all the way through but I really liked them: simple elements combine into interesting puzzles. I admit it, I like puzzles. The very fact that you don't have a gun and you have to find nonobvious, subtle ways to get past each encounter pleases me greatly, much like the people who play Quake "naked". But I think my aesthetic may be in the minority; as Neal Hallford says, one of the most common types of player is the guy who just wants to frag shit.

Visiting postmodern history professor Lewis Call exercises a different part of my brain. Here's my latest half-baked theory: in the seventies and early eighties, the media--particulary movies--portrayed robots and computers as evil, but that changed in the early eighties and nineties. (The change was best illustrated by the transition from Alien to Aliens and Terminator to Terminator 2. Suddenly the simulated human is the good guy.) In the seventies or eighties, the majority had yet to experience the benefits of computers and were afraid of what they didn't understand. Similarly, right now, we see anti-simulation movies: The Matrix, Existenz, Dark City, The Truman Show, Thirteenth Floor, representing the majority's fear of videogames. As more come to understand and accept videogames, we may start seeing films where simulation is good, where people enter the Matrix voluntarily and aren't considered to be betraying their species.