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

Rewrite and rename scripting -> scripting_languages

Browse Source 
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
This commit is contained in:
Nathan Lovato
2020-12-02 15:47:29 -06:00
parent e7643e5925
commit fbb8105a54
11 changed files with 615 additions and 344 deletions
Download Patch File Download Diff File Expand all files Collapse all files
classes/class_script.rst
+1 -1
View File
@@ -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/img/scripting_camera_shake.gif
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 244 KiB

getting_started/step_by_step/img/scripting_cpp.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 35 KiB

getting_started/step_by_step/img/scripting_csharp.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 17 KiB

getting_started/step_by_step/img/scripting_gdscript.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 39 KiB

getting_started/step_by_step/img/scripting_visualscript.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 24 KiB

getting_started/step_by_step/index.rst
+3 -1
View File
@@ -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
-342
View File
@@ -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
+425
View File
@@ -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
+181
View File
@@ -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
+5
View File
@@ -0,0 +1,5 @@
.. _doc_your_first_script:
Creating your first script
--------------------------