6 ms·

> 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 cov

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

wink 3y ago
Observer pattern fits like a glove if you for example have a minimap that displays the same things as the normal map. Yes, you can solve it in a million other ways as well. "How can I use more patterns?" is never the right approach.
hnben 3y ago
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)?
- meheleventyone 3y ago
  Usually the extra complexity is about making sure you only ever have one in your running program.
- dkersten 3y ago
  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.

wink 3y ago

Observer pattern fits like a glove if you for example have a minimap that displays the same things as the normal map. Yes, you can solve it in a million other ways as well. "How can I use more patterns?" is never the right approach.

hnben 3y ago

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

meheleventyone 3y ago
Usually the extra complexity is about making sure you only ever have one in your running program.
dkersten 3y ago
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.