So that's how I came to be reading a book on games programming (with an embarrassing title).
Chapter 2, "An Animation Framework" introduces double-buffering, and shows how to implement it in a
JPanelsubclass. There's no mention of the fact that Swing provides double-buffering way up in
JComponent. A few pages later, the author switches from AWT-like
repaint-driven drawing to what the author calls "active rendering": calling the painting code directly from the game's main loop. So if you wait long enough, reimplementing double-buffering makes more sense, but in the meantime you're left with a feeling of distrust in the author's skill.
And even when you've waited, you're left wondering if the author knows about
JComponent.paintImmediately, and whether he has some reason to avoid Swing's seemingly far more sophisticated double-buffering. It could be that there is a good reason.
JComponent.paintWithOffscreenBufferare private, so you'd have to accept all the complexity in
JComponent._paintImmediatelyfor dealing with overlapping components. Maybe for games that outweighs the benefits of the more sophisticated double-buffering.
But that's surely a decision worth talking about? If I'd made the decision in some of my code, I'd definitely write a comment. When we're talking about a book, where the programs aren't ends in themselves but examples used to demonstrate and explain techniques, it would seem essential to explain why you aren't didn't make the most obvious choice.
Conversely, coverage of the options for timers and reasons for choosing between them is pretty strong.
Chapters 5 and 6, "An Introduction to Java Imaging" and "Image Loading, Visual Effects and Animation", are pretty good. The former is a whistle-stop tour of various alternatives (and, if you know Java, you'll know there are plenty of alternatives) with some discussion of which you'd choose when. The latter is an equally quick tour of some of the options for rendering and processing images once you have them.
I flipped through the chapters on sound, because I've never had any need for it, nor can I imagine myself doing so. I don't write games, and in real programs, use of sound tends to be a mistake because the user's actually listening to a Haydn string quartet with the volume up really loud so they can hear the subtle articulation... BEEEEP! Well done: you just gave your user a heart attack, and now their monkey brain is panicked, and it's going to take a while for them to calm back down and work out what just happened.
Chapter 11, "Sprites", describes a simple game, similar to Arkanoid, but without the bricks. The image used for the bat is of a cartoon ant. This not only makes the use of the word "bat" confusing because the image isn't of a table-tennis bat; it also introduces ambiguity with "bat" the animal, because "ant" brings animals to mind. It's almost funny to see the whole chapter stumble over itself, including explanatory notes in several places intended to help the reader cope with a completely self-inflicted wound.
In the same chapter, there's this code:
player = null; // for garbage collection of previous player
player = new ImagesPlayer(...
I find this distressing from an educational point of view. There are cases where the "x = null" idiom can be useful, such as when x is an array element (see the implementation of
ArrayListfor an example), or when you're finished with x but about to do a lot of work before you next assign to x (this might be true here, for example, depending on the constructor for
ImagesPlayer). But there's no mention of this at all in the text.
If it's non-obvious enough to be worth a comment, it's non-obvious enough to be worth a good comment.
Chapters 12 and 13 conclude the 2D part of the book. (Yeah, it's a pop-up book from then on. You're so funny.)
If you hadn't already noticed that the book is let down by the poor quality of image reproduction, you really notice around this point — the point where actual games are introduced. Not only is there no color, the images have either been crudely scaled or overly-compressed using some lossy mechanism. It's really hard to see anything. The line drawings are fine; it's the screenshots that are unrecognizable.
3D games / Networking
I stopped reading at this point. I'll come back if and when I have reason to, but as I said at the outset, my interest is really in 2D rendering.
The book suffers from not providing sufficient rationale for design choices. Worse, there's little or no attempt to write reusable classes (or explain why that's impossible or undesirable). The authors idea of reuse appears to be of the copy & paste variety, where the copies get new bodies for private methods such as
gameRender, and where you write new boilerplate code for key handling in each game rather than knocking up any kind of system for declaring the keys you're interested in. (There's the occasional
protectedmethod, so it's not like the author's a total C programmer.)
On a related note, the book suffers from what feels to me like an insufficiently clear distinction between general principles and the specifics of implementing the particular game/demo each chapter sets out to build. So not only is it not obvious what code you're supposed to take away as generally useful, it's also not obvious how general-purpose the various ideas are, nor usually what the alternatives are, and how you'd choose between them.
And, as I've said, the quality of image reproduction is truly abysmal.