Game Programming Patterns (2014)
gameprogrammingpatterns.com
gameprogrammingpatterns.com
It is a nice book and, from memory, is well written. I do think that there are better books with regards to game programming.
I would say this book is good is you are a web developer (or something) and want to brush over ideas on how to build games. What you learn from this book can translate to your day job to solving problems. The reality is many languages, libraries, etc, used in other domains are OOP focused.. so if thats your mindset, this is a good book.
However, if you are serious about (wanting) to be a game developer/programmer, would recommend Game Engine Architecture. Real-tim collision detection is another book from memory.
(I am out of touch if there are any modern books for game developers. Open to hear about them if any)
Another recommendation is to watch Mike Actons 'Data Oriented Design' video on youtube. It is likely 10 years old, now. I still believe it is relevant for modern game dev.
Disclaimer: I am not a game developer. I am an app developer. I builds gui apps, web sites, daemons, etc. However.. if I was to build a game, I would be using the C programming language (or maybe Odin)
I see many game developers who fall into this trap, and then there's the endless debates about "writing your own engine" (which is a bit of a misleading position from the beginning, my personal game has no "engine" that I can see that could clearly be separated from the rest of the game. No this does not mean it is poorly architected).
All of this to say, relax about "patterns" already. Write your damn game, it's waiting for you.
Both are fine choices, but you need to know which and stick to it. And engine in that context refers to all the bits that make the game work, not necessarily that they're in a modular form for others to use.
Basically, you can spend your whole time adding cool or clever features but never turning it into an actual game. It's an easy trap to fall into because adding features is a fun distraction from some of the slog of gamedev. Make the features you need, but don't "gold plate" things.
When in fact it's perfectly reasonable to ship a game without using any off the shelf tooling, or worrying too much about "patterns".
Follow up advice (from someone who isn't really qualified to give it): stop listening to people who say "do this, don't do that, you can't do this, it must be done like this" etc. You know yourself what you're curious about and interested in and what you want to build. This includes this advice, maybe reading about patterns will help you. Let your inner voice guide you.
There is another saying I read somewhere. It was something like: - many people who write games never finish them
This hits home, especially in my younger days. If you are making a game.. focus on that game! Your next game might require you starting from scratch. I get why people try to make a nice engine (ie and using ECS) because the goal is to reuse it many games.
I am sure the (silent) majortiy making an engine for their game... just keep working on their engine. It never leaves thier bedroom.
10000% agree.
In all honesty, I use the word "patterns" loosely, but the word is so loaded today (ie design patterns) with ECS included.
Yes - I am writing a game for my kids, also in C. The game comes first. If (things like) ECS makes sense, I will use it.
It's an amazing book! But it's also a whopping 1000 pages :)
I built an interpreter in WASM and Go when reading the book: https://lox.nanmu.me/en/
I wish I could take everyone currently following Casey Muratori and Handmade Hero and point them Thor's way.
He may not do coding streams as far as I'm aware (I mostly know him from YT shorts), but there are tons of resources out there if you want that. I'd still take Thor's advice about what actually works for shipping games and how the industry actually operates over a guy who's been farting around with a debug room for a decade, and whose primary personality trait is spite for modernity.
I don't think you're characterising Muratori/Blow fairly. Muratori's work on Handmade Hero isn't really about making a game as much as it's about showing the process of making a game, from scratch. It goes through all the tiny-but-important problems that an independent game dev might encounter. The problem I see with Thor's work and this kind of game dev is that it's really unlikely to lead anywhere interesting. Games like Braid or The Witness couldn't be built by just drag-dropping things together in GameMaker, as is the case for most compelling games! If you want to flood the market with little stories told in 2D RPGs or basic Unity showcases, that's fine. But it just strikes me as an uninspired approach to game dev. At least, if you follow Muratori's approach, you can basically build anything that a computer is able to do.
I also think it's entirely unfair to characterise a disappointment in modern software and videogames as "spite for modernity". Sure, they both go over the top and make petty complaints every now and then, just like everyone else. But I think it's pretty clear to anyone who's paying attention that software is simply worse than it was previously, and calling that "spite for modernity" isn't going to help anything.
Maybe it was, years ago. Now, it seems like all he does is refactor game code, for a "game" that has yet to even be designed. This is not how anyone actually interested in making a game, even from scratch, would do so. His last HH post on YT was a year ago. Even the HH subreddit is kind of over his shit.
>Games like Braid or The Witness couldn't be built by just drag-dropping things together in GameMaker, as is the case for most compelling games!
I mean, Undertale, one of the most compelling indie games ever made, was written in GameMaker, but ok. You know you can actually write code for games in those frameworks, though, right? No one is "just drag-dropping things together" in any framework.
>At least, if you follow Muratori's approach, you can basically build anything that a computer is able to do.
Nothing he has done has been that groundbreaking. He's basically writing a 2D Zelda clone. Show me where the inspiration is. You can literally surpass Handmade Hero in a day with a tutorial in just about any modern framework.
>Sure, they both go over the top and make petty complaints every now and then, just like everyone else. But I think it's pretty clear to anyone who's paying attention that software is simply worse than it was previously, and calling that "spite for modernity" isn't going to help anything.
He starts with the premise that C++ is a garbage language created by morons and that anyone who uses object oriented programming has their mind permanently corrupted, and then goes downhill from there. His misanthropic attitude isn't going to help anyone write good software, it's just going to lead to programmers who overoptimize on petty shit and never ship anything. He is the epitome of letting the perfect be the enemy of the good.
When you have a product that you keep on improving, that last 20% will come and haunt you :D.
I’m sure there are some use cases where it makes sense, but I’ve yet to encounter situations where I want the flexibility to compose entities out of data-components (ie entities have a lot of variety, most non-games I’ve worked on, entities tend to be one of a handful preset types), need to operate on subsets of entity data in bulk (systems) and can also tolerate in-memory (lack of transactional persistence). Eg if I need to treat data in bulk, say time series, it tends to be a subset of the data and each entry is more or less uniform (no need to compose out of components), or I need transactional guarantees.
So while I’m sure there are cases where it’s useful outside of games, I feel that almost always a dull blown database us preferable (and even in games I’d say that a relational database would probably be preferable, from a data modelling point of view, if performance weren’t a concern)
I’d love to hear from anyone who has used ECS outside of games, though!
This.
When I try to explain ECS.. or just "data oriented" I often say it is like creating a well defined database. Most developers have experience in SQL one way or another.
> I’d love to hear from anyone who has used ECS outside of games, though!
I am a C# programmer. I am also the Lead Developer. While C# is, by default, an OOP language.. I try to limit on inheritence and/or overrides. Point is I try not to go hard on OOP ways of doing things, and seperate logic into their own libraries.
How is this ECS? The truth is, directly.. it isn't. However, I try to encourage seperation of data and logic. You could say this mindset shares a lot with ECS.
One time -- a few years ago now, where I implemented "ECS like" solution was adding a (free version of) google maps onto our web page. My boss was "but the map might do this" or "but how can the map do that?"
"How can we do that?"
and my answer was components! Nobody really understood what I meant so I chucked an example together and they liked it.
Add the map (the entity) and tell it what components you want. Want to add pins = Component. Want to be able add a circle (point with radius) = Component. Want to create polygons = Component.
The System element would update the components.
Not comparable directly to games, but its an example of ECS outside of it.
Looking back and knowing what I know now (having written a basic ECS mechanism for learning), I think ECS would work well as a guiding pattern. There's basically a fixed number of entities and components, and the systems are not hugely complex. Wire it up with a data input layer and a graphical output layer, and it would be a great fit.
If you update every object - every frame - that's a lot of wasted updates for things that don't need to update for various reasons.
This kind of reminds me of the argument between immediate mode user interfaces and retained mode user interfaces.
The moment you want to simulate something more interesting these walls will be hit and it will directly affect your design process though (design is ongoing as the game is built!). So if you want to be a better game developer, develop in ways that you'll hit these walls less often and limit you less.
And as I related elsewhere, with a Ruby-based game engine it took 1000+ objects being updated every frame alongside other heavy stuff (multi-voice waveform based on-the-fly sound-synthesis, in Ruby) and actually passing each of them to the renderer, before I needed to bother to add any filtering.
And then when I did need to it was a trivial change to filter the list of objects to update. To the point where I literally just currently naively every frame does a map over every object in the level and check if they're within the viewport before doing the update.
Yes, you will sooner or later hit limits, but 1) you're likely to hit them later than you think, 2) it doesn't matter because when you do hit them you're likely to have a good idea of what characteristics to filter them by. E.g. for some games you want to update, but not render, objects outside the viewport in many situations based on other measures - e.g. Minecraft-style simulation of mobs within a certain distance of the player; for other games once an object is off-screen it can cease to exist instantly. But it takes consideration, and you might as well defer that consideration until you need to, because it's orthogonal to the actual update.
And it's easy-ish to go from calling update on everything to moving objects in or out of a "currently visible or at least close enough that we bother simulating them and may need updates" bucket (which might be what's on screen, or what's in a room, or in a level, or within X amount of distance, or any number of other things) at whatever granularity you need to get the performance you want.
The general advice of splitting the updates into frame-sized chunks solves the important beginner issue, and the performance tweak of reducing the number of objects you update is something you'll likely encounter much later.
E.g. I'm currently doing a simple platformer with my son for fun, and just a very crude "is any part of this objects default starting position within x distance from what is currently on screen" is more than sufficient to constrain the update. Before that I just had it even naively render every single object in a level, because it was fast enough, so I didn't bother filtering anything. I only needed to start thinking about performance in the first place because of a combination of me going over-board with various effects and a fully waveform-based software synth and this all being written in Ruby (using the DragonRuby game toolkit [1]). If it'd been written in a faster, compiled language, or I'd been more reasonable in my expectations we'd likely never have needed to think about it. But 10+ parallax layers, wave-formed bases synthesis, and a bunch of pixel effects might be nothing in C, but keeping 60 FPS in Ruby that way takes a little bit of care. That said, we got to 1000+ objects updated every frame before I needed any filtering at all.
I'm sure we'll eventually do more - not all objects have any animations or move, so they'd be easy to filter out too, but then I have to ensure every type of object is categorized accordingly, so I won't bother doing that until there's a need to, and it takes calling an update or render method that does nothing for a lot of objects before it starts dragging down the frame rate.
Game Programming Patterns (2014) - https://news.ycombinator.com/item?id=32837121 - Sept 2022 (20 comments)
Game Programming Patterns: Event Queue (2014) - https://news.ycombinator.com/item?id=24233229 - Aug 2020 (123 comments)
Game Programming Patterns (2014) - https://news.ycombinator.com/item?id=23203699 - May 2020 (86 comments)
Game Loop - https://news.ycombinator.com/item?id=19009206 - Jan 2019 (56 comments)
Game Programming Patterns: Double Buffer (2014) - https://news.ycombinator.com/item?id=17845334 - Aug 2018 (58 comments)
Game Programming Patterns - https://news.ycombinator.com/item?id=14475489 - June 2017 (47 comments)
How I made the print and eBook versions of my web book - https://news.ycombinator.com/item?id=8555285 - Nov 2014 (66 comments)
Game Programming Patterns now available in print and eBook - https://news.ycombinator.com/item?id=8555248 - Nov 2014 (8 comments)
How I wrote Game Programming Patterns - https://news.ycombinator.com/item?id=7646985 - April 2014 (43 comments)
“Game Programming Patterns” is now finished - https://news.ycombinator.com/item?id=7634734 - April 2014 (74 comments)
https://news.ycombinator.com/item?id=7569660 (April 2014)
https://news.ycombinator.com/item?id=7569108 (April 2014)
Speed memory access by arranging data to take advantage of CPU caching - https://news.ycombinator.com/item?id=7543158 - April 2014 (52 comments)
Game Programming Patterns – Bytecode - https://news.ycombinator.com/item?id=7466711 - March 2014 (71 comments)
Game Programming Patterns - https://news.ycombinator.com/item?id=6004885 - July 2013 (64 comments)
Game programming patterns - https://news.ycombinator.com/item?id=874080 - Oct 2009 (8 comments)
as this is the mindset necessary to succeed with games - who will always will eat up all the resources.
Also, inheritance is not evil.
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.
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...
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.
(He did say the pushdown automata part was a rabbit hole though.)
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).
Yes, you can solve it in a million other ways as well.
"How can I use more patterns?" is never the right approach.
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.
That being said, these days there are much better resources out there for this stuff.
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.
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 would know the difference between a hitscan vs VHQ model mapped onto a pawn with a camera.
if you knew the engine.
No, I've not the faintest idea about details of game engines, one area where I happily stay on the customer side.
Your engine isn't a smartphone. It's a tool used by a craftsman to make immersive experiences.
Maybe I'm coloured by the fact I work in AAA gamedev but the notion of ignoring my tools and expecting good outcomes is just complete fantasy.
Instead, today I'll link to different free content that is actually useful advice by people who know what they're talking about: https://blog.unity.com/games/level-up-your-code-with-game-pr...
...also, checkout the link at the bottom to their forum where there's some (reasonably) thoughtful commentary on it by folk who've been down that rabbit hole themselves; including why "Game Programming Patterns" misses the boat in at least some respects.
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 :)