I've read through this book 3 times over the years and it's very misguided. If you're working on a game and the words "gang of four" pop into your head you unfortunately have suffered permanent brain damage. The main problem with this book is that it focuses on things that are not actually issues for game development. Instead of deep knowledge you learn trivial factoids.
You don't need or want a service locator in most cases, but if you read a book like this you'll be trained that it's some necessary and integral part of game development. If you can figure out how to draw trees, you can also figure out how not to duplicate their mesh/texture 200 times with their "flyweight pattern". You almost certainly don't want a bytecode interpreter in your game. You shouldn't be thinking in terms of prototypes. The only useful "pattern" in the book is the singleton, and hedged with "Despite noble intentions, the Singleton pattern described by the Gang of Four usually does more harm than good.".
It teaches complete beginners to think incorrectly about how games should be developed, but it covers enough topics will entertain people. If you want a book, I would suggest "Game Engine Architecture" because it goes much more in depth on what actually goes into a game engine instead of abstract design patterns from textbooks that are somewhere between maliciously bad and incompetent.
> The only useful "pattern" in the book is the singleton
I don’t think it’s quite as bad a as you suggest. The Observer, component and event queue chapters cover information that is commonly used in games and the entire Optimization Patterns section is decent too. If you’re a complete beginner, the game loop chapter is also a good introduction. Maybe also the update method on account of the fact that many shipped games do in fact use this.
I also do not like singletons at all and think they should avoided. Just make your object a global if you must. Or my preferred way: namespaced functions that internally use a global (or classes with a static pimpl) with get/set context functions for the cases where this won’t work (testing, crossing DLL boundaries), just like how ImGui does it. But I won’t argue if someone tells me they prefer singleton’s for that.
The rest, I agree on, though, and Game Engine Architecture is one of my favourite books, so definitely second that recommendation.
It’s worth noting that the bill is 10 years old too, so the thinking around this stuff may have evolved in that time too (eg back then ECS was less common).
I am sorry for the stupid question, but aren't "singletons", "global variables" and "classes with a static pimpl" basically the same things from a design-perspective and their main difference is personal preference (and maybe runtime performance)?
Singletons conflate two requirements: global access and enforcing that there is only one insurance.
In my opinion you almost never need the latter and people use them when they really just want global access, and using a “Design pattern” to do it feels like good design while “global bad”.
There are very few cases where limiting to a single instance is necessary. If you only want one instance then create only one instance, but there’s rarely a good reason to make it only possible to have one instance and it’s not uncommon to later need more than one instance. For example, loggers are often given as an example of a singleton, because you only need one, right? Until you want to have different loggers for different purposes or destinations.
So if you don’t need to limit it to only one instance and are only using the pattern for global access, well then there are other options that look very similar but without the single instance rule. The ImGui/OpenGL style is like a singleton where you can only have one instance active at a time, but you can create multiple contexts and switch between the active one if you need (it may not be the nicest API if you need to do that, but it at last makes it possible). But simply making a global instance of a class (eg as is often done with loggers) is in my opinion perfectly ok too.
Making a singleton still makes a global and so is no better design than global are: the same caveats apply to singletons as normal globals (ie you should avoid them), so just make a global and don’t pretend your design is somehow cleaner.
The book is a well-written and charismatic collection of the author's ideas andunderstanding of programming in general mostly from an OOP angle, which was all the rage everywhere during 2000s. He also likes his compilers a lot and it shows.
And yes, Game Engine Architecture is definitely a much better reference to the core engine building business.
But games and gamedev these days is not about that as well. Most of the technical problems are solved by the big engine trio. So all devs do is game rules and logic scripting...
I agree. It's a historical document of how 2000's-era game developers were grappling with making much, much larger codebases than before, and, because everyone in undergraduate CS was learning from a "Java school", it addresses them specifically.
The concepts in it that I still find useful aren't really OO at all, they are just data structures and algorithms: stacks, buffers, formalized ways of handling state.
The engines are useful, but mostly on the front of getting a lot of I/O problems out of the way and doing some stuff to bundle and automate common assets and rendering methods. If you deeply care about any specific part of your game you end up writing your own thing that works around the engine instead. In that respect I dispute the parent's idea that adding some compiler tech is useless - it's one of the essential methods of tools development. It just does not have to be very sophisticated to get the job done - Cave Story, for example, just has a little token reader for the "T-Script" cutscene scripts. That is the right size of tooling for a lot of games.
The basic rule of thumb to apply is that in-house tech only needs to be good enough to express what you already designed in a paper document, or to parse some spreadsheet data. The external documents will be more flexible for revisions than any slick UI you could build, and the type time of coding it is a minor detail relative to the design time. That assumption only changes on some relatively vast scales.
I don't think you are supposed to use these patterns directly, but they describe common solutions to problems that let us use a shared language when discussing code. If I say that 'we can replace this with something like a flyweight', I expect you to know what I'm talking about. I'm not expecting you to implement it "by the book" but we can discuss it without me having to explain wtf a flyweight is, how it works, and how it applies to this situation.
That being said, these days there are much better resources out there for this stuff.
Yes, the in-depth domain specific 1150 page book is going to be more useful for building an engine than the introductory 340 page book on design patterns with a gamedev flavor.
Right. I don't think "design patterns with a gamedev flavor" has any value for game developers, but I didn't want to just say the book was bad without suggesting an alternative. They're both aimed at game developers who want some deeper understanding of how to structure games and you can pick out chapters you like from the 1150 page book.
But why would I care about how the engine works? It should just work, I don't want to waste my time with understanding how.
Are there any good books for actual game development? Not how to make the next generic platformer, but rather how to make sure all your assets, classes and scripts are structured and well organized despite having hundreds or even thousands of files. Or how to create dynamic modules that can be reused for many poarts of the game. When, and when not to build things dynamic vs. simply hardcoding them. I miss all this stuff in every book/tutorial I had so far.
> But why would I care about how the engine works? It should just work, I don't want to waste my time with understanding how.
Either this is sarcasm or you need someone to educate you thoroughly.
How the engine works is fundamental to understanding what you can and cannot do as a game programmer, severe pitfalls and above all: where areas for innovation exist for your specific type of game.
I make racing games for example, you might be surprised to learn that if I ignored my engine then it would be impossible, because my engine (Unreal 5) is not very good at handling extremely fast moving objects in the world. It puts enormous stress on the level-of-detail system. I need to understand that otherwise my game won't work.
What you said is as silly as saying "I'm making an apartment block, why do I need to understand the properties of bricks? they should just work!"
You can approximate extremely fast moving bullets with rays that are large and don't move at all. Which, thinking of it, is definitely a game programming design pattern.
No this wasn't any sarcasm. I also want to use my smartphone without having to know how it works. If the engine can't be used for fast moving objects, just tell me in the docs. It's not my job to know the inner workings of the engine. I stand by my point.
You don't need or want a service locator in most cases, but if you read a book like this you'll be trained that it's some necessary and integral part of game development. If you can figure out how to draw trees, you can also figure out how not to duplicate their mesh/texture 200 times with their "flyweight pattern". You almost certainly don't want a bytecode interpreter in your game. You shouldn't be thinking in terms of prototypes. The only useful "pattern" in the book is the singleton, and hedged with "Despite noble intentions, the Singleton pattern described by the Gang of Four usually does more harm than good.".
It teaches complete beginners to think incorrectly about how games should be developed, but it covers enough topics will entertain people. If you want a book, I would suggest "Game Engine Architecture" because it goes much more in depth on what actually goes into a game engine instead of abstract design patterns from textbooks that are somewhere between maliciously bad and incompetent.