Rewrite and rename scripting -> scripting_languages

The page now focuses on giving an overview of official scripting languages.
Removed first example using signals. We'll introduce signals later in
the series.

Moved the explanation of what scripts are and do to the top, before
talking about languages.

Mentioned other things like that GDScript isn't like Python, that it's
an imperative and OO language, with links to wikipedia that explain the
jargon.

Closes #4172

classes/class_script.rst

@@ -25,7 +25,7 @@ The ``new`` method of a script subclass creates a new instance. :ref:`Object.set
 Tutorials
 ---------
 
-- :doc:`../getting_started/step_by_step/scripting`
+- :doc:`../getting_started/step_by_step/your_first_script`
 
 Properties
 ----------

getting_started/step_by_step/index.rst

@@ -18,7 +18,9 @@ where appropriate.
 
    nodes_and_scenes
    instancing
-   scripting
+   scripting_languages
+   your_first_script
+   scripting_continued
    signals
    your_first_game
    exporting

getting_started/step_by_step/scripting.rst

@@ -1,342 +0,0 @@
-.. _doc_scripting:
-
-Scripting
-=========
-
-Introduction
-------------
-
-Before Godot 3.0, the only choice for scripting a game was to use
-:ref:`GDScript<doc_gdscript>`. Nowadays, Godot has four (yes, four!) official languages
-and the ability to add extra scripting languages dynamically!
-
-This is great, mostly due to the large amount of flexibility provided, but
-it also makes our work supporting languages more difficult.
-
-The "main" languages in Godot, though, are GDScript and VisualScript. The
-main reason to choose them is their level of integration with Godot, as this
-makes the experience smoother; both have slick editor integration, while
-C# and C++ need to be edited in a separate IDE. If you are a big fan of statically typed languages, go with C# and C++ instead.
-
-GDScript
-~~~~~~~~
-
-:ref:`GDScript<doc_gdscript>` is, as mentioned above, the main language used in Godot.
-Using it has some positive points compared to other languages due
-to its high integration with Godot:
-
-* It's simple, elegant, and designed to be familiar for users of other languages such as Lua, Python, Squirrel, etc.
-* Loads and compiles blazingly fast.
-* The editor integration is a pleasure to work with, with code completion for nodes, signals, and many other items pertaining to the scene being edited.
-* Has vector types built-in (such as Vectors, transforms, etc.), making it efficient for heavy use of linear algebra.
-* Supports multiple threads as efficiently as statically typed languages - one of the limitations that made us avoid VMs such as Lua, Squirrel, etc.
-* Uses no garbage collector, so it trades a small bit of automation (most objects are reference counted anyway), by determinism.
-* Its dynamic nature makes it easy to optimize sections of code in C++ (via GDNative) if more performance is required, all without recompiling the engine.
-
-If you're undecided and have experience with programming, especially dynamically
-typed languages, go for GDScript!
-
-VisualScript
-~~~~~~~~~~~~
-
-Beginning with 3.0, Godot offers :ref:`Visual Scripting<doc_what_is_visual_script>`. This is a
-typical implementation of a "blocks and connections" language, but
-adapted to how Godot works.
-
-Visual scripting is a great tool for non-programmers, or even for experienced developers
-who want to make parts of the code more accessible to others,
-like game designers or artists.
-
-It can also be used by programmers to build state machines or custom
-visual node workflows - for example, a dialogue system.
-
-
-.NET / C#
-~~~~~~~~~
-
-As Microsoft's C# is a favorite amongst game developers, we have added
-official support for it. C# is a mature language with tons of code
-written for it, and support was added thanks to
-a generous donation from Microsoft.
-
-It has an excellent tradeoff between performance and ease of use,
-although one must be aware of its garbage collector.
-
-Since Godot uses the `Mono <https://mono-project.com>`_ .NET runtime, in theory
-any third-party .NET library or framework can be used for scripting in Godot, as
-well as any Common Language Infrastructure-compliant programming language, such as
-F#, Boo or ClojureCLR. In practice however, C# is the only officially supported .NET option.
-
-GDNative / C++
-~~~~~~~~~~~~~~
-
-Finally, one of our brightest additions for the 3.0 release:
-GDNative allows scripting in C++ without needing to recompile (or even
-restart) Godot.
-
-Any C++ version can be used, and mixing compiler brands and versions for the
-generated shared libraries works perfectly, thanks to our use of an internal C
-API Bridge.
-
-This language is the best choice for performance and does not need to be
-used throughout an entire game, as other parts can be written in GDScript or Visual
-Script. However, the API is clear and easy to use as it resembles, mostly,
-Godot's actual C++ API.
-
-More languages can be made available through the GDNative interface, but keep in mind
-we don't have official support for them.
-
-Scripting a scene
------------------
-
-For the rest of this tutorial we'll set up a GUI scene consisting of a
-button and a label, where pressing the button will update the label. This will
-demonstrate:
-
-- Writing a script and attaching it to a node.
-- Hooking up UI elements via signals.
-- Writing a script that can access other nodes in the scene.
-
-Before continuing, make sure to skim and bookmark the :ref:`GDScript<doc_gdscript>` reference.
-It's a language designed to be simple, and the reference is structured into sections to make it
-easier to get an overview of the concepts.
-
-Scene setup
-~~~~~~~~~~~
-
-If you still have the "instancing" project open from the previous tutorial, then close that out (Project -> Quit to Project List) and create a New Project.
-
-Use the "Add Child Node" dialogue accessed from the Scene tab (or by pressing :kbd:`Ctrl + A`) to create a hierarchy with the following
-nodes:
-
-- Panel
-
-  * Label
-  * Button
-
-The scene tree should look like this:
-
-.. image:: img/scripting_scene_tree.png
-
-Use the 2D editor to position and resize the Button and Label so that they
-look like the image below. You can set the text from the Inspector tab.
-
-.. image:: img/label_button_example.png
-
-Finally, save the scene with a name such as ``sayhello.tscn``.
-
-.. _doc_scripting-adding_a_script:
-
-Adding a script
-~~~~~~~~~~~~~~~
-
-Right click on the Panel node, then select "Attach Script" from the context
-menu:
-
-.. image:: img/add_script.png
-
-The script creation dialog will pop up. This dialog allows you to set the
-script's language, class name, and other relevant options.
-
-In GDScript, the file itself represents the class, so
-the class name field is not editable.
-
-The node we're attaching the script to is a panel, so the Inherits field
-will automatically be filled in with "Panel". This is what we want, as the
-script's goal is to extend the functionality of our panel node.
-
-Finally, enter a path name for the script and select Create:
-
-.. image:: img/script_create.png
-
-The script will then be created and added to the node. You can
-see this as an "Open script" icon next to the node in the Scene tab,
-as well as in the script property under Inspector:
-
-.. image:: img/script_added.png
-
-To edit the script, select either of these buttons, both of which are highlighted in the above image.
-This will bring you to the script editor, where a default template will be included:
-
-.. image:: img/script_template.png
-
-There's not much there. The ``_ready()`` function is called when the
-node, and all its children, enters the active scene. **Note:** ``_ready()`` is not
-the constructor; the constructor is instead ``_init()``.
-
-The role of the script
-~~~~~~~~~~~~~~~~~~~~~~
-
-A script adds behavior to a node. It is used to control how the node functions
-as well as how it interacts with other nodes: children, parent, siblings,
-and so on. The local scope of the script is the node. In other words, the script
-inherits the functions provided by that node.
-
-.. image:: img/brainslug.jpg
-
-
-.. _doc_scripting_handling_a_signal:
-
-Handling a signal
-~~~~~~~~~~~~~~~~~
-
-Signals are "emitted" when some specific kind of action happens, and they can be
-connected to any function of any script instance. Signals are used mostly in
-GUI nodes, although other nodes have them too, and you can even define custom
-signals in your own scripts.
-
-In this step, we'll connect the "pressed" signal to a custom function. Forming
-connections is the first part and defining the custom function is the second part.
-For the first part, Godot provides two ways to create connections: through a
-visual interface the editor provides or through code.
-
-While we will use the code method for the remainder of this tutorial series, let's
-cover how the editor interface works for future reference.
-
-Select the Button node in the scene tree and then select the "Node" tab. Next,
-make sure that you have "Signals" selected.
-
-.. image:: img/signals.png
-
-If you then select "pressed()" under "BaseButton" and click the "Connect..."
-button in the bottom right, you'll open up the connection creation dialogue.
-
-.. image:: img/connect_dialogue.png
-
-The top of the dialogue displays a list of your scene's nodes with the emitting
-node's name highlighted in blue. Select the "Panel" node here.
-
-The bottom of the dialogue shows the name of the method that will be created.
-By default, the method name will contain the emitting node's name ("Button" in
-this case), resulting in ``_on_[EmitterNode]_[signal_name]``.
-
-And that concludes the guide on how to use the visual interface. However, this
-is a scripting tutorial, so for the sake of learning, let's dive into the
-manual process!
-
-To accomplish this, we will introduce a function that is probably the most used
-by Godot programmers: :ref:`Node.get_node() <class_Node_method_get_node>`.
-This function uses paths to fetch nodes anywhere in the scene, relative to the
-node that owns the script.
-
-For the sake of convenience, delete everything underneath ``extends Panel``.
-You will fill out the rest of the script manually.
-
-Because the Button and Label are siblings under the Panel
-where the script is attached, you can fetch the Button by typing
-the following underneath the ``_ready()`` function:
-
-.. tabs::
- .. code-tab:: gdscript GDScript
-
-    func _ready():
-        get_node("Button")
-
- .. code-tab:: csharp
-
-    public override void _Ready()
-    {
-        GetNode("Button");
-    }
-
-Next, write a function which will be called when the button is pressed:
-
-.. tabs::
- .. code-tab:: gdscript GDScript
-
-    func _on_Button_pressed():
-        get_node("Label").text = "HELLO!"
-
- .. code-tab:: csharp
-
-    public void _OnButtonPressed()
-    {
-        GetNode<Label>("Label").Text = "HELLO!";
-    }
-
-Finally, connect the button's "pressed" signal to ``_on_Button_pressed()`` by
-using :ref:`Object.connect() <class_Object_method_connect>`.
-
-.. tabs::
- .. code-tab:: gdscript GDScript
-
-    func _ready():
-        get_node("Button").connect("pressed", self._on_Button_pressed)
-
- .. code-tab:: csharp
-
-    public override void _Ready()
-    {
-        GetNode("Button").Connect("pressed", this, nameof(_OnButtonPressed));
-    }
-
-The final script should look like this:
-
-.. tabs::
- .. code-tab:: gdscript GDScript
-
-    extends Panel
-
-    func _ready():
-        get_node("Button").connect("pressed", self._on_Button_pressed)
-
-    func _on_Button_pressed():
-        get_node("Label").text = "HELLO!"
-
- .. code-tab:: csharp
-
-    using Godot;
-
-    // IMPORTANT: the name of the class MUST match the filename exactly.
-    // this is case sensitive!
-    public class sayhello : Panel
-    {
-        public override void _Ready()
-        {
-            GetNode("Button").Connect("pressed", this, nameof(_OnButtonPressed));
-        }
-
-        public void _OnButtonPressed()
-        {
-            GetNode<Label>("Label").Text = "HELLO!";
-        }
-    }
-
-
-Run the scene and press the button. You should get the following result:
-
-.. image:: img/scripting_hello.png
-
-Why, hello there! Congratulations on scripting your first scene.
-
-.. note::
-
-    A common misunderstanding regarding this tutorial is how ``get_node(path)``
-    works. For a given node, ``get_node(path)`` searches its immediate children.
-    In the above code, this means that Button must be a child of Panel. If
-    Button were instead a child of Label, the code to obtain it would be:
-
-.. tabs::
- .. code-tab:: gdscript GDScript
-
-    # Not for this case,
-    # but just in case.
-    get_node("Label/Button")
-
- .. code-tab:: csharp
-
-    // Not for this case,
-    // but just in case.
-    GetNode("Label/Button")
-
-Also, remember that nodes are referenced by name, not by type.
-
-.. note::
-
-    The 'advanced' panel of the connect dialogue is for binding specific
-    values to the connected function's parameters. You can add and remove
-    values of different types.
-
-    The code approach also enables this with a 4th ``Array`` parameter that
-    is empty by default. Feel free to read up on the ``Object.connect``
-    method for more information.

getting_started/step_by_step/scripting_continued.rst

@@ -0,0 +1,425 @@
+.. _doc_scripting_continued:
+
+Built-in callbacks
+==================
+
+Processing
+----------
+
+Several actions in Godot are triggered by callbacks or virtual functions,
+so there is no need to write code that runs all the time.
+
+However, it is still common to need a script to be processed on every
+frame. There are two types of processing: idle processing and physics
+processing.
+
+Idle processing is activated when the method :ref:`Node._process() <class_Node_method__process>`
+is found in a script. It can be turned off and on with the
+:ref:`Node.set_process() <class_Node_method_set_process>` function.
+
+This method will be called every time a frame is drawn:
+
+.. tabs::
+ .. code-tab:: gdscript GDScript
+
+    func _process(delta):
+        # Do something...
+        pass
+
+ .. code-tab:: csharp
+
+    public override void _Process(float delta)
+    {
+        // Do something...
+    }
+
+It's important to bear in mind that the frequency with which ``_process()``
+will be called depends on how many frames per second (FPS) your application
+is running at. This rate can vary over time and devices.
+
+To help manage this variability, the ``delta`` parameter contains the time
+elapsed in seconds as a floating-point number since the previous call to ``_process()``.
+
+This parameter can be used to make sure things always take the same
+amount of time, regardless of the game's FPS.
+
+For example, movement is often multiplied with a time delta to make movement
+speed both constant and independent of the frame rate.
+
+Physics processing with ``_physics_process()`` is similar, but it should be used for processes that
+must happen before each physics step, such as controlling a character.
+It always runs before a physics step and it is called at fixed time intervals:
+60 times per second by default. You can change the interval from the Project Settings, under
+Physics -> Common -> Physics Fps.
+
+The function ``_process()``, however, is not synced with physics. Its frame rate is not constant and is dependent
+on hardware and game optimization. Its execution is done after the physics step on single-threaded games.
+
+A simple way to see the ``_process()`` function at work is to create a scene with a single Label node,
+with the following script:
+
+.. tabs::
+ .. code-tab:: gdscript GDScript
+
+    extends Label
+
+    var accum = 0
+
+    func _process(delta):
+        accum += delta
+        text = str(accum) # 'text' is a built-in label property.
+
+ .. code-tab:: csharp
+
+    public class CustomLabel : Label
+    {
+        private float _accum;
+
+        public override void _Process(float delta)
+        {
+            _accum += delta;
+            Text = _accum.ToString(); // 'Text' is a built-in label property.
+        }
+    }
+
+Which will show a counter increasing each frame.
+
+Groups
+------
+
+Groups in Godot work like tags you might have come across in other software.
+A node can be added to as many groups as desired. This is a useful feature for
+organizing large scenes. There are two ways to add nodes to groups. The
+first is from the UI, using the Groups button under the Node panel:
+
+.. image:: img/groups_in_nodes.png
+
+And the second way is from code. The following script would add the current
+node to the ``enemies`` group as soon as it appeared in the scene tree.
+
+.. tabs::
+ .. code-tab:: gdscript GDScript
+
+    func _ready():
+        add_to_group("enemies")
+
+ .. code-tab:: csharp
+
+    public override void _Ready()
+    {
+        base._Ready();
+
+        AddToGroup("enemies");
+    }
+
+This way, if the player is discovered sneaking into a secret base,
+all enemies can be notified about its alarm sounding by using
+:ref:`SceneTree.call_group() <class_SceneTree_method_call_group>`:
+
+.. tabs::
+ .. code-tab:: gdscript GDScript
+
+    func _on_discovered(): # This is a purely illustrative function.
+        get_tree().call_group("enemies", "player_was_discovered")
+
+ .. code-tab:: csharp
+
+    public void _OnDiscovered() // This is a purely illustrative function.
+    {
+        GetTree().CallGroup("enemies", "player_was_discovered");
+    }
+
+The above code calls the function ``player_was_discovered`` on every
+member of the group ``enemies``.
+
+It is also possible to get the full list of ``enemies`` nodes by
+calling
+:ref:`SceneTree.get_nodes_in_group() <class_SceneTree_method_get_nodes_in_group>`:
+
+.. tabs::
+ .. code-tab:: gdscript GDScript
+
+    var enemies = get_tree().get_nodes_in_group("enemies")
+
+ .. code-tab:: csharp
+
+    var enemies = GetTree().GetNodesInGroup("enemies");
+
+The :ref:`SceneTree <class_SceneTree>` class provides many useful methods,
+like interacting with scenes, their node hierarchy and groups of nodes.
+It allows you to easily switch scenes or reload them,
+to quit the game or pause and unpause it.
+It even comes with interesting signals.
+So check it out if you have some time!
+
+Notifications
+-------------
+
+Godot has a system of notifications. These are 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 exist. For example,
+you may add an
+:ref:`Object._notification() <class_Object_method__notification>`
+function in your script:
+
+.. tabs::
+ .. code-tab:: gdscript GDScript
+
+    func _notification(what):
+        match what:
+            NOTIFICATION_READY:
+                print("This is the same as overriding _ready()...")
+            NOTIFICATION_PROCESS:
+                print("This is the same as overriding _process()...")
+
+ .. code-tab:: csharp
+
+    public override void _Notification(int what)
+    {
+        base._Notification(what);
+
+        switch (what)
+        {
+            case NotificationReady:
+                GD.Print("This is the same as overriding _Ready()...");
+                break;
+            case NotificationProcess:
+                var delta = GetProcessDeltaTime();
+                GD.Print("This is the same as overriding _Process()...");
+                break;
+        }
+    }
+
+The documentation of each class in the :ref:`Class Reference <toc-class-ref>`
+shows the notifications it can receive. However, in most cases GDScript
+provides simpler overridable functions.
+
+Overridable functions
+---------------------
+
+Such overridable functions, which are described as
+follows, can be applied to nodes:
+
+.. tabs::
+ .. code-tab:: gdscript GDScript
+
+    # When the node enters the Scene Tree, it becomes active
+    # and  this function is called. Children nodes have not entered
+    # the active scene yet. In general, it's better to use _ready()
+    # for most cases.
+    func _enter_tree():
+        pass
+
+    # This function is called after _enter_tree, but it ensures
+    # that all children nodes have also entered the Scene Tree,
+    # and became active.
+    func _ready():
+        pass
+
+    # When the node exits the Scene Tree, this function is called.
+    # Children nodes have all exited the Scene Tree at this point
+    # and all became inactive.
+    func _exit_tree():
+        pass
+
+    # This function is called every frame.
+    func _process(delta):
+        pass
+
+    func _physics_process(delta):
+        # This is called every physics frame.
+        pass
+
+ .. code-tab:: csharp
+
+    public override void _EnterTree()
+    {
+        // When the node enters the Scene Tree, it becomes active
+        // and  this function is called. Children nodes have not entered
+        // the active scene yet. In general, it's better to use _ready()
+        // for most cases.
+        base._EnterTree();
+    }
+
+    public override void _Ready()
+    {
+        // This function is called after _enter_tree, but it ensures
+        // that all children nodes have also entered the Scene Tree,
+        // and became active.
+        base._Ready();
+    }
+
+    public override void _ExitTree()
+    {
+        // When the node exits the Scene Tree, this function is called.
+        // Children nodes have all exited the Scene Tree at this point
+        // and all became inactive.
+        base._ExitTree();
+    }
+
+    public override void _Process(float delta)
+    {
+        // This function is called every frame.
+        base._Process(delta);
+    }
+
+    public override void _PhysicsProcess(float delta)
+    {
+        // This is called every physics frame.
+        base._PhysicsProcess(delta);
+    }
+
+As mentioned before, it's better to use these functions instead of
+the notification system.
+
+Creating nodes
+--------------
+
+To create a node from code, call the ``.new()`` method, like for any
+other class-based datatype. For example:
+
+
+.. tabs::
+ .. code-tab:: gdscript GDScript
+
+    var s
+    func _ready():
+        s = Sprite.new() # Create a new sprite!
+        add_child(s) # Add it as a child of this node.
+
+ .. code-tab:: csharp
+
+    private Sprite _sprite;
+
+    public override void _Ready()
+    {
+        base._Ready();
+
+        _sprite = new Sprite(); // Create a new sprite!
+        AddChild(_sprite); // Add it as a child of this node.
+    }
+
+To delete a node, be it inside or outside the scene, ``free()`` must be
+used:
+
+.. tabs::
+ .. code-tab:: gdscript GDScript
+
+    func _someaction():
+        s.free() # Immediately removes the node from the scene and frees it.
+
+ .. code-tab:: csharp
+
+    public void _SomeAction()
+    {
+        _sprite.Free(); // Immediately removes the node from the scene and frees it.
+    }
+
+When a node is freed, it also frees all its child nodes. Because of
+this, manually deleting nodes is much simpler than it appears. Free
+the base node and everything else in the subtree goes away with it.
+
+A situation might occur where we want to delete a node that
+is currently "blocked", because it is emitting a signal or calling a
+function. This will crash the game. Running Godot
+with the debugger will often catch this case and warn you about it.
+
+The safest way to delete a node is by using
+:ref:`Node.queue_free() <class_Node_method_queue_free>`.
+This erases the node safely during idle.
+
+.. tabs::
+ .. code-tab:: gdscript GDScript
+
+    func _someaction():
+        s.queue_free() # Removes the node from the scene and frees it when it becomes safe to do so.
+
+ .. code-tab:: csharp
+
+    public void _SomeAction()
+    {
+        _sprite.QueueFree(); // Removes the node from the scene and frees it when it becomes safe to do so.
+    }
+
+Instancing scenes
+-----------------
+
+Instancing a scene from code is done in two steps. The
+first one is to load the scene from your hard drive:
+
+.. tabs::
+ .. code-tab:: gdscript GDScript
+
+    var scene = load("res://myscene.tscn") # Will load when the script is instanced.
+
+ .. code-tab:: csharp
+
+    var scene = GD.Load<PackedScene>("res://myscene.tscn"); // Will load when the script is instanced.
+
+
+Preloading it can be more convenient, as it happens at parse
+time (GDScript only):
+
+.. tabs::
+ .. code-tab:: gdscript GDScript
+
+    var scene = preload("res://myscene.tscn") # Will load when parsing the script.
+
+But ``scene`` is not yet a node. It's packed in a
+special resource called :ref:`PackedScene <class_PackedScene>`.
+To create the actual node, the function
+:ref:`PackedScene.instance() <class_PackedScene_method_instance>`
+must be called. This will return the tree of nodes that can be added to
+the active scene:
+
+.. tabs::
+ .. code-tab:: gdscript GDScript
+
+    var node = scene.instance()
+    add_child(node)
+
+ .. code-tab:: csharp
+
+    var node = scene.Instance();
+    AddChild(node);
+
+The advantage of this two-step process is that a packed scene may be
+kept loaded and ready to use so that you can create as many
+instances as desired. This is especially useful to quickly instance
+several enemies, bullets, and other entities in the active scene.
+
+.. _doc_scripting_continued_class_name:
+
+Register scripts as classes
+---------------------------
+
+Godot has a "Script Class" feature to register individual scripts with the
+Editor. By default, you can only access unnamed scripts by loading the file
+directly.
+
+You can name a script and register it as a type in the editor with the
+``class_name`` keyword followed by the class's name. You may add a comma and an
+optional path to an image to use as an icon. You will then find your new type in
+the Node or Resource creation dialog.
+
+.. tabs::
+ .. code-tab:: gdscript GDScript
+
+    extends Node
+
+    # Declare the class name here
+    class_name ScriptName, "res://path/to/optional/icon.svg"
+
+    func _ready():
+        var this = ScriptName           # reference to the script
+        var cppNode = MyCppNode.new()   # new instance of a class named MyCppNode
+
+        cppNode.queue_free()
+
+.. image:: img/script_class_nativescript_example.png
+
+
+.. warning:: In Godot 3.1:
+
+            - Only GDScript and NativeScript, i.e., C++ and other GDNative-powered languages, can register scripts.
+            - Only GDScript creates global variables for each named script.

getting_started/step_by_step/scripting_languages.rst

@@ -0,0 +1,181 @@
+.. Intention: only introduce what a script does in general and options for
+   scripting languages.
+
+.. _doc_scripting:
+
+Scripting languages
+===================
+
+This lesson will give you an overview of the available scripting languages in
+Godot. You will learn the pros and cons of each option. In the next part, you
+will write your first script using GDScript.
+
+**Scripts attach to a node and extend its behavior**. This means that scripts
+inherit all functions and properties of the node they attach to.
+
+For example, take a game where a Camera2D node follows a ship. The Camera2D node
+follows its parent by default. Imagine you want it to shake when the player
+takes damage. As this feature is not built-into Godot, you would attach a script
+to it and code the camera shake.
+
+.. image:: img/scripting_camera_shake.gif
+
+Available scripting languages
+-----------------------------
+
+Godot offers **five gameplay programming languages**: GDScript, C#,
+VisualScript, and C++ and C via its GDNative technology. There are more
+:ref:`community-supported languages <doc_what_is_gdnative_third_party_bindings>`,
+but these are the official ones.
+
+You can use multiple languages in a single project. For instance, in a team, you
+could code gameplay logic in GDScript as it's fast to write, let level designers
+script quests in the graphical language VisualScript, and use C# or C++ to
+implement complex algorithms and maximize their performance. Or you can write
+everything in GDScript or C#. It's your call.
+
+We provide this flexibility to answer the needs of different game projects and
+developers.
+
+Which language should I use?
+----------------------------
+
+If you're a beginner, we recommend to **start with GDScript**. We made this
+language specifically for Godot and the needs of game developers. It has a
+lightweight and straightforward syntax and provides the tightest integration
+with Godot.
+
+.. image:: img/scripting_gdscript.png
+
+For C#, you will need an external code editor like
+`VSCode <https://code.visualstudio.com/>`_ or Visual Studio. While C# support is
+now mature, you will also find fewer learning resources for it compared to
+GDScript. That's why we recommend C# mainly to users who already have experience
+with the language.
+
+Let's look at each language's features, as well as its pros and cons.
+
+GDScript
+~~~~~~~~
+
+:ref:`GDScript<doc_gdscript>` is an
+`object-oriented <https://en.wikipedia.org/wiki/Object-oriented_programming>`_ and
+`imperative <https://en.wikipedia.org/wiki/Imperative_programming>`_
+programming language built for Godot. It's made by and for game developers
+to save you time coding games. Its features include:
+
+- A simple syntax that leads to short files.
+- Blazing fast compilation and loading times.
+- Tight editor integration, with code completion for nodes, signals, and more
+  information from the scene it's attached to.
+- Built-in vector and transform types, making it efficient for heavy use of
+  linear algebra, a must for games.
+- Supports multiple threads as efficiently as statically typed languages. This
+  is one of the features we couldn't provide easily with a third-party language
+  like Lua or Python.
+- No `garbage collection
+  <https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)>`_, as
+  this feature eventually gets in the way when creating games. The engine counts
+  references and manages the memory for you in most cases by default, but you
+  can also control memory if you need to.
+- `Gradual typing <https://en.wikipedia.org/wiki/Gradual_typing>`_. Variables
+  have dynamic types by default, but you also can use type hints for strong type
+  checks.
+
+GDScript looks like Python as you structure your code blocks using indentations,
+but it doesn't work the same way in practice. It's inspired by multiple
+languages, including Squirrel, Lua, and Python.
+
+.. note::
+
+    Why don't we use Python or Lua directly?
+
+    Years ago, Godot used Python, then Lua. Both languages' integration took a
+    lot of work and had severe limitations. For example, threading support was a
+    big challenge with Python.
+
+    Developing a dedicated language doesn't take us more work and we can tailor
+    it to game developers' needs. We're now working on performance optimizations
+    and features that would've been difficult to offer with third-party
+    languages.
+
+.NET / C#
+~~~~~~~~~
+
+As Microsoft's `C#
+<https://en.wikipedia.org/wiki/C_Sharp_(programming_language)>`_ is a favorite
+amongst game developers, we officially support it. C# is a mature and flexible
+language with tons of libraries written for it. We could add support for it
+thanks to a generous donation from Microsoft.
+
+.. image:: img/scripting_csharp.png
+
+C# offers a good tradeoff between performance and ease of use, although you
+should be aware of its garbage collector.
+
+.. note:: You must use the Mono edition of the Godot editor to script in C#. You
+          can download it on the Godot website's `download
+          <https://godotengine.org/download/>`_ page.
+
+Since Godot uses the `Mono <https://mono-project.com>`_ .NET runtime, in theory,
+you can use any third-party .NET library or framework in Godot, as well as any
+Common Language Infrastructure-compliant programming language, such as F#, Boo,
+or ClojureCLR. However, C# is the only officially supported .NET option.
+
+.. note:: GDScript code itself doesn't execute as fast as compiled C# or C++.
+          However, most script code calls functions written with fast algorithms
+          in C++ code inside the engine. In many cases, writing gameplay logic
+          in GDScript, C#, or C++ won't have a significant impact on
+          performance.
+
+VisualScript
+~~~~~~~~~~~~
+
+:ref:`Visual Scripting<doc_what_is_visual_script>` is a graph-based visual
+programming language where you connect blocks. It can be a great tool for
+non-programmers like game designers and artists.
+
+.. image:: img/scripting_visualscript.png
+
+You can use other languages to create custom blocks that are specific to your
+game. For example, to script AIs, quests, or dialogues. That's where the
+strength of VisualScript lies.
+
+While it provides all the basic building blocks you need to code complete games,
+we do not recommend to use VisualScript this way. Programming everything with it
+is slow compared to using other programming languages.
+
+.. seealso::
+
+    For more information, see
+    :ref:`Getting started with VisualScript <doc_getting_started_visual_script>`.
+
+C and C++ via GDNative
+~~~~~~~~~~~~~~~~~~~~~~
+
+GDNative allows you to write game code in C or C++ without needing to recompile
+or even restart Godot.
+
+.. image:: img/scripting_cpp.png
+
+You can use any version of the language or mix compiler brands and versions for
+the generated shared libraries, thanks to our use of an internal C API Bridge.
+
+This language is the best choice for performance. You don't need to use it
+throughout an entire game, as you can write other parts in GDScript, C#, or
+VisualScript.
+
+When working with GDNative, the available types, functions, and properties
+closely resemble Godot's actual C++ API.
+
+Summary
+-------
+
+Scripts are files containing code that you attach to a node to extend its
+functionality.
+
+Godot supports five official scripting languages, offering you flexibility
+between performance and ease of use.
+
+You can mix languages, for instance, to implement demanding algorithms with C or
+C++ and write most of the game logic with GDScript or C#.

getting_started/step_by_step/your_first_script.rst

@@ -0,0 +1,5 @@
+.. _doc_your_first_script:
+
+Creating your first script
+--------------------------
+