Game Programming Patterns (2014)(gameprogrammingpatterns.com)
gameprogrammingpatterns.com
Game Programming Patterns (2014)
https://gameprogrammingpatterns.com/
76 comments
A note from someone making a game on the side (in C, actually!): beware of over-focusing on "patterns" and books about them. Yes, there are some great ideas (such as ECS and so on), but don't get bogged down in that. Solve the problems your game lays out for you first and see what difficulties arise. Don't "worship the gate" so to speak.
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.
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.
Fellow "making a game on the side in C" here :) One of the best pieces of advice I read was "you have to ask yourself, do I want to make a game, or an engine?"
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.
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.
Absolutely. I think a lot of people misinterpret this advice like this (or actually the advice is intended this way): if you don't use an off the shelf engine you are destined to slogging away writing your own engine.
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.
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.
> make a game, or an engine
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.
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.
> All of this to say, relax about "patterns" already
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.
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.
> would recommend Game Engine Architecture
It's an amazing book! But it's also a whopping 1000 pages :)
It's an amazing book! But it's also a whopping 1000 pages :)
The author has another book: http://craftinginterpreters.com/ , which is fantastic too.
I built an interpreter in WASM and Go when reading the book: https://lox.nanmu.me/en/
I built an interpreter in WASM and Go when reading the book: https://lox.nanmu.me/en/
It's already very difficult to say what amounts to "good" patterns in game programming and even more so if it comes from one of the most mediocre studios in EA's portfolio. Of course financial/critical success and code quality can be totally uncorrelated, but for people who actually want to get to get a grip on game programming, there are very good free resources out there. One of the most insightful ones I've found are the dev streams of Thor from PirateSoftware. He streams on Twitch and you can also find a bunch of his stuff on youtube. He's one of the few people out there who tells you what you actually need to know if you really want to make a game and not just screw around with experiments.
>One of the most insightful ones I've found are the dev streams of Thor from PirateSoftware.
I wish I could take everyone currently following Casey Muratori and Handmade Hero and point them Thor's way.
I wish I could take everyone currently following Casey Muratori and Handmade Hero and point them Thor's way.
Does Thor ever actually code games? The few times I've seen his stream, he's basically editing config files or doing some drag-and-drop game engine thing. Being entirely unfair based on the low amount of exposure I've had to him, I've basically marked him as an edutainment streamer, where if you really want to learn game development your time is better spent consuming actual educational resources. I could be wrong, though!
He worked at Blizzard for six years then started his own indie game company. His father was the cinematic director at Blizzard. He's shipped a game (Heartbound) which is on Steam now.
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.
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.
To be clear, his work at Blizzard had, as far as I'm aware, nothing to do with game development. His father being a cinematic director also has nothing to do with Thor's game development experience. He shipped one game on Steam, and it's a pretty basic game built using GameMaker. I'm sure it's fun and tells a good story, but it's hardly innovative or complex.
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.
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.
You absolutely can make braid in GakeMaker - I think you’re severely underestimating it.
>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.
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.
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.
[deleted]
Never watched him but honestly, that would be pretty standard mature workflow.
In most video games productions, efficient coding is basically conceptualizing a dsl from the game design, writing it's interpeter while gluing the needed library and make some tools to manipulate or better make converter from existing robust tools. 99% of 'actual game design related' content are assets and data.
Thor is a breath of fresh air. I mean, I do like Casey and Jon Blow and so on, but Thor's positivity is infectious.
This resource is free — the web version, anyway.
Do the first 80% of the game the right way, do the last 20% of the game by any means necessary.
Half-OT: Anyone tried to apply ECS in a different context than games?
I’ve thought about it a bunch, because I quite like ECS in games, but for me, doing web service backends, there was never any real benefit over just using a relational database since ECS is basically an in-memory subset of relational. Even when that is enough, I found that I rarely deal with collections of entities with particular components in bulk like I would with ECS, but rather most web API’s operate on individual entities at a time, so the ECS benefits are less useful.
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!
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!
> I’ve thought about it a bunch, because I quite like ECS in games, but for me, doing web service backends, there was never any real benefit over just using a relational database since ECS is basically an in-memory subset of relational.
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.
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.
I don't have any examples but I would love it if spreadsheet programs would use this for generating plots. It's pretty much impossible to plot anything with more than 100k data points in anything I've tried.
It’s just storing the cells in a columnar fashion. If you don’t need the component composition (systems that can iterate entities that have certain components) then to don’t really be ECS, just use a tightly packed array.
Long ago, I interviewed for a job at a company that wrote race car monitoring systems (ie displaying graphical real-time data about car & engine state and conditions). They wanted to know how I would go about developing such a system. My young green self gave some half-arsed answer and I didn't get the job (sadly. The perks were magnificent).
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.
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.
I know that Autodesk (and other construction software vendors) aim to do something akin to this to organize their data API https://aps.autodesk.com/en/docs/fdx/v1/developers_guide/cor... The S for System is somewhat unarticulated here.
https://gameprogrammingpatterns.com/update-method.html
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.
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.
Yes, but often it's okay to do these 'unnecessary' updates. The real slow part is drawing a frame.
This kind of reminds me of the argument between immediate mode user interfaces and retained mode user interfaces.
This kind of reminds me of the argument between immediate mode user interfaces and retained mode user interfaces.
It depends on the kind of game you're working on, but arguably if you're working on anything ambitious then you can't do it. Yes you can scrape by doing pointless heavy updates every frame for only 100 objects in the entire game world.
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.
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.
Those updates don't need to be heavy if nothing is happening.
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 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.
[deleted]
But a lot of the time it doesn't matter.
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.
[1] https://dragonruby.itch.io/dragonruby-gtk
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.
[1] https://dragonruby.itch.io/dragonruby-gtk
It's ok to criticise, but it's more useful to suggest better alternatives. How would you optimise this? Only update objects in view or within a certain distance of the player?
Related:
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)
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)
Obligatory data orientated design https://www.dataorienteddesign.com/site.php
as this is the mindset necessary to succeed with games - who will always will eat up all the resources.
as this is the mindset necessary to succeed with games - who will always will eat up all the resources.
It's not necessary though. For every /r/gamedev ECS project there are many actually shipping products using whatever OO system and doing just fine, also in AAA space. If you are working on state of the art AAA product the situation is a bit different. But for the most games being sold on marketplaces like Steam it really doesn't matter as much as people on gamedev communities like to think.
It should also be mentioned that you can go very, very far with absolutely abysmal code quality when making a game, and you can waste an insane amount of time attempting to lay a solid code foundation.
Also, inheritance is not evil.
Also, inheritance is not evil.
Look at the sauerbraten 2 engine and tell me that again.. inheritance is composition for fools
Streets of Rogue has notoriously awful code, but it's an absolute masterpiece.
I gave up at the command pattern. What an incredible way to beef up loc and to complexify the simple.
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.
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 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.
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.
Usually the extra complexity is about making sure you only ever have one in your running program.
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.
Yes, you can solve it in a million other ways as well.
"How can I use more patterns?" is never the right approach.
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...
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.
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.
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.
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!"
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!"
So Unreal 5 is not very good at handling extremely fast moving bullets? ;)
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.
Correct.
You would know the difference between a hitscan vs VHQ model mapped onto a pawn with a camera.
if you knew the engine.
You would know the difference between a hitscan vs VHQ model mapped onto a pawn with a camera.
if you knew the engine.
I suppose that's either a big yikes or a "ah well, it somehow works anyway".
No, I've not the faintest idea about details of game engines, one area where I happily stay on the customer side.
No, I've not the faintest idea about details of game engines, one area where I happily stay on the customer side.
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 can stand by it all you want, but that's not the nature of the world.
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.
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.
What about the part on state machines? I haven't done much of that yet but my friend used that chapter as reference to make a simple platformer.
(He did say the pushdown automata part was a rabbit hole though.)
(He did say the pushdown automata part was a rabbit hole though.)
Usually when this pops up I drop in to tell people not to waste their time with it, but, people are relentlessly drawn to free content, no matter how questionable it is.
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.
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.
could you summarize what's wrong with the book?
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.
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.
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 :)
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 :)
"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 :)
> 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 :)
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.
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.
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.
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.
The sacred text!
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)