Remove outdated tutorials in the 4.0 documentation

- Step-by-step -> UI tutorials
- Step-by-step -> splash screen tutorial
- 3D -> FPS tutorial

Closes #1412
Closes #1599
Closes #1601
Closes #1620
Closes #1667
Closes #1670
Closes #2346
Closes #2574
Closes #2875
Closes #3151
Closes #3217
Closes #3348
Closes #3751
Closes #4011

<!--
**Note:** Pull Requests should be made against the `master` by default.

Only make Pull Requests against other branches (e.g. `2.1`) if your changes only apply to that specific version of Godot.

All pull requests for Godot 3 should usually go into `master`.
-->

classes/class_animationplayer.rst

@@ -25,8 +25,6 @@ Updating the target properties of animations occurs at process time.
 Tutorials
 ---------
 
-- :doc:`../getting_started/step_by_step/animations`
-
 - :doc:`../tutorials/animation/index`
 
 Properties

getting_started/step_by_step/animations.rst

@@ -1,86 +0,0 @@
-.. _doc_animations:
-
-Animations
-==========
-
-Introduction
-------------
-
-Godot's animation system is extremely powerful and flexible.
-
-To begin, let's use the scene from the previous tutorial (:ref:`doc_splash_screen`).
-The goal is to add a "fade-in" animation to the splash image. Here's a copy
-just in case: :download:`robisplash.zip <files/robisplash.zip>`.
-
-Add an animation player
------------------------
-
-First of all, add an :ref:`AnimationPlayer <class_AnimationPlayer>`
-node to the scene as a child of "background" (the root node):
-
-.. image:: img/robisplash_anim_inspector.png
-
-When a node of this type is selected, the animation editor panel will
-appear:
-
-.. image:: img/robisplash_anim_editor.png
-
-The animation editor panel stays visible until manually hidden.
-
-Creating the animation
-----------------------
-
-It's time to create a new animation! Press the Animation button then select
-new from the menu. Name the animation "intro" when the dialog appears.
-
-.. image:: img/robisplash_anim_button.png
-
-.. image:: img/robisplash_anim_new.png
-
-Now that we have an animation, the property editor enters
-"animation editing" mode. In this mode, a key icon appears next to
-every property of the property editor. In Godot, any property of an object
-can be animated:
-
-.. image:: img/robisplash_anim_property_keys.png
-
-Editing the animation
----------------------
-
-The logo will appear from the top of the screen.
-
-With the animation editor panel open, select the "logo" node and set the
-"Rect / Position" property to ``(118, -400)`` and press the key button next
-to the property to add a keyframe:
-
-.. image:: img/robisplash_anim_logo_inspector_key.png
-
-When the dialog appears, confirm that you are creating a new track.
-
-The keyframe will be added in the animation player editor:
-
-.. image:: img/robisplash_anim_editor_keyframe.png
-
-Move the editor cursor forward in time by clicking here:
-
-.. image:: img/robisplash_anim_editor_track_cursor.png
-
-Change the logo position to ``(118, 0)`` and add a keyframe again. With two
-keyframes with different values, the animation happens.
-
-.. image:: img/robisplash_anim_editor_keyframe_2.png
-
-Pressing "Play selected animation from start" button on the animation panel (or :kbd:`Shift + D` on keyboard)
-will make the logo descend.
-
-.. image:: img/robisplash_anim_editor_play_start.png
-
-Click the "Autoplay on Load" button to set the animation to start automatically
-when the scene starts.
-
-.. image:: img/robisplash_anim_editor_autoplay.png
-
-And finally, when running the scene, the animation should look like
-this:
-
-.. image:: img/out.gif

getting_started/step_by_step/index.rst

@@ -15,12 +15,6 @@ Step by step
    your_first_game
    exporting
    godot_design_philosophy
-   ui_introduction_to_the_ui_system
-   ui_main_menu
-   ui_game_user_interface
-   ui_code_a_life_bar
-   splash_screen
-   animations
    resources
    filesystem
    scene_tree

getting_started/step_by_step/splash_screen.rst

@@ -1,45 +0,0 @@
-.. _doc_splash_screen:
-
-Splash screen
-=============
-
-Tutorial
---------
-
-This is a simple tutorial to establish the basic idea of how the GUI
-subsystem works. The goal is to create a simple, static
-splash screen.
-
-.. image:: img/robisplash_result.png
-
-Following is a file with the assets that will be used. The extracted files can
-be placed directly in your project folder and Godot will import them automatically.
-
-:download:`robisplash_assets.zip <files/robisplash_assets.zip>`.
-
-Setting up
-----------
-
-Set the display resolution to 800x450 in Project Settings, and set up a new scene like this:
-
-.. image:: img/robisplash_scene.png
-
-The nodes "background" and "logo" are of :ref:`TextureRect <class_TextureRect>`
-type. To display an image, drag the corresponding asset to the texture property.
-
-.. image:: img/robisplash_background_inspector.png
-
-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/robisplash_button_inspector.png
-
-Finally, the node "copyright" is a :ref:`Label <class_Label>`.
-
-Your final scene should look something like this.
-
-.. image:: img/robisplash_editor.png
-
-Go ahead and run the project.  If you're satisfied with the results, continue to
-the next tutorial.

getting_started/step_by_step/ui_code_a_life_bar.rst

@@ -1,677 +0,0 @@
-.. _doc_ui_code_a_life_bar:
-
-Control the game's UI with code
-===============================
-
-Intro
------
-
-In this tutorial, you will connect a character to a life bar and animate
-the health loss.
-
-.. figure:: img/lifebar_tutorial_final_result.gif
-
-   Here's what you'll create: the bar and the counter animate when
-   the character takes a hit. They fade when it dies.
-
-
-You will learn:
-
--  How to **connect** a character to a GUI with signals
--  How to **control** a GUI with GDscript
--  How to **animate** a life bar with the :ref:`Tween <class_Tween>` node
-
-
-If you want to learn how to set up the interface instead, check out the
-step-by-step UI tutorials:
-
--  :doc:`ui_main_menu`
--  :doc:`ui_game_user_interface`
-
-
-When you code a game, you want to build the core gameplay first: the
-main mechanics, player input, win and loss conditions. The UI comes a
-bit later. You want to keep all the elements that make up your project
-separate if possible. Each character should be in its own scene, with
-its own scripts, and so should the UI elements. This prevents bugs,
-keeps your project manageable, and allows different team members to work
-on different parts of the game.
-
-Once the core gameplay and the UI are ready, you'll need to connect them
-somehow. In our example, we have the Enemy who attacks the Player at
-constant time intervals. We want the life bar to update when the Player
-takes damage.
-
-To do this, we will use **signals**.
-
-.. note::
-
-    Signals are Godot's version of the Observer pattern. They allow us to send out some message. Other nodes can connect to the object that **emits** the signal and receive the information. It's a powerful tool we use a lot for User Interface and achievement systems. You don't want to use them everywhere, though. Connecting two nodes adds some coupling between them. When there's a lot of connections, they become hard to manage.
-    For more information, check out the `signals video tutorial <https://youtu.be/l0BkQxF7X3E>`_ on GDquest.
-
-Download and explore the start project
---------------------------------------
-
-Download the Godot project: :download:`ui_code_life_bar.zip <files/ui_code_life_bar.zip>`. It contains all the assets and scripts you
-need to get started. Extract the .zip archive to get two folders: `start` and `end`.
-
-Load the ``start`` project in Godot. In the ``FileSystem`` dock,
-double click on LevelMockup.tscn to open it. It's an RPG game's mockup
-where 2 characters face each other. The pink enemy attacks and damages
-the green square at regular time intervals, until its death. Feel free
-to try out the game: the basic combat mechanics already work. But as the
-character isn't connected to the life bar, the ``GUI`` doesn't do
-anything.
-
-.. note::
-
-    This is typical of how you'd code a game: you implement the core gameplay first, handle the player's death, and only then you'll add the interface. That's because the UI listens to what's happening in the game. So it can't work if other systems aren't in place yet.
-    If you design the UI before you prototype and test the gameplay, chances are it won't work well and you'll have to re-create it from scratch.
-
-The scene contains a background sprite, a GUI, and two characters.
-
-.. figure:: img/lifebar_tutorial_life_bar_step_tut_LevelMockup_scene_tree.png
-
-   The scene tree, with the GUI scene set to display its children
-
-The GUI scene encapsulates all of the game's Graphical User Interface. It comes with
-a barebones script where we get the path to nodes that exist inside the
-scene:
-
-.. tabs::
- .. code-tab:: gdscript GDScript
-
-    onready var number_label = $Bars/LifeBar/Count/Background/Number
-    onready var bar = $Bars/LifeBar/TextureProgress
-    onready var tween = $Tween
-
- .. code-tab:: csharp
-
-    public class Gui : MarginContainer
-    {
-        private Tween _tween;
-        private Label _numberLabel;
-        private TextureProgress _bar;
-
-        public override void _Ready()
-        {
-            // C# doesn't have an onready feature, this works just the same.
-            _bar = (TextureProgress) GetNode("Bars/LifeBar/TextureProgress");
-            _tween = (Tween) GetNode("Tween");
-            _numberLabel = (Label) GetNode("Bars/LifeBar/Count/Background/Number");
-        }
-    }
-
--  ``number_label`` displays a life count as a number. It's a ``Label``
-   node
--  ``bar`` is the life bar itself. It's a ``TextureProgress`` node
--  ``tween`` is a component-style node that can animate and control any
-   value or method from any other node
-
-.. note::
-
-    The project uses a simple organization that works for game jams and tiny games.
-
-    At the root of the project, in the `res://` folder, you will find the `LevelMockup`. That's the main game scene and the one we will work with. All the components that make up the game are in the `scenes/` folder. The `assets/` folder contains the game sprites and the font for the HP counter. In the `scripts/` folder you will find the enemy, the player, and the GUI controller scripts.
-
-    Click the edit scene icon to the right of the node in the scene tree to open the scene in the editor. You'll see the LifeBar and EnergyBar are sub-scenes themselves.
-
-.. figure:: img/lifebar_tutorial_Player_with_editable_children_on.png
-
-       The scene tree, with the Player scene set to display its children
-
-Set up the Lifebar with the Player's max\_health
-------------------------------------------------
-
-We have to tell the GUI somehow what the player's current health is, to
-update the lifebar's texture, and to display the remaining health in the
-HP counter in the top left corner of the screen. To do this we send the
-player's health to the GUI every time they take damage. The GUI will then
-update the ``Lifebar`` and ``Number`` nodes with this value.
-
-We could stop here to display the number, but we need to initialize the
-bar's ``max_value`` for it to update in the right proportions. The first
-step is thus to tell the ``GUI`` what the green character's
-``max_health`` is.
-
-.. tip::
-
-    The bar, a `TextureProgress`, has a `max_value` of `100` by default. If you don't need to display the character's health with a number, you don't need to change its `max_value` property. You send a percentage from the `Player` to the `GUI` instead:  `health / max_health * 100`.
-
-.. figure:: img/lifebar_tutorial_TextureProgress_default_max_value.png
-
-Click the script icon to the right of the ``GUI`` in the Scene dock to
-open its script. In the ``_ready`` function, we're going to store the
-``Player``'s ``max_health`` in a new variable and use it to set the
-``bar``'s ``max_value``:
-
-.. tabs::
- .. code-tab:: gdscript GDScript
-
-    func _ready():
-        var player_max_health = $"../Characters/Player".max_health
-        bar.max_value = player_max_health
-
- .. code-tab:: csharp
-
-    public override void _Ready()
-    {
-        // Add this below _bar, _tween, and _numberLabel.
-        var player = (Player) GetNode("../Characters/Player");
-        _bar.MaxValue = player.MaxHealth;
-    }
-
-Let's break it down. ``$"../Characters/Player"`` is a shorthand that
-goes one node up in the scene tree, and retrieves the
-``Characters/Player`` node from there. It gives us access to the node.
-The second part of the statement, ``.max_health``, accesses the
-``max_health`` on the Player node.
-
-The second line assigns this value to ``bar.max_value``. You could
-combine the two lines into one, but we'll need to use
-``player_max_health`` again later in the tutorial.
-
-``Player.gd`` sets the ``health`` to ``max_health`` at the start of the
-game, so we could work with this. Why do we still use ``max_health``?
-There are two reasons:
-
-We don't have the guarantee that ``health`` will always equal
-``max_health``: a future version of the game may load a level where
-the player already lost some health.
-
-.. note::
-
-    When you open a scene in the game, Godot creates nodes one by one, following the order in your Scene dock, from top to bottom. `GUI` and `Player` are not part of the same node branch. To make sure they both exist when we access each other, we have to use the `_ready` function. Godot calls `_ready` right after it loaded all nodes, before the game starts. It's the perfect function to set everything up and prepare the game session.
-    Learn more about _ready: :doc:`scripting_continued`
-
-Update health with a signal when the player takes a hit
--------------------------------------------------------
-
-Our GUI is ready to receive the ``health`` value updates from the
-``Player``. To achieve this we're going to use **signals**.
-
-.. note::
-
-    There are many useful built-in signals like `enter_tree` and `exit_tree`, that all nodes emit when they are respectively created and destroyed. You can also create your own using the `signal` keyword. On the `Player` node, you'll find two signals we created for you: `died` and `health_changed`.
-
-Why don't we directly get the ``Player`` node in the ``_process``
-function and look at the health value? Accessing nodes this way creates
-tight coupling between them. If you did it sparingly it may work. As
-your game grows bigger, you may have many more connections. If you get
-nodes this way it gets complex quickly. Not only that: you
-need to listen to the state change constantly in the ``_process``
-function. This check happens 60 times a second and you'll likely break
-the game because of the order in which the code runs.
-
-On a given frame you may look at another node's property *before* it was
-updated: you get a value from the last frame. This leads to obscure
-bugs that are hard to fix. On the other hand, a signal is emitted right
-after a change happened. It **guarantees** you're getting a fresh piece
-of information. And you will update the state of your connected node
-*right after* the change happened.
-
-.. note::
-
-    The Observer pattern, that signals derive from, still adds a bit of coupling between node branches. But it's generally lighter and more secure than accessing nodes directly to communicate between two separate classes. It can be okay for a parent node to get values from its children. But you'll want to favor signals if you're working with two separate branches.
-    Read Game Programming Patterns for more information on the `Observer pattern <https://gameprogrammingpatterns.com/observer.html>`_.
-    The `full book <https://gameprogrammingpatterns.com/contents.html>`_ is available online for free.
-
-With this in mind, let's connect the ``GUI`` to the ``Player``. Click on
-the ``Player`` node in the scene dock to select it. Head down to the
-Inspector and click on the Node tab. This is the place to connect nodes
-to listen to the one you selected.
-
-The first section lists custom signals defined in ``Player.gd``:
-
--  ``died`` is emitted when the character died. We will use it in a
-   moment to hide the UI.
--  ``health_changed`` is emitted when the character got hit.
-
-.. figure:: img/lifebar_tutorial_health_changed_signal.png
-
-   We're connecting to the health\_changed signal
-
-Select ``health_changed`` and click on the Connect button in the bottom
-right corner to open the Connect Signal window. On the left side you can
-pick the node that will listen to this signal. Select the ``GUI`` node.
-The right side of the screen lets you pack optional values with the
-signal. We already took care of it in ``Player.gd``. In general I
-recommend not to add too many arguments using this window as they're
-less convenient than doing it from the code.
-
-.. figure:: img/lifebar_tutorial_connect_signal_window_health_changed.png
-
-   The Connect Signal window with the GUI node selected
-
-.. tip::
-
-    You can optionally connect nodes from the code. However doing it from the editor has two advantages:
-
-    1. Godot can write new callback functions for you in the connected script
-    2. An emitter icon appears next to the node that emits the signal in the Scene dock
-
-At the bottom of the window you will find the path to the node you
-selected. We're interested in the second row called "Method in Node".
-This is the method on the ``GUI`` node that gets called when the signal
-is emitted. This method receives the values sent with the signal and
-lets you process them. If you look to the right, there is a "Make
-Function" radio button that is on by default. Click the connect button
-at the bottom of the window. Godot creates the method inside the ``GUI``
-node. The script editor opens with the cursor inside a new
-``_on_Player_health_changed`` function.
-
-.. note::
-
-   When you connect nodes from the editor, Godot generates a
-   method name with the following pattern: ``_on_EmitterName_signal_name``.
-   If you wrote the method already, the "Make Function" option will keep
-   it. You may replace the name with anything you'd like.
-
-.. figure:: img/lifebar_tutorial_godot_generates_signal_callback.png
-
-   Godot writes the callback method for you and takes you to it
-
-Inside the parentheses after the function name, add a ``player_health``
-argument. When the player emits the ``health_changed`` signal, it will send
-its current ``health`` alongside it. Your code should look like:
-
-.. tabs::
- .. code-tab:: gdscript GDScript
-
-    func _on_Player_health_changed(player_health):
-        pass
-
- .. code-tab:: csharp
-
-    public void OnPlayerHealthChanged(int playerHealth)
-    {
-    }
-
-.. note::
-
-    The engine does not convert PascalCase to snake_case, for C# examples we'll be using
-    PascalCase for method names & camelCase for method parameters, which follows the official `C#
-    naming conventions. <https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions>`_
-
-
-.. figure:: img/lifebar_tutorial_player_gd_emits_health_changed_code.png
-
-   In Player.gd, when the Player emits the health\_changed signal, it also
-   sends its health value
-
-Inside ``_on_Player_health_changed``, let's call a second function called
-``update_health`` and pass it the ``player_health`` variable.
-
-.. note::
-
-    We could directly update the health value on `LifeBar` and `Number`. There are two reasons to use this method instead:
-
-    1. The name makes it clear for our future selves and teammates that when the player took damage, we update the health count on the GUI
-    2. We will reuse this method a bit later
-
-Create a new ``update_health`` method below ``_on_Player_health_changed``.
-It takes a new\_value as its only argument:
-
-.. tabs::
- .. code-tab:: gdscript GDScript
-
-    func update_health(new_value):
-        pass
-
- .. code-tab:: csharp
-
-    public void UpdateHealth(int health)
-    {
-    }
-
-This method needs to:
-
--  set the ``Number`` node's ``text`` to ``new_value`` converted to a
-   string
--  set the ``TextureProgress``'s ``value`` to ``new_value``
-
-.. tabs::
- .. code-tab:: gdscript GDScript
-
-    func update_health(new_value):
-        number_label.text = str(new_value)
-        bar.value = new_value
-
- .. code-tab:: csharp
-
-    public void UpdateHealth(int health)
-    {
-        _numberLabel.Text = health.ToString();
-        _bar.Value = health;
-    }
-
-.. tip::
-
-    ``str`` is a built-in function that converts about any value to
-    text. ``Number``'s ``text`` property requires a string, so we can't
-    assign it to ``new_value`` directly
-
-Also call ``update_health`` at the end of the ``_ready`` function to
-initialize the ``Number`` node's ``text`` with the right value at the
-start of the game. Press :kbd:`F5` to test the game: the life bar updates with
-every attack!
-
-.. figure:: img/lifebar_tutorial_LifeBar_health_update_no_anim.gif
-
-   Both the Number node and the TextureProgress update when the Player
-   takes a hit
-
-Animate the loss of life with the Tween node
---------------------------------------------
-
-Our interface is functional, but it could use some animation. That's a
-good opportunity to introduce the ``Tween`` node, an essential tool to
-animate properties. ``Tween`` animates anything you'd like from a start
-to an end state over a certain duration. For example, it can animate the
-health on the ``TextureProgress`` from its current level to the
-``Player``'s new ``health`` when the character takes damage.
-
-The ``GUI`` scene already contains a ``Tween`` child node stored in the
-``tween`` variable. Let's now use it. We have to make some changes to
-``update_health``.
-
-We will use the ``Tween`` node's ``interpolate_property`` method. It
-takes seven arguments:
-
-1. A reference to the node who owns the property to animate
-2. The property's identifier as a string
-3. The starting value
-4. The end value
-5. The animation's duration in seconds
-6. The type of the transition
-7. The easing to use in combination with the equation.
-
-The last two arguments combined correspond to an easing
-equation. This controls how the value evolves from the start to
-the end point.
-
-Click the script icon next to the ``GUI`` node to open it again. The
-``Number`` node needs text to update itself, and the ``Bar`` needs a
-float or an integer. We can use ``interpolate_property`` to animate a
-number, but not to animate text directly. We're going to use it to
-animate a new ``GUI`` variable named ``animated_health``.
-
-At the top of the script, define a new variable, name it
-``animated_health``, and set its value to 0. Navigate back to the ``update_health`` method and
-clear its content. Let's animate the ``animated_health`` value. Call the
-``Tween`` node's ``interpolate_property`` method:
-
-.. tabs::
- .. code-tab:: gdscript GDScript
-
-    func update_health(new_value):
-        tween.interpolate_property(self, "animated_health", animated_health, new_value, 0.6)
-
- .. code-tab:: csharp
-
-    // Add this to the top of your class.
-    private float _animatedHealth = 0;
-
-    public void UpdateHealth(int health)
-    {
-        _tween.InterpolateProperty(this, "_animatedHealth", _animatedHealth, health, 0.6f, Tween.TransitionType.Linear,
-            Tween.EaseType.In);
-    }
-
-Let's break down the call:
-
-::
-
-    tween.interpolate_property(self, "animated_health", ...
-
-We target ``animated_health`` on ``self``, that is to say the ``GUI``
-node. ``Tween``'s interpolate\_property takes the property's name as a
-string. That's why we write it as ``"animated_health"``.
-
-::
-
-    ... _health", animated_health, new_value, 0.6 ...
-
-The starting point is the current value the bar's at. We still have to
-code this part, but it's going to be ``animated_health``. The end point
-of the animation is the ``Player``'s ``health`` after the
-``health_changed``: that's ``new_value``. And ``0.6`` is the animation's
-duration in seconds.
-
-The animation will not play until we activated the ``Tween`` node with
-``tween.start()``. We only have to do this once if the node is not
-active. Add this code after the last line:
-
-.. tabs::
- .. code-tab:: gdscript GDScript
-
-        if not tween.is_active():
-            tween.start()
-
- .. code-tab:: csharp
-
-        if (!_tween.IsActive())
-        {
-            _tween.Start();
-        }
-
-.. note::
-
-    Although we could animate the `health` property on the `Player`, we shouldn't. Characters should lose life instantly when they get hit. It makes it a lot easier to manage their state, like to know when one died. You always want to store animations in a separate data container or node. The `tween` node is perfect for code-controlled animations. For hand-made animations, check out `AnimationPlayer`.
-
-Assign the animated\_health to the LifeBar
-------------------------------------------
-
-Now the ``animated_health`` variable animates but we don't update the
-actual ``Bar`` and ``Number`` nodes anymore. Let's fix this.
-
-So far, the update\_health method looks like this:
-
-.. tabs::
- .. code-tab:: gdscript GDScript
-
-    func update_health(new_value):
-        tween.interpolate_property(self, "animated_health", animated_health, new_value, 0.6)
-        if not tween.is_active():
-            tween.start()
-
- .. code-tab:: csharp
-
-    public void UpdateHealth(int health)
-    {
-        _tween.InterpolateProperty(this, "_animatedHealth", _animatedHealth, health, 0.6f, Tween.TransitionType.Linear,
-            Tween.EaseType.In);
-
-        if(!_tween.IsActive())
-        {
-            _tween.Start();
-        }
-    }
-
-
-In this specific case, because ``number_label`` takes text, we need to
-use the ``_process`` method to animate it. Let's now update the
-``Number`` and ``TextureProgress`` nodes like before, inside of
-``_process``:
-
-.. tabs::
- .. code-tab:: gdscript GDScript
-
-    func _process(delta):
-        number_label.text = str(animated_health)
-        bar.value = animated_health
-
- .. code-tab:: csharp
-
-    public override void _Process(float delta)
-    {
-        _numberLabel.Text = _animatedHealth.ToString();
-        _bar.Value = _animatedHealth;
-    }
-
-.. note::
-
-    `number_label` and `bar` are variables that store references to the `Number` and `TextureProgress` nodes.
-
-Play the game to see the bar animate smoothly. But the text displays
-decimal number and looks like a mess. And considering the style of the
-game, it'd be nice for the life bar to animate in a choppier fashion.
-
-.. figure:: img/lifebar_tutorial_number_animation_messed_up.gif
-
-   The animation is smooth, but the number is broken
-
-We can fix both problems by rounding out ``animated_health``. Use a
-local variable named ``round_value`` to store the rounded
-``animated_health``. Then assign it to ``number_label.text`` and
-``bar.value``:
-
-.. tabs::
- .. code-tab:: gdscript GDScript
-
-    func _process(delta):
-        var round_value = round(animated_health)
-        number_label.text = str(round_value)
-        bar.value = round_value
-
- .. code-tab:: csharp
-
-    public override void _Process(float delta)
-    {
-        var roundValue = Mathf.Round(_animatedHealth);
-        _numberLabel.Text = roundValue.ToString();
-        _bar.Value = roundValue;
-    }
-
-Try the game again to see a nice blocky animation.
-
-.. figure:: img/lifebar_tutorial_number_animation_working.gif
-
-   By rounding out animated\_health, we kill two birds with one stone
-
-.. tip::
-
-    Every time the player takes a hit, the ``GUI`` calls
-    ``_on_Player_health_changed``, which in turn calls ``update_health``. This
-    updates the animation and the ``number_label`` and ``bar`` follow in
-    ``_process``. The animated life bar that shows the health going down gradually
-    is a trick. It makes the GUI feel alive. If the ``Player`` takes 3 damage,
-    it happens in an instant.
-
-Fade the bar when the Player dies
----------------------------------
-
-When the green character dies, it plays a death animation and fades out.
-At this point, we shouldn't show the interface anymore. Let's fade the
-bar as well when the character died. We will reuse the same ``Tween``
-node as it manages multiple animations in parallel for us.
-
-First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal
-to know when it died. Press :kbd:`F1` to jump back to the 2D
-Workspace. Select the ``Player`` node in the Scene dock and click on the
-Node tab next to the Inspector.
-
-Find the ``died`` signal, select it, and click the Connect button.
-
-.. figure:: img/lifebar_tutorial_player_died_signal_enemy_connected.png
-
-   The signal should already have the Enemy connected to it
-
-In the Connecting Signal window, connect to the ``GUI`` node again. The
-Path to Node should be ``../../GUI`` and the Method in Node should show
-``_on_Player_died``. Leave the Make Function option on and click Connect
-at the bottom of the window. This will take you to the ``GUI.gd`` file
-in the Script Workspace.
-
-.. figure:: img/lifebar_tutorial_player_died_connecting_signal_window.png
-
-   You should get these values in the Connecting Signal window
-
-.. note::
-
-    You should see a pattern by now: every time the GUI needs a new piece of information, we emit a new signal. Use them wisely: the more connections you add, the harder they are to track.
-
-To animate a fade on a UI element, we have to use its ``modulate``
-property. ``modulate`` is a ``Color`` that multiplies the colors of our
-textures.
-
-.. note::
-
-    `modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit from it. It lets you toggle the visibility of the node, assign a shader to it, and modify it using a color with `modulate`.
-
-``modulate`` takes a ``Color`` value with 4 channels: red, green, blue
-and alpha. If we darken any of the first three channels it darkens the
-interface. If we lower the alpha channel, our interface fades out.
-
-We're going to tween between two color values: from a white with an
-alpha of ``1``, that is to say at full opacity, to a pure white with an
-alpha value of ``0``, completely transparent. Let's add two variables at
-the top of the ``_on_Player_died`` method and name them ``start_color``
-and ``end_color``. Use the ``Color()`` constructor to build two
-``Color`` values.
-
-.. tabs::
- .. code-tab:: gdscript GDScript
-
-    func _on_Player_died():
-        var start_color = Color(1.0, 1.0, 1.0, 1.0)
-        var end_color = Color(1.0, 1.0, 1.0, 0.0)
-
- .. code-tab:: csharp
-
-    public void OnPlayerDied()
-    {
-        var startColor = new Color(1.0f, 1.0f, 1.0f);
-        var endColor = new Color(1.0f, 1.0f, 1.0f, 0.0f);
-    }
-
-``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument,
-respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``,
-is the alpha channel.
-
-We then have to call the ``interpolate_property`` method of the
-``Tween`` node again:
-
-.. tabs::
- .. code-tab:: gdscript GDScript
-
-    tween.interpolate_property(self, "modulate", start_color, end_color, 1.0)
-
- .. code-tab:: csharp
-
-    _tween.InterpolateProperty(this, "modulate", startColor, endColor, 1.0f, Tween.TransitionType.Linear,
-      Tween.EaseType.In);
-
-This time, we change the ``modulate`` property and have it animate from
-``start_color`` to the ``end_color``. The duration is of one second,
-with a linear transition. Here's the complete ``_on_Player_died``
-method:
-
-.. tabs::
- .. code-tab:: gdscript GDScript
-
-    func _on_Player_died():
-        var start_color = Color(1.0, 1.0, 1.0, 1.0)
-        var end_color = Color(1.0, 1.0, 1.0, 0.0)
-        tween.interpolate_property(self, "modulate", start_color, end_color, 1.0)
-
- .. code-tab:: csharp
-
-    public void OnPlayerDied()
-    {
-        var startColor = new Color(1.0f, 1.0f, 1.0f);
-        var endColor = new Color(1.0f, 1.0f, 1.0f, 0.0f);
-
-        _tween.InterpolateProperty(this, "modulate", startColor, endColor, 1.0f, Tween.TransitionType.Linear,
-            Tween.EaseType.In);
-    }
-
-And that is it. You may now play the game to see the final result!
-
-.. figure:: img/lifebar_tutorial_final_result.gif
-
-   The final result. Congratulations for getting there!
-
-.. note::
-
-    Using the exact same techniques, you can change the color of the bar when the Player gets poisoned, turn the bar red when its health drops low, shake the UI when they take a critical hit... the principle is the same: emit a signal to forward the information from the `Player` to the `GUI` and let the `GUI` process it.

getting_started/step_by_step/ui_game_user_interface.rst

@@ -1,633 +0,0 @@
-.. _doc_ui_game_user_interface:
-
-Design the GUI
-==============
-
-Now that you've nailed the basics, we're going to see how to build a
-game Graphical User Interface (GUI) with reusable UI components: a life bar, an
-energy bar, and bomb and emerald counters. By the end of this tutorial,
-you'll have a game GUI, ready to control with GDscript or VisualScript:
-
-.. figure:: img/ui_gui_design_final_result.png
-
-   The final result
-
-You'll also learn to:
-
-1. Create flexible UI components
-2. Use scene inheritance
-3. Build a complex UI
-
-Download the project files: :download:`ui_gui_design.zip <files/ui_gui_design.zip>` and extract the archive. Import the `start/` project in Godot to follow this tutorial. The `end/` folder contains the final result.
-
-.. note::
-
-    You can watch this tutorial as a `video on YouTube <https://www.youtube.com/watch?v=y1E_y9AIqow>`_.
-
-Breaking down the UI
---------------------
-
-Let's break down the final UI and plan the containers we'll use. As in
-the :doc:`ui_main_menu`, it starts with a ``MarginContainer``.
-Then, we can see up to three columns:
-
-1. The life and energy counters on the left
-2. The life and energy bars
-3. The bomb and emerald counters on the right
-
-But the bar's label and the gauge are two parts of the same UI element.
-If we think of them this way, we're left with two columns:
-
-1. The life and energy bars on the left
-2. The bomb and emerald counters on the right
-
-This makes it easier to nest containers: we have some margins around the
-border of the screen using a ``MarginContainer``, followed by an
-``HBoxContainer`` to manage our two columns. The two bars stack on top
-of one another inside a ``VBoxContainer``. And we'll need a last
-``HBoxContainer`` in the right column to place the bomb and emerald
-counters side-by-side.
-
-.. figure:: img/ui_gui_step_tutorial_containers_structure.png
-
-   We get a clean UI layout with only 4 containers
-
-We will need extra containers inside the individual UI components, but
-this gives us the main GUI scene's structure. With this plan in place,
-we can jump into Godot and create our GUI.
-
-Create the base GUI
--------------------
-
-There are two possible approaches to the GUI: we can design elements in
-separate scenes and put them together, or prototype everything in a
-single scene and break it down later. I recommend working with a single
-scene as you can play with your UI's placement and proportions faster
-this way. Once it looks good, you can save entire sections of the node
-tree as reusable sub-scenes. We'll do that in a moment.
-
-For now, let's start with a few containers.
-
-Create a new scene and add a ``MarginContainer``. Select the node and name it
-``GUI``.
-
-We want our interface to anchor to the top of the screen. Select the ``GUI``
-node and click the Layout button at the top of the viewport. Select the ``Top
-Wide`` option. The ``GUI`` node will anchor to the top edge of its parent, the
-viewport by default. It will resize automatically on the vertical axis to make
-space for its child UI components.
-
-Save the scene as ``GUI.tscn``. We will put the entire GUI in it.
-
-With the ``MarginContainer`` selected, head to the inspector and scroll
-down to the custom constants section. Unfold it and click the field next
-to each of the ``Margin`` properties. Set them all to ``20`` pixels.
-Next, add an ``HBoxContainer`` node. This one will contain our two bars
-on the left and separate them from the two counters on the right.
-
-We want to stack the bars vertically inside the ``HBoxContainer``.
-Add a ``VBoxContainer`` as a child of ``HBoxContainer`` and name it ``Bars``. Select the parent
-``HBoxContainer`` again and this time, add another ``HBoxContainer`` as a child of it.
-Call it ``Counters``. With these four containers, we have the base for our GUI scene.
-
-.. figure:: img/ui_gui_containers_structure_in_godot.png
-
-   You should have 4 containers that look like this
-
-.. note::
-
-    We can work this way because we first broke down our UI design
-    and took a few moments to think about the containers we'd use. When you
-    follow a tutorial like this, it may seem weird. But once you're working
-    on real games, you'll see it's an efficient workflow.
-
-Create the bars' base
-~~~~~~~~~~~~~~~~~~~~~
-
-Each bar is split into two sub-elements that align horizontally: the
-label with the health count on the left, and the gauge on the right.
-Once again, the ``HBoxContainer`` is the perfect tool for the job.
-Select the ``Bars`` node and add a new ``HBoxContainer`` inside of it.
-Name it ``Bar``.
-
-The label itself requires at least three nodes: a ``NinePatchRect``
-for the background, on top of which we'll add a texture on the left,
-either ``HP`` or ``EP``, and a ``Label`` on the right for the value. We
-can nest ``Control`` nodes however we want. We could use the
-``NinePatchRect`` as a parent for the two other elements, as it
-encompasses them. In general, you want to use containers instead, as
-their role is to help organize UI components. We'll need a
-``MarginContainer`` later anyway to add some space between the life
-count and the gauge. Select the ``Bar`` and add a ``MarginContainer``.
-Name it ``Count``. Inside of it, add three nodes:
-
-1. A ``NinePatchRect`` named ``Background``
-2. A ``TextureRect`` named ``Title``
-3. And a ``Label`` named ``Number``
-
-To add the nodes as siblings, always select the ``Count`` node first.
-
-.. figure:: img/ui_gui_step_tutorial_bar_template_1.png
-
-   Your scene tree should look like this. We're ready to throw in some
-   textures
-
-Our scene is still empty. It's time to throw in some textures. To load
-the textures, head to the FileSystem dock to the left of the viewport.
-Browse down to the res://assets/GUI folder.
-
-.. figure:: img/ui_gui_step_tutorial_textures_in_FileSystem_tab.png
-
-   You should see a list of textures that we'll use to skin our
-   interface.
-
-Select the ``Background`` in the Scene dock. In the Inspector, you
-should see a ``Texture`` property. In the FileSystem tab, click and drag
-``label_HP_bg.png`` onto the ``Texture`` slot. It stays squashed. The
-parent MarginContainer will force its size down to 0 until we force
-elements inside the container to have a minimum size. Select the
-``Background`` node. In the Inspector, scroll down to the Rect section.
-Set ``Min Size`` to (100, 40). You should see the ``Background`` resize
-along with its parent containers.
-
-Next, select the ``Title`` and drag and drop ``label_HP.png`` into its
-``Texture`` slot. Select the ``Number`` node, click the field next to
-the ``Text`` property and type ``10``. This way, we can see both nodes
-in the viewport. They should stack up in the top-left corner of their
-parent ``MarginContainer``.
-
-.. figure:: img/ui_gui_step_tutorial_bar_label_stacked.png
-
-   If you select both nodes, you should see something like this
-
-As they have a container as their direct parent, we cannot move them
-freely: the ``Count`` node will always reset their anchors, their size
-and position. Try to move and resize the nodes in the viewport. Then,
-select any of the three textures and press :kbd:`Ctrl + Up` or :kbd:`Ctrl + Down` to
-reorder them in the Scene dock. They'll snap back to their previous size
-and position.
-
-Parent containers control the size, the scale, the margins, and the
-anchors of their direct children. To modify the nodes, you must nest
-them inside a regular Control or another UI element. We'll use the
-``Background`` as a parent for the ``Title`` and ``Number``. Select both
-the ``Title`` and ``Number``, and drag and drop them onto
-``Background``.
-
-.. figure:: img/ui_gui_step_tutorial_bar_nesting_inside_background.png
-
-   By using the Background node as the two textures' parent, we take
-   control away from the Count MarginContainer
-
-Select the ``Title`` and in the Inspector, change its ``Stretch Mode`` property
-to ``Keep Centered``. Next find the ``Rect`` category in the Inspector and
-change the ``Size`` property to (50, 40) so it only takes the left half of
-the background.  Next, select the ``Number`` node. In the viewport, click the
-``Layout`` menu and click ``Full Rect``. The node will resize to fit
-the ``Background``. Head to the Inspector and change its ``Align``
-property to ``Right``, and the ``Valign`` property to ``Center``. The
-text should snap to the center of the ``Background``'s right edge.
-Resize the node horizontally, so it takes the right half of the
-``Background`` and there's a bit of padding with the right edge.
-
-.. figure:: img/ui_gui_step_tutorial_bar_placed_title_and_label.png
-
-   Here's how the nodes' bounding boxes should look in the viewport.
-   Keep it rough, you don't need to place them too precisely for now.
-
-Replace the Label's font
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-The label's font is too small. We need to replace it. Select the
-``Number`` node and in the Inspector, scroll down to the ``Control``
-class, and find the ``Custom Font`` category. Click the field next to
-the ``Font`` property and click on ``New Dynamic Font``. Click on the
-field again and select Edit.
-
-You will enter the ``Dynamic Font`` resource. Unfold the ``Font``
-category and click the field next to ``Font Data``. Click the ``Load``
-button. In the file browser, navigate down to the assets/font folder and
-double click ``Comfortaa-Bold.ttf`` to open it. You should see the font
-update in the viewport. Unfold the settings category to change the font
-size. Set the ``Size`` property to a higher value, like ``24`` or
-``28``.
-
-We now need the text's baseline, the number's lower edge, to align with
-the HP texture on the left. To do so, still in the ``DynamicFont``
-resource, you can tweak the ``Bottom`` property under the
-``Extra Spacing`` category. It adds some bottom padding to the text.
-Click the ``Number`` node in the Scene tab to go back to the node's
-properties and change the ``Valign`` to ``Bottom``. To adjust the text's
-baseline, click on the font field under the ``Custom Font`` category
-again and tweak the ``Bottom`` property until the text aligns with the
-``Title`` node. I used a value of ``2`` pixels.
-
-.. figure:: img/ui_gui_step_tutorial_number_baseline.png
-
-   With a Bottom value of 2 pixels, the Number aligns with the Title
-
-With this, we finished the hardest part of the GUI.
-Congratulations! Let's move on to the simpler nodes.
-
-Add the progress bar
-~~~~~~~~~~~~~~~~~~~~
-
-We need one last element to complete our life bar: the gauge itself.
-Godot ships with a ``TextureProgress`` node that has everything we need.
-
-Select the Bar node and add a ``TextureProgress`` inside of it. Name it
-``Gauge``. In the inspector unfold the ``Textures`` section. Head to the
-FileSystem dock and drag and drop the ``lifebar_bg.png`` texture onto
-the ``Under`` slot. Do the same with the ``lifebar_fill.png`` image and
-drop it onto the ``Progress`` slot. Under the ``Range`` class in the
-inspector, change the ``Value`` property to ``50`` to see the gauge fill
-up.
-
-With only five ``Control`` nodes, our first bar is ready to use.
-
-.. figure:: img/ui_gui_step_tutorial_bar_final.png
-
-   That's it, our life bar is ready. This last part was quick, wasn't
-   it? That's thanks to our robust container setup.
-
-Design the bomb and emerald counters
-------------------------------------
-
-The bomb and emerald counters are like the bar's ``Count`` node. So we'll
-duplicate it and use it as a template.
-
-Under the ``Bar`` node, select ``Count`` and press :kbd:`Ctrl + D` to duplicate
-it. Drag and drop the new node under the ``Counters`` ``HBoxContainer``
-at the bottom of the scene tree. You should see it resize automatically.
-Don't worry about this for now, we'll fix the size soon.
-
-Rename the ``Count2`` node to ``Counter``. Unlike the bars, we want the
-number to be on the left, and an icon to sit on the right. The setup is
-the same: we need a background (a ``NinePatchRect``), the title, and the
-number nodes. The ``Title`` node is a ``TextureRect``, so it's what we
-need to display the icon. In the scene tree, select the ``Title`` node,
-and rename it to ``Icon``.
-
-.. figure:: img/ui_gui_step_tutorial_counter_design_1.png
-
-   Here's how your node tree should look so far
-
-With the ``Icon`` node selected, in the inspector, scroll to the top to
-see the ``Texture`` slot. Head to the FileSystem dock on the left and
-select the ``bombs_icon.png``. Drag and drop it onto the ``Texture``
-slot. In the Scene Tab select both the ``Icon`` and the ``Number``
-nodes. Click the Layout menu in the toolbar at the top of the viewport
-and select ``Full Rect``. Both nodes will update to fit
-the size of the ``Background``.
-
-.. figure:: img/ui_gui_step_tutorial_counter_design_2.png
-
-   The nodes anchor to the entire Background, but their position is off
-
-Let's change the ``Number``'s align properties to move it to the left
-and center of the ``Background``. Select the ``Number`` node, change its
-``Align`` property to left and the ``Valign`` property to center. Then
-resize its left edge a bit to add some padding between the left
-edge of the ``Background`` and the text.
-
-.. figure:: img/ui_gui_step_tutorial_counter_design_3.png
-
-   The Number node aligned to the left and center
-
-To overlap the Icon and the background, we need a few tweaks. First, our
-background is a bit too tall. It's because it's inside a margin
-container that is controlled by the top-most GUI node. Select the GUI
-node at the top of the scene tree and downsize it vertically so that
-it's as thin as possible. You'll see the gauge prevents you from making
-it too small. A container cannot be smaller than the minimal size of its
-children. The container's margins also weigh in.
-
-Select the Icon, click the Layout menu, and select
-``Full Rect`` to re-center it. We need it to anchor to
-the ``Background``'s right edge. Open the Layout menu again and select
-``Center Right``. Move the icon up so it is centered vertically with the
-``Background``.
-
-.. figure:: img/ui_gui_step_tutorial_counter_design_4.png
-
-   The bomb icon anchors to the Background's right edge. Resize the
-   Counter container to see the Icon node stick to its right side
-
-Because we duplicated the ``Counter`` from the bar's ``Count``, the
-``Number`` node's font is off. Select the ``Number`` node again, head to
-the ``Font`` property, and click it to access the ``DynamicFont``
-resource. In the ``Extra Spacing`` section, change the ``Bottom`` value
-to ``0`` to reset the font's baseline. Our counter now works as
-expected.
-
-Let's make the ``Counters`` anchor to the right edge of the viewport. To do so,
-we need to set the ``Bars`` container take all the available horizontal space it
-can. Select the ``Bars`` node and scroll down to the ``Size Flags`` category. In
-the ``Horizontal`` category, check the ``Expand`` value. The ``Bars`` node
-should resize and push the counter to the right side of the screen.
-
-.. figure:: img/ui_gui_step_tutorial_counter_design_5.png
-
-   An expanding container eats all the space it can from its parent,
-   pushing everything else along the way
-
-Turn the bar and counter into reusable UI components
-----------------------------------------------------
-
-We have one bar and one counter widget. But we need two of each. We may
-need to change the bars' design or their functionality later on. It'd be
-great if we could have a single scene to store a UI element's template,
-and child scenes to work on variations. Godot lets us do this with
-Inherited Scenes.
-
-Let's save both the ``Counter`` and the ``Bar`` branches as separate
-scenes that we'll reduce to create the ``LifeBar``, the ``EnergyBar``,
-the ``BombCounter``, and the ``EmeraldCounter``. Select the ``Bar``
-HBoxContainer. Right click on it and click on ``Save Branch as Scene``.
-Save the scene as ``Bar.tscn``. You should see the node branch turn it
-to a single ``Bar`` node.
-
-.. tip::
-
-    A scene is a tree of nodes. The topmost node is the tree's
-    **root**, and the children at the bottom of the hierarchy are
-    **leaves**. Any node other than the root along with one or more children is
-    a **branch**. We can encapsulate node branches into separate scenes, or
-    load and merge them from other scenes into the active one. Right click
-    on any node in the Scene dock and select ``Save Branch as Scene`` or
-    ``Merge from Scene``.
-
-Then, select the ``Counter`` node and do the same. Right click,
-``Save Branch as Scene``, and save it as ``Counter.tscn``. A new edit
-scene icon appears to the right of the nodes in the scene tree. Click on
-the one next to ``Bar`` to open the corresponding scene. Resize the
-``Bar`` node so that its bounding box fits its content. The way we named
-and placed the Control nodes, we're ready to inherit this template and
-create the life bar. It's the same for the ``Counter``.
-
-.. figure:: img/ui_gui_step_tutorial_bar_template_scene.png
-
-   With no extra changes, our Bar is ready to use
-
-Use scene inheritance to create the remaining elements
-------------------------------------------------------
-
-We need two bars that work the same way: they should feature a label on
-the left, with some value, and a horizontal gauge on the right. The only
-difference is that one has the HP label and is green, while the other is
-called EP and is yellow. Godot gives us a powerful tool to create a
-common base to reuse for all bars in the game: **inherited scenes**.
-
-.. figure:: img/gui_step_tutorial_gui_scene_hierarchy.png
-
-   Inherited scenes help us keep the GUI scene clean. In the end, we
-   will only have containers and one node for each UI component.
-
-On an inherited scene, you can change any property of every node in the
-inspector, aside from its name. If you modify and save the parent scene,
-all the inherited scenes update to reflect the changes. If you change a
-value in the inherited scene, it will always override the parent's
-property. It's useful for UIs, as they often require variations of the same
-elements. In general, in UI design, buttons, panels etc. share a common
-base style and interactions. We don't want to copy it over to all
-variations manually.
-
-A reload icon will appear next to the properties you override. Click it
-to reset the value to the parent scene's default.
-
-.. note::
-
-    Think of scene inheritance like the node tree, or the
-    ``extends`` keyword in GDScript. An inherited scene does everything like
-    its parent, but you can override properties, resources and add extra
-    nodes and scripts to extend its functionality.
-
-Inherit the Bar Scene to build the LifeBar
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Go to ``Scene -> New Inherited Scene`` to create a new type of ``Bar``.
-Select the Bar scene and open it. You should see a new [unsaved] tab,
-that's like your ``Bar``, but with all nodes except the root in grey.
-Press :kbd:`Ctrl + S` (:kbd:`Cmd + S` on macOS) to save the new inherited scene and name it
-``LifeBar``.
-
-.. figure:: img/ui_gui_step_tutorial_inherited_scene_parent.png
-
-   You can't rename grey nodes. This tells you they have a parent scene
-
-First, rename the root or top level node to ``LifeBar``. We always want
-the root to describe exactly what this UI component is. The name
-differentiates this bar from the ``EnergyBar`` we'll create next. The
-other nodes inside the scene should describe the component's structure
-with broad terms, so it works with all inherited scenes. Like our
-``TextureProgress`` and ``Number`` nodes.
-
-.. note::
-
-    If you've ever done web design, it's the same spirit as
-    working with CSS: you create a base class, and add variations with
-    modifier classes. From a base button class, you'll have button-green and
-    button-red variations for the user to accept and refuse prompts. The new
-    class contains the name of the parent element and an extra keyword to
-    explain how it modifies it. When we create an inherited scene and change
-    the name of the top level node, we're doing the same thing.
-
-Design the EnergyBar
-~~~~~~~~~~~~~~~~~~~~
-
-We already setup the ``LifeBar``'s design with the main ``Bar`` scene.
-Now we need the ``EnergyBar``.
-
-Let's create a new inherited scene, and once again select the
-``Bar.tscn`` scene and open it. Double-click on the ``Bar`` root node and rename it
-to ``EnergyBar``. Save the new scene as ``EnergyBar.tscn``.
-We need to replace the HP texture with EP one, and to
-change the textures on the gauge.
-
-Head to the FileSystem dock on the left, select the ``Title`` node in
-the Scene tree and drag and drop the ``label_EP.png`` file onto the
-texture slot. Select the ``Number`` node and change the ``Text``
-property to a different value like ``14``.
-
-You'll notice the EP texture is smaller than the HP one. We should
-update the ``Number``'s font size to better fit it. A font is a
-resource. All the nodes in the entire project that use this resource
-will be affected by any property we change. You can try to change the
-size to a huge value like ``40`` and switch back to the ``LifeBar`` or
-the ``Bar`` scenes. You will see the text increased in size.
-
-.. figure:: img/ui_gui_step_tutorial_design_EnergyBar_1.png
-
-   If we change the font resource, all the nodes that use it are
-   affected
-
-To change the font size on this node only, we must create a copy of the
-font resource. Select the ``Number`` node again and click on the wrench
-and screwdriver icon on the top right of the inspector. In the drop-down
-menu, select the ``Make Sub-Resources Unique`` option. Godot will find
-all the resources this node uses and create unique copies for us.
-
-.. figure:: img/ui_gui_step_tutorial_design_EnergyBar_2.png
-
-   Use this option to create unique copies of the resources for one node
-
-.. tip::
-
-    When you duplicate a node from the Scene tree, with
-    :kbd:`Ctrl + D` (:kbd:`Cmd + D` on macOS), it shares its resources with the original node. You
-    need to use ``Make Sub-Resources Unique`` before you can tweak the
-    resources without affecting the source node.
-
-Scroll down to the ``Custom Font`` section and open ``Font``. Lower the
-``Size`` to a smaller value like ``20`` or ``22``. You may also need to
-adjust the ``Bottom`` spacing value to align the text's baseline with
-the EP label on the left.
-
-.. figure:: img/ui_gui_step_tutorial_design_EnergyBar_3.png
-
-   The EP Count widget, with a smaller font than its HP counterpart
-
-Now, select the ``TextureProgress`` node. Drag the ``energy_bar_bg.png``
-file onto the ``Under`` slot and do the same for ``energy_bar_fill.png``
-and drop it onto the ``Progress`` texture slot.
-
-You can resize the node vertically so that its bounding rectangle fits
-the gauge. Do the same with the ``Count`` node until its size aligns
-with that of the bar. Because the minimal size of ``TextureProgress`` is
-set based on its textures, you won't be able to downsize the ``Count``
-node below that. That is also the size the ``Bar`` container will have.
-You may downscale this one as well.
-
-Last but not least, the ``Background`` container has a minimum size that
-makes it a bit large. Select it and in the ``Rect`` section, change the
-``Min Size`` property down to ``80`` pixels. It should resize
-automatically and the ``Title`` and ``Number`` nodes should reposition
-as well.
-
-.. figure:: img/ui_gui_step_tutorial_design_EnergyBar_4.png
-
-   The Count looks better now it's a bit smaller
-
-.. tip::
-
-    The Count node's size affects the position of the
-    TextureProgress. As we'll align our bars vertically in a moment, we're
-    better off using the Counter's left margin to resize our EP label. This
-    way both the EnergyBar's Count and the LifeBar's Count nodes are one
-    hundred pixels wide, so both gauges will align perfectly.
-
-Prepare the bomb and emerald counters
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Let us now take care of the counters. Go to
-``Scene -> New Inherited Scene`` and select the ``Counter.tscn`` as a
-base. Rename the root node as ``BombCounter`` too.
-Save the new scene as ``BombCounter.tscn``. That's all for this scene.
-
-.. figure:: img/ui_gui_step_tutorial_design_counters_1.png
-
-   The bomb counter is the same as the original Counter scene
-
-Go to ``Scene -> New Inherited Scene`` again and select ``Counter.tscn``
-once more. Rename the root node ``EmeraldCounter`` and save the scene as ``EmeraldCounter.tscn``.
-For this one, we mainly need to replace the bomb icon
-with the emerald icon. In the FileSystem tab, drag the ``emeralds_icon.png``
-onto the ``Icon`` node's ``Texture`` slot. ``Icon`` already anchors to
-the right edge of the ``Background`` node so we can change its position
-and it will scale and reposition with the ``EmeraldCounter`` container.
-Shift the emerald icon a bit to the right and down. Use the Arrow
-Keys on the keyboard to nudge its position. Save, and we're done with
-all the UI elements.
-
-.. figure:: img/ui_gui_step_tutorial_design_counters_2.png
-
-   The emerald counter should look something like this
-
-Add the UI components to the final GUI
---------------------------------------
-
-Time to add all the UI elements to the main GUI scene. Open the
-``GUI.tscn`` scene again, and delete the ``Bar`` and ``Counter`` nodes.
-In the FileSystem dock, find the ``LifeBar.tscn`` and drag and drop it
-onto the ``Bars`` container in the scene tree. Do the same for the
-``EnergyBar``. You should see them align vertically.
-
-.. figure:: img/ui_gui_step_tutorial_assemble_final_gui_1.png
-
-   The LifeBar and the EnergyBar align automatically
-
-Now, drag and drop the ``BombCounter.tscn`` and ``EmeraldCounter.tscn`` scenes onto the
-``Counters`` node. They'll resize automatically.
-
-.. figure:: img/ui_gui_step_tutorial_assemble_final_gui_2.png
-
-   The nodes resize to take all the available vertical space
-
-To let the ``EmeraldCounter`` and ``BombCounter`` use the size we defined
-in ``Counter.tscn``, we need to change the ``Size Flags`` on the
-``Counters`` container. Select the ``Counters`` node and unfold the
-``Size Flags`` section in the Inspector. Uncheck the ``Fill`` tag for
-the ``Vertical`` property, and check ``Shrink Center`` so the container
-centers inside the ``HBoxContainer``.
-
-.. figure:: img/ui_gui_step_tutorial_assemble_final_gui_3.png
-
-   Now both counters have a decent size
-
-.. tip::
-
-    Change the ``Min Size`` property of the ``Counters`` container
-    to control the height of the counters' background.
-
-We have one small issue left with the EP label on the EnergyBar: the 2
-bars should align vertically. Click the icon next to the ``EnergyBar``
-node to open its scene. Select the ``Count`` node and scroll down to the
-``Custom Constants`` section. Add a ``Margin Left`` of ``20``. In
-the ``Rect`` section set the node's ``Min Size`` back to 100, the same
-value as on the LifeBar. The ``Count`` should now have some margin on
-the left. If you save and go back to the GUI scene, it will be aligned
-vertically with the ``LifeBar``.
-
-.. figure:: img/ui_gui_step_tutorial_assemble_final_gui_4.png
-
-   The 2 bars align perfectly
-
-.. note::
-
-    We could have set up the ``EnergyBar`` this way a few moments
-    ago. But this shows you that you can go back to any scene anytime, tweak
-    it, and see the changes propagate through the project!
-
-Place the GUI onto the game's mockup
-------------------------------------
-
-To wrap up the tutorial we're going to insert the GUI onto the game's
-mockup scene.
-
-Head to the FileSystem dock and open ``LevelMockup.tscn``.
-
-Drag-and-drop the ``GUI.tscn`` scene right below the ``bg`` node and
-above the ``Characters``. The GUI will scale to fit the entire viewport.
-Head to the Layout menu and select the ``Center Top`` option so it anchors
-to the top edge of the game window. Then resize the GUI to make it as
-small as possible vertically. Now you can see how the interface looks in
-the context of the game.
-
-Congratulations for getting to the end of this long tutorial. You can
-find the final project here: :download:`ui_gui_design.zip <files/ui_gui_design.zip>`.
-
-.. figure:: img/ui_gui_design_final_result.png
-
-   The final result
-
-.. note::
-
-    **A final note about Responsive Design**. If you resize the
-    GUI, you'll see the nodes move, but the textures and text won't scale.
-    The GUI also has a minimum size, based on the textures inside of it. In
-    games, we don't need the interface to be as flexible as that of a
-    website. You almost never want to support both landscape and portrait
-    screen orientations. It's one or the other. In landscape orientation,
-    the most common ratios range from 4:3 to 16:9. They are close to one
-    another. That's why it's enough for the GUI elements to only move
-    horizontally when we change the window size.

getting_started/step_by_step/ui_introduction_to_the_ui_system.rst

@@ -1,354 +0,0 @@
-.. _doc_design_interfaces_with_the_control_nodes:
-
-Design interfaces with the Control nodes
-========================================
-
-Computer displays, mobile phones, and TV screens come in all shapes and
-sizes. To ship a game, you'll need to support different screen ratios
-and resolutions. It can be hard to build responsive interfaces that
-adapt to all platforms. Thankfully, Godot comes with robust tools to
-design and manage a responsive User Interface.
-
-.. figure:: img/godot_editor_ui.png
-
-   Godot's editor is made with the engine's UI framework
-
-This guide will get you started with UI design. You will learn:
-
--  The five most useful control nodes to build your games' interface
--  How to work with the anchor of UI elements
--  How to efficiently place and arrange your user interface using
-   containers
--  The five most common containers (you can learn more about containers in
-   the :ref:`GUI Containers <doc_gui_containers>` documentation page).
-
-To learn how to control the interface and connect it to other scripts,
-read :ref:`Build your first game UI in Godot <doc_ui_game_user_interface>`.
-
-To design your UI, you'll use the Control nodes. These are the nodes with green icons in the
-editor. There are dozens of them, for creating anything from life bars to
-complex applications. Godot's editor itself is built using Control nodes.
-
-Control nodes have unique properties that allow them to work well with one another.
-Other visual nodes, like Node2D and Sprite don't have these capabilities. So to
-make your life easier use Control nodes wherever possible when building your UIs.
-
-All control nodes share the same main properties:
-
-1. Anchor
-2. Bounding rectangle
-3. Focus and focus neighbor
-4. Size flags
-5. Margin
-6. The optional UI theme
-
-Once you understand the basics of the Control node, it will take you less time to learn all the
-nodes that derive from it.
-
-
-The 5 most common UI elements
------------------------------
-
-Godot ships with dozens of Control nodes. A lot of them are here to help
-you build editor plugins and applications.
-
-For most games, you'll only need five types of UI elements, and a few
-Containers. These five Control nodes are:
-
-1. Label: for displaying text
-2. TextureRect: used mostly for backgrounds, or everything that should
-   be a static image
-3. TextureProgress: for lifebars, loading bars, horizontal, vertical or
-   radial
-4. NinePatchRect: for scalable panels
-5. TextureButton: to create buttons
-
-.. figure:: img/five_most_common_nodes.png
-
-   The 5 most common Control nodes for UI design
-
-TextureRect
-~~~~~~~~~~~
-
-**TextureRect** displays a texture or image inside a UI.
-It seems similar to the Sprite node, but it offers multiple scaling modes.
-Set the Stretch Mode property to change its behavior:
-
-- ``Scale On Expand (compat)`` scales the texture to fit the node's bounding rectangle,
-  only if ``expand`` property is ``true``; otherwise, it behaves like ``Keep`` mode.
-  Default mode for backwards compatibility.
-- ``Scale`` scales the texture to fit the node's bounding rectangle.
-- ``Tile`` makes the texture repeat, but it won't scale.
--  ``Keep`` and ``Keep Centered`` force the texture to remain at its
-   original size, in the top left corner or the center of the frame
-   respectively.
-- ``Keep Aspect`` and ``Keep Aspect Centered`` scales the texture but force it to remain
-  its original aspect ratio, in the top left corner or the center of the frame respectively.
-- ``Keep Aspect Covered`` works just like ``Keep Aspect Centered`` but the shorter side
-  fits the bounding rectangle and the other one clips to the node's limits.
-
-As with Sprite nodes, you can modulate the TextureRect's color. Click
-the ``Modulate`` property and use the color picker.
-
-.. figure:: img/five_common_nodes_textureframe.png
-
-   TextureRect modulated with a red color
-
-TextureButton
-~~~~~~~~~~~~~
-
-**TextureButton** is like TextureRect, except it has 6 texture slots:
-one for each of the button's states. Most of the time, you'll use the
-Normal, Pressed, and Hover textures. Focused is useful if your interface
-listens to the keyboard's input. The sixth image slot, the Click Mask,
-lets you define the clickable area using a 1-bit, pure black and white
-image.
-
-In the Base Button section, you'll find a few checkboxes that change how
-the button behaves. When ``Toggle Mode`` is on, the button will toggle
-between active and normal states when you press it. ``Disabled`` makes it
-disabled by default, in which case it will use the ``Disabled`` texture.
-TextureButton shares a few properties with the texture frame: it has a
-``modulate`` property, to change its color, and ``Resize`` and ``Stretch`` modes to
-change its scale behavior.
-
-.. figure:: img/five_common_nodes_texturebutton.png
-
-   TextureButton and its 5 texture slots
-
-TextureProgress
-~~~~~~~~~~~~~~~
-
-**TextureProgress** layers up to 3 sprites to create a progress bar. The
-Under and Over textures sandwich the Progress one, which displays the
-bar's value.
-
-The ``Mode`` property controls the direction in which the bar grows:
-horizontally, vertically, or radially. If you set it to radial, the
-``Initial Angle`` and ``Fill Degrees`` properties let you limit the range of the
-gauge.
-
-To animate the bar, you'll want to look at the Range section. Set the
-``Min`` and ``Max`` properties to define the range of the gauge. For instance,
-to represent a character's life, you'll want to set ``Min`` to ``0,`` and ``Max`` to
-the character's maximum life. Change the ``Value`` property to update the
-bar. If you leave the ``Min`` and ``Max`` values to the default of ``0`` and ``100,``
-and set the ``Value`` property to ``40``, 40% of the ``Progress`` texture will show
-up, and 60% of it will stay hidden.
-
-.. figure:: img/five_common_nodes_textureprogress.png
-
-   TextureProgress bar, two thirds filled
-
-Label
-~~~~~
-
-**Label** prints text to the screen. You'll find all its properties in
-the Label section, in the Inspector. Write the text in the ``Text``
-property, and check Autowrap if you want it to respect the textbox's
-size. If Autowrap is off, you won't be able to scale the node. You can
-align the text horizontally and vertically with Align and Valign,
-respectively.
-
-.. figure:: img/five_common_nodes_label.png
-
-   Picture of a Label
-
-NinePatchRect
-~~~~~~~~~~~~~
-
-**NinePatchRect** takes a texture split in 3 rows and 3 columns. The
-center and the sides tile when you scale the texture, but it never
-scales the corners. It is useful to build panels, dialog boxes
-and scalable backgrounds for your UI.
-
-.. figure:: img/five_common_nodes_ninepatchrect.png
-
-   NinePatchRect scaled with the min\_size property
-
-There are two workflows to build responsive UIs
------------------------------------------------
-
-There are two workflows to build scalable and flexible interfaces in Godot:
-
-1. You have many container nodes at your disposal that scale and place UI elements for you. They take control over their children.
-2. On the other side, you have the layout menu. It helps you to anchor, place and resize a UI element within its parent.
-
-The two approaches are not always compatible. Because a container controls its children, you cannot use the layout menu on them. Each container has a specific effect, so you may need to nest several of them to get a working interface. With the layout approach you work from the bottom up, on the children. As you don't insert extra containers in the scene it can make for cleaner hierarchies, but it's harder to arrange items in a row, column, grid, etc.
-
-As you create UIs for your games and tools, you'll develop a sense for what fits best in each situation.
-
-
-Place UI elements precisely with anchors
-----------------------------------------
-
-Control nodes have a position and size, but they also have anchors and
-margins. Anchors define the origin, or the reference point, for the
-Left, Top, Right and Bottom edges of the node. Change any of the 4
-anchors to change the reference point of the margins.
-
-.. figure:: img/anchor_property.png
-
-   The anchor property
-
-How to change the anchor
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-Like any properties, you can edit the 4 anchor points in the Inspector,
-but this is not the most convenient way. When you select a control node,
-the layout menu appears above the viewport, in the toolbar. It gives you
-a list of icons to set all 4 anchors with a single click, instead of
-using the inspector's 4 properties. The layout menu will only show up
-when you select a control node.
-
-.. figure:: img/layout_menu.png
-
-   The layout menu in the viewport
-
-Anchors are relative to the parent container
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Each anchor is a value between 0 and 1. For the left and top anchors, a
-value of 0 means that without any margin, the node's edges will align
-with the left and top edges of its parent. For the right and bottom
-edges, a value of 1 means they'll align with the parent container's
-right and bottom edges. On the other hand, margins represent a distance
-to the anchor position in pixels, while anchors are relative to the
-parent container's size.
-
-.. figure:: img/ui_anchor_and_margins.png
-
-   Margins are relative to the anchor position, which is relative to the
-   anchors. In practice, you'll often let the container update margins
-   for you
-
-Margins change with the anchor
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Margins update automatically when you move or resize a control node.
-They represent the distance from the control node's edges to its anchor,
-which is relative to the parent control node or container. That's why
-your control nodes should always be inside a container, as we'll see in
-a moment. If there's no parent, the margins will be relative to the
-node's own bounding Rectangle, set in the Rect section, in the
-inspector.
-
-.. figure:: img/control_node_margin.png
-
-   Margins on a CenterContainer set to the "Full Rect" anchor
-
-Try to change the anchors or nest your Control nodes inside Containers:
-the margins will update. You'll rarely need to edit the margins
-manually. Always try to find a container to help you first; Godot comes
-with nodes to solve all the common cases for you. Need to add space
-between a lifebar and the border of the screen? Use the MarginContainer.
-Want to build a vertical menu? Use the VBoxContainer. More on these
-below.
-
-Use size tags to change how UI elements fill the available space
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Every control node has Size Flags. They tell containers how the UI
-elements should scale. If you add the "Fill" flag to the Horizontal or
-Vertical property, the node's bounding box will take all the space it
-can, but it'll respect its siblings and retain its size. If there are 3
-TextureRect nodes in an HBoxContainer, with the "Fill" flags on both
-axes, they'll each take up to a third of the available space, but no
-more. The container will take over the node and resize it automatically.
-
-.. figure:: img/textureframe_in_box_container_fill.png
-
-   3 UI elements in an HBoxContainer, they align horizontally
-
-The "Expand" flag lets the UI element take all the space it can, and
-push against its siblings. Its bounding rectangle will grow against the
-edges of its parent, or until it's blocked by another UI node.
-
-.. figure:: img/textureframe_in_box_container_expand.png
-
-   The same example as above, but the center node has the "Expand" size
-   flag
-
-You'll need some practice to understand the size tags, as their effect
-can change quite a bit depending on how you set up your interface.
-
-Arrange control nodes automatically with containers
----------------------------------------------------
-
-Containers automatically arrange all children Control nodes including
-other containers in rows, columns, and more. Use them to add padding
-around your interface or center nodes in their bounding rectangles. All
-built-in containers update in the editor, so you can see the effect
-instantly.
-
-Containers have a few special properties to control how they arrange UI
-elements. To change them, navigate down to the Custom Constants section
-in the Inspector.
-
-The 5 most useful containers
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If you build tools, you might need all of the containers. But for most
-games, a handful will be enough:
-
--  MarginContainer, to add margins around part of the UI
--  CenterContainer, to center its children in its bounding box
--  VboxContainer and HboxContainer, to arrange UI elements in rows or
-   columns
--  GridContainer, to arrange Controls nodes in a grid-like pattern
-
-CenterContainer centers all its children inside of its bounding
-rectangle. It's one you typically use for title screens, if you want the
-options to stay in the center of the viewport. As it centers everything,
-you'll often want a single container nested inside it. If you use
-textures and buttons instead, they'll stack up.
-
-.. figure:: img/five_containers_centercontainer.png
-
-   CenterContainer in action. The life bar centers inside its parent
-   container.
-
-The MarginContainer adds a margin on any side of the child nodes. Add a
-MarginContainer that encompasses the entire viewport to add a separation
-between the edge of the window and the UI. You can set a margin on the
-top, left, right, or bottom side of the container. No need to tick the
-checkbox: click the corresponding value box and type any number. It will
-activate automatically.
-
-.. figure:: img/five_containers_margincontainer.png
-
-   The MarginContainer adds a 40px margin around the Game User Interface
-
-There are two BoxContainers: VBoxContainer and HBoxContainer. You cannot
-add the BoxContainer node itself, as it is a helper class, but you can
-use vertical and horizontal box containers. They arrange nodes either in
-rows or columns. Use them to line up items in a shop, or to build
-complex grids with rows and columns of different sizes, as you can nest
-them to your heart's content.
-
-.. figure:: img/five_containers_boxcontainer.png
-
-   The HBoxContainer horizontally aligns UI elements
-
-VBoxContainer automatically arranges its children into a column. It puts
-them one after the other. If you use the separation parameter, it will
-leave a gap between its children. HBoxContainer arranges UI elements in
-a row. It's similar to the VBoxContainer, with an extra ``add_spacer``
-method to add a spacer control node before its first child or after its
-last child, from a script.
-
-The GridContainer lets you arrange UI elements in a grid-like pattern.
-You can only control the number of columns it has, and it will set the
-number of rows by itself, based on its children's count. If you have
-nine children and three columns, you will have 9÷3 = 3 rows. Add three
-more children and you'll have four rows. In other words, it will create
-new rows as you add more textures and buttons. Like the box containers,
-it has two properties to set the vertical and horizontal separation
-between the rows and columns respectively.
-
-.. figure:: img/five_containers_gridcontainer.png
-
-   A GridContainer with 2 columns. It sizes each column automatically.
-
-Godot's UI system is complex, and has a lot more to offer. To learn how
-to design more advanced interfaces, head to the :ref:`GUI section <toc-learn-features-gui>` of the docs.

getting_started/step_by_step/ui_main_menu.rst

@@ -1,316 +0,0 @@
-.. _doc_ui_main_menu:
-
-Design a title screen
-=====================
-
-In the next two tutorials, you will build two responsive UI (user interface)
-scenes step-by-step using the engine's UI system:
-
-1. A main menu.
-2. A game UI with a health bar, energy bar, bomb and money counters.
-
-You will learn how to design game UIs efficiently, and how to use Godot's
-Control nodes. This page focuses on the visual part: everything you do
-from the editor. To learn how to code a life bar,
-read :doc:`ui_code_a_life_bar`.
-
-
-.. figure:: img/ui_main_menu_design_final_result.png
-
-   The GUI you're going to create.
-
-Download the project files: :download:`ui_main_menu_design.zip
-<files/ui_main_menu_design.zip>` and extract the archive. Import the ``start/``
-project in Godot to follow this tutorial. The ``end/`` folder contains the
-final result. You'll find all the sprites in the ``start/assets/main_menu``
-folder.
-
-.. note::
-
-    Read the :doc:`ui_introduction_to_the_ui_system` first to learn how
-    Godot's UI system works.
-
-How to design your game UI
---------------------------
-
-To design a good UI, you want to come up with a rough mockup first: a
-plain drawing version that focuses on the placement of your UI
-components, their size, and user interaction. Pen and paper is all you
-need. You shouldn't use fancy and final graphics at this stage. Then,
-you only need simple placeholder sprites and you're good to jump into
-Godot. You want to make sure the players can find their way around the
-interface using those placeholders.
-
-.. figure:: img/ui_design_rough.png
-
-   The UI's rough plan or mockup
-
-Placeholder doesn't have to mean ugly, but you should keep the graphics
-simple and clean. Avoid special effects, animation, and detailed
-illustration before you have players playtest your UI. Otherwise:
-
-1. The graphics might skew the players' perception of the experience and
-   you'll miss out on valuable feedback.
-2. If the User Experience doesn't work, you'll have to redo some sprites.
-
-.. tip::
-
-    Always try to make the interface work with simple text and
-    boxes first. It's easy to replace the textures later. Professional UX
-    designers often work with plain outlines and boxes in greyscale. When
-    you take colors and fancy visuals away, it's a lot easier to size and
-    place UI elements properly. It helps you refine the design foundation
-    you'll build upon.
-
-There are two ways to design your UI in Godot. You can:
-
-1. Build it all in a single scene, and eventually save some branches as
-   reusable scenes.
-2. Build template scenes for reusable components and create specific
-   components that inherit from your base scenes.
-
-We will use the first approach, because the first version of your UI may
-not work as well as you'd like. You're likely to throw parts away and
-redesign components as you go. When you're sure everything works, it's
-easy to make some parts reusable, as you'll see below.
-
-.. figure:: img/ui_main_menu_placeholder_assets.png
-
-   The files you'll find in Godot. The graphics look cleaner than on the
-   rough design, but they're still placeholders.
-
-Design the main menu
---------------------
-
-Before we jump into the editor, we want to plan how we'll nest
-containers based on our mockup image.
-
-Break down the UI mockup
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-Here are my three rules of thumb to find the right containers:
-
-1. Break down the UI into nested boxes, from the largest that contains
-   everything, to the smallest ones, that encompass one widget, like a
-   bar with its label, a panel or a button.
-2. If there's some padding around an area, use a ``MarginContainer``.
-3. If the elements are arranged in rows or columns, use an
-   ``HBoxContainer`` or ``VBoxContainer``.
-
-These rules are enough to get us started, and work well for simple
-interfaces.
-
-For the main menu, the largest box is the entire game window. There's
-padding between the edges of the window and the first components: this
-should be a ``MarginContainer``. Then, the screen is split into two
-columns, so we'll use an ``HBoxContainer``. In the left column, we'll
-manage the rows with a ``VBoxContainer``. And in the right column, we'll
-center the illustration with a ``CenterContainer``.
-
-.. figure:: img/ui_mockup_break_down.png
-
-   Interface building blocks, broken down using the three rules of thumb.
-
-.. tip::
-
-    Containers adapt to the window's resolution and width-to-height
-    ratio. Although we could place UI elements by hand, containers are
-    faster, more precise, and **responsive**.
-
-Prepare the Main Menu scene
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-.. note::
-
-    This tutorial is based on a window size of 1366×768. To change the project's
-    base window size, open **Project > Project Settings** at the top of the
-    editor then change **Display > Window > Size > Width** to ``1366`` and
-    **Display > Window > Size > Height** to ``768``.
-
-    If you forget to change the window size, anchors and containers may not
-    behave as expected.
-
-Let's create the main menu. We'll build it in a single scene. To create
-an empty scene, click on **Scene > New Scene**.
-
-We have to add a root node before we can save the scene. Your UI's root
-should be the outermost container or element. In this case it's a
-``MarginContainer``. ``MarginContainer`` is a good starting point for
-most interfaces, as you often need padding around the UI. Press
-:kbd:`Ctrl + S` (:kbd:`Cmd + S` on macOS) to save the scene to the disk. Name it *MainMenu*.
-
-Select the ``MarginContainer`` again, and head to the inspector to
-define the margins' size. Scroll down the ``Control`` class, to the
-``Custom Constants`` section. Unfold it. Set the margins as such:
-
--  Margin Right: *120*
--  Margin Top: *80*
--  Margin Left: *120*
--  Margin Bottom: *80*
-
-We want the container to fit the window. In the toolbar above the Viewport,
-open the **Layout** menu and select the last option, **Full Rect**.
-
-Add the UI sprites
-~~~~~~~~~~~~~~~~~~
-
-Select the ``MarginContainer``, and create the UI elements as
-``TextureRect`` nodes. We need:
-
-1. the title or logo,
-2. the three text options as individual nodes,
-3. the version note,
-4. and the main menu's illustration.
-
-Click the **Add Node** button or press :kbd:`Ctrl + A` (:kbd:`Cmd + A` on macOS) on your keyboard.
-Start to type ``TextureRect`` to find the corresponding node and press
-enter. With the new node selected, press :kbd:`Ctrl + D` (:kbd:`Cmd + D` on macOS) five times to
-create five extra ``TextureRect`` instances.
-
-Click each of the nodes to select it. In the inspector, find the **Texture**
-property and click **[empty] > Load**. A file browser opens and lets
-you pick a sprite to load into the texture slot.
-
-.. figure:: img/ui_texturerect_load_texture.png
-
-   The file browser lets you find and load textures.
-
-Repeat the operation for all ``TextureRect`` nodes. You should have the
-logo, the illustration, the three menu options and the version note,
-each as a separate node. Then, double click on each of the nodes in the
-Scene tab to rename them. Nothing has been placed in containers yet so this
-should look messy.
-
-.. figure:: img/ui_main_menu_6_texturerect_nodes.png
-
-   The six nodes with textures loaded.
-
-.. note::
-
-    If you want to support localization in your game, use
-    ``Labels`` for menu options instead of ``TextureRect``.
-
-Add containers to place UI elements automatically
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Our main menu has some margin around the edges of the screen. It is
-split in two parts: on the left, you have the logo and the menu options.
-On the right, you have the characters. We can use one of two containers
-to achieve this: ``HSplitContainer`` or ``HBoxContainer``. Split
-containers split the area into two: a left and a right side or a top and
-a bottom side. They also allow the user to resize the left and right
-areas using an interactive bar. On the other hand, ``HBoxContainer``
-just splits itself into as many columns as it has children. Although you
-can deactivate the split container's resize behavior, I recommend to
-favor box containers.
-
-Select the ``MarginContainer`` and add an ``HBoxContainer``. Then, we
-need two containers as children of our ``HBoxContainer``: a
-``VBoxContainer`` for the menu options on the left, and a
-``CenterContainer`` for the illustration on the right.
-
-.. figure:: img/ui_main_menu_containers_step_1.png
-
-   You should have four nested containers and the TextureRect nodes
-   sitting aside from it.
-
-In the node tree, select all the ``TextureRect`` nodes that should go on the
-left side: the logo, the menu options (Continue, NewGame, Options), and the
-version note. Drag and drop them into the ``VBoxContainer``. The nodes should
-position automatically.
-
-.. figure:: img/ui_main_menu_containers_step_2.png
-
-   Containers automatically place and resize textures
-
-We're left with two problems to solve:
-
-1. The characters on the right aren't centered.
-2. There's no space between the logo and the other UI elements.
-
-To center the characters on the right, first select the ``CenterContainer``.
-Then in the Inspector, scroll down to the **Size Flags** category and click
-on the field to the right of the **Vertical** property, and check **Expand**
-in addition to **Fill**. Do the same for the **Horizontal** property. This
-makes the ``CenterContainer`` expand into all available space while
-respecting its neighbour ``VBoxContainer``. Finally, drag and drop the
-Characters node into the ``CenterContainer``. The Characters element will center
-automatically.
-
-.. figure:: img/ui_main_menu_containers_step_3.png
-
-   The character node centers inside the right half of the screen as
-   soon as you place it inside the CenterContainer.
-
-To space out the menu options and the logo on the left, we'll use one
-final container and its size flags. Select the ``VBoxContainer`` and
-press :kbd:`Ctrl + A` (:kbd:`Cmd + A` on macOS) to add a new node inside it. Add a second
-``VBoxContainer`` and name it *MenuOptions*. Select all three menu
-options, ``Continue``, ``NewGame`` and ``Options``, and drag and drop
-them inside the new ``VBoxContainer``. The UI's layout should barely
-change, if at all.
-
-.. figure:: img/ui_main_menu_containers_step_4.png
-
-   Place the new container between the other two nodes to retain the
-   UI's layout.
-
-Now we grouped the menu options together, we can tell their container to
-expand to take as much vertical space as possible. Select the
-``MenuOptions`` node. In the Inspector, scroll down to the
-**Size Flags** category. Click on the field to the right of the
-**Vertical** property, and check **Expand** in addition to **Fill**.
-The container expands to take all the available vertical space
-while respecting its neighbors, the ``Logo`` and ``Version`` elements.
-
-To center the nodes in the ``VBoxContainer``, scroll to the top of the
-Inspector and change the **Alignment** property to **Center**.
-
-.. figure:: img/ui_main_menu_containers_step_5.png
-
-   The menu options should center vertically in the UI's left column.
-
-To wrap things up, let's add some separation between the menu options.
-Expand the **Custom Constants** category below **Size Flags**, and click
-the field next to the **Separation** parameter. Set it to 30. Once you
-press enter, the **Separation** property becomes active and Godot adds
-30 pixels between menu options.
-
-.. figure:: img/ui_main_menu_design_final_result.png
-
-   The final interface.
-
-Without a single line of code, we have a precise and responsive main
-menu.
-
-Congratulations for getting there! You can download the final
-menu :download:`ui_main_menu_design.zip <files/ui_main_menu_design.zip>`
-to compare with your own. In the next tutorial, you'll
-create a Game User Interface with bars and item counters.
-
-Break down the UI mockup
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-A responsive User Interface is all about making sure our UIs scale well on
-all screen types. TV screens and computer displays have different sizes
-and ratios. In Godot, we use containers to control the position and the
-size of UI elements.
-
-The order in which you nest matters. To see if your
-UI adapts nicely to different screen ratios, select the root node, press
-:kbd:`Q` to activate the Select Mode, select the container and click
-and drag on one of the container's corners to resize it. The UI
-components should flow inside of it.
-
-You'll notice that although
-containers move sprites around, they don't scale them. This is normal.
-We want the UI system to handle different screen ratios, but we also
-need the entire game to adapt to different screen resolutions. To do
-this, Godot scales the entire window up and down.
-
-You can change the scale mode in the project settings: click
-**Project > Project Settings** in the top menu. In the window's left column,
-look for the **Display** category. Click on the **Window** sub-category.
-On the right side of the window, you'll find a **Stretch** section.
-The three settings, **Mode**, **Aspect**, and **Shrink**, control the
-screen size. For more information, see :ref:`doc_multiple_resolutions`.

getting_started/step_by_step/your_first_game.rst

@@ -995,7 +995,6 @@ on the other two Control nodes.
           origin - the reference point for the edges of the node. Margins
           update automatically when you move or resize a control node. They
           represent the distance from the control node's edges to its anchor.
-          See :ref:`doc_design_interfaces_with_the_control_nodes` for more details.
 
 Arrange the nodes as shown below. Click the "Layout" button to
 set a Control node's layout: