grammar tweaks 04-target-practice.md

23 list part "agreement": a's for b, c's for d, e "for" f.

59 "at the same point" or "in the same space"

114 originally I made this "what used to be exciting seems" and then realized that I was miss-chunking/interpreting it, because "games" -> "it" made the "it" seem so wrong.

137 "between 0 and 100", "from 0 up to 100". 'between' sounds more like "0 < number < 100". and you want "0 <= number < 100".

src/04-target-practice.md

@@ -20,7 +20,7 @@ We need to render our target sprites too, so include those in the array we push
 {{#include code/chapter_04/01_display_targets/app/main.rb:79}}
 ```
 
-Similar to how we represent the player and fireball sprites, the targets have an x and y coordinate for position, a width and height, and an image file to represent the sprite. We create three items in our `args.state.targets` array, which then displays three different targets.
+Similar to how we represent the player and fireball sprites, the targets have x and y coordinates for position, width and height for size, and an image file to represent the sprite. We create three items in our `args.state.targets` array, which then displays three different targets.
 
 ![dragon sprite with three targets rendered to the right](./img/c04-display-targets.jpg)
 
@@ -54,9 +54,9 @@ Then when we lazily assign `args.state.targets ||=`, we call the method three ti
 
 ## Collision Detection
 
-The fireballs our dragon spits just fly behind our targets and off the screen into infinity. Let's make it so that if a fireball hits a target, _something_ happens. Eventually we'll want to play a sound, remove the target, and even play an animation. But humble beginnings, humble beginnings.
+The fireballs our dragon spits just fly behind our targets and off the screen into infinity. Let's make it so that if a fireball hits a target, _something_ happens. Eventually, we'll want to play a sound, remove the target, and even play an animation. But humble beginnings, humble beginnings.
 
-Collision detection is when one object overlaps with another object in our game. Because we're manufacturing the space the game exists in, there's no physics like we have in real life. We need to simulate that by checking to see if two objects are attempting to exist in the same point and react accordingly.
+Collision detection is when one object overlaps with another object in our game. Because we're manufacturing the space the game exists in, there's no physics like we have in real life. We need to simulate that by checking to see if two objects are attempting to exist at the same point and react accordingly.
 
 Our fireball sprite is a 32x32 square, so we want to check in every single game loop whether or not the points of the fireball's square overlapping with any of the points of the target sprites. If they are overlapping, then we do that _something_.
 
@@ -76,9 +76,9 @@ Here's the written out logic behind the collision detection we'll implement:
 {{#include code/chapter_04/03_collision_detection/app/main.rb:67:75}}
 ```
 
-Play the game and hit the some targets. Nothing visually happens (yet), but if you check the console (<kbd>~</kbd>), you'll see that `"fireball hit target"` was output multiple times.
+Play the game and hit some targets. Nothing visually happens (yet), but if you check the console (<kbd>~</kbd>), you'll see that `"fireball hit target"` was output multiple times.
 
-With a loop and a method we've implemented collision detection. That wasn't too bad, was it?
+With a loop and a method, we've implemented collision detection. That wasn't too bad, was it?
 
 ## Remove Targets On Collision
 
@@ -105,13 +105,13 @@ So in our collision detection code where we call `puts`, we'll instead mark the
 {{#include code/chapter_04/04_remove_targets/app/main.rb:67:79}}
 ```
 
-Since the target and fireball that collided are no longer being tracked in `args.state`, they don't get rendered on the screen and are, for all intents and purposes, gone! We then `#reject!` each fireball and target that are `dead`.
+Since the target and fireball that collided are no longer being tracked in `args.state`, they don't get rendered on the screen and are, for all intents and purposes, gone! We then `#reject!` each fireball and target that is `dead`.
 
 This almost feels like a game. That's a great feeling. We're getting close to _fun_.
 
 ## Spawn New Targets
 
-Shooting three targets and having them disappear doesn't make for much fun though. After the three targets are hit, it's just your dragon floating in the sky with not much else to do. We're back to chapter 3! Ugh, chapter 3 was so boring! I can't believe we ever even made anything that boring before. (But remember how cool it was when we got the fireballs working? That was cool! It's funny how games evolve and what it used to be seems so basic compared to where we're at now.)
+Shooting three targets and having them disappear doesn't make for much fun though. After the three targets are hit, it's just your dragon floating in the sky with not much else to do. We're back to chapter 3! Ugh, chapter 3 was so boring! I can't believe we ever even made anything that boring before. (But remember how cool it was when we got the fireballs working? That was cool! It's funny how a game evolves and what it used to be, seems so basic compared to where we're at now.)
 
 Remember back in the day, way back when, like a few sections ago, when we introduced `#spawn_target`? It was helpful then, but now it's going to be even more helpful. We'll call it every time we destroy a target so that a new one spawns. We'll be able to play _Target Practice_ forever!
 
@@ -134,13 +134,13 @@ We create a `size` variable to store the width and height of the sprite to use i
 
 Then we apply some math. Don't let math scare you away from programming! We'll keep it simple and the toolbox you need is relatively small. Plus, the math will help make our game even better. Games make math fun.
 
-`rand` is a method that we get from DragonRuby that's available everywhere. `rand` without any parameter generates a random real number between 0 and 1. That's not really useful for us right now, so we can instead pass in a parameter that sets the upper boundary of the random number. `rand(100)` generates a random integer between 0 up to 100 (not including 100).
+`rand` is a method that we get from DragonRuby that's available everywhere. `rand` without any parameter generates a random real number between 0 and 1. That's not really useful for us right now, so we can instead pass in a parameter that sets the upper boundary of the random number. `rand(100)` generates a random integer from 0 up to 100 (not including 100).
 
 So for the x position of the target, we generate a random number that's up to two-fifths the width of the game screen and then we add three-fifths of the width to that number so that the targets spawn on the far right side of the screen. We don't want to spawn targets too close to the player, otherwise our game will be too easy.
 
 For the y position, we generate a random y position based on the height of the game, but we subtract twice the size of the target sprite and then add one of its sizes back to the random number to give the spawn area a gutter. This prevents the target from spawning partially off the screen, which would make it impossible to hit.
 
-### Change initial three targets
+### Change the initial three targets
 
 ``` ruby
 {{#include code/chapter_04/05_spawn_new_targets/app/main.rb:22:24}}