some terminology tweaks

content/concepts/component.md

@@ -4,7 +4,7 @@ date: 2019-05-22T12:51:29-07:00
 weight: 5
 ---
 
-A Component is a collection of related data.
+A Component is a structure of related data.
 
 To define a Component, declare a struct which implements the **IComponent** interface.
 

content/why/architecture/mecs.md

@@ -16,11 +16,11 @@ Let's go back to our earlier example.
 
 We have TransformComponent, which contains position and orientation data, and VelocityComponent, which contains an *x* and *y* component for linear motion.
 
-Our MotionDetecterSystem reads each Entity that has both a TransformComponent and a VelocityComponent, and emits a MotionMessage, which contains a reference to the Entity and the *x* and *y* velocity given by the VelocityComponent.
+Our MotionSystem reads each Entity that has both a TransformComponent and a VelocityComponent, and emits a MotionMessage, which contains a reference to the Entity and the *x* and *y* velocity given by the VelocityComponent.
 
 We also have a **TeleportSystem** that needs to teleport the character forward a bit. Let's say when the player presses the X button, a TeleportMessage is fired. The TeleportSystem reads this message and emits a MotionMessage in response.
 
-Now we have our **MotionSystem**. The MotionSystem declares that it Mutates the TransformComponent, reads the MotionMessages that apply to each TransformComponent, and applies them simultaneously, adding their *x* and *y* values to the TransformComponent. Voilà! No race conditions! We can re-use similar behaviors easily without re-writing code by consolidating Messages.
+Now we have our **MotionSystem**. The MotionSystem declares that it Writes the TransformComponent, reads the MotionMessages that apply to each TransformComponent, and applies them simultaneously, adding their *x* and *y* values to the TransformComponent. Voilà! No race conditions! We can re-use similar behaviors easily without re-writing code by consolidating Messages.
 
 You might be wondering: how does the game know which order these systems need to be in? Well...
 
@@ -34,4 +34,4 @@ Systems are not allowed to create message cycles. If System A sends Message B, w
 
 The other restriction involves two separate systems which Write the same Component. They may do so, but they must declare a priority. If we allowed Systems to Write components willy-nilly, we would introduce the possibility of two Systems changing the same component on the same frame, creating a race condition. If we have two Systems where it makes sense to change the same Component, we can either create a new Message and System to consolidate the changes, or we can declare write priority so that one System's changes always override the other's. This way we can avoid race conditions.
 
-If you are used to programming games in an object-oriented way, you will likely find the pattern counter-intuitive at first. But once you learn to think in a MECS way, you will be shocked at how flexible and simple your programs become.
+If you are used to programming games in an object-oriented way, you will likely find the pattern counter-intuitive at first. You will have to completely invert how you think about constructing game objects. But once you learn to think in a MECS way, you will be shocked at how flexible and simple your programs become.