I purchased this book. Might have been about 10 years ago, now.
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)
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.
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.
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.
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!
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’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.
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.
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.
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.
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.
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?
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.
Readit News
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.
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.
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 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
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.