You know, this book was a pleasant surprise to me. I wasn't surprised by it being a good book. In fact, I kind of expected it to be a book of quality since David Weller had a hand in it. What surprised me was just how good the book was.
I am a strong believer that now matter how much you “think” you know about a subject, if the book is good enough, there is always *something* you can learn from a book (even if it is a “beginner's” book and you are an “expert”). While I feel that I am becoming more experienced in the realm of game development with managed code, there were definitely things that I learned from this book. With that said, let's lay out exactly how I felt the book “performed”.
Good book reviews are tough to write. You have to evaluate the book and how it applies to it's targeted audience, not to you. This book is not targeted for “seasoned” game developers, it's not even targeted for intermediate game developers. The book targets developers that are reasonably well-versed with managed code already, but are new to game programming. Does this book cater well to that targeted audience? Absolutely!
As a coming-of-age-soon-to-be-sometime-in-the-future-seasoned-developer-in-general, there were certain aspects of the book that I absolutely loved to see. Mostly, I loved seeing the thought that went behind the design of the games. In many game development books that I have read over the years, little or no time is devoted to explaining the design behind the solution. Other books will explain the fundamentals, and then just throw code at you with little or no explanation of why the code is designed that way. As a developer on quest to become much more engineer-like, I want to see well thought out design. I want to know the design considerations being made. I don't want to see code just thrown out like a..... well, I'll save the comparison for a later, less “professional” post ('cause I'm here on business yo! Mad business!).
I loved seeing the use of UML to diagram the designs. More books should do this. Teach new developers by example. There were some questions I had about some of the designs, but I'm sure most of those questions can come down to taste and just how anal picky of a person I am. It's just nice to at least see a good process being shown. I think it teaches good habits to the developers reading the book. This is especially important in the realm of game development, I believe. Game development, even today, still tends to be heavily code-and-fix. This is a paradigm we all need to get away from. And the sooner the better.
Well, I've discussed some of the things I liked about the book, how 'bout some things that I felt could have been done better. My primary objection comes to the quality of the code samples, at least in print. There were a good number of typos (not tons, but more than I would like to see in a technical book). Some of these problems came from the conversion process from the C# book to VB.NET book, I'm sure. For instance, I remember reading a couple code samples when BLAM! one of the code samples in the middle of everything was in C#. Gave me a good laugh, that's for sure. I'm just wondering if it could cause some heartburn for the less experienced out there. But taking the target audience in to account again, I don't think this is that big of a deal.
I think the games throughout the book probably could have been more consistent. When dealing with beginners, I think it is best to present a consistent approach to each game, especially when presenting many games like this book does. I have seen quite the number of beginners wonder if they are using a “correct“ game loop or not, and I think that using a near-identical game loop from game to game would help clear up some of these questions. Some of the other things are simply style. At times, you can tell that the different games were either written at different times or by different coders.
Although this is just a personal opinion, I think there probably could have been less time spent on GDI+ and more on Direct3D. I also think that DirectDraw shouldn't have been used at all. DirectDraw is no longer supported, and most places you go recommend doing 2d game development via Direct3D and textured quads. I know this could have made the transition a little more difficult, but I think it's important to get away from teaching technologies that are no longer supported. It's hard enough to find a book that is up to date and uses managed resources for game development, so why spend some of that precious time showing how to use a deprecated technology? Don't get me wrong, I like the transition through the series of technologies that one can use when writing a game in managed code, I just think the “gradient“ of the transitions could have been better proportioned.
Closing Thoughts
I don't particularly like putting numeric ratings on a product. I personally just want to know if a product is worth buying or not. Just like movie reviews. I don't care if the movie was rated poorly as long as I enjoyed myself. So, would I recommend this book to others? Absolutely! If you are interested in game development with managed code, this book should most definitely be in your library. If you don't have it, buy it now and support the authors who wrote a great book.