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
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.