Polish text in the "Instancing (Continued)" section

None of the changes in this CL change the meaning or spirit of the
underlying text. Instead, my goal was to tidy up miscellaneous things,
like:

* Remove passive voice
* Tighten wording when possible
* Clean up misc grammar nits and other errors
* Relayout text to fill 80 columns in some case

learning/step_by_step/instancing_continued.rst

@@ -6,72 +6,78 @@ Instancing (continued)
 Recap
 -----
 
-Instancing has many handy uses. At a glance, with instancing you have:
+Instancing has many handy uses. At a glance, it provides: 
 
 -  The ability to subdivide scenes and make them easier to manage.
--  A more flexible alternative to prefabs (and much more powerful given
-   instances work at many levels).
--  A way to design more complex game flows or even UIs (UI Elements are
-   nodes in Godot too).
+-  A more flexible alternative to prefabs (and much more powerful given that
+   instances can be nested).
+-  A way to organize and embed complex game flows or even UIs (in Godot, UI
+   Elements are nodes, too).
 
 Design language
 ---------------
 
-But the real strong point of instancing scenes is that it works as an
-excellent design language. This is pretty much what makes Godot special
-and different to any other engine out there. The entire engine was designed
-from the ground up around this concept.
+But the greatest strength that comes with instancing scenes is that it works
+as an excellent design language. This is pretty much what distinguishes Godot
+from all the other engines out there. Godot was designed from the ground up
+around this concept.
 
-When making games with Godot, the recommended approach is to leave aside
-other design patterns such as MVC or Entity-Relationship diagrams and
-start thinking about games in a more natural way. Start by imagining the
-visible elements in a game, the ones that can be named not just by a
+When making games with Godot, the recommended approach is to dismiss most
+common design patterns, such as MVC or Entity-Relationship diagrams, and
+instead think about your scenes in a more natural way. Start by imagining the
+visible elements in your game, the ones that can be named not just by a
 programmer but by anyone.
 
-For example, here's how a simple shooter game can be imagined:
+For example, here's how a simple shooter game could be imagined:
 
 .. image:: /img/shooter_instancing.png
 
 It's pretty easy to come up with a diagram like this for almost any kind
-of game. Just write down the elements that come to mind, and then the
-arrows that represent ownership.
+of game. Just write down the parts of the game that you can visualize, and then
+add arrows to represent ownership of one component by another.
 
-Once this diagram exists, making a game is about creating a scene for
-each of those nodes, and using instancing (either by code or from the editor) to represent ownership.
+Once you have a diagram like this, the recommended process for making a game is
+to create a scene for each element listed in the diagram. You'll use instancing
+(either by code or directly in the editor) for the ownership relationships.
 
-Most of the time programming games (or software in general) is spent
-designing an architecture and fitting game components to that
-architecture. Designing based on scenes replaces that and makes
-development much faster and more straightforward, allowing you to
-concentrate on the game itself. Scene/Instancing based design is
-extremely efficient at saving a large part of that work, since most of
-the components designed map directly to a scene. This way, none or
-little architectural code is needed.
+A lot of time spent in programming games (or software in general) is on
+designing an architecture and fitting game components to that architecture.
+Designing based on scenes replaces that approach and makes development much
+faster and more straightforward, allowing you to concentrate on the game logic
+itself. Because most game components map directly to a scene, using a design
+based on scene instantiation means little other architectural code is needed.
 
-The following is a more complex example, an open-world type of game with
-lots of assets and parts that interact:
+Let's take a look at one more, somewhat more complex, example of an open-world
+type game with lots of assets and nested elements:
 
 .. image:: /img/openworld_instancing.png
 
-Make some rooms with furniture, then connect them. Make a house later,
-and use those rooms as the interior.
+Take a look at the room element. Let's say we started there. We could make a
+couple of different room scenes, with different arrangements of furniture (also
+scenes) in them. Later, we could make a house scene, connecting rooms to make
+up its interior.
 
-The house can be part of a citadel, which has many houses. Finally the
-citadel can be put on the world map terrain. Add also guards and other
-NPCs to the citadel by previously creating their scenes.
+Then, we could make a citadel scene, which is made out of many instanced
+houses. Then, we could start working on the world map terrain, adding the
+citadel onto it.
 
-With Godot, games can grow as quickly as desired, as all it needs is for
-more scenes to be created and instanced . The editor UI is designed to be
-operated by non programmers too, so a typical team development process
-can involve 3D or 2D artists, level designers, game designers, animators,
-etc all working with the editor interface.
+Later, we could create scenes that represent guards (and other NPCs) and add
+them to the citadel as well. As a result, they would be indirectly added to the
+overall game world.
+
+With Godot, it's easy to iterate on your game like this, as all you need to do
+is create and instance more scenes. Furthermore, the editor UI is designed to be user
+friendly for programmers and non-programmers alike. A typical team development
+process can involve 2D or 3D artists, level designers, game designers,
+and animators, all working with the editor interface.
 
 Information overload!
 ---------------------
 
-Do not worry too much, the important part of this tutorial is to create
-awareness of how scenes and instancing are used in real life. The best
-way to understand all this is to make some games.
+This has been a lot of high level information dropped on you all at once.
+However, the important part of this tutorial was to create an awareness of how
+scenes and instancing are used in real projects.
 
-Everything will become very obvious when put to practice, so please do
-not scratch your head and go on to the next tutorial!
+Everything discussed here will become second nature to you once you start
+making games and putting these concepts into practice. For now, don't worry
+about it too much, and just go on to the next tutorial!