Core Techniques and Algorithms in Game Programming [Paperback]

I find it telling that the author's bio does not mention any games that he has worked on, because it quickly becomes apparent when reading it that this is *not* the advice of a seasoned developer, and I doubt that he has worked on anything more than very small demos. The book does cover a broad range of techniques and algorithms that are applicable to game programming, but it seems that the author's knowledge of these techniques is of an academic nature - gleaned from reading other books or newsgroups and a little dabbling in his spare time, not from professional game development. As such, it provides an introduction to quite a lot of topics, but as soon as it comes to adding more detail on implementation or practical advice, he suddenly becomes very vague and occasionally just plain wrong. Furthermore, his programming style is very academic (smells of unix) - not of the standard expected of a professional programmer.

The book may serve as a good warm-up for a student wishing to enter the industry, but for anybody with a year or two under their belt it is unlikely that they will find anything here to improve their skill set. This does not necessarily make it a bad book, as there are plenty of people out there who want to get into the industry and don't know where to start, and more in-depth books would probably create information overload. However, the book would have got a higher score if it had included the word "introduction" in the title somewhere. As it is pitched, as a reference book for the industry, it is a definite disappointment.

This is an ambitious and expensive book. In my opinion it isn't really worth the cost. I have two major criticisms: first, there is no CD with code samples, and no color plates for showing off graphics. Second, it is *very* poorly edited, and the code formatting is so bad as to be almost unreadable.
For example, on page 576 on reducing texture memory requirements the author talks about how using RGB4 is generally okay if you don't have fine color gradients. This is correct. He then refers to an unnamed figure (which we find on the next page) but swaps the left and right side (presumably) defeating his point. He then later refers to the figure, by number, but with completely incorrect content. The actual picture referred to was apparently removed, and the wrong one got its number. This is not an isolated incident. Page 329 has a nasty (yet typical for integer divides) off-by-one error.
Further, I find he often uses pseudo-code where you would want details, and real code where you would want pseudo-code. And the coding style used is also poor, especially when one thinks it is meant to be an example to new programmers. Often #define's are written exactly like normal variables and are used when enums would be much better, upper case and lower case are regularly switched when referring to the same variable, long, unreadable, all lowercase variable names are used, constants are not brought out of loops, braces are not matched up, erratic use of whitespace, etc.
I also found discussion often sadly lacking. The book is admittedly already large, but much could be cut out that isn't interesting or germane (e.g. pages of badly formatted code, or mixing force-feedback effects for DirectX which belongs in a DirectX book). For example, in discussing A* searching no mention is made of using pessimistic heuristics, which in practice can dramatically improve performance. In a very brief section of Design Patterns, no discussion is made about why the author thinks its better to subclass strategies rather than use function pointers.
Some statements are just wrong: "As anyone familiar with algorithm theory knows, sorting a list of N numbers needs at most N log N comparisons, and no algorithm can perform better than that (in a worst case scenario)." Well, in fact, if you can meet certain criteria, you *can* sort in O(N) time (even in the worst case), and many "standard" algorithms require N*N comparisons in the worst case.
There are some good points. The history of games was quite interesting, as was the review of tiling, sprite, and palette techniques. And, if you're a complete beginner to programming, there's a fair bit of useful information, and I'd give the book 3 stars instead of two. Even experienced game programmers will probably learn something, or at least be pushed in that direction. The explanation of BSPs was quite good, for example.

All in all, disappointing. For reference, I've programmed the PlayStation (one) for Electronic Arts, and more recently done gaming stuff for mobile phones, and have a background and interest in gaming, 3D graphics, and AI.

I have read about half of this book so far. I was very excited about this book while reading it because it does contain a lot of useful general information. However, if you are looking for actual code examples...this book falls short.

I am writing my own game engine right now and I went to the book to use an algorithm it had listed...except the algorithm doesn't actually work! i tried to debug the algorithm for hours before giving up and writing my own. (Which was a good exercise in itself) Once again I turned to the book for an algorithm it listed, but the explaination of it was so bad I decided to write that one myself too.

So...if you are a programmer already this book will be useful to you because the code snippets provided are less important that overall concepts which is why i bought it in the first place. But if you are a beginner programmer looking to learn how to code, I wouldn't recommend this book to you.