Steffen Cole Blake 2 лет назад
Родитель
Сommit
09e92d855a
1 измененных файлов с 4 добавлено и 4 удалено
  1. 4 4
      content/post/unity/building-a-gamestate-with-zenject-in-unity.md

+ 4 - 4
content/post/unity/building-a-gamestate-with-zenject-in-unity.md

@@ -19,17 +19,17 @@ aliases = ["building-a-gamestate-with-zenject-in-unity"]
 
 Unity provides countless mechanisms by which one can shoot themself in the foot. It's a common and popular entrypoint to picking up C# for newcomers to the language. However, there's a common gotcha individuals will quickly begin to encounter as they familiarize themselves with the basics of the language via Unity's `MonoBehavior` classes.
 
-Unfortunately this comes with a common and harsh pitfall: By default, Unity really encourages individuals to produce countless individual batches of code that they tightly couple to their game objects, which results in sooner than usual confronting the big bad wolf that is the Byzantine Generals Problem.
+Unfortunately this comes with a common and harsh pitfall: by default, Unity really encourages individuals to produce countless individual batches of code that they tightly couple to their game objects, which results in sooner than usual confronting the big bad wolf that is the Byzantine Generals Problem.
 
 For those not in the know, the crux of the issue is the fact that by breaking up their game state into numerous individual "shards", where every individual entity in their game has its own pool of statefulness, it produces a very easy pile of spaghetti one can find themself tripping and falling into.
 
-Eventually you find yourself naturally wanting to sort the mess out and unify all this logic. Rather than countless individual objects having little pieces of the game state pie, you wonder to yourself, "Is there a better way?" Is there perhaps some easier, cleaner way I can bring all the game state into one single place, one single source of truth, and everything else orbits around it?
+Eventually you find yourself naturally wanting to sort the mess out and unify all this logic. Rather than countless individual objects having little pieces of the game state pie, you wonder to yourself, "Is there a better way?". Is there perhaps some easier, cleaner way I can bring all the game state into one single place, one single source of truth, and everything else orbits around it?
 
-Well, there absolutely is, and in fact there are countless ways to do it. I will today go over the solution I came up with that takes a bit of inspiration from a few other common forms of C# projects.
+Well, there absolutely is, and in fact there are countless ways to do it. In this post I will go over the solution I came up with that takes a bit of inspiration from a few other common forms of C# projects.
 
 # Centralizing the Engine through Dependency Injection
 
-To begin we will need to do a bit of legwork. I am a massive proponent of Dependency Injection and I strongly encourage folks to get familiar. Unity has a fairly popular Dependency Injection library called Zenject that we will be using today. However keep in mind it is *not* the only option, nor is it even potentially the best! I'm merely using it in this example because it is popular and the first result on the unity asset store. Also, it's free.
+To begin we will need to do a bit of legwork. I am a massive proponent of Dependency Injection and I strongly encourage folks to get familiar with it. Unity has a fairly popular Dependency Injection library called Zenject that we will be using today. However keep in mind it is *not* the only option, nor is it even potentially the best! I'm merely using it in this example because it is popular and the first result on the unity asset store. Also, it's free.
 
 For the purpose of this project we will start things off by creating a new 2d core project, and installing the latest Zenject unity package which you can download from here: https://github.com/modesttree/Zenject/releases/latest