The book is aimed at people who know how to work with Linux and who can program in C, and it wants to be of interest to everyone meeting these criteria, whether they're absolute beginners in game programming or professionally porting games to Linux. This is a bit strange; while the first two chapters are spent explaining the difference between game genres and introducing gcc, make, gdb, and CVS (with a specific slant to what game programmers need to know), later in the book, we get chapters on low-level audio programming and programming directly to the Linux framebuffer. This is useful for people who program game libraries or port commercial games, but rather useless for people who just want to write their own computer games as efficiently as possible.
In my opinion, the first two chapters of the book are of doubtful value. If you want to program games on Linux, you will need a reference book anyway that covers tools such as gcc and make in more detail than John can provide. I already have half a dozen other books that try to explain these tools on a few dozen pages while really addressing another topic, and I do not want any more books with short introductions to gcc. I think John could have used these pages better by addressing design issues (which are ignored altogether in the book), by giving us a more thorough treatment of game-specific debugging issues, or by showing how to compile SDL applications for Windows.
Chapter 3 gives an overview of the most prominent Linux gaming APIs. This is solid and useful information for anyone new to game programming with Open Source tools. However, it covers mostly low-level libraries that do the things DirectX does on Windows. Game engines (which on Windows are typically licensed for hundreds of thousands of dollars) are not mentioned, although there are two very promising Open Source game engines available, Crystal Space and The Nebula Device. If you want to produce a professional-looking game, you should definitely check these out. They save a lot of work.
In Chapter 4, entitled Mastering SDL, we get into the real subject matter of the book. SDL is a low-level gaming API that has been used by Loki to port games from Windows to Linux. It has the largest and most active user community of all Open Source gaming projects, is being actively developed under the leadership of former Loki lead programmer Sam Lantinga, and is (correct me if I'm wrong) the only gaming API that is included as a shared library with most Linux distributions. In short, SDL is the closest we have to a DirectX equivalent, and anyone planning to write a game or multimedia application on Linux should look at SDL first. SDL is well-documented, but it is also quite large, and there is no comprehensive introductory tutorial available online. That is what John provides in this chapter; he shows you which API functions to call to get a basic game going with loading of graphics, double-buffered animation, input processing, and audio playback. He also gives short introductions to multithreading (which he actually uses in his demo game) and to displaying 3D graphics with OpenGL from SDL. This is really quite amazing; all it takes are 8 SDL calls, and you are ready to use OpenGL rendering commands. John wisely stops after displaying one triangle instead of giving us a short introduction to OpenGL, but, together with a book on OpenGL, here you have all you need to use the same SDL/OpenGL technology Loki used for most of their commercial game ports. This chapter packs a lot of information in a few pages, and is a solid introduction to SDL.
Chapter 5 is on audio programming, and consists of two distinct parts: The first 45 pages cover various low-level audio APIs, while the next 30 explain how to use OpenAL and Ogg Vorbis. The first part presents Multi-Play, a program John has written to play sound files with different APIs, namely OSS, ALSA, and ESD. My advice to game programmers: Do not use these in your own code! Why does John include them in the book? I think he enjoys low-level hacking, and wants to share this passion with us, and I must admit that I did find this stuff quite interesting. Direct DMA buffer access, a technique Quake3 uses to achieve superior speed... could this be something to talk about at the next party?
OpenAL is an API for environmental audio, which associates sound sources with (possibly moving) points in space. The library computes the sound that reaches the listener (including things like the Doppler effect) and renders it in surround sound if the proper hardware is available. Ogg Vorbis is a patent-free library for streaming compressed (similar to MP3) music files. This is cutting edge cool stuff, and John integrates both these technologies into his demo game Penguin Warrior.
Chapter 6 covers scripting. Not only does John teach us the basics of Tcl (enough to write usable scripts), but he shows us how to embed the scripting engine in the game, and develops a script-based AI program for the player's opponent in Penguin Warrior, all on 30 pages. This is another instance in which John demonstrates his talent for saying what's important and leaving out what's not. He also discusses the uses of scripting in games, and I think it bears repeating: Scripting is useful if there are many game agents with diverse behaviors, and either these behaviors will be designed by non-programmers or the code base is so large (and intertwined) that the programmer/designer wants to avoid recompiling after every change in this part of the code. This applies only to large games, and most hobby programmers will have no need to employ scripting. What hobby programmers should do to avoid excessive time loss due to recompiles, however, is to use a data-driven design in which all constants that will be changed during game balancing and AI tuning are read from files. This is really important and useful for many more people than scripting, yet John neither practices it in his code nor mentions it anywhere in the book (probably because it is a design issue, and game design is explicitly excluded).
Chapter 7 makes Penguin Warrior into a networked game. To achieve good network performance in multiplayer games is one of the most difficult challenges a programmer can face, and John does not really get into that; he just introduces socket programming, then lets two instances of the game exchange their states in a P2P model. This is good enough to play on a LAN, but does not work well on the Internet. We can't really blame John for stopping there; as far as I know, there is currently no source available that describes and evaluates all the various techniques being used to combat lag and coordinate smooth multiplayer gaming. If you want to program a realtime multiplayer Internet game, you will just have to do your own research and development (look at Gamasutra first).
I wonder why chapter 8 made it into the book. It is entitled "Gaming with the Linux Console", but it really should be called "Don't Try This at Home, Kids!" In it, we learn how to display graphics directly to the Linux framebuffer device. This was introduced in the Linux 2.2 kernel to allow porting Linux to systems like the Mac which don't have a native text mode. Personally, I find its interface ugly and downright dangerous. John teaches us stuff like setting a new video mode. If someone writes buggy code along these lines, it could set your video mode to something your monitor does not support. Later, John describes how to access keyboard scancodes and switch keyboard operating modes. There must be an evil inner child lurking within me, for the only application of these techniques in gaming that springs to my mind is writing a routine named "Punish()", which would make the user's keyboard unusable and scramble his monitor when he fails at his assigned task. Considering that, in a framebuffer game, these things could also happen due to a bug that manifests on my machine but not on the author's, I don't think programming directly to the Linux framebuffer device is something aspiring game developers should be encouraged to do. SDL has the option of rendering to the framebuffer device, and SDL code is portable even to Windows, whereas framebuffer code cannot even be ported to FreeBSD. Why would any game programmer want to step into this quagmire?
Ahh, I've gotten into a rant, haven't I? Of course you'd like to mess around with this stuff if you like kernel hacking and bold adventures in coding. The framebuffer may be your only option if you want to target a truly exotic platform. Last but not least, for the users of libraries such as SDL, it is worthwhile to learn something about the inner workings of those libraries. My admiration for the SDL crew has certainly grown after reading this chapter. I've also decided I'd rather not install any games programmed directly to the framebuffer device by an amateur. Luckily, when I searched SourceForge for "framebuffer" projects, I found 12 non-game projects and only one game, which is in the planning stage with 0 activity. What a relief!
After the intense excitement of chapter 8, chapters 9 and 10 are a bit of a letdown. Chapter 9 does lots of little things necessary to finish Penguin Warrior, and chapter 10 addresses installation issues, focusing mainly on the GPLed program Loki Setup, which allows you to do slick installations from a CD. Since I don't expect to be selling games on CDs, this didn't really turn my crank.
I've been criticizing John's book in a lot of concrete ways, and this may give you the impression that I find substantial fault with it, so I want to say in closing that I do not. This is a good book. Granted, I think it could have been improved if John had reigned in his enthusiasm for low-level hacking and given us a bit more on SDL, but this just reflects my personal bias; I prefer high-level APIs. This book has something for everyone, and the Linux game development community now has a really talented author. John "Overcode" Hall is very good at explaining things, and he is outstanding at figuring out what needs explaining and what can be left for the reader to figure out by herself. Here's hoping you'll write more books, John!