Professional XNA Game Programming - Review

I just finished reading Professional XNA Game Development by Benjamin Nitchske.  It was my first attempt at using the XNA Framework.  I have some experience with DirectX, as I have been tinkering with it since version 5. Most of my work has been with the Managed DirectX bits for .NET 1.1. I found it to be much easier and readable than C++, just because of the language differences.

XNA takes that next productivity leap and really allows you to hit the ground running.  You start out with a game loop (complete with elapsed time already calculated for you), a graphics device already setup, and a managed content pipeline for imported models, sounds, and textures.  Things like graphics memory getting lost when you alt-tab are already handled for you.

But enough about XNA, this post is a review for Benjamin's book.  If you haven't heard of him before, he was the author of the first Managed DirectX game called Arena Wars, and later wrote RocketCommander. Both games are very well done and he ported RocketCommander to XNA so that you can play it on the XBOX 360. XNA Racer was also done completely by himself, which is very impressive.  Needless to say, with all that background and expertise... I had high hopes for this book.

The first few chapters introduced how Benjamin approaches game development.  He calls them "Unit Tests" but that term often implies that the tests are automated.  His tests are basically slices of game functionality that he calls manually.  For example he might have a unit test to verify that shadows work properly, or that a specific collision detection algorithm works.  He is able to setup the update and render loops using anonymous methods and execute them using batch files or manually calling the unit test instead of the main game.  I found this to be very interesting, however the code that he used to write it was somewhat ugly and unintuitive.  I coded the Pong game following his coding style and was disappointed the whole way through it.  While he does say that we will utilize better code for the next game, the code he wrote here was inexcusably bad. I got the game working, however new features and modifications would prove to be difficult because it is just spaghetti code.  I swallowed my pride and told myself, ".. it will get better."

So then I started to follow his next example: Breakout.  I have built breakout before using Managed DirectX, and it was quite fun.  I was disappointed to find out that he didn't really buid the game through the book, he rather took the reader on an exploration of code already written. And he was true to his word, the code pulled a lot of functionality into "helper" classes which made them reusable.  And yes, the code was still horrid.

I mentioned reusable code.  It wasn't reusable like you're thinking.  He actually tells you to copy the code from the previous game and paste it into the new game.  I'm not kidding.  I'm a professional developer.  This book is called Professional XNA.  Professionals don't write code like that. He begins to talk about 3D programming in a way that is -- while full of information -- poorly organized and generally boring.  I learned a lot in this section, but nothing I can really refer to later.  It was more like a stream of conciousness than organized writing.

Let me give you a hard example of how bad the code is.  At one point he is talking about how he handles car physics, which was very interesting.  Then I saw the class diagram where he implemented it.  It looked something like this:

What!?!? So ChaseCamera inherits from CarPhysics which in turn inherits from Player?  Sounds like an object model from the Twilight Zone. This is pure junk as an object model, and is really only there because the CarPhysics object needs to know details about what the player is doing, and indeed so does the camera. But that doesn't mean you should break all rules of OO just to achieve a hack that works.  I was so appalled by this I almost didn't finish the book.

Benjamin knows his stuff, no doubt.  I think it’s amazing that someone can build something as beautiful as RocketCommander or XNA Racer in less than a month by yourself.  But I just can’t recommend this book because of the code quality.

I will wrap this up by saying that I *did* enjoy the book because it got me into game programming again, but I find this type of writing almost intolerable.  I enjoyed to learn about some nuances around XBOX 360 vs. PC versions of XNA Games, and I especially liked his Unit Testing technique. The information on Shaders was mildly useful, albeit boring. But if you're going to be reading this book, be fore-warned that the code sucks.

I give it 2.5 / 5 stars.