[HN Gopher] Game Programming Patterns (2014)
___________________________________________________________________
Game Programming Patterns (2014)
Author : simonpure
Score : 389 points
Date : 2020-05-16 14:36 UTC (8 hours ago)
(HTM) web link (gameprogrammingpatterns.com)
(TXT) w3m dump (gameprogrammingpatterns.com)
| marvinblum wrote:
| 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!
| [deleted]
| elyseum wrote:
| Same author as http://craftinginterpreters.com/ Can't wait for
| this one to appear in print.
| signaru wrote:
| 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.
| aidos wrote:
| He's an amazing writer. I couldn't put this book down when I
| first read it. At the time I sent him a message saying that it
| was the best technical book I'd ever read and his response was
| along the lines of "thanks! It's the best (though, only) one
| I've written". I'm glad that's no longer true.
|
| Even reading his writing about writing risks reducing you to
| tears.
|
| http://journal.stuffwithstuff.com/2020/04/05/crafting-crafti...
| airstrike wrote:
| You might enjoy this discussion
| https://news.ycombinator.com/item?id=22788738
| edem wrote:
| This book is pure gold. I recommend this to any programmer!
| lachlan-sneff wrote:
| 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 :)
| tgb wrote:
| 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?
| formalsystem wrote:
| There's a combination of patterns. IMO the best way to learn
| how this stuff works is to look at the code of a production
| level MMO/MOBA/RTS. Here is a really good one
| https://assetstore.unity.com/packages/templates/systems/ummo...
|
| Worth every penny.
| s3cur3 wrote:
| If you'd like a summary of the book, my study notes are here:
|
| https://tylerayoung.com/2017/01/23/notes-on-game-programming...
| Sprakle wrote:
| Does this book have much relevance for someone already working in
| an existing engine like Unity?
| zwaps wrote:
| 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.
| trynewideas wrote:
| Yes, absolutely, 100%. It's engine and language agnostic; many
| of the examples are written in C++ in lieu of pseudocode, but
| he also goes into where C# differs in behavior enough to affect
| the pattern.
| rimher wrote:
| Loved this book! Reads really well.
|
| Author here: https://twitter.com/munificentbob/
| isoos wrote:
| Also author here on HN:
| https://news.ycombinator.com/user?id=munificent
| dang wrote:
| See also... the largest previous threads:
|
| 2017: https://news.ycombinator.com/item?id=14475489
|
| 2014: https://news.ycombinator.com/item?id=7646985
|
| 2014 ('now finished'):
| https://news.ycombinator.com/item?id=7634734
|
| 2013: https://news.ycombinator.com/item?id=6004885
|
| About specific chapters:
|
| 2018: https://news.ycombinator.com/item?id=17845334
|
| 2014: https://news.ycombinator.com/item?id=7543158
|
| 2014: https://news.ycombinator.com/item?id=7466711
|
| The first thread was 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.
| formalsystem wrote:
| 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?
| LudwigNagasena wrote:
| The MonoBehaviour pattern is similar to ECS (both follow
| composition over inheritance), but there are some crucial
| differences IMO. In case of monobehaviours there are no systems
| as such and components aren't mere data containers.
| ElFitz wrote:
| > turn each entity in a game into a server which sends events
| to other entities.
|
| This reminds me of event-driven microservices. Is it similar,
| in principle?
| anchpop wrote:
| > 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 wrote:
| 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.
| Konryan wrote:
| Do you have any recommendations for books about Game
| Architecture?
| meheleventyone wrote:
| Game Engine Architecture is a great overview and on it's third
| edition.
| hesdeadjim wrote:
| First version of this book was an immense help for me early
| in my career.
| fao_ wrote:
| 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!
| softfalcon wrote:
| Yeah, before you know it, you're in the land of colliding mouse
| down events.
|
| Best I've been able to do is group interaction views together
| (think inventory and character menus vs the character
| controller).
|
| Separate these view groups so they are triggered by a mode
| state using an event system that tells each view group which is
| active.
|
| Only update the active view group.
|
| This isolates each view group to receive mouse/key events by
| itself. It also keeps menus that interact with one another
| consolidated together in one place. This helps you reason out
| the mouse/key events more easily since you know this view group
| won't disrupt the other inactive view groups.
|
| Within a view group though, a focused control pattern is a good
| idea. A simple way is via hit bounding and z-ordering. The top-
| most, mouse over bounds control is active to receive click
| events. Everything else is ignoring input.
|
| tldr; hierarchy your input controls into groups so you can
| ignore the input on inactive/not visible ones.
| simonbw wrote:
| 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_ wrote:
| 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
| krapp wrote:
| Have you tried SDL2? I don't know what your criteria for
| "messy" is but its event stack makes it pretty straightforward
| to get input from the mouse, controller and keyboard.
| Kapura wrote:
| 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.
| erikbye wrote:
| > novel problem set
|
| Examples?
| Kapura wrote:
| Well, I've spent the past week tuning our boss fight camera
| algorithms so that the camera does its best to track the boss
| if they dash across the room or leap into the air. Nobody can
| really tell me how to do this outside of our company, because
| nobody else is dealing with a boss that moves like ours,
| nobody else has the same camera language constraints, and
| frankly dealing with algorithmic camera motion is not
| something most programmers ever have to do.
|
| I can look at our other code, I can look at other cameras in
| game & film, but ultimately it's just me down there in the
| code deciding whether the pull the camera in or pitch down or
| lengthen the lens or how to handle blends or whatever.
| vvanders wrote:
| Oh man camera systems.
|
| We had one dev and an animator spend _months_ getting our
| camera system to the point where it felt natural.
| Definitely one of those things that takes a ton of work and
| only gets noticed when it goes wrong.
| mmoll wrote:
| > Everything else I work on is essentially a novel problem set.
|
| It's a rotate! ;-)
| gww wrote:
| 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?
| krapp wrote:
| Just start anywhere. You're going to end up throwing it all out
| anyway. Accept that failure is the path to success and just do
| it.
| meheleventyone wrote:
| Pick a simple game and make that game. Pick a new game and make
| that game. Take the things that fit the second game from the
| first game. Now you have at least some basics that do input,
| rendering and audio. Pick a bit to improve towards your target.
|
| Making "an engine" isn't really something you can do unless you
| have an idea about what making a game actually means. Then you
| can work out what it is that you actually value.
| gww wrote:
| Thanks, I am going to try to start with something easy like
| tetris.
| learc83 wrote:
| That's definitely the way to do it. For my first game I
| built pong.
| skocznymroczny wrote:
| A common recommendation is not to write an engine, but to write
| a game instead. Create a Pong game. Create a 2D space shooter.
| Create a simple Mario-like 2D platformer. Now take the code
| that is shared between all three projects - there's your game
| engine. Just extract that so that it's nicely separated and
| easily reusable in future projects.
| DethNinja wrote:
| 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.
___________________________________________________________________
(page generated 2020-05-16 23:00 UTC)