typos nwn;

content/blog/a-query-about-game-state/index.md

@@ -39,7 +39,7 @@ Seasoned game devs, disciplined object-oriented programmers, and existing ECS de
 
 How do we add a Spiked Shield item -- one which derives the behaviors of `Weapon` and `Armor`? If we were using a language which supports multiple inheritance this could potentially be a nonissue: except that multiple inheritance is often [purposefully missing](https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem) in many languages. We could decide that the item belongs more to one class than the other and just duplicate the missing behavior but these types of decisions often introduce unforeseen complexity: will the damage algorithm need to do a specific type check for `SpikedShield`? What about the equipment screen? And of course, what happens when we need to implement a damaging potion?
 
-Perhaps the most appropriate solution this case would be to forego the inheritance pattern in favor of [composition](https://en.wikipedia.org/wiki/Composition_over_inheritance). In C#, this could be achieved with `interfaces` and default implementations.
+Perhaps the most appropriate solution this case would be to forgo the inheritance pattern in favor of [composition](https://en.wikipedia.org/wiki/Composition_over_inheritance). In C#, this could be achieved with `interfaces` and default implementations.
 
 ```cs
 interface ICollectable {
@@ -96,8 +96,8 @@ class DamageEventQueue {
     }
 
     private void OnTick(float deltaTime) {
-        while(queue.TryDequeue(out var event, out int priority)) {
-            event.Source.ApplyDamage(event.Target, event.Value);
+        while(queue.TryDequeue(out var e, out int priority)) {
+            e.Source.ApplyDamage(e.Target, e.Value);
         }
     }
 }
@@ -107,10 +107,10 @@ DamageEvent.Invoke(this, new DamageEventArgs(player, bossEnemy, 10));
 
 ```
 
-There's a lot of issues with this code that I'm going to pretend were deliberate decisions for brevity. The point of this example is to show that we can ingest events and sort them arbitrarily based on the requirements of our games. We've made a step in the right direction by identifying a need to explicitly order these events. Even if this implementation isn't ideal, it properly encodes the requirements of the design ("player damage should be processed before all other types").
+There's a lot of issues with this code that I'm going to pretend were deliberate decisions for brevity. The point of this example is to show that we can ingest events and sort them arbitrarily based on the requirements of our games. We've made a step in the right direction by identifying a need to explicitly order these events. Even if this implementation isn't ideal, it properly encodes the requirements of the design (ie. player damage should be processed before all other types).
 
 ## In search of loot
-Managing game state is difficult. As a game grows, so too does the amount of amount of objects active at any given time. Dozens, hundreds, or even thousands of entities each with their own behaviors, goals, and concerns that interact with each other in different ways. This explosion in complexity can be exceedingly hard to manage even in games that are small in scope. Games, even at their simplest, tend to be *highly* complex.
+Managing game state is difficult. As a game grows, so too does the amount of objects active at any given time. Dozens, hundreds, or even thousands of entities each with their own behaviors, goals, and concerns that interact with each other in different ways. This explosion in complexity can be exceedingly hard to manage even in games that are small in scope. Games, even at their simplest, tend to be *highly* complex.
 
 ## Enter ECS
 ECS solves many of the problems presented by object oriented programming patterns but it's still in its infancy.