bounce section editing

content/pong/ball/bouncing/_index.md

@@ -14,10 +14,10 @@ We don't want the behavior of any object to be directly tied to some state outsi
 
 There's something else going on here too: eventually we're gonna need the ball to bounce off of the paddles as well right? I think what we really need here is a collision system.
 
-All of our objects are rectangles so I think a simple AABB check will suffice. Essentially we just use non-rotating rectangles and check if they are overlapping.
+All of our objects are rectangles so I think a simple AABB (axis-aligned bounding box) check will suffice. Essentially we just use non-rotating rectangles and check if they are overlapping.
 
 Hang on a sec though - this is a pretty standard problem right? Pretty much every game in existence uses collision detection.
 
 LOVE provides a physics system under _love.physics_. But it's actually a fully featured physics simulator that attempts to behave realistically under physical constraints. It's a little heavy to use it just for simple collision detection and we'd probably have to rework all of our entities and components to integrate it properly at this point.
 
-Turns out that there is a library for AABB (axis-aligned bounding box) collision that will work just fine for our purposes. It's called [bump.lua](https://github.com/kikito/bump.lua). Let's start by integrating it.
+Turns out that there is a library for AABB collision that will work just fine for our purposes. It's called [bump.lua](https://github.com/kikito/bump.lua). Let's start by integrating it.

content/pong/ball/bouncing/collision_checking.md

@@ -28,7 +28,7 @@ Let's break down what we want collision detection to actually do.
 
 First, we tell the Collision World about the current positions of the objects. Next we check each object for collisions by using the "check" method, which takes the proposed new position of the object and gives us collision information in return.
 
-For every collision that we find, we create a CollisionMessage for it. Why are we comparing the collision types? Let's say we want to have a BallWallCollisionMessage. Obviously we will want to know which entity in the collision represents the ball and which one represents the wall. So we just sort them at this step for convenience.
+For every collision that we find, we create a CollisionMessage for it.
 
 In **game/engines/collision_check.ts**:
 
@@ -117,6 +117,20 @@ export class CollisionCheckEngine extends Engine {
 }
 ```
 
+Why are we comparing the collision types? Let's say we want to have a BallWallCollisionMessage. Obviously we will want to know which entity in the collision represents the ball and which one represents the wall. So we just sort them at this step for convenience.
+
+Let's make sure that our enum is sorted in alphabetical order.
+
+In **game/components/collision_types.ts**:
+
+```ts
+export enum CollisionType {
+    ball,
+    paddle,
+    wall,
+}
+```
+
 The "initialize" method gives the Engine a reference to the Collision World that needs to be shared by everything that deals with collision. Let's make sure to call the "initialize" method from **game.ts**:
 
 ```ts

content/pong/ball/bouncing/collision_dispatch.md

@@ -4,7 +4,7 @@ date: 2019-05-28T19:06:03-07:00
 weight: 700
 ---
 
-Let's make the CollisionDispatchEngine.
+Let's make the CollisionDispatchEngine. All it needs to do is read the CollisionMessages and create specific collision messages from them.
 
 In **games/engines/collision_dispatch.ts**:
 
@@ -56,7 +56,13 @@ export class CollisionDispatchEngine extends Engine {
 }
 ```
 
-Now we are emitting a BallWallCollisionMessage every time a ball collides with a wall. Next we need to resolve the collision.
+Now we are emitting a BallWallCollisionMessage every time a ball collides with a wall. Why don't you try filling in the other collision messages yourself?
+
+Don't forget to add it in **game.ts**
+
+```ts
+    world_builder.add_engine(CollisionDispatchEngine);
+```
 
 {{% notice notice %}}
 Clever readers have probably noticed that this is a bit of an awkward structure. For our game, we only have three types of colliding entities we care about, so some switch statements work fine. What about a game with 20 different kinds of colliding entities? 100? We'd probably want a much more generic structure or this Engine's complexity would get out of hand.

content/pong/ball/bouncing/motion_engine.md

@@ -4,6 +4,8 @@ date: 2019-05-28T18:01:49-07:00
 weight: 500
 ---
 
+Let's rewrite our MotionEngine.
+
 In **game/messages/collision_check.ts**:
 
 ```ts
@@ -29,9 +31,9 @@ export class UpdatePositionMessage extends Message implements ComponentMessage {
 }
 ```
 
-Let's rewrite our MotionEngine.
+Here's the process we'll follow for our MotionEngine:
 
-We associate MotionMessages with their PositionComponents. We consolidate them to get an "x_delta" and a "y_delta". We create an UpdatePositionMessage containing these values. Next, we create CollisionCheckMessages containing the delta values if the PositionComponent's entity has a BoundingBoxComponent.
+We associate MotionMessages with their PositionComponents. We consolidate them to get a total "x_delta" and a "y_delta". We create an UpdatePositionMessage containing these values. Next, we create CollisionCheckMessages containing the delta values if the PositionComponent's entity has a BoundingBoxComponent.
 
 Finally, we go over all BoundariesComponents that didn't have MotionMessages associated with them and create CollisionCheckMessages for those too. Otherwise things that didn't move wouldn't be collision checked, and that would not be correct.
 

content/pong/ball/bouncing/putting_it_together.md

@@ -0,0 +1,7 @@
+---
+title: "Putting It All Together"
+date: 2019-05-28T21:22:44-07:00
+weight: 900
+---
+
+Our Entities are getting a bit more complex now with the addition of BoundingBoxComponents and CollisionTypeComponents so why don't we go ahead and create Spawners for everything.