Game Programming Patterns (2014)

by vmoore • 2 years ago

118 74 2 years ago

djmips2• 2 years ago

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.

4pkjai• 2 years ago

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.

LightHugger• 2 years ago

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.

vidarh2• 2 years ago

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

oneeyedpigeon2• 2 years ago

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?

sigmoid10• 2 years ago

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.

oneeyedpigeon2• 2 years ago

This resource is free — the web version, anyway.

krapp3• 2 years ago

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.

cnity3• 2 years ago

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.

snet02• 2 years ago

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!

wokwokwok2• 2 years ago

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.

hacful-tonteg• 2 years ago

could you summarize what's wrong with the book?

wokwokwok2• 2 years ago

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.

vsuperpower20203• 2 years ago

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.

toppy• 2 years ago

Are you referring to this one? https://www.gameenginebook.com/

vsuperpower20203• 2 years ago

That's it.

s_m_t• 2 years ago

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.

vsuperpower20203• 2 years ago

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.

vkazanov• 2 years ago

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

crq-yml• 2 years ago

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.

andai• 2 years ago

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

dkersten4• 2 years ago

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

wink3• 2 years ago

Observer pattern fits like a glove if you for example have a minimap that displays the same things as the normal map.

Yes, you can solve it in a million other ways as well.

"How can I use more patterns?" is never the right approach.

hnben• 2 years ago

I am sorry for the stupid question, but aren't "singletons", "global variables" and "classes with a static pimpl" basically the same things from a design-perspective and their main difference is personal preference (and maybe runtime performance)?

withinboredom2• 2 years ago

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.

lfkdev4• 2 years ago

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.

dijit3• 2 years ago

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!"

k__• 2 years ago

Half-OT: Anyone tried to apply ECS in a different context than games?

dkersten4• 2 years ago

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!

masfoobar4• 2 years ago

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.

omikun• 2 years ago

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.

kitd• 2 years ago

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.

aothms• 2 years ago

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.

sparrowInHand3• 2 years ago

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.

AHTERIX5000• 2 years ago

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.

JoeyJoJoJr• 2 years ago

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.

dang• 2 years ago

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)

dvh• 2 years ago

Do the first 80% of the game the right way, do the last 20% of the game by any means necessary.

koonsolo• 2 years ago

This basically works for any project that has a final release data, and only bug fixes after.

When you have a product that you keep on improving, that last 20% will come and haunt you :D.

djmips2• 2 years ago

haha so true. :D

masfoobar4• 2 years ago

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)

cnity3• 2 years ago

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.

mysterydip• 2 years ago

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.

masfoobar4• 2 years ago

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.

spacechild12• 2 years ago

would recommend Game Engine Architecture

It's an amazing book! But it's also a whopping 1000 pages :)

nanmu42• 2 years ago

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/

richrichie• 2 years ago

I gave up at the command pattern. What an incredible way to beef up loc and to complexify the simple.

jmacklin308• 2 years ago

The sacred text!

Game Programming Patterns (2014)

Related Stories