Merge branch 'master' of https://github.com/munificent/game-programming-patterns

Author: munificent

README.md

@@ -3,7 +3,7 @@ Issues and pull requests are more than welcome!
 
 ## Building the Book
 
-The book is written in Markdown (in `book/`). A little Python script (`script/format.py`) converts that along with a SASS file (`asset/style.scss`) and HTML template (`asset/template.html`) to the final HTML (in `book/`). To run the format script locally, you'll need to have Python 2.7-ish, and install Python Markdown, Pygments, and SmartyPants:
+The book is written in Markdown (in `book/`). A little Python script (`script/format.py`) converts that along with a SASS file (`asset/style.scss`) and HTML template (`asset/template.html`) to the final HTML (in `html/`). To run the format script locally, you'll need to have Python 2.7-ish, and install Python Markdown, Pygments, and SmartyPants:
 
     $ pip install markdown
     $ pip install pygments
@@ -19,4 +19,4 @@ Make sure to run this from the root directory of the repo. That will regenerate
 
 That will monitor the file system for changes to the markdown files, SASS file, or HTML template, and reprocess them as needed.
 
-[game programming patterns]: http://gameprogrammingpatterns.com/
+[game programming patterns]: http://gameprogrammingpatterns.com/

asset/template.html

@@ -40,6 +40,6 @@ <h1 class="book"><a href="/">Game Programming Patterns</a>{{section_header}}</h1
 </nav>
 </div>
 </div>
-<footer>&copy; 2009-2014 Robert Nystrom</footer>
+<footer>&copy; 2009-2015 Robert Nystrom</footer>
 </body>
 </html>

book/component.markdown

@@ -612,7 +612,7 @@ likely support more than one at the same time in your designs.
         <span name="queue">Now</span>, if a component has access to its
         container, it can send messages to the container, which will
         rebroadcast the message to all of the contained components. (That
-        inclues the original component that sent the message; be careful that
+        includes the original component that sent the message; be careful that
         you don't get stuck in a feedback loop!) This has a couple of
         consequences:
 
@@ -667,7 +667,7 @@ communication paths if you need them.
 ## See Also
 
  *  The [Unity](http://unity3d.com) framework's core [`GameObject`](http://docs.unity3d.com/Documentation/Manual/GameObjects.html) class is designed
-    entirely around [components](http://docs.unity3d.com/Documentation/Manual/UsingComponents40.html).
+    entirely around [components](http://docs.unity3d.com/Manual/UsingComponents.html).
 
  *  The open source [Delta3D](http://www.delta3d.org) engine has a base
     `GameActor` class that implements this pattern with the appropriately named

book/data-locality.markdown

@@ -615,7 +615,7 @@ particle system that will be spawning and killing particles anyway.
 
 OK, this is the last example of a simple technique for making your cache
 happier. Say we've got an AI component for some game entity. It has some state
-in it -- the animation it's currently playing, a goal position its heading
+in it -- the animation it's currently playing, a goal position it's heading
 towards, energy level, etc. -- stuff it checks and tweaks every single frame.
 Something like:
 

book/object-pool.markdown

@@ -252,7 +252,7 @@ called once per frame.
 
 The pool needs to know which particles are available for reuse. It gets this
 from the particle's `inUse()` function. This function takes advantage of the fact that
-particles have a limited lifetime and uses the `_framesLeft` variable to
+particles have a limited lifetime and uses the `framesLeft_` variable to
 discover which particles are in use without having to store a separate flag.
 
 The pool class is also simple:
@@ -319,7 +319,7 @@ the data for the unused particles themselves.
 
 When a particle isn't in use, most of its state is irrelevant. Its position and
 velocity aren't being used. The only state it needs is the stuff required to
-tell if it's dead. In our example, that's the `_framesLeft` member. All those
+tell if it's dead. In our example, that's the `framesLeft_` member. All those
 other bits can be reused. Here's a revised particle:
 
 ^code 4

code/cpp/component.h

@@ -100,12 +100,12 @@ namespace Monolithic
     switch (Controller::getJoystickDirection())
     {
       case DIR_LEFT:
-      velocity_ -= WALK_ACCELERATION;
-      break;
+        velocity_ -= WALK_ACCELERATION;
+        break;
 
       case DIR_RIGHT:
-      velocity_ += WALK_ACCELERATION;
-      break;
+        velocity_ += WALK_ACCELERATION;
+        break;
       //^omit
       case DIR_NONE: break; // Do nothing.
       //^omit