I love this book as well. I think part of what makes it so good is that the patterns are discussed in a very domain-specific context and their usage is not overly abstracted. I often find it hard to see why a particular "widget" or "foo/bar" pattern or structure is used/useful, but when you put the examples in a very specific context like this, it's much easier to understand their value and remember why/when/how to use them.
I wish there were other Pattern and Software-Engineering books that discussed things in more domain-specific contexts, but I suspect game development is one of the few domains large enough, and with enough people looking for domain specific literature, to really warrant such a book.
The secret subtext of my book is that almost all of the patterns are perfectly useful outside of games too. Very few patterns here are specific to games (though "Game Loop" is one of them).
Maybe it's just me, but if I'm going to read a few thousand words about some piece of software architecture, I'd rather be reading about trolls and magic than employee record databases.
Thank you very much for all your work on "Game Programming Patterns." It's an amazing resource. I was not aware of "Crafting Interpreters" before now. I can't wait to start digging into it.
I've come across very few Design Patterns, and Software Engineering topics in general, that couldn't be taught/explained from the perspective of game development. I'm surprised that it isn't used as a teaching-tool more often then it is. It's an inherently complex domain that most audiences are already quite familiar with; the "why" behind things is either immediately obvious or easily explained. If someone doesn't know what the requirements are for something like an employee record databases, and how such a system might be used, using that as a context for teaching is not much more useful then "class Widget" and "Foo.Bar()".
I similarly have difficulty learning a concept when it's presented using real-world metaphors that aren't often actually expressed via code. This is how object oriented programming was taught to me: imagine a door object, which contains methods open and close, and it contains a knob property, which is its own object with functions to turn left and right, and so forth. Once you're familiar with OOP this might seem like a good way to explain the concept, but without a specific application to apply it to, it's difficult to see the purpose.
OOP examples such as these and their instruction in traditional schooling is arguably one of the biggest failures of computer science education of our time. This is literally the last thing object oriented patterns are ever used for (depicting real world objects as members of categories). They are primarily designed for describing systems that are managing the user's interactions in the software rather than representations of real-world physical objects.
The only time these overlap is in video games, which is usually not used as the context for teaching software development when OOP is taught.
I couldn't agree more, although I'd take a step further and extend it to way more stuff: options, features, libraries, and even applications. Building up an index of knowledge generally help in deciding what tool or technique to reach for.
I'll often look at stuff and wonder: what is your purpose? In my experience, explanations without context aren't generally very useful. It's much easier to incorporate knowledge when you're first presented with a concrete example of a problem along with its solution, and then you're presented with the abstraction.
One of the most notorious examples I can think of is when someone tries to explain monads. For some reason people often start by providing a long mathematical definition, which is completely useless if you don't even understand the weird words being used. It's worth learning Haskell just for all the new concepts and ideas it'll expose you to, even though the syntax looks very unfamiliar at first.
I wish there were other Pattern and Software-Engineering books that discussed things in more domain-specific contexts, but I suspect game development is one of the few domains large enough, and with enough people looking for domain specific literature, to really warrant such a book.