fix: various typos after re-reading with fresh eyes

src/02-player-movement.md

@@ -35,7 +35,7 @@ There are a couple of new things here:
 - `args.state`
 - `||=`
 
-Let's start with `args.state`. It's basically a blob that can be anything you want it to be, a bit like Kirby. Feed it `player_x` and it keeps track of it. Whatever you feed the `args.state`, it'll be accessible in future ticks. Keeping track of the game state across ticks is important! It's part of the game loop. If we don't know where the player last was, how can we calculate where they should move to? We need to keep track of it in someplace. `args.state` is a fine place to start.
+Let's start with `args.state`. It's basically a blob that can be anything you want it to be, a bit like Kirby. Feed it `player_x` and it keeps track of it. Whatever you feed the `args.state`, it'll be accessible in future ticks. Keeping track of the game state across ticks is important! It's part of the game loop. If we don't know where the player last was, how can we calculate where they should move to? We need to keep track of it somewhere. `args.state` is a fine place to start.
 
 You can define anything on `args.state`, so it's up to you to use useful names. You could make `args.state.bleh` and set it to your favorite color, `args.state.bleh = "blue"` or your age, `args.state.age = 30`. Much like Kirby, `args.state` doesn't care what you feed it. It's just hungry for your data.
 

src/04-target-practice.md

@@ -58,7 +58,7 @@ The fireballs our dragon spits just fly behind our targets and off the screen in
 
 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_.
+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 are overlapping with any of the points of the target sprites. If they are overlapping, then we do that _something_.
 
 ![diagram showing two rectangles overlapping and not overlapping](./img/c04-rect-overlap.png)
 
@@ -158,7 +158,7 @@ We loop through the fireballs and move each one, just as before. And then we che
 
 The one new line is where we push a new target into `args.state.targets` from `#spawn_target`. That'll make a new target appear in a random location whenever we hit another.
 
-Play the game a bit and see how feels. Is there anything that can be adjusted or improved? What if you adjust the formula for `#spawn_target`? How does that feel with targets spawning close or further away?
+Play the game a bit and see how it feels. Is there anything that can be adjusted or improved? What if you adjust the formula for `#spawn_target`? How does that feel with targets spawning close or further away?
 
 ## Score Tracking
 

src/07-high-score.md

@@ -16,7 +16,7 @@ DragonRuby GTK gives us two handy methods to do so:
 - `DR.write_file("high-score.txt")`
 - `DR.read_file("high-score.txt")`
 
-Save data, especially for our game, can be as simple as a text file on the computer. While this may allow for save tampering, that's not something we're too worried about for our game. The foundations of writing our data to a file and loading it apply no matter how complex our game data persistent needs get.
+Save data, especially for our game, can be as simple as a text file on the computer. While this may allow for save tampering, that's not something we're too worried about for our game. The foundations of writing our data to a file and loading it apply no matter how complex our game's data persistence needs get.
 
 We'll be working exclusively in `#game_over_tick`:
 

src/11-scenes.md

@@ -68,7 +68,7 @@ We continue to handle input and display the gameplay sprites and labels in `#gam
 
 Then, finally, `#tick` has been drastically simplified. It no longer needs to be responsible for so much. It can instead just handle three things:
 
-1. starting the music for the game
+1. Starting the music for the game
 2. Lazily initializing the scene to start with (in our case, `"gameplay"`)
 3. Calling the proper scene tick method and passing in `args`
 

src/12-ship-it.md

@@ -54,7 +54,7 @@ Fill out the details for your game. Be sure to write a description, add screensh
 
 <img alt="itch.io upload screenshot with button to upload files" src="./img/c12-itch-upload.jpg" style="max-width: 380px; width: 100%;" />
 
-Tap "Upload files" and select the zips of the game for all of the platforms you want to upload it for. For `target-practice-html5.zip`, check the "This file will be played in the browser" box, as itch.io will use that to determine what to make playable. For the other platforms, choose the proper OS for each file. Be sure to set the web embed size to 1280 pixels wide and 720 pixels tall so it renders at the proper size. Enable `Frame options -> SharedArrayBuffer support`, DragonRuby html5 games require this to run in the browser.
+Tap "Upload files" and select the zips of the game for all of the platforms you want to upload it for. For `target-practice-html5.zip`, check the "This file will be played in the browser" box, as itch.io will use that to determine what to make playable. For the other platforms, choose the proper OS for each file. Be sure to set the web embed size to 1280 pixels wide and 720 pixels tall so it renders at the proper size. Enable `Frame options -> SharedArrayBuffer support`, DragonRuby HTML5 games require this to run in the browser.
 
 If you make changes to your game, you can upload new versions to itch.io automatically by running `./dragonruby-publish mygame` without having to upload them through the web browser as long as `gameid` in `game_metadata.txt` matches your itch.io project slug.