Many are “generic advice” that does not apply; singletons, for example are an anti pattern in unity and other engines (due to scene loading) resetting world objects.
Some of the other patterns are legitimate (eg state machines) but trivialise a complex domain (AI) and are cover far better and more comprehensively by specific resources on the topic.
It also fails to address actual programming patterns that actual gamedevs use like GPU kernels, ECS (real ecs) or deterministic simulations.
Patterns are not just magic sauce you sprinkle on and bam it’s a great game! Complexity solved! Use them thoughtfully to solve actual problems, when you need them.
This just very generic advice, like “how to write unit tests” with no specific language or engine or framework.
Yes, in general test are good, and “your test runner and package manager here can help you run tests” but the advice is deeply lacking if you want to try use it for writing actual tests in c++.
…but hey, read the 10 or so previous HN threads on it. People have had opinions on it since the beginning of time, when it was first posted. This is just my opinion.
My only really strong advice is to look around and consume other resources too, don’t just take this one as gospel.
> My only really strong advice is to look around and consume other resources too, don’t just take this one as gospel.
True! But I would say this about any book :)
They would be way be best described with: "similar solutions that people came up under extraordinary, rare circumstances and pressure". Usefull - if and only if you get into a project/warstorie similar to the one that pattern re-emerged. Not usefull if added on top of some pattern bloatfloater that can barely move anymore.
This is literally the only time I've used patterns in my entire career: to communicate ideas on how to solve problems. I don't think I've ever even once implemented a pure "by the book" pattern though.
It's general softare development knowledge, tangentially related to game development, perhaps because that's an angle that people - especially self-taught developers - approach development from. One can argue that the title/selling point is misguided. It's an introductory programming book, angled towards non-engine game development or introductory game-engine development, aimed at self taught developers, is my takeaway.
Most design patterns can be anti patterns in one setting and useful in others. That's not really specific to game development. You can't ever sprinkle them :)