diff --git a/tutorials/io/saving_games.rst b/tutorials/io/saving_games.rst index eb31db9e7..0e37fc6ea 100644 --- a/tutorials/io/saving_games.rst +++ b/tutorials/io/saving_games.rst @@ -25,7 +25,7 @@ sessions and what information we want to keep from those objects. For this tutorial, we will use groups to mark and handle objects to be saved, but other methods are certainly possible. -We will start by adding objects we wish to save to the "Persist" group. we can +We will start by adding objects we wish to save to the "Persist" group. We can do this through either the GUI or script. Let's add the relevant nodes using the GUI: diff --git a/tutorials/scripting/gdscript/gdscript_basics.rst b/tutorials/scripting/gdscript/gdscript_basics.rst index 41feee597..796305bd1 100644 --- a/tutorials/scripting/gdscript/gdscript_basics.rst +++ b/tutorials/scripting/gdscript/gdscript_basics.rst @@ -1211,7 +1211,7 @@ path. For example, if you name a script file ``character.gd``:: Registering named classes ~~~~~~~~~~~~~~~~~~~~~~~~~ -Instead, you can give your class a name to register it as a new type in Godot's +You can give your class a name to register it as a new type in Godot's editor. For that, you use the ``class_name`` keyword. You can optionally use the ``@icon`` annotation with a path to an image, to use it as an icon. Your class will then appear with its new icon in the editor:: diff --git a/tutorials/scripting/gdscript/static_typing.rst b/tutorials/scripting/gdscript/static_typing.rst index 049ca52c8..408e8f8cc 100644 --- a/tutorials/scripting/gdscript/static_typing.rst +++ b/tutorials/scripting/gdscript/static_typing.rst @@ -107,7 +107,7 @@ Currently you can use three types of… types: 1. :ref:`Built-in ` 2. Core classes and nodes (``Object``, ``Node``, ``Area2D``, ``Camera2D``, etc.) -3. Your own, custom classes. Look at the new :ref:`class_name ` +3. Your own custom classes. Look at the new :ref:`class_name ` feature to register types in the editor. .. note:: diff --git a/tutorials/scripting/groups.rst b/tutorials/scripting/groups.rst index b1682891d..5e11a9034 100644 --- a/tutorials/scripting/groups.rst +++ b/tutorials/scripting/groups.rst @@ -83,7 +83,7 @@ scene tree. AddToGroup("guards"); } -Imagine you're creating a strategy game inspired by Metal Gear Solid. When an +Imagine you're creating an infiltration game. When an enemy spots the player, you want all guards and robots to be on alert. In the fictional example below, we use ``SceneTree.call_group()`` to alert all diff --git a/tutorials/scripting/idle_and_physics_processing.rst b/tutorials/scripting/idle_and_physics_processing.rst index a86520d29..c0a0d616b 100644 --- a/tutorials/scripting/idle_and_physics_processing.rst +++ b/tutorials/scripting/idle_and_physics_processing.rst @@ -4,7 +4,7 @@ Idle and Physics Processing =========================== Games run in a loop. Each frame, you need to update the state of your game world -before drawing it on screen. Godot provides two virtual methods on the Node +before drawing it on screen. Godot provides two virtual methods in the Node class to do so: :ref:`Node._process() ` and :ref:`Node._physics_process() `. If you define either or both in a script, the engine will call them automatically. @@ -14,7 +14,7 @@ There are two types of processing available to you: 1. **Idle processing** allows you to run code that updates a node every frame, as often as possible. 2. **Physics processing** happens at a fixed rate, 60 times per second by - default, independently of your game's actual framerate, and keeps physics + default. This is independent of your game's actual framerate, and keeps physics running smoothly. You should use it for anything that involves the physics engine, like moving a body that collides with the environment. @@ -70,12 +70,12 @@ The engine calls this method every time it draws a frame: // Do something... } -The function ``_process()`` is not synced with physics. Its rate depends on -hardware and game optimization. It also runs after the physics step on +The function ``_process()`` is not synchronized with physics. Its rate depends on +hardware and game optimization. It also runs after the physics step in single-threaded games. You can see the ``_process()`` function at work by creating a scene with a -single Label node, with the following script: +single Label node, with the following script attached to it: .. tabs:: .. code-tab:: gdscript GDScript diff --git a/tutorials/scripting/index.rst b/tutorials/scripting/index.rst index 2805d35a3..144f6585a 100644 --- a/tutorials/scripting/index.rst +++ b/tutorials/scripting/index.rst @@ -26,7 +26,7 @@ case, an interface that works with multiple languages. Core features ------------- -Some features are specific to the engine and available in all supported +Some features are specific to the engine and are available in all supported languages. Whether you code in GDScript, C#, or another language, the pages below will help you make the most of Godot. diff --git a/tutorials/scripting/nodes_and_scene_instances.rst b/tutorials/scripting/nodes_and_scene_instances.rst index cfb07dd5e..34c0f9390 100644 --- a/tutorials/scripting/nodes_and_scene_instances.rst +++ b/tutorials/scripting/nodes_and_scene_instances.rst @@ -14,7 +14,7 @@ You can get a reference to a node by calling the :ref:`Node.get_node() present in the scene tree. Getting it in the parent node's ``_ready()`` function guarantees that. -Say you have a scene tree like this, and you want to get a reference to the +If, for example, you have a scene tree like this, and you want to get a reference to the Sprite and Camera2D nodes to access them in your script. .. image:: img/nodes_and_scene_instances_player_scene_example.png @@ -50,7 +50,7 @@ node into Skin, the call to get it would have to be ``get_node("Skin")``. Node paths ---------- -You're not limited to getting a direct child. The ``get_node()`` function +When getting a reference to a node, you're not limited to getting a direct child. The ``get_node()`` function supports paths, a bit like when working with a file browser. Add a slash to separate nodes. @@ -81,15 +81,15 @@ To get the Tween node, you would use the following code. } .. note:: As with file paths, you can use ".." to get a parent node. The best - practice is to avoid doing that though not to break encapsulation and - keep your code organized. You can also start the path with a forward + practice is to avoid doing that though not to break encapsulation. + You can also start the path with a forward slash to make it absolute, in which case your topmost node would be "/root", the application's predefined root viewport. Syntactic sugar ~~~~~~~~~~~~~~~ -You can use two shorthands to shorten your code in GDScript: putting the +You can use two shorthands to shorten your code in GDScript. Firstly, putting the ``onready`` keyword before a member variable makes it initialize right before the ``_ready()`` callback. @@ -138,7 +138,7 @@ script. To delete a node and free it from memory, you can call its ``queue_free()`` method. Doing so queues the node for deletion at the end of the current frame -after it finished processing. At that point, the engine removes the node from +after it has finished processing. At that point, the engine removes the node from the scene and frees the object in memory. .. tabs:: @@ -176,8 +176,9 @@ Instancing a scene from code happens in two steps: var scene = GD.Load("res://MyScene.tscn"); -Preloading it can improve the user's experience as it happens when parsing the -script. This feature is only available with GDScript. +Preloading the scene can improve the user's experience as the load operation +happens when the compiler reads the script and not at runtime. This feature is +only available with GDScript. .. tabs:: .. code-tab:: gdscript GDScript @@ -187,7 +188,7 @@ script. This feature is only available with GDScript. At that point, ``scene`` is a packed scene resource, not a node. To create the actual node, you need to call :ref:`PackedScene.instance() `. It returns a tree of nodes that you can -add as a child. +as a child of your current node. .. tabs:: .. code-tab:: gdscript GDScript diff --git a/tutorials/scripting/overridable_functions.rst b/tutorials/scripting/overridable_functions.rst index 679bb60f6..9c17bef80 100644 --- a/tutorials/scripting/overridable_functions.rst +++ b/tutorials/scripting/overridable_functions.rst @@ -8,7 +8,7 @@ every frame or on specific events, like when they enter the scene tree. This document presents the ones you'll use most often. -.. seealso:: Under the hood, these functions rely on Godot's uses a low-level +.. seealso:: Under the hood, these functions rely on Godot's low-level notifications system. To learn more about it, see :ref:`doc_godot_notifications`. @@ -16,13 +16,13 @@ Two functions allow you to initialize and get nodes, besides the class's constructor: ``_enter_tree()`` and ``_ready()``. When the node enters the Scene Tree, it becomes active and the engine calls its -``_enter_tree()`` method. Children may not be part of the active scene yet. As +``_enter_tree()`` method. That node's children may not be part of the active scene yet. As you can remove and re-add nodes to the scene tree, this function may be called multiple times throughout a node's lifetime. Most of the time, you'll use ``_ready()`` instead. This function is called only -once in a node's lifetime, after ``_enter_tree()``. It ensures that all children -have entered the scene tree first, so you can safely call ``get_node()`` in it. +once in a node's lifetime, after ``_enter_tree()``. ``_ready()`` ensures that all children +have entered the scene tree first, so you can safely call ``get_node()`` on it. .. seealso:: To learn more about getting node references, read :ref:`doc_nodes_and_scene_instances`. @@ -43,7 +43,7 @@ a node exits the scene tree. This can be when you call :ref:`Node.remove_child() pass # Called when the node is about to leave the scene tree, after all its - children. + children received the _exit_tree() callback. func _exit_tree(): pass @@ -69,7 +69,7 @@ a node exits the scene tree. This can be when you call :ref:`Node.remove_child() } The two virtual methods ``_process()`` and ``_physics_process()`` allow you to -update the node, respectively, every frame and every physics frame. For more +update the node, every frame and every physics frame respectively. For more information, read the dedicated documentation: :ref:`doc_idle_and_physics_processing`. @@ -100,15 +100,14 @@ information, read the dedicated documentation: Two more essential built-in node callback functions are :ref:`Node._unhandled_input() ` and -:ref:`Node._input() `, which you both use to receive +:ref:`Node._input() `, which you use to both receive and process individual input events. The ``_unhandled_input()`` method receives -every key press, mouse click, etc. that had not been handled already in an -``_input()`` callback or in a piece of user interface. You want to use it for +every key press, mouse click, etc. that have not been handled already in an +``_input()`` callback or in a user interface component. You want to use it for gameplay input in general. The ``_input()`` callback allows you to intercept and process input events before ``_unhandled_input()`` gets them. -There's a lot to say about input handling in Godot. You'll find a lot more -information in the :ref:`Input section `. +To learn more about inputs in Godot, see the :ref:`Input section `. .. tabs:: .. code-tab:: gdscript GDScript