Game Programming Patterns
About Game Programming Patterns:
There are already dozens of game programming books out there. Why write another?
Most game programming books I’ve seen fall into one of two categories:
Domain-specific books. These narrowly-focused books give you a deep dive on some specific aspect of game development. They’ll teach you about 3D graphics, real-time rendering, physics simulation, artificial intelligence, or audio. These are the areas that many game programmers specialize in as their career progresses.
Whole-engine books. In contrast, these try to span all of the different parts of an entire game engine. They compose them together to build a complete engine suited to some specific genre of game, usually a 3D first-person shooter.
I like both of these kinds of books, but I think they leave some gaps. Books specific to a domain rarely tell you how that chunk of code interacts with the rest of the game. You may be a wizard at physics and rendering, but do you know how to tie them together gracefully?
The second category covers that, but I find it often too monotlithic and too genre-specific. Especially with the rise of mobile and casual gaming, we’re in a period where lots of different genres of games are being created. We aren’t all just cloning Quake anymore. Books that walk you through a single engine aren’t a good fit when your game doesn’t fit that mold.
Instead, what I’m trying to do here is more à la carte. Each of the chapters in this book is an independent idea that you can apply to your code. This way, you can mix and match them in a way that works best for the game you want to make.
Most game programming books I’ve seen fall into one of two categories:
Domain-specific books. These narrowly-focused books give you a deep dive on some specific aspect of game development. They’ll teach you about 3D graphics, real-time rendering, physics simulation, artificial intelligence, or audio. These are the areas that many game programmers specialize in as their career progresses.
Whole-engine books. In contrast, these try to span all of the different parts of an entire game engine. They compose them together to build a complete engine suited to some specific genre of game, usually a 3D first-person shooter.
I like both of these kinds of books, but I think they leave some gaps. Books specific to a domain rarely tell you how that chunk of code interacts with the rest of the game. You may be a wizard at physics and rendering, but do you know how to tie them together gracefully?
The second category covers that, but I find it often too monotlithic and too genre-specific. Especially with the rise of mobile and casual gaming, we’re in a period where lots of different genres of games are being created. We aren’t all just cloning Quake anymore. Books that walk you through a single engine aren’t a good fit when your game doesn’t fit that mold.
Instead, what I’m trying to do here is more à la carte. Each of the chapters in this book is an independent idea that you can apply to your code. This way, you can mix and match them in a way that works best for the game you want to make.