Game Programming Patterns(gameprogrammingpatterns.com)
gameprogrammingpatterns.com
Game Programming Patterns
http://gameprogrammingpatterns.com/
48 comments
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?
Does anyone have any recommendations for other books about game engine design?
I use extensively in my projects the Component decoupling pattern: http://gameprogrammingpatterns.com/component.html
The Observer and Mediator patterns can then be used for wiring components.
The Observer and Mediator patterns can then be used for wiring components.
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...
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...
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.
> 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.
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.
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.
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.
With that use case I can understand why people would want this! You should make one of these books.
As you say, you've not programmed games, and it becomes clear in your further replies. To describe the often-used Command pattern as "harmful" is somewhat obtuse. Event-dispatch does not include undo functionality, and the command pattern can itself enhance debugging.
That you dislike a particular, widely used pattern in the few pages you've bothered reading of a book that's outside of your experience doesn't really help anyone interested in reading that book. That's why I described it as not particularly on-topic.
That you dislike a particular, widely used pattern in the few pages you've bothered reading of a book that's outside of your experience doesn't really help anyone interested in reading that book. That's why I described it as not particularly on-topic.
And in that case, the polite response would be to explain why the pattern is used, rather than attacking the OP as being off-topic. Reading and asking questions when things are not understood, as the OP did, is how one gains understanding. Saying that someone should not even ask questions unless one has experience, as you did, is how one discourages people from learning.
If the OP had been asking questions, I might. Instead, they were posting unfounded, authoritative, nitpicking negativity ("the Command interface wasn't a good replacement") against what looks to be a reasonably good book. I understand that blithe, negative comments tend to rise to the top on HN, so I guess it's normal.
> unfounded, authoritative, nitpicking negativity
After seeing shadowmint's reply I understand why the "Command" organization is a good idea. Like shadowmint I don't see Jump as being a good example.
The examples in this book make it difficult to see why this is a good idea. If the examples of this book are taken to heart and directly applied then I think the code of the resulting game would be unwieldy. It seems the only people who understand what the author is trying to show are the ones who actually have experience in the field where they've constructed these methods of scaffolding already.
If this book is directed at programmers who are not game developers yet then this book as not succeeded. As a programmer, who's spent more a quarter of their years on this Earth in the field, if I can't get the sense of why a pattern shown in this book would be useful then I think there's a problem. The book is not effectively reaching it's intended audience: programmers who are not game developers or who are new to game development paradigms.
I think my point still stands. For what the example is showing the Command interface isn't an appropriate replacement for the if-else tree. I still think an Event system is a better choice for dispatching an action to handlers. It seems like real game developers also feel this way (see BatFastard's comment).
> against what looks to be a reasonably good book
A good book can have a few bad examples. A good book also requires many revisions. This is more so when you're talking about technical books. Do you think the first revision of the Art of Computer Programming was perfect when published? There are many hexadecimal dollars out there to show you that is not the case [1].
> I understand that blithe, negative comments tend to rise to the top on HN, so I guess it's normal.
If you refuse to look at valid criticism and just go strait to saying "Oh HackerNews is so negative! That's why people are agreeing with you!" then you're going to be avoiding a treasure trove of good information out there. I've had much harsher "criticism" of my work levied in person by people I actually know and instead of putting on blinders I addressed it and ended up with a better product in the end.
[1] - https://en.wikipedia.org/wiki/Knuth_reward_check
After seeing shadowmint's reply I understand why the "Command" organization is a good idea. Like shadowmint I don't see Jump as being a good example.
The examples in this book make it difficult to see why this is a good idea. If the examples of this book are taken to heart and directly applied then I think the code of the resulting game would be unwieldy. It seems the only people who understand what the author is trying to show are the ones who actually have experience in the field where they've constructed these methods of scaffolding already.
If this book is directed at programmers who are not game developers yet then this book as not succeeded. As a programmer, who's spent more a quarter of their years on this Earth in the field, if I can't get the sense of why a pattern shown in this book would be useful then I think there's a problem. The book is not effectively reaching it's intended audience: programmers who are not game developers or who are new to game development paradigms.
I think my point still stands. For what the example is showing the Command interface isn't an appropriate replacement for the if-else tree. I still think an Event system is a better choice for dispatching an action to handlers. It seems like real game developers also feel this way (see BatFastard's comment).
> against what looks to be a reasonably good book
A good book can have a few bad examples. A good book also requires many revisions. This is more so when you're talking about technical books. Do you think the first revision of the Art of Computer Programming was perfect when published? There are many hexadecimal dollars out there to show you that is not the case [1].
> I understand that blithe, negative comments tend to rise to the top on HN, so I guess it's normal.
If you refuse to look at valid criticism and just go strait to saying "Oh HackerNews is so negative! That's why people are agreeing with you!" then you're going to be avoiding a treasure trove of good information out there. I've had much harsher "criticism" of my work levied in person by people I actually know and instead of putting on blinders I addressed it and ended up with a better product in the end.
[1] - https://en.wikipedia.org/wiki/Knuth_reward_check
I should be less abrupt. For that abruptness, I apologise.
However, I think that you might want to consider the effects of the decisions you make and the size of your generalisations. You have a problem with a particular application of a particular example in a particular chapter of a book, on a technique you don't fully understand, and provide wider comments that explicitly undermine the whole book, that may well dissuade people who could benefit from reading it.
However, I think that you might want to consider the effects of the decisions you make and the size of your generalisations. You have a problem with a particular application of a particular example in a particular chapter of a book, on a technique you don't fully understand, and provide wider comments that explicitly undermine the whole book, that may well dissuade people who could benefit from reading it.
In my game engine each set of events has its own event dispatcher (for example a model loading event has 6 stages). Its make it much easier to see who events a class is using, exactly who is using them. Also provides a better sense of encapsulation.
I agree that it can help with debugging but it puts that other "load" into your brain. Which dispatcher do I want for this event?
If you're using C++ or another strongly typed language then it's probably fine because you'll get a compiler/IDE error about your types. If you're using something more "loose" having a central router helps.
If you're using C++ or another strongly typed language then it's probably fine because you'll get a compiler/IDE error about your types. If you're using something more "loose" having a central router helps.
For me it does just the opposite. Since each event class has its own dispatcher, the question of which dispatcher disappears.
RegionEvent.create( RegionEvent.ADD_MODEL, series, guid, modelData );
The dispatcher is internal to the RegionEvent. The other great thing here is the custom events allow me to pass the type of parameters that are appropriate for this class.
which is handled by RegionEvent.addListener( RegionEvent.ADD_MODEL, addModel );
I also use the rule that all event have to be treated as async events. This pattern works great for non real time portions of my engine.
RegionEvent.create( RegionEvent.ADD_MODEL, series, guid, modelData );
The dispatcher is internal to the RegionEvent. The other great thing here is the custom events allow me to pass the type of parameters that are appropriate for this class.
which is handled by RegionEvent.addListener( RegionEvent.ADD_MODEL, addModel );
I also use the rule that all event have to be treated as async events. This pattern works great for non real time portions of my engine.
That's very nice. I'll have to give this a try in my work. Never thought about that.
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
...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...
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
...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...
Maybe it depends on your experience / field?
I don't do C++ or games programming generally so for me it was amazing. I'd actually go so far as to say it's one of my favourite technical books of all time.
The style is great and I went away with lots to think about.
So for anyone that's thinking of giving it a miss based on my parents comment - I'd recommend you read it yourself (it's free) to make your own judgement.
I don't do C++ or games programming generally so for me it was amazing. I'd actually go so far as to say it's one of my favourite technical books of all time.
The style is great and I went away with lots to think about.
So for anyone that's thinking of giving it a miss based on my parents comment - I'd recommend you read it yourself (it's free) to make your own judgement.
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.
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.
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.
I bought the paper book a long time ago and read it in an afternoon. Most of the ideas are pretty straightforward, not many of them are specifically game-oriented. Overall I came away thinking there wasn't much depth.
edit: I really enjoyed the writing style and illustrations. If anything, I meant the above to be encouragement to the author (should he happen to read my comment) to flesh it out more (perhaps by interviewing industry veterans, and converting their wisdom into this very easy to digest format).
edit: I really enjoyed the writing style and illustrations. If anything, I meant the above to be encouragement to the author (should he happen to read my comment) to flesh it out more (perhaps by interviewing industry veterans, and converting their wisdom into this very easy to digest format).
The first random chapter I clicked on (the Update Method) is using doubles for movement.
Computers may have become a lot more powerful, but that's not a reason for throwing out sloppy code.
Computers may have become a lot more powerful, but that's not a reason for throwing out sloppy code.
>On the prototype pattern:
>...
>..what? Then why did you bring it up at all?
From the intro: "Prototyping — slapping together code that’s just barely functional enough to answer a design question — is a perfectly legitimate programming practice. There is a very large caveat, though. If you write throwaway code, you must ensure you’re able to throw it away."
Prototyping — coding without architecture in mind? I dont find it relevant to his book.
From the intro: "Prototyping — slapping together code that’s just barely functional enough to answer a design question — is a perfectly legitimate programming practice. There is a very large caveat, though. If you write throwaway code, you must ensure you’re able to throw it away."
Prototyping — coding without architecture in mind? I dont find it relevant to his book.
The GP is referring to the section on prototypes (objects that can be cloned to make new instances).
"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... , 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.
I read this book some years ago: https://www.amazon.com/3-0-Design-Patterns-Real-World-Proble... , 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.
This is an excellent programming book, even if you don't intend to make games. Highly recommend
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.
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.
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.
Like the landing page as well, very clean and to the point.
Will this book teach me to code videogames? If not where can I learn that before reading this book?
I think this book is better suited to people that have already written a few games.
It mostly talks about common patterns that arise during gamedev and how to work with them. IIRC, it shows trade-offs of different approaches.
I suggest starting out with Love2d [1]. Docs are good, community is great, lots of tutorials online.
There's this guy writing a tutorial series [2] on creating a game with Love2D. Not finished yet, but it is awesome! I think that would be a good place to start.
I hope this helps.
[1] https://love2d.org
[2] https://github.com/SSYGEA/blog/issues/11
It mostly talks about common patterns that arise during gamedev and how to work with them. IIRC, it shows trade-offs of different approaches.
I suggest starting out with Love2d [1]. Docs are good, community is great, lots of tutorials online.
There's this guy writing a tutorial series [2] on creating a game with Love2D. Not finished yet, but it is awesome! I think that would be a good place to start.
I hope this helps.
[1] https://love2d.org
[2] https://github.com/SSYGEA/blog/issues/11
Also check out the Graphics Gems series.
handmade hero series of videos might be your best bet. prepare to put in a lot of time!
I was just watching a code challenge where a guy tried to make the game of Snake in 15 minutes (it took him 30 minutes.)
That introduced me to the P5 JavaScript library, and with that I was able to get up and running with just a web browser, an index.html page, and a script.js file.
I'm almost done with my clone of Snake, and after that I think I'd like to try a top-down shooter. I'm thinking of a simple runaway-from-zombies game.
Anyways the channel was The Coding Train on Youtube: https://www.youtube.com/watch?v=AaGK-fj-BAM
Man, it's good to get back to fun side projects!
That introduced me to the P5 JavaScript library, and with that I was able to get up and running with just a web browser, an index.html page, and a script.js file.
I'm almost done with my clone of Snake, and after that I think I'd like to try a top-down shooter. I'm thinking of a simple runaway-from-zombies game.
Anyways the channel was The Coding Train on Youtube: https://www.youtube.com/watch?v=AaGK-fj-BAM
Man, it's good to get back to fun side projects!
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/
[2]http://nehe.gamedev.net/
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/
[2]http://nehe.gamedev.net/
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.
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.
3D has a whole ton of boilerplate; it's better to start with something a little simpler to experiment with some patterns.
I've been using this site and finding it very useful: http://www.opengl-tutorial.org/
It does a good job explaining how to use OpenGL in the shader pipeline, instead of the legacy fixed pipeline, while also providing a lot of the annoying setup code (initializing the libraries and setting options, loading, compiling, and linking shaders, etc).
It does a good job explaining how to use OpenGL in the shader pipeline, instead of the legacy fixed pipeline, while also providing a lot of the annoying setup code (initializing the libraries and setting options, loading, compiling, and linking shaders, etc).
nehe tutorials are extremely dated by now, targetting old versions of OpenGL. By no means start with NeHe's tutorials.
The tutorials will compile and render stuff in the screen, but learning this in 2017 will do no good as all those APIs are now deprecated and I wouldn't be surprised if drivers start removing OpenGL 1.
You should be learning OpenGL 3+ or Vulkan.
The tutorials will compile and render stuff in the screen, but learning this in 2017 will do no good as all those APIs are now deprecated and I wouldn't be surprised if drivers start removing OpenGL 1.
You should be learning OpenGL 3+ or Vulkan.
Somewhat related - are there similar resources for other other kinds of software?
What did you use to generate the web version of the book?
Have a look at the author's blog and at the book repository on GitHub
http://journal.stuffwithstuff.com/category/book/
https://github.com/munificent/game-programming-patterns
xiaoma(1)
Thank you so much for your work.