stan220/godot-docs
1
0
Fork 0
mirror of https://github.com/stan220/godot-docs.git synced 2026-09-08 21:29:07 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #131 from jdknox/grammar-fix

Browse Source 
Grammar and link fixes for "InputEvent" and "Simple 2D Game"
This commit is contained in:
Rémi Verschelde
2016-05-01 14:55:23 +02:00
parent 496226cec5 c32b2a6485
commit d165c029ce
2 changed files with 39 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tutorials/engine/inputevent.rst
+14 -14
View File
@@ -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
+25 -25
View File
@@ -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)