[wokwokwok]

The patterns (eg. Implementing a scripting language, double buffering, components) aren’t things you would use unless you were implementing a game engine, and are actively anti patterns if you are using an existing engine like godot, unity or unreal.

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.

[alkonaut]

Yes I think these are mostly game development patterns for when you aren't using an engine like Godot/Unreal/Unity, or if you intend to write your own engine.(Personally I find this 100x more interesting than game development using ready built engines - but then again I never intend to write a finished game ever either!).

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 :)

[spacechild1]

"Game Programming Patterns" is obviously not a book about how to develop games in specific game engines. Like the title says, it is about general game programming patterns (that some engines might employ - or not). I think the target audience is people who want to know how games work under the hood and/or want to write (simple) games from scratch.

> 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 :)

[sparrowInHand]

Patterns are something totally overrepresented in developer knowledge.

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.

[withinboredom]

Patterns and their names are useful to communicate to other developers wtf you want to do. For example, "we can do a bit of flyweight with an FSM on this bit here to get this feature working".

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.