
Game Programming Patterns - netgusto
http://gameprogrammingpatterns.com/
======
netgusto
This is from the same fine gentleman that gives us
[http://www.craftinginterpreters.com/](http://www.craftinginterpreters.com/)

Thank you so much for your work.

------
kgabis
Great book. I recommend buying a paper/ebook version to support the author.
His writing style is very concise and funny so it's easy to follow and it
reads very fast. The only thing I didn't like is that for code examples he
uses C++ with unnecessary classes where vanilla C functions would've been
sufficient, but I understand his reasoning for doing so ("It is the lingua
franca of the industry").

Does anyone have any recommendations for other books about game engine design?

~~~
EamonnMR
I enjoyed reading this book:

[http://www.gameenginebook.com](http://www.gameenginebook.com)

~~~
kgabis
Thanks, I'll give it a try.

------
tydok
I use extensively in my projects the Component decoupling pattern:
[http://gameprogrammingpatterns.com/component.html](http://gameprogrammingpatterns.com/component.html)

The Observer and Mediator patterns can then be used for wiring components.

------
gravypod
I had to come here after reading up to the "Command" interface idea. This book
has a lot of things that look good on a 3 to 4 element case but, when scaled
up, will become unwieldy.

Adding all of this complexity to button clicks does not sound very intuitive.
The original if statement wasn't either but the Command interface wasn't a
good replacement. I've always liked using event systems for handling actions
like this. C++ would probably be a great language to implement a fast priority
based, cancellable, and event system. For something along the lines of what
I'm talking about see [1]. It's not perfect (you need a dispatcher for every
event) but it still better captures the idea that "Something happens and it
triggers N many actions".

Maybe it's just different style. Maybe it's just different ways of thinking
about the problem. Maybe it's just that I'm not a gamedev and I work in a
different sector.

[1] -
[https://codereview.stackexchange.com/questions/118628/c14-ev...](https://codereview.stackexchange.com/questions/118628/c14-event-
system)

~~~
ghusbands
Given that the book talks about it being used for controller buttons and for
undoable actions in strategy games and editors, performance is not a
significant concern and event-dispatchers are insufficient. Your comment is
not particularly on-topic.

~~~
gravypod
> Given that the book talks about it being used for controller buttons and for
> undoable actions in strategy games and editors

The state should be managed by a UI object if you're talking about calling up
UIs. The key presses will be subscribed to in that object and, when the event
is triggered, the UI object takes over. Then the button is clicked again the
UI object can undo whatever state it has created.

> performance is not a significant concern

Performance isn't my concern. My concern is that you've created 6 new classes
to handle 5 button clicks. That sort of class bloating makes it very
difficulty to enter the code base (lots of unneeded wrappers for actions).

It also decouples the action from the object that the action is built for.
This spreading doesn't make sense to me. The UI object should handle all
things UI. The player's object should handle all things player. A Command
object shouldn't be extended by 10 other objects who all touch different
objects doing different things.

> event-dispatchers are insufficient

Why?

> Your comment is not particularly on-topic.

It is. I am talking about how I only got a few pages in and found it to be
promoting patterns I'd consider harmful which either use an abstraction that
doesn't fit the problem, or do things that make it very hard to enter a new
code base.

~~~
shadowmint
Yup.

See, this is why I struggle to recommend this book.

> In some ways, the Command pattern is a way of emulating closures in
> languages that don’t have them.

...

> For me, the usefulness of the Command pattern really shows how effective the
> functional paradigm is for many problems.

So close, yet so far. The Command pattern is a brilliantly useful pattern, and
I've seen it used to great effect; but it's not remotely about callbacks or
closures; thats just an implementation detail.

You're completely right, do you really need a JumpCommand, a
JumpCommandHandler, and an UndoJumpCommand (?? What does that even mean?) when
you could just have one class, called Player, with a method `jump`?

No. You don't.

It's a daft example.

The Command pattern is about have _composable atomic state transactions_ over
your game state.

For example, if you have a SpawnMonsterCommand, and a
ApplyStatusEffectCommand, you can create a hoard of raging monsters using a
SpawnHoardCommand; that _calls_ the SpawnMonsterCommand 100x and then calls
ApplyStatusEffectCommand to the monsters.

Then you can have a SpawnBattleCommand that calls SpawnHoardCommand twice,
with a different faction, or say, three times with 3 different factions to
generate a battle.

Or perhaps you're using an async resolution model, where you're commands are
like MoveToLocationCommand, and AttackTargetCommand; and you need to start the
MoveToLocationCommand then wait for it to finish before you run the
AttackTargetCommand.

Abstracting the functionality into small chunks lets you easily build complex
chained behaviour, and you can even test it easily because each 'Command' is
an isolated and known behaviour.

...but yeah, totally. A flurry of classes. Don't use it if you don't get some
value from it.

Having an undoable 'JumpCommand' falls firmly into the 'dont bother' category.

~~~
gravypod
With that use case I can understand why people would want this! You should
make one of these books.

------
shadowmint
I don't know.

I have such mixed feelings about this; it's free... but, I don't actually
think it's... good? I mean, it's well written, and it has examples that try to
tie it into practical examples, and _thats_ good, but there are just lots of
little technical details that I find are slightly off.

For example, a considerable amount of time is devote to showing that the
'observer' pattern isn't a bad idea.

...but, although its not always a bad idea, there are a number of people (see
[1]) who have comprehensively covered why it is troublesome.

On the prototype pattern:

> With all of these options, I honestly can’t say I’ve found a case where I
> felt the Prototype design pattern was the best answer. Maybe your experience
> will be different, but for now let’s put that away and talk about something
> else: prototypes as a language paradigm.

...what? Then why did you bring it up at all?

Each of the chapters is really long, covering what is really quite basic
material mixed in with some kind of questionable content and some examples...
but no actual working code to show how to use the examples.

I like
[https://en.wikipedia.org/wiki/Software_design_pattern](https://en.wikipedia.org/wiki/Software_design_pattern)

...I'd like this too, if it was just... I don't know. Slightly more
technically sharp and less rambling?

Surely you could cut down the discussion slightly, show a practical example of
where each pattern is _actually useful_ that _actually compiles_ , and just
drop any patterns that... aren't useful, and you'd have an excellent book.

[1] -
[https://infoscience.epfl.ch/record/148043/files/DeprecatingO...](https://infoscience.epfl.ch/record/148043/files/DeprecatingObserversTR2010.pdf)

~~~
ghusbands
It's a reasonable introduction to many concepts and design patterns that are
useful in many areas of programming, including games. Even if it's not the
best treatment of each, the quality, style and pace keeps it useful and
engaging. If it's not for you, that's fine, but if your comment becomes the
top one, I think it could dissuade a lot of people who could benefit from
giving it a read.

~~~
danielbarla
I agree with this assessment. One of the issues I had with the GoF patterns
book (from the perspective of one's first book on patterns), is that it's
heavy reading for the target audience (i.e. people clearly not exposed to
patterns before). If you're in that situation, you'll struggle to stick with
the book and appreciate it. For everyone else, it's probably preaching to the
choir.

This book on the other hand - while perhaps lacking on implementation details
- does a wonderful job of introducing a variety of patterns and their
usefulness as abstractions.

------
partycoder
"What is software architecture". Just skip all that part and refer to ISO/IEC
42010 instead. This description of software architecture is the equivalent of
the Industrial Revolution description from Adam Sandler's movie "Billy
Madison". In fact, 99% of people speaking about software architecture haven't
even bothered to read the actual definition of it.

I read this book some years ago: [https://www.amazon.com/3-0-Design-Patterns-
Real-World-Proble...](https://www.amazon.com/3-0-Design-Patterns-Real-World-
Problems/dp/059652773X) , it's rather dated now (from 2008, targetting C#
3.0), but illustrates patterns well with clear, concise and self-contained
code and a more general approach.

------
seibelj
This is an excellent programming book, even if you don't intend to make games.
Highly recommend

~~~
yoodenvranx
Yes, the "game" part of the title is slightly misleading. I have never touched
any game related code and I still found the book very helpful.

------
justinhj
I jumped into a few topics at random and this seems like a good book,
definitely filled the void it intended too. When I was getting into game
programming in the early 90s there was literally nothing for me in the book
store specifically about game programming.

------
maaaats
Wow, the free web version looks great. Will give it a read, as all my game
projects ends up with me reinventing a game engine or getting stuck with some
dataflow that should be a solved problem with a cleaner solution.

Like the landing page as well, very clean and to the point.

------
HiroshiSan
Will this book teach me to code videogames? If not where can I learn that
before reading this book?

~~~
felipemnoa
Start by learning OpenGL. Two resources I would start with are the OpenGL Red
Book [1] and NeHe [2] tutorials.

The OpenGL Red Book has everything a beginner needs to know about OpenGL and
NeHe is a bunch of tutorials that you can study to learn more about the
concepts. If you search around the web you should be able to find NeHe
examples in your programming language of preference.

[1] [http://www.opengl-redbook.com/](http://www.opengl-redbook.com/)

[2][http://nehe.gamedev.net/](http://nehe.gamedev.net/)

~~~
maaaats
Thats way too much complexity to get into game programming. Just start with
something where you can draw shapes and images to some canvas, and make it
interactive. No need to start with 3d, and at least not the low level 3d
stuff. Then you will never actually end up creating something.

~~~
khedoros1
Agreed. I'm currently teaching myself OpenGL, but only after getting pretty
comfortable with using SDL and SFML for 2D graphics (drawing directly to a
buffer in SDL, and using SFML to draw textured shapes, sprites, and such).

3D has a whole ton of boilerplate; it's better to start with something a
little simpler to experiment with some patterns.

------
IE6
Somewhat related - are there similar resources for other other kinds of
software?

------
wheresvic1
What did you use to generate the web version of the book?

~~~
msangi
Have a look at the author's blog and at the book repository on GitHub
[http://journal.stuffwithstuff.com/category/book/](http://journal.stuffwithstuff.com/category/book/)
[https://github.com/munificent/game-programming-
patterns](https://github.com/munificent/game-programming-patterns)

