Update step-by-step tutorial

Update phrasing for a better flow in reading, minor grammar fixes

(cherry picked from commit 18e51fec9416380a751d82b0222edbbb0834bf22)

tutorials/step_by_step/animations.rst

@@ -10,14 +10,14 @@ This tutorial will explain how everything is animated in Godot. Godot's
 animation system is extremely powerful and flexible.
 
 To begin, let's just use the scene from the previous tutorial (:ref:`doc_splash_screen`).
-The goal will be to add a simple animation to it. Here's a copy
+The goal is, to add a simple animation to it. Here's a copy
 just in case: :download:`robisplash.zip </files/robisplash.zip>`.
 
 Creating the animation
 ----------------------
 
 First of all, add an :ref:`AnimationPlayer <class_AnimationPlayer>`
-node to the scene as a child of bg (the root node):
+node to the scene as a child of "bg" (the root node):
 
 .. image:: /img/animplayer.png
 
@@ -31,7 +31,7 @@ and name the animation "intro".
 
 .. image:: /img/animnew.png
 
-After the animation has been created, then it's time to edit it, by
+After the animation has been created, it's time to edit it, by
 pressing the "edit" button:
 
 .. image:: /img/animedit.png
@@ -47,8 +47,8 @@ for similar functionality.)
 
 .. image:: /img/animeditor.png
 
-But the second, and most important, is that the property editor enters
-into "animation editing" mode. In this mode, a key icon appears next to
+The second and most important, is that the property editor enters
+"animation editing" mode. In this mode, a key icon appears next to
 every property of the property editor. This means that, in Godot, *any
 property of any object* can be animated:
 
@@ -57,10 +57,10 @@ property of any object* can be animated:
 Making the logo appear
 ----------------------
 
-Next, the logo will appear from the top of the screen. After selecting
+The logo will appear from the top of the screen. After selecting
 the animation player, the editor panel will stay visible until
 manually hidden (or the animation node is erased). Taking advantage of
-this, select the "logo" node and go to the "pos" property, move it up,
+this, select the "logo" node and go to the "pos" property, move it up
 to position: 114,-400.
 
 Once in this position, press the key button next to the property:
@@ -72,11 +72,11 @@ it!
 
 .. image:: /img/addtrack.png
 
-And the keyframe will be added in the animation player editor:
+The keyframe will be added in the animation player editor:
 
 .. image:: /img/keyadded.png
 
-Second, move the editor cursor to the end, by clicking here:
+Move the editor cursor to the end, by clicking here:
 
 .. image:: /img/move_cursor.png
 

tutorials/step_by_step/filesystem.rst

@@ -28,7 +28,7 @@ saved in a single file together with all the bundled sub-resources. For
 example, a font resource is often bundled together with the font textures.
 
 In general the Godot file system avoids using metadata files. The reason for
-this is simple, existing asset managers and VCSs are just much better than
+this is simple, existing asset managers and VCSs are simply much better than
 anything we can implement, so Godot tries the best to play along with SVN,
 Git, Mercurial, Perforce, etc.
 
@@ -46,7 +46,7 @@ engine.cfg
 ----------
 
 The engine.cfg file is the project description file, and it is always found at
-the root of the project, in fact it's location defines where the root is. This
+the root of the project. In fact it's location defines where the root is. This
 is the first file that Godot looks for when opening a project.
 
 This file contains the project configuration in plain text, using the win.ini
@@ -80,7 +80,7 @@ read-only and writing will no longer be permitted.
 User path
 ---------
 
-Writing to disk is still often needed for various tasks such as saving game
+Writing to disk is often still needed for various tasks such as saving game
 state or downloading content packs. To this end, the engine ensures that there is a
 special path ``user://`` that is always writable.
 
@@ -106,6 +106,6 @@ but then references it as "myfile.png", it will work just fine on their platorm,
 on other platforms, such as Linux, Android, etc. This may also apply to exported binaries,
 which use a compressed package to store all files.
 
-It is recommend that your team clearly defines a naming convention for files when
+It is recommended that your team clearly defines a naming convention for files when
 working with Godot! One simple fool-proof convention is to only allow lowercase
 file and path names.

tutorials/step_by_step/gui_tutorial.rst

@@ -6,12 +6,12 @@ GUI tutorial
 Introduction
 ~~~~~~~~~~~~
 
-If there is something that most programmers hate with passion, that is
+If there is something that most programmers hate with passion, it is
 programming graphical user interfaces (GUIs). It's boring, tedious and
-unchallenging. Several aspects make matters worse such as:
+unchallenging. Several aspects make matters worse, such as:
 
--  Pixel alignment of UI elements is difficult (so it looks just like
-   the designer intends).
+-  Pixel alignment of UI elements is difficult (such that it looks just
+   like the designer intends).
 -  UIs are changed constantly due to design and usability issues that
    appear during testing.
 -  Handling proper screen re-sizing for different display resolutions.
@@ -19,7 +19,7 @@ unchallenging. Several aspects make matters worse such as:
 
 GUI programming is one of the leading causes of programmer burnout.
 During the development of Godot (and previous engine iterations),
-several techniques and philosophies for UI development were put in
+several techniques and philosophies for UI development were put into
 practice, such as immediate mode, containers, anchors, scripting, etc.
 This was always done with the main goal of reducing the stress
 programmers had to face while putting together user interfaces.
@@ -40,7 +40,7 @@ provides user interface functionality descends from it.
 
 When controls are put in a scene tree as a child of another control,
 it's coordinates (position, size) are always relative to the parent.
-This sets the basis for editing complex user interface quickly and
+This sets the basis for editing complex user interfaces quickly and
 visually.
 
 Input and drawing
@@ -51,9 +51,9 @@ Controls receive input events by means of the
 callback. Only one control, the one in focus, will receive
 keyboard/joypad events (see
 :ref:`Control.set_focus_mode() <class_Control_set_focus_mode>`
-and :ref:`Control.grab_focus() <class_Control_grab_focus>`.)
+and :ref:`Control.grab_focus() <class_Control_grab_focus>`).
 
-Mouse Motion events are received by the control directly below the mouse
+Mouse motion events are received by the control directly below the mouse
 pointer. When a control receives a mouse button pressed event, all
 subsequent motion events are received by the pressed control until that
 button is released, even if the pointer moves outside the control
@@ -62,14 +62,14 @@ boundary.
 Like any class that inherits from :ref:`CanvasItem <class_CanvasItem>`
 (Control does), a :ref:`CanvasItem._draw() <class_CanvasItem__draw>`
 callback will be received at the beginning and every time the control
-needs to be redrawn (programmer needs to call
+needs to be redrawn (the programmer needs to call
 :ref:`CanvasItem.update() <class_CanvasItem_update>`
 to enqueue the CanvasItem for redraw). If the control is not visible
 (yet another CanvasItem property), the control does not receive any
 input.
 
 In general though, the programmer does not need to deal with drawing and
-input events directly when building UIs, (that is more useful when
+input events directly when building UIs (that is more useful when
 creating custom controls). Instead, controls emit different kinds of
 signals with contextual information for when action occurs. For
 example, a :ref:`Button <class_Button>` emits
@@ -84,7 +84,7 @@ way to get the picture on how controls works, as they are not as
 complex as it might seem.
 
 Additionally, even though Godot comes with dozens of controls for
-different purposes, it happens often that it's just easier to attain a
+different purposes, it happens often that it's easier to attain a
 specific functionality by creating a new one.
 
 To begin, create a single-node scene. The node is of type "Control" and
@@ -114,9 +114,9 @@ Add a script to that node, with the following code:
             tapped=true
             update()
 
-Then run the scene. When the rectangle is clicked/tapped, it will go from
-blue to red. That synergy between the events and drawing is pretty much
-how most controls work internally.
+Then run the scene. When the rectangle is clicked/tapped, it will change
+color from blue to red. That synergy between the events and the drawing
+is pretty much how most controls work internally.
 
 .. image:: /img/ctrl_normal.png
 
@@ -125,7 +125,7 @@ how most controls work internally.
 UI complexity
 ~~~~~~~~~~~~~
 
-As mentioned before, Godot includes dozens of controls ready for using
+As mentioned before, Godot includes dozens of controls ready for use
 in a user interface. Such controls are divided in two categories. The
 first is a small set of controls that work well for creating most game
 user interfaces. The second (and most controls are of this type) are
@@ -143,22 +143,22 @@ be skinned easily with regular textures.
 -  :ref:`Label <class_Label>`: Node used for showing text.
 -  :ref:`TextureFrame <class_TextureFrame>`: Displays a single texture,
    which can be scaled or kept fixed.
--  :ref:`TextureButton <class_TextureButton>`: Displays a simple texture
-   buttons, states such as pressed, hover, disabled, etc. can be set.
+-  :ref:`TextureButton <class_TextureButton>`: Displays a simple textured
+   button, states such as pressed, hover, disabled, etc. can be set.
 -  :ref:`TextureProgress <class_TextureProgress>`: Displays a single
    textured progress bar.
 
 Additionally, re-positioning of controls is most efficiently done with
 anchors in this case (see the :ref:`doc_size_and_anchors` tutorial for more
-info).
+information).
 
 In any case, it will happen often that even for simple games, more
-complex UI behaviors will be required. An example of this is a scrolling
+complex UI behaviors are required. An example of this is a scrolling
 list of elements (for a high score table, for example), which needs a
 :ref:`ScrollContainer <class_ScrollContainer>`
 and a :ref:`VBoxContainer <class_VBoxContainer>`.
 These kind of more advanced controls can be mixed with the regular ones
-seamlessly (they are all controls anyway).
+seamlessly (they are all controls after all).
 
 Complex UI controls
 ~~~~~~~~~~~~~~~~~~~
@@ -173,4 +173,4 @@ another set of scenarios, most commonly:
 
 Re-positioning controls for these kind of interfaces is more commonly
 done with containers (see the :ref:`doc_size_and_anchors` tutorial for more
-info).
+information).

tutorials/step_by_step/instancing.rst

@@ -109,5 +109,5 @@ property to the original value that came from the scene.
 Conclusion
 ----------
 
-Instancing seems handy, but there is more to it than it meets the eye!
+Instancing seems handy, but there is more to it than meets the eye!
 The next part of the instancing tutorial should cover the rest..

tutorials/step_by_step/instancing_continued.rst

@@ -60,8 +60,8 @@ 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.
 
-With Godot, games can grow as quickly as desired, as only more scenes
-have to be made and instanced. The editor UI is also designed to be
+With Godot, games can grow as quickly as desired, as all it needs is
+to create and instance more scenes. 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.
@@ -73,5 +73,5 @@ Do not worry too much, the important part of this tutorial is to create
 awareness on how scenes and instancing are used in real life. The best
 way to understand all this is to make some games.
 
-Everything will become very obvious when put to practice, so, please do
+Everything will become very obvious when put to practice, so please do
 not scratch your head and go on to the next tutorial!

tutorials/step_by_step/resources.rst

@@ -8,8 +8,8 @@ Nodes and resources
 
 So far, :ref:`Nodes <class_Node>`
 have been the most important datatype in Godot, as most of the behaviors
-and features of the engine are implemented through them. There is,
-though, another datatype that is equally as important. That is
+and features of the engine are implemented through them. There is
+another datatype that is equally important:
 :ref:`Resource <class_Resource>`.
 
 Where *Nodes* focus on behaviors, such as drawing a sprite, drawing a
@@ -59,28 +59,28 @@ in a :ref:`Sprite <class_Sprite>` node:
 
 .. image:: /img/spriteprop.png
 
-Pressing the the ">" button the right side of the preview, allows to
+Pressing the ">" button on the right side of the preview allows to
 view and edit the resources properties. One of the properties (path)
-shows where it came from. In this case, it came from a png image.
+shows where it comes from. In this case, it comes from a png image.
 
 .. image:: /img/resourcerobi.png
 
 When the resource comes from a file, it is considered an *external*
-resource. If the path property is erased (or never had a path to begin
-with), it is then considered a built-in resource.
+resource. If the path property is erased (or it never had a path to
+begin with), it is considered a built-in resource.
 
 For example, if the path \`"res://robi.png"\` is erased from the "path"
 property in the above example, and then the scene is saved, the resource
 will be saved inside the .scn scene file, no longer referencing the
 external "robi.png". However, even if saved as built-in, and even though
-the scene can be instanced multiple times, the resource will still
-always be loaded once. That means, different Robi robot scenes instanced
+the scene can be instanced multiple times, the resource will always
+be loaded only once. That means, different Robi robot scenes instanced
 at the same time will still share the same image.
 
 Loading resources from code
 ---------------------------
 
-Loading resources from code is easy, there are two ways to do it. The
+Loading resources from code is easy. There are two ways to do it. The
 first is to use load(), like this:
 
 ::
@@ -139,6 +139,6 @@ resources are freed too.
 Scripting
 ---------
 
-Like any object in Godot, not just nodes, resources can be scripted too.
-However, there isn't generally much of a win, as resources are just data
-containers.
+Like any object in Godot, not just nodes, resources can be scripted,
+too. However, there isn't generally much of an advantage, as resources
+are just data containers.

tutorials/step_by_step/scene_tree.rst

@@ -10,19 +10,18 @@ This is where things start getting abstract, but don't panic, as
 there's not really more depth than this.
 
 In previous tutorials, everything revolves around the concept of
-Nodes, scenes are made of them, and they become active once they enter
+nodes, scenes are made of them, and they become active once they enter
 the *scene tree*.
 
-This deserves going a little more into depth. In fact, the scene system
-is not even a core component of Godot, as it is possible to skip it and
-make a script (or C++ code) that talks directly to the servers. But
-making a game that way would be a lot of work and is reserved for other
-uses.
+This concept deserves going into a little more detail. In fact, the
+scene system is not even a core component of Godot, as it is possible to
+skip it and write a script (or C++ code) that talks directly to the
+servers. But making a game that way would be a lot of work.
 
 MainLoop
 --------
 
-The way Godot works internally is as follows. There is the the
+The way Godot works internally is as follows. There is the
 :ref:`OS <class_OS>` class,
 which is the only instance that runs at the beginning. Afterwards, all
 drivers, servers, scripting languages, scene system, etc are loaded.
@@ -50,15 +49,14 @@ and servers are the low level API.
 
 In any case, the scene system provides it's own main loop to OS,
 :ref:`SceneTree <class_SceneTree>`.
-
 This is automatically instanced and set when running a scene, no need
 to do any extra work.
 
 It's important to know that this class exists because it has a few
 important uses:
 
--  It contains the root :ref:`Viewport <class_Viewport>`,
-   when a scene is first opened, it's added as a child of it to become
+-  It contains the root :ref:`Viewport <class_Viewport>`, to which a
+   scene is added as a child when it's first opened, to become
    part of the *Scene Tree* (more on that next)
 -  It contains information about the groups, and has means to call all
    nodes in a group, or get a list of them.
@@ -74,8 +72,8 @@ Root viewport
 -------------
 
 The root :ref:`Viewport <class_Viewport>`
-is always a top of the scene. From a node, it can be obtained in two
-different ways:
+is always at the top of the scene. From a node, it can be obtained in
+two different ways:
 
 ::
 
@@ -105,14 +103,15 @@ _enter_tree() and _ready() callbacks (as well as _exit_tree()).
 When nodes enter the *Scene Tree*, they become active. They get access
 to everything they need to process, get input, display 2D and 3D,
 notifications, play sound, groups, etc. When they are removed from the
-*scene tree*, they lose it.
+*scene tree*, they lose access.
 
 Tree order
 ----------
 
 Most node operations in Godot, such as drawing 2D, processing or getting
 notifications are done in tree order. This means that parents and
-siblings with less order will get notified before the current node.
+siblings with a smaller rank in the tree order will get notified before
+the current node.
 
 .. image:: /img/toptobottom.png
 
@@ -137,7 +136,7 @@ Changing current scene
 ----------------------
 
 After a scene is loaded, it is often desired to change this scene for
-another one. The simple way to do this to use the
+another one. The simple way to do this is to use the
 :ref:`SceneTree.change_scene() <class_SceneTree_change_scene>`
 function:
 

tutorials/step_by_step/scripting.rst

@@ -52,24 +52,24 @@ inside Godot. It was designed with the following goals:
 Programmers generally take a few days to learn it, and within two weeks
 feel comfortable with it.
 
-As with most dynamically typed languages though, the higher productivity
+As with most dynamically typed languages, the higher productivity
 (code is easier to learn, faster to write, no compilation, etc) is
-balanced with a performance penalty, but most critical code is written
+balanced with a performance penalty. But most critical code is written
 in C++ already in the engine (vector ops, physics, math, indexing, etc),
-making the resulting performance more than enough for most types of
+resulting in a more than sufficient performance for most types of
 games.
 
 In any case, if more performance is required, critical sections can be
 rewritten in C++ and exposed transparently to the script. This allows
-for replacing a GDScript class with a C++ class without altering the
-rest of the game.
+the replacement of a GDScript class with a C++ class without altering
+the rest of the game.
 
 Scripting a scene
 -----------------
 
 Before continuing, please make sure to read the :ref:`doc_gdscript` reference.
-It's a simple language and the reference is short, should not take more
-than a few minutes to glance.
+It's a simple language and the reference is short, it will not take
+more than a few minutes to get an overview of the concepts.
 
 Scene setup
 ~~~~~~~~~~~
@@ -107,7 +107,7 @@ The script creation dialog will pop up. This dialog allows to select
 the language, class name, etc. GDScript does not use class names in
 script files, so that field is not editable. The script should inherit
 from "Panel" (as it is meant to extend the node, which is of Panel type,
-this is automatically filled anyway).
+this is automatically filled).
 
 Enter a path name for the script and then select "Create":
 
@@ -143,7 +143,7 @@ script.
 Handling a signal
 ~~~~~~~~~~~~~~~~~
 
-Signals are used mostly in GUI nodes, (although other nodes have them
+Signals are used mostly in GUI nodes (although other nodes have them
 too). Signals are "emitted" when some specific kind of action happens,
 and can be connected to any function of any script instance. In this
 step, the "pressed" signal from the button will be connected to a custom
@@ -155,13 +155,12 @@ selecting the "Node" tab. Make sure that you have "Signals" selected.
 
 .. image:: /img/signals.png
 
-In any case, at this point it is clear that that we are interested in
-the "pressed" signal. Instead of doing it with the visual
-interface, we will opt to make the connection using code.
+In any case, at this point it is clear that we are interested in
+the "pressed" signal. Instead of using the visual interface, we will opt
+to code the connection.
 
-For this, there is a function that is probably the one that Godot
-programmers will use the most, this is
-:ref:`Node.get_node() <class_Node_get_node>`.
+For this, a function exists that is probably the one most used by Godot
+programmers, namely :ref:`Node.get_node() <class_Node_get_node>`.
 This function uses paths to fetch nodes in the current tree or anywhere
 in the scene, relative to the node holding the script.
 
@@ -171,8 +170,8 @@ To fetch the button, the following must be used:
 
     get_node("Button")
 
-So, next, a callback will be added for when a button is pressed, that
-will change the label's text:
+Next, a callback will be added that will change the label's text when
+the button is pressed:
 
 ::
 
@@ -209,7 +208,7 @@ button:
 
 .. image:: /img/scripting_hello.png
 
-**Note:** As it is a common mistake in this tutorial, let's clarify
+**Note:** As it is a common misunderstanding in this tutorial, let's clarify
 again that get_node(path) works by returning the *immediate* children of
 the node controlled by the script (in this case, *Panel*), so *Button*
 must be a child of *Panel* for the above code to work. To give this
@@ -222,5 +221,4 @@ to obtain it would be:
     # but just in case
     get_node("Label/Button") 
 
-And, also, try to remember that nodes are referenced by name, not by
-type.
+Also, remember that nodes are referenced by name, not by type.

tutorials/step_by_step/scripting_continued.rst

@@ -59,15 +59,15 @@ ways to do this, the first is from the UI, from the Groups button under Node-pan
 
 .. image:: /img/groups_in_nodes.PNG
 
-And the second from code. One useful example would be, for example, to
-tag scenes which are enemies.
+And the second from code. One useful example would be to tag scenes
+which are enemies.
 
 ::
 
     func _ready():
         add_to_group("enemies")
 
-This way, if the player, sneaking into the secret base, is discovered,
+This way, if the player is discovered sneaking into the secret base,
 all enemies can be notified about the alarm sounding, by using
 :ref:`SceneTree.call_group() <class_SceneTree_call_group>`:
 
@@ -94,9 +94,9 @@ later.
 Notifications
 -------------
 
-Godot has a system of notifications. This is usually not needed to be
-used from scripting, as it's too low level and virtual functions are
-provided for most of them. It's just good to know they exists. Simply
+Godot has a system of notifications. This is usually not needed for
+scripting, as it's too low level and virtual functions are provided for
+most of them. It's just good to know they exists. Simply
 add a
 :ref:`Object._notification() <class_Object__notification>`
 function in your script:
@@ -111,14 +111,14 @@ function in your script:
             print("This is the same as overriding _process()...")
 
 The documentation of each class in the :ref:`Class Reference <toc-class-ref>`
-shows the notifications it can receive. However, again, for most cases
-script provides simpler overrideable functions.
+shows the notifications it can receive. However, for most cases GDScript
+provides simpler overrideable functions.
 
 Overrideable functions
 ----------------------
 
-As mentioned before, it's better to use these functions. Nodes provide
-many useful overrideable functions, which are described as follows:
+Nodes provide many useful overrideable functions, which are described as
+follows:
 
 ::
 
@@ -159,10 +159,12 @@ many useful overrideable functions, which are described as follows:
         # Called when game is unpaused.
         pass
 
+As mentioned before, it's best to use these functions.
+
 Creating nodes
 --------------
 
-To create a node from code, just call the .new() method, (like for any
+To create a node from code, just call the .new() method (like for any
 other class based datatype). Example:
 
 ::
@@ -184,14 +186,14 @@ When a node is freed, it also frees all its children nodes. Because of
 this, manually deleting nodes is much simpler than it appears. Just free
 the base node and everything else in the sub-tree goes away with it.
 
-However, it might happen very often that we might want to delete a node
-that is currently "blocked" this means, the node is emitting a signal or
-calling a function. This will result in crashing the game. Running Godot
+However, it might happen very often that we want to delete a node that
+is currently "blocked", because it is emitting a signal or calling a
+function. This will result in crashing the game. Running Godot
 in the debugger often will catch this case and warn you about it.
 
 The safest way to delete a node is by using
-:ref:`Node.queue_free() <class_Node_queue_free>`
-instead. This erases the node during idle, safely.
+:ref:`Node.queue_free() <class_Node_queue_free>`.
+This erases the node safely during idle.
 
 ::
 
@@ -215,7 +217,7 @@ time.
 
     var scene = preload("res://myscene.scn") # will load when parsing the script
 
-But 'scene' is still not a node containing subnodes. It's packed in a
+But 'scene' is not yet a node containing subnodes. It's packed in a
 special resource called :ref:`PackedScene <class_PackedScene>`.
 To create the actual node, the function
 :ref:`PackedScene.instance() <class_PackedScene_instance>`
@@ -229,5 +231,5 @@ the active scene:
 
 The advantage of this two-step process is that a packed scene may be
 kept loaded and ready to use, so it can be used to create as many
-instances as desired. This is specially useful, for example, to instance
-several enemies, bullets, etc. quickly in the active scene.
+instances as desired. This is especially useful to quickly instance
+several enemies, bullets, etc. in the active scene.

tutorials/step_by_step/simple_2d_game.rst

@@ -6,11 +6,11 @@ Simple 2D game
 Pong
 ~~~~
 
-In this simple tutorial, a basic game of Pong will be created. There are
-plenty of more complex examples in the demos included with the engine,
-but this should get one introduced to basic functionality for 2D Games.
+In this tutorial, a basic game of Pong will be created. There are plenty
+of more complex examples in the demos included with the engine, but this
+should get you introduced to the basic functionalities for 2D Games.
 
-Run Godot Engine and start a new project.
+To begin with, run the Godot Engine and start a new project.
 
 Assets
 ~~~~~~
@@ -170,7 +170,7 @@ this function.
 
 We have to init some useful values for computation. The first one is the
 ball position (from the node), the second one is the rectangle
-(``Rect2``) for each pad. These rectangles will be used for collisions
+(``Rect2``) for each pad. These rectangles will be used for collision
 tests between the ball and the pads. Sprites center their textures by
 default, so a small adjustment of ``pad_size / 2`` must be added.
 
@@ -194,7 +194,7 @@ This code line is called at each iteration of the ``_process()``
 function. That means the ball position will be updated at each new
 frame.
 
-Then, now that the ball has a new position, we need to test if it
+Now that the ball has a new position, we need to test if it
 collides with anything, that is the window borders and the pads. First,
 the floor and the roof:
 
@@ -204,9 +204,9 @@ the floor and the roof:
         if ((ball_pos.y < 0 and direction.y < 0) or (ball_pos.y > screen_size.y and direction.y > 0)):
             direction.y = -direction.y
 
-Second, the pads: if one of the pads was touched, we need to invert the
+Second, the pads: if one of the pads is touched, we need to invert the
 direction of the ball on the X axis so it goes back, and define a new
-random Y direction using ``randf()`` function. We also increase its
+random Y direction using the ``randf()`` function. We also increase its
 speed a little.
 
 ::
@@ -218,9 +218,9 @@ speed a little.
             direction = direction.normalized()
             ball_speed *= 1.1
 
-If the ball went out of the screen, it's game over. That is, we test if
+Finally, if the ball went out of the screen, it's game over. That is, we test if
 the X position of the ball is less than 0 or greater than the screen
-width. If so, the game then restarts:
+width. If so, the game restarts:
 
 ::
 
@@ -230,15 +230,15 @@ width. If so, the game then restarts:
             ball_speed = INITIAL_BALL_SPEED
             direction = Vector2(-1, 0)
 
-Once everything was done with the ball, the node is updated with the new
-position which was computed before:
+Once everything is done, the node is updated with the new position of
+the ball, which was computed before:
 
 ::
 
         get_node("ball").set_pos(ball_pos)
 
-Pads movement: we only update the pads according to player input. This
-is done using the Input class:
+Next, we allow the pads to move. We only update their position according
+to player input. This is done using the Input class:
 
 ::
 
@@ -262,10 +262,10 @@ is done using the Input class:
 
         get_node("right").set_pos(right_pos)
         
-We use the 4 actions previously defined in the Input actions setup
-section. When the player activates the according key, the corresponding
-action is triggered. When the action is triggered, we simply compute a
-new position for the pad in the wished direction. Finally, we set this
-new position to the node.
+We use the four actions previously defined in the Input actions setup
+section above. When the player activates the respective key, the
+corresponding action is triggered. As soon as this happens, we simply
+compute a new position for the pad in the desired direction and apply it
+to the node.
 
-And that's it! A simple Pong was written with a few lines of code.
+That's it! A simple Pong was written with a few lines of code.

tutorials/step_by_step/singletons_autoload.rst

@@ -34,7 +34,7 @@ Auto-loading nodes and scripts caters to this need.
 AutoLoad
 --------
 
-You can use AutoLoad to load a scene, or a script that inherits from Node (a Node
+You can use AutoLoad to load a scene, or a script that inherits from Node (a node
 will be created and the script will be set to it). 
 
 To autoload a scene or script, select Scene > Project Settings from the menu and switch

tutorials/step_by_step/splash_screen.rst

@@ -6,11 +6,11 @@ Splash screen
 Tutorial
 --------
 
-This will be a simple tutorial to cement the basic idea of how the GUI
-subsystem works. The goal will be to create a really simple, static
+This is a simple tutorial to establish the basic idea of how the GUI
+subsystem works. The goal is to create a really simple, static
 splash screen.
 
-Following is a file with the assets that will be used. These can be added directly to your project folder—no need to import them:
+Following is a file with the assets that will be used. These can be added directly to your project folder - no need to import them:
 
 :download:`robisplash_assets.zip </files/robisplash_assets.zip>`.
 
@@ -23,20 +23,20 @@ Set the display resolution to 800x450 in Project Settings, and set up a new scen
 
 .. image:: /img/robisplashpreview.png
 
-The nodes 'background" and "logo" are of :ref:`TextureFrame <class_TextureFrame>`
+The nodes "background" and "logo" are of :ref:`TextureFrame <class_TextureFrame>`
 type. These have a special property for setting the texture to be
 displayed, just load the corresponding file.
 
 .. image:: /img/texframe.png
 
-The node "start" is a :ref:`TextureButton <class_TextureButton>`,
-it takes several images for different states, but only the normal and
+The node "start" is a :ref:`TextureButton <class_TextureButton>`.
+It takes several images for different states, but only the normal and
 pressed will be supplied in this example:
 
 .. image:: /img/texbutton.png
 
 Finally, the node "copyright" is a :ref:`Label <class_Label>`.
-Labels can be set a custom font by editing the following property:
+A custom font can be set for labels by editing the following property:
 
 .. image:: /img/label.png