I think it's probably good to know for every engine and besides, it's a beautiful book.
That being said, armed with my baby knowledge of programming patterns, I then did find it frustrating that today's engines are very high level and quite opinionated about how you code. Take for example Godot. It's not 'quite' an ECS and there are certain ways to script things which you should follow.
How to fit the patterns from this book into a Godot game is a whole other ballgame.
This book makes me want to write my own engine. Not to deal with the technical details, but to be in control of the program logic. This excellent book makes you want to worry about the stuff that engines abstract from in their own special way. That's not efficient from the standpoint of getting a game done - things are done in Unity or Godot in their specific way for good and battle-tested reasons.
I've been working on a game engine for several months now. It's a similar kind of hell to working on an OS (though easier to debug...until you start using threads), but it's fun.
Yes, absolutely, 100%. It's engine and language agnostic; many of the examples are written in C++ in lieu of pseudocode, but he also goes into where C# differs in behavior enough to affect the pattern.
That being said, armed with my baby knowledge of programming patterns, I then did find it frustrating that today's engines are very high level and quite opinionated about how you code. Take for example Godot. It's not 'quite' an ECS and there are certain ways to script things which you should follow. How to fit the patterns from this book into a Godot game is a whole other ballgame.
This book makes me want to write my own engine. Not to deal with the technical details, but to be in control of the program logic. This excellent book makes you want to worry about the stuff that engines abstract from in their own special way. That's not efficient from the standpoint of getting a game done - things are done in Unity or Godot in their specific way for good and battle-tested reasons.