Merge pull request #421 from d9n/docpolish+instancing_continued

Polish text in the "Instancing (Continued)" section

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!