Book: Game Programming Patterns
Welcome to my review and readings of the book Game Programming Patterns by Robert Nystrom.
Day 1 Impressions
After reading the first couple of pages on my Kindle Phone app I bought this book to read. In almost every game I have developed I come across some of the most common issues that should of been solved a long time ago. This author seems to have read my mind and has brought his experience and knowledge into this book about patters of design.
Since this is about patterns of design there is no better book then the one written by the gang of four called Design Patters: Elements of Reusable Object-Oriented Code. I have this book too and may even dust it off for a discussion thread.
Anyways back to the book at hand. The main reason I went ahead and got this book was I like how the author used humor and back story to start his book. Update to come....
Since this is about patterns of design there is no better book then the one written by the gang of four called Design Patters: Elements of Reusable Object-Oriented Code. I have this book too and may even dust it off for a discussion thread.
Anyways back to the book at hand. The main reason I went ahead and got this book was I like how the author used humor and back story to start his book. Update to come....
Day 2 Continued
I've read quite a bit of the first section of the book already. Not sure what chapter I'm on the Amazon Kindle doesn't list chapters it seems.
After getting through the first few introductory chapters and reading some history about the author and patterns of design I have to say I like this author's writing style! And for those of you reading the book I have master ditch digging which is why I wanted to move into programming....
Now to the content of the book. The first couple of patterns are enlightening. Not only does the author describe the technical gorgon of the original Gang of Four Patterns of Design (GoF) he breaks it down to something very understandable and then shows why we would care about this particular pattern with very concrete examples. Take for example the command pattern. When I read this in the GoF book it made no sense and was really confusing why we designers would even care about this pattern. Well now I know why I would care. It is a very elegant class that makes many of our programming techniques easier. If your wondering why I'm not giving the information to you in this review it because I want you to buy this book and not give away all the great information. Robert Nystrom has spent a lot of time writing this book and I feel it is worth you time and money!
Even at 10% complete reading this book is full of some great information. Now time to get back to reading and programming.
After getting through the first few introductory chapters and reading some history about the author and patterns of design I have to say I like this author's writing style! And for those of you reading the book I have master ditch digging which is why I wanted to move into programming....
Now to the content of the book. The first couple of patterns are enlightening. Not only does the author describe the technical gorgon of the original Gang of Four Patterns of Design (GoF) he breaks it down to something very understandable and then shows why we would care about this particular pattern with very concrete examples. Take for example the command pattern. When I read this in the GoF book it made no sense and was really confusing why we designers would even care about this pattern. Well now I know why I would care. It is a very elegant class that makes many of our programming techniques easier. If your wondering why I'm not giving the information to you in this review it because I want you to buy this book and not give away all the great information. Robert Nystrom has spent a lot of time writing this book and I feel it is worth you time and money!
Even at 10% complete reading this book is full of some great information. Now time to get back to reading and programming.
Quater of the way done
I'm already a quarter the way through this book. Some of the topic the author covers are good and shows solid examples of where we would use a particular pattern. But like most purists he makes it evident that the Singleton pattern is worthless because of its global scope. My take on this is many developers jump into programming and fall in love with the singleton pattern because its easy to understand and you can quickly get access to its members.
I'll be the first to admit that this I over use the singleton pattern because there are so many places I need to access common structures it just makes sense to create it once and use it multiple times. We could of used a little more real answer to why we shouldn't use singleton and give solid ideas on what we can do to replace them. Granted the author did say we would find better solutions later in the book.
So far though some of the patterns he has discussed are very enlightening. More and more I find myself compelled to keep reading to find those great secrets the author has locked in this book. The next post I make will have some experimental code for review and discussion.
I'll be the first to admit that this I over use the singleton pattern because there are so many places I need to access common structures it just makes sense to create it once and use it multiple times. We could of used a little more real answer to why we shouldn't use singleton and give solid ideas on what we can do to replace them. Granted the author did say we would find better solutions later in the book.
So far though some of the patterns he has discussed are very enlightening. More and more I find myself compelled to keep reading to find those great secrets the author has locked in this book. The next post I make will have some experimental code for review and discussion.
40% read I think
This is more of a rant today about the Amazon Kindle App for my Windows 8.1 phone. After getting though 40% of the book I have found it is hard to know where I'm at in the book. I'm not sure if this was a cost saving measure of the publisher or what but removing the chapter numbers from my pages kind of removes the relevance. Maybe it was a pixel saving measure but please put chapter numbers back into my books to make it easier to follow along.
Anyways today I was reading a bit about the different patters of the game loop. Finally someone has given me insight into how the DeltaTime can be calculated in the game loop. The game loop chapter is very informative and provides a good discussion about how important to game play that the main game loop plays into performance. I also liked the discussion on game development and some of the history. It maybe more because I remembered some of the older games and have more respect for those developer now then when I played their games.
Anyways today I was reading a bit about the different patters of the game loop. Finally someone has given me insight into how the DeltaTime can be calculated in the game loop. The game loop chapter is very informative and provides a good discussion about how important to game play that the main game loop plays into performance. I also liked the discussion on game development and some of the history. It maybe more because I remembered some of the older games and have more respect for those developer now then when I played their games.
Insperation reading!
Well today I've completed a few more chapters and have been learning about the importance of memory allocation and how important it can be to the performance of a game. I really like the analogy of how main memory gets piped into the process for usage. He explained it very simple terms to describe a very complex concept.
The simple concept of just aligning your data into memory properly can change the amount of work that can be performed by a factor of 50 times. So far all the games I have done have been very simple and don't have a large number of objects to deal with. But reading about in-lining my data had turned on a few light bulbs. I have one game engine I've designed that when you add a bunch of objects and then throw in the physics the FPS drops down to about 5-10 FPS. This is because of two issues. One the physics engine was calculating all collisions in the scene, the other issue is there were many objects in the scene that even at rest were needing calculations.
These two problems have lead me to understand the importance of dirty bit settings and caching major calculations for times when we can take the processing hit without affecting game play. I've started playing around with a new code base with different scaffolding based on the books suggestions. One of the best things I learned was trying to deal with not using a singleton pattern in my designs. My logging class this time was not a singleton pattern but instead now I can pass multiple logging system into the engine and now not have to wade through a log file ten million lines deep to find what I need to know.
So far here is an example game I'm working on:
The simple concept of just aligning your data into memory properly can change the amount of work that can be performed by a factor of 50 times. So far all the games I have done have been very simple and don't have a large number of objects to deal with. But reading about in-lining my data had turned on a few light bulbs. I have one game engine I've designed that when you add a bunch of objects and then throw in the physics the FPS drops down to about 5-10 FPS. This is because of two issues. One the physics engine was calculating all collisions in the scene, the other issue is there were many objects in the scene that even at rest were needing calculations.
These two problems have lead me to understand the importance of dirty bit settings and caching major calculations for times when we can take the processing hit without affecting game play. I've started playing around with a new code base with different scaffolding based on the books suggestions. One of the best things I learned was trying to deal with not using a singleton pattern in my designs. My logging class this time was not a singleton pattern but instead now I can pass multiple logging system into the engine and now not have to wade through a log file ten million lines deep to find what I need to know.
So far here is an example game I'm working on:
Yes I know the graphics are one of the best things you have ever seen and want to know how I did it...
Okay your right this is a designed based on one of my favorite BBS games I played as a teenager back in the 1980's. The idea want that I wanted to make this awesome graphic based game but to build a conceptual engine that could either use ASCII as the graphics or swap it out with another render engine. Even though right now it is using a simple render engine with ASCII art the design allows for a quick swap out of the render engine.
Now time to learn how to work on a memory management system
Okay your right this is a designed based on one of my favorite BBS games I played as a teenager back in the 1980's. The idea want that I wanted to make this awesome graphic based game but to build a conceptual engine that could either use ASCII as the graphics or swap it out with another render engine. Even though right now it is using a simple render engine with ASCII art the design allows for a quick swap out of the render engine.
Now time to learn how to work on a memory management system
Finished!
I finished the book last night and I have to reiterate this is a must read for developers who want to get a better understanding of how good patterns can be used. Heck you may already be using a pattern in your design and don't even know it. But the author really brings some thought provoking ideas to mind with this book!
As for the game engine I started from this book I'm moving it to a new page for more detail progress.
As for the game engine I started from this book I'm moving it to a new page for more detail progress.