Game Programming Patterns – book review
Every self-respecting programmer wants to have read programming books. But actually reading one, while billions of internet distractions compete for our attention, is an entirely different matter. After acknowledging that my patience and time are limited resources, I became rather unforgiving in evaluating books that end up on my reading list.
Robert Nystrom, former programmer at Electronic Arts and the author of Game Programming Patterns, deserves recognition for writing an excellent book that is very respectful of reader’s time.
In a clear and concise way, Nystrom describes 19 design patterns commonly used in games. The first six originate from the famous Gang of Four book, but are revisited for game programming. The author then discusses a selection of other patterns, some of which are specific to games (e.g. Game Loop), but sometimes also applicable to other kinds of programs (Event Queue and Service Locator). The final part of the book addresses performance and memory usage. Given such scope, every game programmer will find something useful there, regardless if working on a simple puzzle or a 3D game. The choice of patterns shows that the author values solving practical problems over baroque designs.
Each chapter of the book follows the same structure. The author presents a problem, using familiar types of games as an illustration. For instance, how to spawn hundreds of similar, but slightly different monsters in a dungeon crawler game? It is followed by a brief definition of a design pattern that addresses the problem. Every pattern is then illustrated with basic implementation in C++. I have never worked with this language, but the samples are short and easy to understand to anyone familiar with object oriented programming. I had to look up some C++ idioms in a few rare cases, but those served as an interesting exercise. The code is then explained and often gradually tweaked, if the first iteration was incomplete or had design problems. A chapter ends by describing variations of the pattern and tradeoffs associated with them.
The book is not for absolute beginners. The author doesn’t explain basic programming concepts. He skips tedious introductions and focuses on problems that will be interesting to someone experienced enough to care about design patterns. The content has been condensed to about 340 pages, though it may take a certain amount of time and effort to digest.
What really distinguishes this book is the quality of writing and editing. I was not familiar with Mr Nystrom before, so I might be oblivious to the extent of his brilliance, but I attribute at least some of that quality to the way the book was conceived. The entire content was published on Github, and the author was accepting comments and fixes from readers before the book was officially published. As a result, the text is remarkably clear and free of mistakes. I wish more technical books were written this way.
The author went to extra lengths to illustrate some of the more difficult concepts with his own drawings. While he is unlikely to have a second career as an artist, the drawings give the book a nice personal touch and help readers to better grasp the content. It’s also worth mentioning that the text is beautifully typeset and looks gorgeous on paper. I haven’t tried the e-book versions, but other reviewers praise their looks.
Speaking of e-books, the entire publication is available for free in HTML format. Paperback and various other electronic versions are available for sale (and worth their price).
While reading Game Programming Patterns I felt it really was a labor of love, and as such I wholeheartedly recommend it to any game programmer. Unlike books covering specific tools, software architecture has a much longer shelf life, so learning about it will be paying off for a long time.
Finishing this book enabled me to look with fresh eyes at my own codebase. It helped me to recognize certain patterns in other people’s code, thus better understand their designs. After all, using design patterns helps to communicate intent to fellow programmers.
While it is uncertain if Mr Nystrom will ever decide to write another book (I surely hope he does), you can read more from him on his blog.