Game Coding Complete, Third Edition [Paperback]

Unfortunately Mr. McShaffry fell into the same pitfall most other "here's THE right way to write code" authors fall into: he just has too many opinions and not enough facts. He touches on a lot of subjects which are programming religions, and there is no objective right or wrong for much of what he discusses. I feel some of the problem lies in the fact that McShaffry has worked on two types of games: the Ultima series and a playing card game. If you work on one codebase for years, you're going to think your solutions are perfect. As a person who has worked on numerous different types of games and engines I can tell you that there is no magic solution for writing the perfect engine. The engine is always very heavily tailored to the game desired. This is why you hear about the Quake engine, or some other third-party technology, being licensed and then gutted with major portions rewritten. So most of McShaffry's game-specific ideas need to be taken with a grain of salt. An example: smart pointers sure are safe, but if you're working on the PS2 you probably can't spare the memory or execution time for all that tracking.

I also disagree with his opening statements about variable and function naming. This is a constant headache for development teams, particularly game dev teams whose programmers are mostly self-taught. But just saying "Hungarian is useless!" is ridiculous. Sure Visual Studio tells you the type of variable, but this works maybe half the time (it is incredibly easy to confuse Microsoft's Intellitype), and not everyone uses VS. If a person is more comfortable in Emacs, should they be forced to change editors just to get context information on a variable? Is one to three letters of information in front of a variable name really that hard to type?

Those are just a couple of examples for the sake of brevity. My main objection about this book is that I don't feel I learned anything by reading it. I just read Mr. McShaffry's opinions about a few things, some of which had merit, but most of which weren't supported by any factual or reasonable data. They are just opinions. I did agree with his statement that all objects should have a stream-constructor defined; having tried to graft in "save anywhere" to two engines I can attest to the usefulness of this type of planning ahead. But other than that the book is mostly useless to me.

People new to the industry or curious about it might find it exciting to read tales from the trenches. And if you're a pro, I would expect your enthusiasm for the book to be directly relative to how closely your opinions match Mr. McShaffry's. But frankly I wouldn't recommend most of his ideas over anyone else's. Maybe it's the title that grates on me - perhaps a better title would have been "Game Coding: One Man's Opinion"

I've bought many game programming books over the years, and two authors stand out... Mike McShaffry and Andre LaMothe. This book is incredibly valuable as a reference and as a guide. Quite honestly, I wonder who paid the guy who wrote the "Spotlight Review" to dis it so badly, or who he paid to get his opinion in the spotlight.

But here's a test you can take for yourself... go to http://www.mcshaffry.com/GameCode and see how Mike McShaffry is *still* helping folks who've read his book, (or anyone who post on the site for that matter). He's still giving *free* advice on his book's forum, when most other authors won't even respond to an email.

In response to those who objected to the author's "coding opinions":
Yes, the guy has an opinon - he's entitled to. What do you expect from a book? "well, this is probably wrong, and I don't really know what I'm talking about, but the publisher paid me a lot of money so I have to say something." Give me a freaking break! OF COURSE the book is full of opinions - that's what books are!

Just one caveat - it doesn't teach you C++. It assumes some experience, meaning you can take the coding advice and apply it to suit your own style. It does assume a basic level of professional ability in other words.

IMHO this book is geared toward those who want to make a professional career in making games, but have no idea how, while at the same time teaching concrete principles of game programming to those like me who are currently hobby coders. Many times had I tried and failed to start developing a game, but I am now building my game intelligently and efficiently, knowing exactly what I need to do to get things done. I have to say it is all because of this book.
This is also one of the few books that has managed to grip my attention for as long as it did because of the clever way that Mike writes. His writing style is such that it is easy to read because of its almost informal nature. The text thankfully lacks rigid structure, and welcomed breaks in the lessons of "how and why" are made up of "I remember the day" stories that are both amusing and filled with helpful hints on what NOT to do OR how the approached a problem and fixed it :) (Which is the point BTW)
The code in the book is sparse, and it initially bugged me, but I came to realize that it really is not about giving the reader chunks of code. This is not a step by step guide on how to make a game, but a collection of ideas on how to cleverly write and manage your game. Mike frequently comments on the potential problems one might have compiling his code, and he rightfully tells the reader to fix it as an exercise. After all that is the kind of industry Game Development is if I am not mistaken: Fixing broken code and solving problems???

Anyways, this book is not for know it alls already in the industry. This is a book for people like me who are passionate about games but don't have a clue on where and how to start. To me working in the industry is an impossible endeavor, but this book is not only filled with concepts on game programming, but it is filled with motivational stories and tips on how to GET IN. This is a booster in the right direction, and to actually get the opinions of someone already in the business, and not just straight HOW TO LOAD A BITMAP crap, (which is also in the book I might add...) has left me pleasantly surprised and content. If McShaffry wrote another book, hopefully something that covers topics he didn't cover in the original, I would be all over it like a Fat Kid on a Smarty.

I highly recommend it!!