Minor tweaks

docs/level_design.md

@@ -1,6 +1,6 @@
 # Level Design Guidelines
 
-The name of the game is ***rapid iteration***. **Throw shit together**, see if it works, if it doesn't, iterate.
+The name of the game is ***rapid iteration***. **Throw shit together**, see if it works, and if it doesn't, iterate.
 If iteration doesn't help or becomes too slow, sometimes you need to **scrap it and start over**.
 This lets you start with a clean slate for more creativity, and make better use of lessons you learned while testing.
 
@@ -34,9 +34,9 @@ For designing levels, it is **heavily suggested** to make use of:
     - If you have to explain a design to a playtester, then the design might need more work
 - Testing each level segment individually before working on the next segment
 - ...and then testing each segment together at once!
-- Feel free to make separate levels for testing ideas
+- Make separate, small levels for testing specific ideas
 
-As with all forms of design, **level design should speak for itself**.
+As with all forms of design, **the level's design should speak for itself** to players.
 The player should naturally be pulled to whatever solution the developer asks, but be left open for resolution themself.
 
 The following guidelines are here to reduce friction between the player and the game, while providing tools for innovation.
@@ -106,19 +106,19 @@ as well as the challenges they might encounter.
 First impressions are just as important in-game as they are out of game.
 
 ### Mechanics
-When teaching a player a new mechanic, follow these guidelines:
+When teaching the player a new mechanic, follow these guidelines:
 - Give the player a safe space to fail in
 - Ensure that the problem can only be solved with the given mechanic if possible
 - Ensure that the problem makes sense within the context of the setting
 - Keep instructions minimal, but clear
 - Lead the player to the solution with context clues
 
-Ideally, we do not have to directly tell the player what they need to do.
-We may do this for clarity's sake, but the level design should make it clear with lighting, leading lines, and other rules of composition.
-
 Giving players a safe space for failure allows experimentation and learning, without creating stress.
 As soon as the player becomes frustrated, they are not enjoying the game, and we have failed our objective.
 
+Ideally, we do not have to directly tell the player what they need to do.
+We might do this anyway for clarity's sake, but the level design should make it clear with lighting, leading lines, and other rules of composition.
+
 ### Enemies
 When introducing a new enemy type to the player, follow these guidelines:
 - Only one of that type of enemy should be in the given encounter
@@ -134,17 +134,17 @@ Giving them time to observe, think, and react is better than dropping them into
 As stated before, players should be eased into combat and new enemies initially.
 Using small amounts of enemies in initial encounters with those types allow players to develop strategies without being overwhelmed.
 Once you think a player has "mastered" something, test their skills by ramping the intensity, or mixing in other underused mechanics.
-Spawning more enemies, using platforming hazards, and etc can further encourage the player to move ahead.
+Spawning more enemies, using platforming hazards, and etc can further challenge the player.
 This can easily be done with [**arenas**](#arenas), as mentioned before.
 
-The same goes for platforming. As the player becomes more acquainted with their tools, mixing up movement or creating more hazards can encourage the player to think more creatively.
+The same goes for platforming. As the player becomes more acquainted with their tools, mixing up movement combinations or creating more hazards can encourage the player to think more creatively.
 Combining platforming and combat can lead to a successful flow state, but requires careful planning and lots of iteration.
 
 ## Final Notes
-While there is a lot of considerations to making a level, these are still ideas and not entirely rigid rules.
+While there are a lot of considerations to making a level, these are still ideas and not entirely rigid rules.
 *Sometimes, rules are best broken*, and this applies to game design as well.
 
 If you think something enhances an experience but challenges these guidelines, *test it and see how it plays out*.
 Have other devs try it! Have playtesters try it! If it enhances the game, then you've successfully iterated.
 
-See other project guidelines [here](../README.md).
+See other project guidelines [here](../README.md#resources-and-guidelines).