Update change_scenes_manually.rst

Rewrote to use active voice. Reworded some sections for grammar, clarity, or removal of banned words

tutorials/scripting/change_scenes_manually.rst

@@ -3,11 +3,11 @@
 Change scenes manually
 ======================
 
-Sometimes it helps to have more control over how one swaps scenes around.
+Sometimes it helps to have more control over how you swap scenes around.
 A :ref:`Viewport <class_Viewport>`'s child nodes will render to the image
-it generates, this holds true even for nodes outside
-of the "current" scene. Autoloads fall into this category, but so do
-scenes which one instances and adds to the tree at runtime:
+it generates. This holds true even for nodes outside of the "current"
+scene. Autoloads fall into this category, and also scenes which you
+instantiate and add to the tree at runtime:
 
 .. tabs::
  .. code-tab:: gdscript GDScript
@@ -36,16 +36,16 @@ scenes which one instances and adds to the tree at runtime:
     }
 
 To complete the cycle and swap out the new scene with the old one,
-developers have a choice to make. Many strategies exist for removing a scene
+you have a choice to make. Many strategies exist for removing a scene
 from view of the :ref:`Viewport <class_Viewport>`. The tradeoffs involve
-balancing operation speed and memory consumption as well as balancing data
+balancing operation speed and memory consumption, as well as balancing data
 access and integrity.
 
-1. **We can delete the existing scene.**
+1. **Delete the existing scene.**
    :ref:`SceneTree.change_scene_to_file() <class_SceneTree_method_change_scene_to_file>` and
    :ref:`SceneTree.change_scene_to_packed() <class_SceneTree_method_change_scene_to_packed>`
-   will delete the current scene immediately. Developers can also delete the
-   main scene though. Assuming the root node's name is "Main", one could do
+   will delete the current scene immediately. You can also delete the
+   main scene. Assuming the root node's name is "Main", you could do
    ``get_node("/root/Main").free()`` to delete the whole scene.
 
     - Unloads memory.
@@ -65,60 +65,60 @@ access and integrity.
 
     - Processing stops.
 
-        - Pro: No nodes means no process, physics process, or input
+        - Pro: No nodes means no processing, physics processing, or input
           handling. The CPU is available to work on the new scene's contents.
 
         - Con: Those nodes' processing and input handling no longer operate.
           Not a problem if using the updated data is unnecessary.
 
-2. **We can hide the existing scene.** By changing the visibility or collision
-   detection of the nodes, we can hide the entire node sub-tree from the
+2. **Hide the existing scene.** By changing the visibility or collision
+   detection of the nodes, you can hide the entire node sub-tree from the
    player's perspective.
 
     - Memory still exists.
 
-        - Pro: One can still access the data if need be.
+        - Pro: You can still access the data if needed.
 
         - Pro: There's no need to move any more nodes around to save data.
 
-        - Con: More data is being kept in memory which will become a problem
+        - Con: More data is being kept in memory, which will be become a problem
           on memory-sensitive platforms like web or mobile.
 
     - Processing continues.
 
         - Pro: Data continues to receive processing updates, so the scene will
-          keep updated any data within it that relies on delta time or frame
-          data.
+          keep any data within it that relies on delta time or frame data
+          updated.
 
         - Pro: Nodes are still members of groups (since groups belong to the
           :ref:`SceneTree <class_SceneTree>`).
 
         - Con: The CPU's attention is now divided between both scenes. Too much
-          load could result in low frame rates. One should be sure to test
-          performance as they go to ensure the target platform can support the
-          load they are giving it.
+          load could result in low frame rates. You should be sure to test
+          performance as you go to ensure the target platform can support the
+          load from this approach.
 
-3. **We can remove the existing scene from the tree.** Assign a variable
+3. **Remove the existing scene from the tree.** Assign a variable
    to the existing scene's root node. Then use
    :ref:`Node.remove_child(Node) <class_Node_method_remove_child>` to detach the entire
    scene from the tree.
 
-    - Memory still exists (similar pros/cons as with hiding it from view).
+    - Memory still exists (similar pros/cons as hiding it from view).
 
-    - Processing stops (similar pros/cons as with deleting it completely).
+    - Processing stops (similar pros/cons as deleting it completely).
 
     - Pro: This variation of "hiding" it is much easier to show/hide. Rather
-      than potentially keeping track of multiple changes to the scene, one
-      must only call the one method add/remove_child pair of methods. It is
-      similar to disabling game objects in other engines.
+      than potentially keeping track of multiple changes to the scene, you
+      only need to call the add/remove_child methods. This is similar to
+      disabling game objects in other engines.
 
     - Con: Unlike with hiding it from view only, the data contained within
       the scene will become stale if it relies on delta time, input, groups,
       or other data that is derived from :ref:`SceneTree <class_SceneTree>`
       access.
 
-There are also cases where one may wish to have many scenes present at the same
-time. Perhaps one is adding their own singleton at runtime, or preserving
+There are also cases where you may wish to have many scenes present at the same
+time, such as adding your own singleton at runtime, or preserving
 a scene's data between scene changes (adding the scene to the root node).
 
 .. tabs::
@@ -130,11 +130,11 @@ a scene's data between scene changes (adding the scene to the root node).
 
         GetTree().Root.AddChild(scene);
 
-Perhaps instead they wish to display multiple scenes at the same time using
-:ref:`SubViewportContainers <class_SubViewportContainer>`. This is optimal in
-cases where the intent is to render different content in different parts of the
-screen. Minimaps and split-screen multiplayer are good examples.
+Another case may be displaying multiple scenes at the same time using
+:ref:`SubViewportContainers <class_SubViewportContainer>`. This is optimal for
+rendering different content in different parts of the screen (e.g. minimaps, 
+split-screen multiplayer).
 
-Each option will have cases where it is best appropriate, so one must
-examine the effects of each and determine what path best fits
-their unique situation.
+Each option will have cases where it is best appropriate, so you must examine
+the effects of each approach, and determine what path best fits your unique
+situation.