Merge pull request #131 from jdknox/grammar-fix

Grammar and link fixes for "InputEvent" and "Simple 2D Game"

tutorials/engine/inputevent.rst

@@ -16,9 +16,9 @@ How does it work?
 -----------------
 
 Every input event is originated from the user/player (though it's
-possible to generate an InputEvent and feed then back to the engine,
+possible to generate an InputEvent and feed them back to the engine,
 which is useful for gestures). The OS object for each platform will read
-events from the device, then feed the to MainLoop. As :ref:`SceneTree <class_SceneTree>`
+events from the device, then feed them to MainLoop. As :ref:`SceneTree <class_SceneTree>`
 is the default MainLoop implementation, events are fed to it. Godot
 provides a function to get the current SceneTree object :
 **get_tree()**.
@@ -31,7 +31,7 @@ received input, in order:
 .. image:: /img/input_event_flow.png
 
 1. First, it will try to feed the input to the GUI, and see if any
-   control can receive it. If so, the :ref:`Control <class_Control>` will be called the
+   control can receive it. If so, the :ref:`Control <class_Control>` will be called via the
    virtual function :ref:`Control._input_event() <class_Control__input_event>` and the signal
    "input_event" will be emitted (this function is re-implementable by
    script by inheriting from it). If the control wants to "consume" the
@@ -39,19 +39,19 @@ received input, in order:
    not spread any more.
 2. If the GUI does not want the event, the standard _input function
    will be called in any node with input processing enabled (enable with
-   :ref:`Node.set_process_input() <class_Node_set_process_input>`) and override
+   :ref:`Node.set_process_input() <class_Node_set_process_input>` and override
    :ref:`Node._input() <class_Node__input>`). If any function consumes the event, it can
    call :ref:`SceneTree.set_input_as_handled() <class_SceneTree_set_input_as_handled>`, and the event will
    not spread any more.
 3. If so far no one consumed the event, the unhandled input callback
    will be called (enable with
-   :ref:`Node.set_process_unhandled_input() <class_Node_set_process_unhandled_input>`) and override
+   :ref:`Node.set_process_unhandled_input() <class_Node_set_process_unhandled_input>` and override
    :ref:`Node._unhandled_input() <class_Node__unhandled_input>`). If any function consumes the
    event, it can call :ref:`SceneTree.set_input_as_handled() <class_SceneTree_set_input_as_handled>`, and the
    event will not spread any more.
 4. If no one wanted the event so far, and a :ref:`Camera <class_Camera>` is assigned
    to the Viewport, a ray to the physics world (in the ray direction from
-   the click) will be casted. If this ray hits an object, it will call the
+   the click) will be cast. If this ray hits an object, it will call the
    :ref:`CollisionObject._input_event() <class_CollisionObject__input_event>` function in the relevant
    physics object (bodies receive this callback by default, but areas do
    not. This can be configured through :ref:`Area <class_Area>` properties).
@@ -76,19 +76,19 @@ Example of changing event type.
     # create event
     var ev = InputEvent()
     # set type index
-    ev.type=InputEvent.MOUSE_BUTTON
+    ev.type = InputEvent.MOUSE_BUTTON
     # button_index is only available for the above type
-    ev.button_index=BUTTON_LEFT
+    ev.button_index = BUTTON_LEFT
 
 There are several types of InputEvent, described in the table below:
 
 +-------------------------------------------------------------------+--------------------+-----------------------------------------+
 | Event                                                             | Type Index         | Description                             |
 +-------------------------------------------------------------------+--------------------+-----------------------------------------+
-| :ref:`InputEvent <class_InputEvent>`                              | NONE               | Empty Input Event                       |
+| :ref:`InputEvent <class_InputEvent>`                              | NONE               | Empty Input Event.                      |
 +-------------------------------------------------------------------+--------------------+-----------------------------------------+
 | :ref:`InputEventKey <class_InputEventKey>`                        | KEY                | Contains a scancode and unicode value,  |
-|                                                                   |                    | as well as modifiers                    |
+|                                                                   |                    | as well as modifiers.                   |
 +-------------------------------------------------------------------+--------------------+-----------------------------------------+
 | :ref:`InputEventMouseButton <class_InputEventMouseButton>`        | MOUSE_BUTTON       | Contains click information, such as     |
 |                                                                   |                    | button, modifiers, etc.                 |
@@ -121,8 +121,8 @@ An InputEvent may or may not represent a pre-defined action. Actions are
 useful because they abstract the input device when programming the game
 logic. This allows for:
 
--  The same code to work on different devices with different inputs (ie:
-   keyboard on PC, Joypad on console)
+-  The same code to work on different devices with different inputs (e.g.,
+   keyboard on PC, Joypad on console).
 -  Input to be reconfigured at run-time.
 
 Actions can be created from the Project Settings menu in the Actions
@@ -140,7 +140,7 @@ SceneTree (derived from MainLoop) has a method for this:
 ::
 
     var ev = InputEvent()
-    ev.type=InputEvent.ACTION
+    ev.type = InputEvent.ACTION
     # set as move_left, pressed
     ev.set_as_action("move_left", true) 
     # feedback
@@ -154,4 +154,4 @@ whole workflow depends on actions, the :ref:`InputMap <class_InputMap>` singleto
 ideal for reassigning or creating different actions at run-time. This
 singleton is not saved (must be modified manually) and its state is run
 from the project settings (engine.cfg). So any dynamic system of this
-type needs to store settings in the way the programmer sees best fit.
+type needs to store settings in the way the programmer best sees fit.

tutorials/step_by_step/simple_2d_game.rst

@@ -8,7 +8,7 @@ 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 introduced to basic functionality for 2D Games.
+but this should get one introduced to basic functionality for 2D Games.
 
 Assets
 ~~~~~~
@@ -25,7 +25,7 @@ resolution. This can be configured in the Project Settings (see :ref:`doc_scenes
 .. image:: /img/clearcolor.png
 
 Create a :ref:`class_Node2D` node for the project root. Node2D is the base
-type for the 2D engine. After this, add some sprites :ref:`class_Sprite`
+type for the 2D engine. After this, add some sprites (:ref:`class_Sprite`
 node) and set each to the corresponding texture. The final scene layout
 should look similar to this (note: the ball is in the middle!):
 
@@ -38,7 +38,7 @@ The scene tree should, then, look similar to this:
 Save the scene as "pong.scn" and set it as the main scene in the project
 properties.
 
-.. _doc_simple_2d_game-input_actions_setup
+.. _doc_simple_2d_game-input_actions_setup:
 
 Input actions setup
 ~~~~~~~~~~~~~~~~~~~
@@ -56,8 +56,8 @@ Open the project properties dialog again, but this time move to the
 "Input Map" tab.
 
 On it, add 4 actions:
-"left_move_up","left_move_down","right_move_up","right_move_down".
-Assign the keys that you desire. A/Z for left and Up/Down as keys
+``left_move_up``, ``left_move_down``, ``right_move_up``, ``right_move_down``.
+Assign the keys that you desire. A/Z (for the left player) and Up/Down (for the right player) as keys
 should work in most cases.
 
 .. image:: /img/inputmap.png
@@ -92,16 +92,16 @@ the dimensions of the screen and the pad:
         pad_size = get_node("left").get_texture().get_size()
         set_process(true)
 
-Then, some variables used for in-game will be added:
+Then, some variables used for in-game processing will be added:
 
 ::
 
-    #speed of the ball (in pixels/second0
+    #speed of the ball (in pixels/second)
 
     var ball_speed = 80
     #direction of the ball (normal vector)
 
-    var direction = Vector2(-1,0)
+    var direction = Vector2(-1, 0)
     #constant for pad speed (also in pixels/second)
 
     const PAD_SPEED = 150
@@ -113,8 +113,8 @@ Finally, the process function:
     func _process(delta):
 
 Get some useful values for computation. The first is the ball position
-(from the node), the second is the rectangles (Rect2) of the pads.
-Sprites by defaut center the textures, so a small adjustment of size/2
+(from the node), the second is the rectangle (``Rect2``) for each of the pads.
+Sprites center their textures by default, so a small adjustment of ``pad_size / 2``
 must be added.
 
 ::
@@ -123,18 +123,18 @@ must be added.
         var left_rect = Rect2( get_node("left").get_pos() - pad_size/2, pad_size )
         var right_rect = Rect2( get_node("right").get_pos() - pad_size/2, pad_size )
 
-Since the ball pos was obtained, integrating it should be simple:
+Since the ball position was obtained, integrating it should be simple:
 
 ::
 
-        ball_pos+=direction*ball_speed*delta
+        ball_pos += direction * ball_speed * delta
 
 Then, now that the ball has a new position, it should be tested against
 everything. First, 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)):
+        if ( (ball_pos.y < 0 and direction.y < 0) or (ball_pos.y > screen_size.y and direction.y > 0)):
             direction.y = -direction.y
 
 If one of the pads was touched, change direction and increase speed a
@@ -143,19 +143,19 @@ little.
 ::
 
         if ( (left_rect.has_point(ball_pos) and direction.x < 0) or (right_rect.has_point(ball_pos) and direction.x > 0)):
-            direction.x=-direction.x
-            ball_speed*=1.1
-            direction.y=randf()*2.0-1
+            direction.x = -direction.x
+            ball_speed *= 1.1
+            direction.y = randf() * 2.0 - 1
             direction = direction.normalized()
 
 If the ball went out of the screen, it's game over. Game restarts:
 
 ::
 
-        if (ball_pos.x<0 or ball_pos.x>screen_size.x):
-            ball_pos=screen_size*0.5 #ball goes to screen center
-            ball_speed=80
-            direction=Vector2(-1,0)
+        if (ball_pos.x < 0 or ball_pos.x > screen_size.x):
+            ball_pos = screen_size * 0.5  # ball goes to screen center
+            ball_speed = 80
+            direction = Vector2(-1, 0)
 
 Once everything was done with the ball, the node is updated with the new
 position:
@@ -164,7 +164,7 @@ position:
 
         get_node("ball").set_pos(ball_pos)
 
-Only updating the pads according to player input. the Input class is
+Only update the pads according to player input. The Input class is
 really useful here:
 
 ::
@@ -173,9 +173,9 @@ really useful here:
         var left_pos = get_node("left").get_pos()
 
         if (left_pos.y > 0 and Input.is_action_pressed("left_move_up")):
-            left_pos.y+=-PAD_SPEED*delta
+            left_pos.y += -PAD_SPEED * delta
         if (left_pos.y < screen_size.y and Input.is_action_pressed("left_move_down")):
-            left_pos.y+=PAD_SPEED*delta
+            left_pos.y += PAD_SPEED * delta
 
         get_node("left").set_pos(left_pos)
 
@@ -183,9 +183,9 @@ really useful here:
         var right_pos = get_node("right").get_pos()
 
         if (right_pos.y > 0 and Input.is_action_pressed("right_move_up")):
-            right_pos.y+=-PAD_SPEED*delta
+            right_pos.y += -PAD_SPEED * delta
         if (right_pos.y < screen_size.y and Input.is_action_pressed("right_move_down")):
-            right_pos.y+=PAD_SPEED*delta
+            right_pos.y += PAD_SPEED * delta
 
         get_node("right").set_pos(right_pos)