
Game Programming Patterns (2014) - simonpure
http://gameprogrammingpatterns.com/
======
formalsystem
This is the book that finally helped me grok software design patterns. Gang of
four reads like a dictionary while the examples of Game Programming patterns
have stayed with me.

If I'm rendering a forest of course I don't want to copy the data for trees a
1000 times so of course I need to use the flyweight pattern

The decoupling patterns chapter is particularly good and will help you
understand how to turn each entity in a game into a server which sends events
to other entities. That way you end up with many small pieces of a code as
opposed to a single giant game loop. The entity component system (ECS) is one
of the main reasons why programming games in Unity is so pleasant.

If it wasn't obvious by now, this is not a book about game programming
patterns it's the best book on software design patterns that I've ever read.
Most software design books seems to think I'm only interested in designing
accounting or banking software, why not a game?

~~~
anchpop
> The entity component system (ECS) is one of the main reasons why programming
> games in Unity is so pleasant.

I agree programming in Unity can be very pleasant. To avoid confusion, I
wanted to point out that traditional Unity programming isn't really a typical
example of an ECS. Unity's system actually lacks most of the performance
benefits you can get from one. This is relevant because Unity is actually
currently developing a "real" ECS architecture they call DOTS (data oriented
technology stack).

~~~
meheleventyone
To be ultra confusion avoiding you don’t necessarily get great perf benefits
from the merely organising things as per the ECS pattern. You still need to
organise your data around how it is used. Which is why Unity uses archetypes
which trade fairly automatic organisation based on entities component
signature for increased cost if you add and remove components from them (as it
triggers reorganising where that entities components are stored). There are
other patterns with different trade offs.

In terms of just mental overhead any form of composition is useful be it
Components in the Unity sense or Components and Systems in the ECS sense.

------
munificent
I know this book! :)

I had occasion to dig through my sales data, so if anyone is curious, since I
first put this book out there, I've sold 26,009 print copies and 13,066 Kindle
copies. I didn't count the ePub and PDF sales. It's been translated to Korean,
Chinese, Japanese, German, and Polish.

It's incredibly gratifying to see it still helping people six years later. I
can't wait until I'm through building the print edition of my second book [1]
so people can get their hands on that too.

[1]: [http://craftinginterpreters.com/](http://craftinginterpreters.com/)

~~~
nivethan
Thank you for the book and I can’t wait to get a copy of it! I did the first
part in typescript and it’s crazy how much of your java code just works with
minimal massaging.

Would you recommend brushing up on C before jumping into the second half, I
don’t want to just be copying code and miss the real picture.

Just some a stream of consciousness as I read the book and had my mind blown a
few times.

[https://github.com/Krowemoh/ts-lox](https://github.com/Krowemoh/ts-lox)

~~~
munificent
It depends on your level of C expertise. It's not very advanced, sophisticated
C, so if you're mostly got pointers loaded into your head, you'll be fine. If
a few ` _` and ` &` will leave you scratching your head, it's not a bad idea
to practice a little before you tackle the book.

The introduction chapter suggests this exercise:

_> To get some practice with pointers, define a doubly-linked list of heap-
allocated strings. Write functions to insert, find, and delete items from it.
Test them.*

If you can handle that, you should be fine for the rest of the book.

------
Kapura
I've been programming in the games industry, first at indie scale and now at
AAA, and I use almost all of the patterns described in the book in some way.
This is an invaluable resource for people to learn not only the sorts of
programming patterns used in games, but also the sorts of problems that game
developers are challenged to solve.

I've found that google and stack overflow are now worthless for anything
outside of checking syntax for a C++ lambda. Everything else I work on is
essentially a novel problem set.

~~~
robmaister
I 100% agree and I also work in AAA. On the subject of StackOverflow being
worthless... I've been working for 4 years now and I have learned pretty
consistently over that time that the best way to solve a problem is to just
keep digging deeper into the system with the issue.

You will eventually figure out that either the system has a bug or you used it
wrong. And along the way you will familiarize yourself more with the system.
(and debugging tools!)

The learning effect of this snowballs the more you do it. I'm a year and a
half into a UE4 project and am now the "engine person" who people come to with
questions or odd crashes.

I have seen every single pattern this book describes used somewhere within
Unreal. They are all super valuable to know especially within game programming
where problems are novel and often open ended.

~~~
Kapura
>I have learned pretty consistently over that time that the best way to solve
a problem is to just keep digging deeper into the system with the issue.

>You will eventually figure out that either the system has a bug or you used
it wrong. And along the way you will familiarize yourself more with the
system. (and debugging tools!)

I identify with this so much. It's a different kind of programming, where
you're finding the source of the bleeding instead of trying to just bandage
the wound, which is much more what I encountered in the tech industry.

------
dang
See also... the largest previous threads:

2017:
[https://news.ycombinator.com/item?id=14475489](https://news.ycombinator.com/item?id=14475489)

2014:
[https://news.ycombinator.com/item?id=7646985](https://news.ycombinator.com/item?id=7646985)

2014 ('now finished'):
[https://news.ycombinator.com/item?id=7634734](https://news.ycombinator.com/item?id=7634734)

2013:
[https://news.ycombinator.com/item?id=6004885](https://news.ycombinator.com/item?id=6004885)

About specific chapters:

2018:
[https://news.ycombinator.com/item?id=17845334](https://news.ycombinator.com/item?id=17845334)

2014:
[https://news.ycombinator.com/item?id=7543158](https://news.ycombinator.com/item?id=7543158)

2014:
[https://news.ycombinator.com/item?id=7466711](https://news.ycombinator.com/item?id=7466711)

The first thread was
[https://news.ycombinator.com/item?id=874080](https://news.ycombinator.com/item?id=874080)
from 2009, and the discussion is about how incomplete everything is. That's
interesting, because how many items with a discussion like that ever actually
do get completed?

If I missed any interesting discussions let me know and I'll add to the list.

------
elyseum
Same author as
[http://craftinginterpreters.com/](http://craftinginterpreters.com/) Can’t
wait for this one to appear in print.

~~~
signaru
This guy really deserves an award. I wonder decades from now, how many people
would look back and say how much these books have influenced them.

~~~
munificent
_> This guy really deserves an award._

I have been amply rewarded by both sales and really really nice words from
people over the years, so I think I've got more awards than anyone could ask
for.

What's interesting is how circular the process is. If my first book hadn't
been successful, I certainly wouldn't have written my second book, so I owe
its existence to many other people.

------
s3cur3
If you'd like a summary of the book, my study notes are here:

[https://tylerayoung.com/2017/01/23/notes-on-game-
programming...](https://tylerayoung.com/2017/01/23/notes-on-game-programming-
patterns-by-robert-nystrom/)

------
DethNinja
This is one of the best books available on the subject of design patterns. I
highly recommend it for all programmers even those not in gamedev.

Keep in mind that some novice programmers assume design patterns are strict
rules and you have to copy all idioms, naming rules etc. but they are just
simple guidelines, feel free pick them apart and combine them on your code.

------
rectang
According to the "Game Loop" chapter, the "intent" of the Game Loop pattern is
to _" Decouple the progression of game time from user input and processor
speed."_

[http://gameprogrammingpatterns.com/game-
loop.html](http://gameprogrammingpatterns.com/game-loop.html)

The chapter goes on to assert:

> _Game loops are the quintessential example of a “game programming pattern”.
> Almost every game has one, no two are exactly alike, and relatively few
> programs outside of games use them._

It seems to me like audio programs would typically be organized using
something very close to the Game Loop pattern, though? A loop with where a
batch of data is rendered on each iteration, decoupled from the processor
because of the need to match the sample clock.

Is there a resource out there that describes audio programming patterns for
organizing the whole program? Most of what I've read describes how to use an
existing framework — e.g. how to write a plugin — and while that's not
surprising, I'd really like to explore all the possible options for high-level
organization of a real time audio app. I haven't ever seen something similar
to this "Game Loop" chapter for audio.

~~~
mcv
Yeah, I imagine anything that needs to produce output continuously independent
from user input, while quickly responding to user input, needs this kind of
loop.

At the same time, while most games these days need it, I don't see why a
purely turn-based game would need it. If you only produce output when the user
gives input, you probably won't need it. Those kind of games are rare these
days, but roguelikes are still getting made apparently.

------
dakom
I had a bit of difficulty with this book. Loved reading it in every way
(style, content, clarity, etc.) - but in parts[0] of every section I found
myself thinking, "wait - of course that's what I'd do... but that's just,
like, the thing to do... why is it a pattern? Does it really matter if I call
it that pattern or if I don't know the pattern name?"

Maybe it's because I didn't learn coding in university, or because most of my
career has been spent in _very_ small teams with little need to use pre-
established jargon, but I get slightly annoyed when I see discussions about
this pattern or that pattern and I have no clue what they're doing, even if
I've myself used that "pattern" dozens of times without knowing the accepted
name for it. YMMV

[0] the other parts would be when it got into the nitty gritty of solving a
specific problem instead of the generic pattern. For example, propagating
transforms using the |= trick. That stuff was great for me.

~~~
munificent
_> I get slightly annoyed when I see discussions about this pattern or that
pattern and I have no clue what they're doing, even if I've myself used that
"pattern" dozens of times without knowing the accepted name for it._

Having an agreed-on name for it _is_ how you avoid that frustration.

~~~
dakom
Hehe - I wasn't sure which person to reply to... then I realized, it's YOU!

First of all - I want to say thank you. I really really did enjoy the book and
smiled at the picture with your dog (as well as all the programming stuff ;)).
Honestly, I've recommended it to others enthusiastically and got a lot out of
it. Thanks!

I totally agree with what you and others said. I get it - and the only way
I've been able to get away with not knowing the names of some of these
patterns is precisely because I've only worked in very small teams and had a
lot of autonomy. Also, for async/internet discussions I often have enough time
to look it up if someone uses the jargon, and because I've encountered the
names/concepts before (like in your book) it doesn't take long to catch up to
the conversation.

That said - I'd like to explore one more avenue... is it possible that not
seeing things as patterns allows for a more intuitive grasp? e.g. if I want to
do things based on some current state, yeah I could reach for "statecharts" or
"finite state machines"... but thinking of things as enums with switching
based on the enum value might lead to a more intimate grasp of what's going
on, and clearer insight into the different ways to hack around the problem?
That might not be the best example (I've basically described a state machine
and then said "how about not using a state machine") - feel free to substitute
a better one if the question makes sense.

I guess I'm wondering if maybe there's an advantage to solving these things
over and over but not seeing them as patterns? Not saying I'd recommend it..
just, if there's a silver lining to a bit of ignorance?

~~~
munificent
_> is it possible that not seeing things as patterns allows for a more
intuitive grasp?_

Yes! I think about this often. There is sort of a Zen or Bruce Lee aspect
where thinking of things strictly in terms of named categories can lead to
overly rigid thinking and cause you to avoid better solutions simply because
they don't have a name and don't seem as "real".

There is a balancing act, though. When we write code on a team, there is a
real value to _shared_ understanding of the codebase. Sticking to familiar
categories, even at some minor expense of fitness to the task, is probably a
net gain if it makes it easier to the entire team to understand what the code
is doing and why.

It's also important to remember that the primary reason the Gang of Four wrote
Design Patterns and called them _patterns_ after Christopher Alexander's A
Pattern Language is because they are _not_ rigid copy/paste structures. If
they were, we'd just call them data structures or algorithms.

The fundamental premise of why we call these patterns is that each
manifestation of a pattern will appear slightly different, shaped by the
context in which it is applied. That's why you don't often see resuable
"pattern implementation libraries".

Good literature on patterns stresses this flexibility. Less good literature
tends to just say "here's the thing that solves all your problems" and
discourages readers from thinking deeply.

~~~
dakom
Btw, I _think_ this exact concept might have been dealt with a bit in Zen and
the Art of Motorcycle Maintenance. I just can't figure out which viewpoint
falls into the "classical/analytical" and which falls into the
"romantic/intuitive"... an argument could be made on either side, and as you
said it's best to master both and find the balance. Food for thought!

------
fao_
So far with game programming the most difficult problem I've had is input
states. There doesn't seem to be a clean way to manage it that doesn't get
very messy, very fast. Even though it should be easy to manage since it's just
a state machine!

~~~
simonbw
By input states do you mean stuff like knowing whether a key is currently
pressed or a mouse button is currently held down? Could you explain what you
mean by it gets messy?

~~~
fao_
I mean segregating mouse actions. So: Drag, Click, etc. Also handling
selection events and so on. I've been using love2d, which basically means you
have to set up those manually. Then building a state machine in lua gets very
messy.

I dunno, maybe I'm just overthinking it

------
rimher
Loved this book! Reads really well.

Author here:
[https://twitter.com/munificentbob/](https://twitter.com/munificentbob/)

~~~
isoos
Also author here on HN:
[https://news.ycombinator.com/user?id=munificent](https://news.ycombinator.com/user?id=munificent)

------
gww
I have always wanted to program a 2D game engine in C++ for fun. Mostly as a
learning experience but whenever I decide to do it I get intimidated trying to
figure out how to design it and give up. Does anyone have any recommendations
of resources to get over figuring out how where to start?

~~~
markus_zhang
My advice is to follow gaming history and reuse engine code as much as
possible. Use SDL2 as it is barebone and yet privides you sophisticated tools.

Here is a list of 12 games that I picked because I'm biased towards RPG but
you can definitely choose your own wishlist.

Part one: Warm up and basic input, audio and video.

Pong, Snake, Tetris, Breakout, Galaxian, Frogger.

Part Two: Scrolling screen, levels and overall game architecture:

Super Mario, Gradius, Twinbee

Part Three: RPGs which are more or less "complete" games and need some
tooling:

Ultima III, Wizardry I Japanese version, Dungeon Master

Part Four: Just keep practicing. You already graduated and can do whatever you
want!

Also don't forgrt to read Masters of Doom which will give you tons of
inspiration. You can actually walk Carmack's route as well. His first
commercial game is an Ultima spin off called Wraith.

~~~
markus_zhang
To correct: Carmack's first commercial game is NOT Wraith, but Shadowforge.
But the engine is very similar to the one he used to develop Wraith.

------
tgb
What's the gist of the setup for how a complex RPG rule system gets coded up?
Like in D&D or a Diablo-like, you have base stats, equipment or classes modify
those stats, sometimes the modifiers depend upon the circumstances, and maybe
the modifiers get modified. So clearly you don't want to have a Belt of +4
Strength just do wearer.strength += 4 since at some point you'll have to take
off the belt or are in an anti-magic field, etc. But what's a good and/or
standard design for encoding all that kind of logic?

~~~
munificent
I've run into this exact issue in my roguelike [1]. I don't think I have a
fully baked solution yet, but the direction I'm going [2] is a combination of
the Observer pattern and caching.

For derived stats, it's not enough to just always recalculate its value from
scratch every time you access it. At least in my game, I also want to tell the
user when the value of a derived stat changes. If you equip a piece of armor
that raises your strength, I want the game to tell you "You feel stronger!".

So each derived stat stores its current value and then has a refresh()
function to recalculate itself. The stat is refreshed at the end of each turn.
It recalculates the value and then compares its previously cached one. If the
value changed, it logs the result and then updates the cache.

[1]:
[https://github.com/munificent/hauberk](https://github.com/munificent/hauberk)

[2]:
[https://github.com/munificent/hauberk/blob/master/lib/src/en...](https://github.com/munificent/hauberk/blob/master/lib/src/engine/hero/stat.dart)

------
lachlan-sneff
I haven't had time to read the book yet, but the web version of it is just so
beautifully displayed. So, kudos for that :)

~~~
munificent
Thank you, I put a _lot_ of time into the design and CSS.

------
Sprakle
Does this book have much relevance for someone already working in an existing
engine like Unity?

~~~
zwaps
I think it's probably good to know for every engine and besides, it's a
beautiful book.

That being said, armed with my baby knowledge of programming patterns, I then
did find it frustrating that today's engines are very high level and quite
opinionated about how you code. Take for example Godot. It's not 'quite' an
ECS and there are certain ways to script things which you should follow. How
to fit the patterns from this book into a Godot game is a whole other
ballgame.

This book makes me want to write my own engine. Not to deal with the technical
details, but to be in control of the program logic. This excellent book makes
you want to worry about the stuff that engines abstract from in their own
special way. That's not efficient from the standpoint of getting a game done -
things are done in Unity or Godot in their specific way for good and battle-
tested reasons.

~~~
moonchild
> This book makes me want to write my own engine

Do it!

I've been working on a game engine for several months now. It's a similar kind
of hell to working on an OS (though easier to debug...until you start using
threads), but it's fun.

------
marvinblum
Ah yes I remember. This site teached me so much, even if I'm not doing game
programming anymore. It shows some generally useful patterns and algorithms
not only relevant to game development. So if you're a programmer, give it a
shot!

------
rahulpyd1
This book is well written. It has the right amount of detail and simplicity.
When I started out in game development the book helped me lot in understanding
game development.

------
toastal
I wish there was a complete FP engine. Most 'patterns' in FP are (surprise)
just functions. There's a lot of blogs with some simple examples from scratch,
and that's really cool, but there's a lot of room for a complete system. What
isn't needed is all this encapsulation and inheritance I see in many other big
engines.

~~~
mwindow
Have you heard of the Nu game engine[1]? It is a FRP-based game engine for F#.

[1] [https://github.com/bryanedds/Nu](https://github.com/bryanedds/Nu)

~~~
toastal
I have. It seems pretty neat, but .NET is not for me.

------
gentleman11
This book is fantastic. If the author is reading this, please don’t feel shy
about expanding the chapter on state machines. It is an extremely deep and
valuable subject with a lot of “get your hands dirty” learning to do. Thanks
for writing what you did!

------
edem
This book is pure gold. I recommend this to any programmer!

------
golyi
I love this book and will not only will it help you for game development, but
all software engineering in general. Highly recommended.

------
lonk
It's a good book, but it contains lines of code that appeal to the
subconscious like:

int destY = unit->y() - 1;

------
kuharich
dang, prior comments:
[https://news.ycombinator.com/item?id=8555285](https://news.ycombinator.com/item?id=8555285)

------
Konryan
Do you have any recommendations for books about Game Architecture?

~~~
meheleventyone
Game Engine Architecture is a great overview and on it’s third edition.

~~~
hesdeadjim
First version of this book was an immense help for me early in my career.

