From d79580cfbc4e5c65a6c8884f0e2dffcd56dd1ce6 Mon Sep 17 00:00:00 2001
From: Evan Hemsley <2342303+ehemsley@users.noreply.github.com>
Date: Tue, 21 May 2019 18:51:00 -0700
Subject: [PATCH] adding some drama

---
 content/why/architecture/hyper_ecs.md | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/content/why/architecture/hyper_ecs.md b/content/why/architecture/hyper_ecs.md
index fe4fc35..ddef7b4 100644
--- a/content/why/architecture/hyper_ecs.md
+++ b/content/why/architecture/hyper_ecs.md
@@ -22,13 +22,15 @@ We also have a TeleportSystem that needs to teleport the character forward a bit
 
 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! And 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?
+You might be wondering: how does the game know which order these systems need to be in? Well...
 
-With the power of graph theory, we can construct an order for our Systems so that any System which Emits a certain Message runs before any System that Reads the same Message. This means, when you write behavior for your game, you *never* have to specify the order in which your Systems run. You simply write code, and the Systems run in a valid order, every time, without surprising you.
+**Encompass figures it out for you.**
+
+That's right! With the power of graph theory, we can construct an order for our Systems so that any System which Emits a certain Message runs before any System that Reads the same Message. This means, when you write behavior for your game, you *never* have to specify the order in which your Systems run. You simply write code, and the Systems run in a valid order, every time, without surprising you.
 
 Of course, to accomplish this, there are some restrictions that your Systems must follow.
 
-Systems are not allowed to create message cycles: if System A emits Message B, which is read by System B which emits Message C, which is read by System A, then we cannot create a valid ordering of Systems. This is not a flaw in the architecture: A message cycle is simply evidence that you haven't quite thought through what your Systems are doing, and can generally be easily eliminated by the introduction of a new System.
+Systems are not allowed to create message cycles. If System A emits Message B, which is read by System B which emits Message C, which is read by System A, then we cannot create a valid ordering of Systems. This is not a flaw in the architecture: A message cycle is simply evidence that you haven't quite thought through what your Systems are doing, and can generally be easily eliminated by the introduction of a new System.
 
 Two separate systems are not allowed to Mutate the same Component. Obviously, if we allowed this, we would introduce the possibility of two Systems changing the same component, creating a race condition. If we have two Systems where it makes sense to change the same Component, we can create a new Message and System to consolidate the changes, and avoid race conditions.