First thanks for joining me on this journey as I read through this book.  It was a lot of fun and I did learn a few new things.  For the most part the later chapters in this book provide little if no useful information.  I would rate this a 3 out of 5 stars because most of the more complex topics covered really didn’t have any insightful information.  For a starting game developer it covers some basic topics but be prepared to buy a bunch more books on the topics this book covered but didn’t go into details.

Please join me for my next adventure which will be going through the two examples the author created for this book.

This is a very deep topic and to try and cover it in one chapter is a difficult task.  I do have to say the information he gathered for this chapter had a lot of good information.  He provides enough information to get you started thinking about the subject but then leave you on your own to investigate further how to properly implement this technology.

The book does a good job covering the different types of topologies used by network games.  The examples provided as to which topology was used by a specific AAA title was a bonus.  I have always wondered which type of techniques are used for many of my favorite games.  If you’re wondering which topology you should use there isn’t a really good answer other than it depends on your game.

The section on cheating had some really insightful ideas on how players can try and cheat in your game.  The book covers several common cheats and some of the countermeasures that have been deployed in some of the major AAA games.  Since I’m not a cheater in my games I have not been aware of some things Blizzard has done to prevent these programs from spoiling the game play for others.  It also is why many times I have not liked playing online with other people.

This chapter had some fairly basic ideas on what scripting languages should be used in a game engine and also some basic ideas for storing game data.  There was no real ground breaking information in this chapter and I felt it was only added for completeness.  The author didn’t really share any real information about the subject and should've left the scripting languages to authors that understand the subject with better clarity.

It really wasn’t that he didn’t have any knowledge on the subject it was just most of the information could of been gleaned from wikipedia or other game developer resources on the internet. His description and ideas on how to build a scripting language lacked many of the core components of building your own language. I’ve actually written a parser before for a project and if all I had was this information it would have failed. This is because you really need a good understanding of how languages get created and what tools are available to do the job. Which he skipped over many important core tools. Like YACC and Lex which play a major role in writing parsers.

The agnostic approach on the subject was just lacking real information that would be needed to complete these tasks. And even his concepts on how to store data isn’t anything new or great. He talks about using XML and JSON or event binary files but the examples in the book leave the reader wondering really how they could be used. A good data design book will provide better understanding of how to break your data down into manageable block. And again when the topic got to difficult to discuss he throws in the common comment that this is out of scope for the book. Well if it is out of scope then why include it in the book in the first place. Granted if we took out the sections the author didn’t want to discuss then the book would of been only 6-7 chapters long.

After all the reading I have done in this book it is clear to me that this is not going to be a major reference book in my library.  The first couple of chapters are good but once we started getting into more difficult topics the book really lost it’s focus and ability to captivate my attention and imagination.

The chapter on UI is a very thoughtful and high level discussion.  He does a great job of introducing the topic and then giving a great example of how to make a radar map.  I really enjoy this section because it made me rethink how I could implement such a feature in one of my current Unity3D games.  I did something similar but couldn't figure out how to place generic enemy shapes on the mini-map and in the end it wasn’t very appealing. 

My only complaint for this chapter is the ending.  He tries to introduce the UX topic but then cops out of the explanation and instead defers discussion to outside sources.  A better ending would of been to approach the topic and explain why UX is important and how to really break it down so developers can make good choices.  Instead he seems to fall back to his favorite saying of this is out of scope for this book.

Maybe in the next version of this book he will devote some time to the writing a chapter on UX design and how to properly approach it.  You may say it isn’t important for programmers to understand this topic but I have to disagree.  Having a good pattern and understanding how this is done can really help developers approach this task.

I do recommend that you follow his advice and read the external references on UX design which are links to other web resources.

Today I finished the chapter on AI programming which honestly the author did a poor job on this subject.  He covered some common algorithms in AI programming but his explanations lacked a coherency on the subject matter I would expect for the subject.  His explanation on the algorithm to solve path finding lack a good explanation and would leave programmers in a quandary of how to make them work.  I have programmed several AI systems included an accurate replication of Pac-Man the 1985 hit game.  His agnostic look at this subject really failed to do justice for the subject matter in my opinion.

Don't get me wrong there was some really decent information in the chapter but if your looking to do any serious AI programming then this book will leave you with more questions than it answered. Thankfully he did cover the finite state machine and tried to point developers in the right way to build a decent FSM model. He even suggested that it would be better to use a finite design patter from the gang of four book. I would recommend Game Programming Patterns, his chapter 7 on states, for a better explanation on the subject.

If your looking to get this book because it induces a chapter on AI then don't do it specifically for this chapter.  There are defiantly other chapters that a really good information in them so for now I will still say this is a good book to read.  So for now I will leave this section alone and continue on.

Currently I'm in the middle of the section about the different kinds of Camera's that are used in games today.  Most of this information has been covered in many of the books I have read so it is much of a simple review for me.  But it did get me to thinking that I need to add camera support to my game engine.

The more I think about this subject the more I want camera's to be part of the game engine.  This would solve many problems I have had in the past on how to deal with players moving around the game world.  If the camera is to follow the main character then it would make the scrolling code a lot easier to manage instead of having to deal with it at the tile level.  What this means is now it will be a lot easier to know which tiles should be seen but the player and which ones we can scrap and not worry about drawing.

Also here is an update UML diagram of the new object system with the Camera class add into the diagram.

Now that we know this is an updateable object we can set the velocity in the engine so that the update method change the camera position.  The code to manage this hasn't been written but I will be adding it in on my next session so stay tuned to my streaming channel and to the blog for more updates.

Today I took some time to do some programming.  Nothing fancy just a quick addition of the mouse events to the core engine.  Found in the psudo code I had writen a nice nasty mouse bug but once that was sorted out the event system really started to shine.  For now the demo code will just output the x and y position of the mouse when clicked.  This should be enough information to start creating engine objects to handle the mouse collisions when moving around the game scene.

Also did a small update to the quit key system.  Origianlly it was handled by the helper function to the class so when it saw the escape code it would quit the game.  Changed this to now the core engine will handle the quit key for the game.  This is also mutable by the core engine by calling the SetQuitCode.  

My last update ended on chapter 5 input.  Chapter 6 discusses sound which had some really good information about setting up the player sound and building a 3D environment around sound.  The book does a decent job at introducing the subject but if you are really interested in working with sound more reading will be needed.  The basic classes and very little implementation was provided which stays true to the agnostic approach of this book.

The chapter on physics was very interesting and has some of the more commonly seen algorithms in the games.  This subject is difficult to cover in just one chapter but at least it does a decent job of introducing the subject to its readers.

I've read a couple of the books on this subject which suggested at a high level of collision to use a spherical collision detection.  This is because you can write the algorithm in a way that makes it very fast to do a quick comparison.  All you need to know is a few numbers and you can quickly calculate if the two spheres are overlapping.  The cool trick I learned which was reinforced in this chapter was to use the square distance as a comparison instead of trying to calculate the square root of a value.  This is because a processor can quickly square a value but to do the square root take a lot of time.

At first you may want to know the exact distance but in the long run do you want to know every exact distance between 10,000 objects?  Probably not so finding as many short cuts as you can is important.

Sorry didn’t have any time to really do much programming on the game engine but you can check out the few small changes I made to the code that now hook up the escape key to the exit engine.  You can always get the latest code from my codeplex repository!

Just updated my code from today's research and reading.  You can grab the lattest copy from CodePlex.

Just finished the chapter on Input and it was a good chapter with great ideas.  Knowing about chords and sequences might be important for some types of games.  And even creating a event system around input opens up a lot of different things that can be done.  Mobile devices as always have a different culture of how to get input into the system.

This chapter for the most part doesn't have any real ground breaking information on the subject but it does do a good job at providing some insight into the input process.  I would of liked to seen some more explanations about how some forms of input were developed over the years as games became more complex.  Also there are times where the GUI would need to prevent the bubbling of an event to other parts of the game engine and he kind of just leaves us hanging on that subject.  In many event systems the event object has a way to stop the bubbling of an event through some Boolean type value in the event object itself.  There are many solutions which is why I would have liked to see more on this subject instead of such a high level description.

One thing I do like in all the chapters I have read so far is his style of questions.  If you read the chapter for the most part the questions at the end are very easy to answer.  Unlike several other programming books I have read in the past where they have chapter questions which leave you wondering where the information was found his are very straight forward.

There is one point I have to disagree with after reading many books on design patterns is he recommended using a singleton class for your input.  At first glance this may seem like a good idea yet many design pattern experts would disagree with this advice.  Don’t get me wrong I have used lots of singleton classes in the past but going forward I’ve been paying penance in redesigning my work to not use these classes anymore.  There is no difference between using a global variable or a singleton class both are a bad idea in many cases.  A good design should try and avoid these kind of design patterns from the start.  If you know how to build pipe lines between your systems then a singleton will not be needed.

His section on the Analog input was really good and I liked the math implementation for the dead zone for variable feedback systems.  Being able to set a small amount aside to prevent joystick noise is a really good idea and I’ve read discussions about this topic.  I can see a lot of practical usage for this simple algorithm.

As for progress on my work I’ve modeled an event system that connects to the input system.  This way we can define some basic events like an event to shut down the game simulation.  Sadly the author never discusses how or why a good event system should be designed as part of the core game engine.  Events are not just something that need to be handled for input but also for many parts of the game.  For example the physics engine could use an event system to handle collisions, or the sound system may need to know when to change the music track based on the player’s level location.  There are so many different reasons to use events that I don’t think I could list them all but just know start thinking about events is important to the core of a game engine.  Here is the UML diagram of the conceptual idea for the event system

 

That is it for this post but will continue working on my reading.  Already 25% through the book!

Sorry I didn't post an update yesterday but a lot of my time was wasted on trying to setup a GitHub repo in my Visual Studio project.  It seems all the tutorials I followed didn't show ecactly what I was seeing and once I did get the project added to the repo I couldn't check in all the code files.  I'm not a big fan of GitHub because it has been so difficult to make work.  I prefer Perforce for my versioning software because their software intergrates very nicely with Visual Studio and many of the programs I use.

Anyways I plowed through chapter on math which really left me more confused then ever.  I think the next book I buy will be a good book on linear algebra because this is one of the subjects I really lack any competancy.  Still with the foggy understanding of the math chapter I moved on to the 3D section of game programming.  Even though I have a weak knowledge of how vectors are used with matricies the explination of how to use a matrix to perform very cool tricks is very well explained.  I now only wish I had a better understanding of the math!

This is still a very good book and I would recomend any serious game programmer to pick up a copy.  Even experienced programmers will learn something from what is contained in this book.

Update

Today I spent a few hours working with CodePlex and setting up a repository for this review and project.  You can now access the most current code from:

https://cplusengine.codeplex.com/

You will need to download the SDL library from the libsdl.org because I didn't want to have any license issues.

Today was a slow day for reading and mainly because his chapter on math is more confusing then helpful.  I think this chapter should have been left to those who know the subject better than the author.  Because of this chapter I will need to be spending some time learning more about these topics so I can better use them in my development process.

As for the new game engine I spent some time working on the graphic engine using SDL for the main library so that this project will have the potential of being ported to other operating systems besides Windows.  I did take the time and start designing the UML diagram for the core portion of the engine and here is the base interface diagram.

This diagram isn't that exciting but it shows how I've been working on interfacing the graphic system so it isn't dependent on one technology.  So the SdlGfx class has the responsibility for making the interface work.  This diagram will probably change as the engine progresses but it gives a decent start.

In the small tests I have completed connecting the SDL library to the engine project has given me decent results.  As I have been working on the engine code I have been thinking about either creating a new mine sweeper based game or working on a very simple side scroller based game.  Either one should be a lot of fun to make as I progress through the book and learn more about game development.

So cahpter one has a lot of good basic game design information and a lot of history behind how game data structures and techniques have been developed.  The basic data structures are an important part of the game design and for this book I've decided to start working on a C++ based project and using a UML based diagram to visually show what the code will be doing.  This game engine will be based on many of my past experiences building simple game engines and also include some of the new techniques I learn from reading this book.

Even though the book uses an agnostic approach to talking about a hypotheical game engine I will be working on this project to give a more concreat design idea to many of the topics in the book.  As this project progress so will the documentation so other programmers can learn from the designs I am building here.

Now back to the book.  It is a very good read and at this point I've finished chapter 2 and have started Chapter 3.  Chapter two discusses more of the 2D based game development that is needed to make historic games like Pac Man, Zelda, and other many great games that have defined the industry.  At this point I haven't decided on a genra or even a game concept but as I gtet cloaser to finishing some of the core engine features I will address this lack of design need.  This does go against many recomendations of game design processes but for now "It is what it is".

The UML diagram shows a basic pattern the book discusses and has a very fluid pattern that should be easy to implament and fund to run.