[geek] Review of Developing Serious Games

Serious games are video games that serve a serious purpose: they cover the gamut from the military's most sophisticated simulators to iPod- or PDA-based games designed to assist surgical residents. That's a lot of turf, on a lot of platforms, using a lot of tools... and this book, Developing Serious Games by Bryan Bergeron, shows it... I just got the book today, and just finished it an hour or so ago. Here's my Amazon review ('wickerman' is another, older 'net pseudonym I've used) - I gave it three stars:

I don't know what I expected from this book, and, as a result, I think I probably got what I deserved. I had high hopes for this book; I work for a small software company that is teetering on the brink of becoming a producer of 'serious games', and I was hoping for some kind of bolt from the blue, some kind of revelation. My career, my company at a frontier - should we cross in? Or should we run screaming? Peering into the entrails of this book, what dark auguries could I see? Unsurprisingly, the answer is 'not too much'. That's too much to expect from a book, and honestly, I knew that going in. So what is the book good for? The book is a good overview of the contemporary state of the field. It touches upon games development in general, best practices for software development, ditto for game development; it covers dev tools, platforms & engines; it covers art and sound resources. It discusses funding sources, and the differences between 'entertainment games' and 'serious games'. In short, it covers everything. And, as such, it covered nothing in particular in depth. Labeling on the back to the contrary, I didn't feel like this was a book geared towards software developers. Rather, it felt like an accessible book geared towards anyone with some familiarity with software development: PMs, VCs, CEOs, software devs and testers, media and art specialists... There're a couple of C/C++ code snippets, there's some pseudo-code, but compared to, say, the pages of calculus in Neal Stephenson's Cryptonomicon, the technical content of this book is really quite low: if you don't need to understand code, you can probably safely skip these bits and still understand how the big picture bits apply to you in your role. I also found some of the editing to be sloppy. The writing is strong, but the proofreading left a bit to be desired: "a" for "an", "fist" for "first". CRM: sloppy, sloppy, sloppy. There may not have been a lot of these typos, but the ones I noticed were quite jarring. If you're looking for a 50,000-ft view of the field, this book will probably suffice. If you're looking for an intensely geeky dev-oriented book, you will probably be left wanting more. Perhaps I'll change my mind in a day or so, but I doubt it. Don't get me wrong - there are some great things in this book for a developer, such as the appendices with their snapshots of tools and concepts. But I'm not sure if this book will stay on my shelf of 'keepers'. We'll see.

Random and tangential thought... With Amazon's new 'tagging' system, you can create your own taxonomy for your books, much like Technorati or Ice Rocket allows for blog content or Flickr does for images. If, as in the case of this book, a potential reviewer sees that the author has personally tagged the book, what impact do you think that'll have on the review? More fawning? More confrontational? Or will the prospective reviewer be intimidated enough to not post a review at all?