scripting.rst 9.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260
  1. .. _doc_scripting:
  2. Scripting
  3. =========
  4. Introduction
  5. ------------
  6. Before Godot 3.0, the only choice for scripting a game in Godot was to use
  7. :ref:`doc_gdscript`. Nowadays, Godot has four (yes four!) official languages
  8. and the ability to add extra scripting languages dynamically!
  9. This is great, mostly, due the large amount of flexibility provided, but
  10. it also makes our work of supporting languages more difficult.
  11. The "Main" languages in Godot, though, are GDScript and VisualScript. The
  12. main reason to choose them is the level of integration with Godot, as this
  13. makes the experience smoother (both have very slick editor integration, while
  14. C# and C++ need to be edited in a separate IDE). If you are a big fan of statically typed languages, though, go with C# and C++.
  15. There are more languages available via GDNative interface, but keep in mind
  16. we don't have official support for them so you will have to work with the
  17. provided in that case.
  18. GDScript
  19. ~~~~~~~~
  20. :ref:`doc_gdscript` is, as mentioned above, the main language used in Godot.
  21. Using it has some really positive points compared to other languages due
  22. to the high integration with Godot:
  23. * It's simple, elegant and designed to be friendly with users of other languages such as Lua, Python, Squirrel, etc.
  24. * Loads and compiles blazingly fast.
  25. * The editor integration is a pleasure to work with, with code completion expanding as far as completing nodes, signals, and many other items pertaining to the current scene being edited.
  26. * Has vector types built-in (such as Vectors, transorms etc), making it efficient for heavy linear algebra.
  27. * It supports multiple threads as well as statically typed languages (which is one of the limitation that avoided us going for other VMs such as Lua, Squirrel, etc).
  28. * It uses no garbage collector, so it trades a small bit of automation (most objects are reference counted anyway), by determinism.
  29. * The dynamic nature of it makes it easy to optimize chunks of it in C++ (via GDNative) if more performance is required at some point, without recompiling the engine.
  30. If undecided, and have experience in programming (especially dynamically
  31. typed languages), go for GDScript!
  32. Visual Script
  33. ~~~~~~~~~~~~~
  34. Begining 3.0, Godot offers :ref:`visualscript<Visual Scripting>`. This is a
  35. somewhat typical implementation of blocks and connections language, but
  36. adapted to how Godot works.
  37. Visual Scripting is a great tool for non-programmers, or even for developers
  38. with ample programming experience that want to make parts of the code more
  39. accessible to others (like Game/Level Designers or Artists).
  40. It can also be used by programmers to build state machines or custom
  41. visual node workflows (like a Dialogue System).
  42. Microsoft C#
  43. ~~~~~~~~~~~~
  44. As Microsoft's C# is a favorite amongst game developers, we have added
  45. solid and official support for it. C# is a very mature language with tons of code
  46. written for it. Support for this language was added thanks to a generous
  47. donation from Microsoft.
  48. It has an excellent tradeoff between performance and ease to use, although
  49. the main item one must be aware of is the garbage collector.
  50. For companies, this is usually the best choice, given the large amount of
  51. programmers that can be found in the labor market familiar with it, which
  52. reduces the learning time of the engine.
  53. GDNative C++
  54. ~~~~~~~~~~~~
  55. Finally, this is one of our brightest additions for the 3.0 release.
  56. GDNative allows scripting in C++ without requiring to recompile (or even
  57. restart) Godot.
  58. Any C++ version can be used, and mixing compiler brands and versions for the
  59. generated shared libraries works perfectly, thanks to our use of an internal C
  60. API Bridge.
  61. This language is the best choice for performance and does not need to be
  62. used for an entire game (other parts can be written in GDScript or Visual
  63. Script). Yet, the API is very clear and easy to use as it resembles, mostly,
  64. Godot actual C++ API.
  65. Scripting a scene
  66. -----------------
  67. In the rest of this tutorial, we'll set up a simple GUI scene consisting of a
  68. button and a label, where pressing the button will update the label. This will
  69. demonstrate:
  70. - how to write a basic script and attach it to a node
  71. - how to hook up UI elements via *signals*
  72. - how to write a script that can access other nodes in the scene
  73. Before continuing, please make sure to read the :ref:`doc_gdscript` reference.
  74. It's a simple language and the reference is short, so it will not take more
  75. than a few minutes to get an overview of the concepts.
  76. Scene setup
  77. ~~~~~~~~~~~
  78. Use the add node dialog to create the following hierarchy, with the following
  79. nodes:
  80. - Panel
  81. * Label
  82. * Button
  83. It should look like this in the scene tree:
  84. .. image:: img/scripting_scene_tree.png
  85. Use the 2D editor to position and resize the button and label so that they
  86. look like the image below. You can set the text in the Inspector pane.
  87. .. image:: img/label_button_example.png
  88. Finally, save the scene, with a name such as "sayhello.tscn"
  89. .. _doc_scripting-adding_a_script:
  90. Adding a script
  91. ~~~~~~~~~~~~~~~
  92. Right click on the panel node, and then select "Add Script" in the context
  93. menu:
  94. .. image:: img/add_script.png
  95. The script creation dialog will pop up. This dialog allows you to set the
  96. language, class name, and other relevant options.
  97. Actually, in GDScript, the file itself represents the class, so in this case,
  98. the class name field is not editable.
  99. The node we're attaching the script to is a panel, so the "Inherits" field
  100. should automatically be filled in with "Panel". This is what we want as our
  101. script's goal is to extend this panel node's functionality.
  102. Finally, enter a path name for the script and select "Create":
  103. .. image:: img/script_create.png
  104. Once this is done, the script will be created and added to the node. You can
  105. see this both as an extra icon in the node as well as in the script property:
  106. .. image:: img/script_added.png
  107. To edit the script, select either of the highlighted buttons. This will bring
  108. you to the script editor where an existing template will be included by default:
  109. .. image:: img/script_template.png
  110. There is not much in there. The "_ready()" function is called when the
  111. node (and all its children) enter the active scene. (Note: "_ready()" is not
  112. the a constructor; the constructor is "_init()").
  113. The role of the script
  114. ~~~~~~~~~~~~~~~~~~~~~~
  115. A script adds behavior to a node. It is used to control how the node functions
  116. as well as how it interacts with other nodes (children, parent, siblings,
  117. etc.). The local scope of the script is the node. In other words, the script
  118. inherits the functions provided by that node.
  119. .. image:: /img/brainslug.jpg
  120. Handling a signal
  121. ~~~~~~~~~~~~~~~~~
  122. Signals are "emitted" when some specific kind of action happens, and they can be
  123. connected to any function of any script instance. Signals are used mostly in
  124. GUI nodes (although other nodes have them too, and you can even define custom
  125. signals in your own scripts).
  126. In this step, we'll connect the "pressed" signal to a custom function.
  127. The editor provides an interface for connecting signals to your scripts. You
  128. can access this by selecting the node in the scene tree and then selecting the
  129. "Node" tab. Next, make sure that you have "Signals" selected.
  130. .. image:: img/signals.png
  131. At this point, you could use the visual interface to hook up the "pressed"
  132. signal by double clicking on it and selecting a target node that already has a
  133. script attached to it. But for the sake of learning, we're going to code up the
  134. connection manually.
  135. To accomplish this, we will introduce a function that is probably the most used
  136. by Godot programmers, namely :ref:`Node.get_node() <class_Node_get_node>`.
  137. This function uses paths to fetch nodes anywhere in the scene, relative to the
  138. node that owns the script.
  139. In our case, because the button and the label are siblings under the panel
  140. where the script is attached, you can fetch the button as follows:
  141. ::
  142. get_node("Button")
  143. Next, write a function which will be called when the button is pressed:
  144. .. tabs::
  145. .. code-tab:: gdscript GDScript
  146. func _on_button_pressed():
  147. get_node("Label").text="HELLO!"
  148. .. code-tab:: csharp
  149. // i dont know how this is supposed to be in C#
  150. .. group-tab:: VS
  151. .. image:: img/signals.png
  152. Finally, connect the button's "pressed" signal to that callback in _ready(), by
  153. using :ref:`Object.connect() <class_Object_connect>`.
  154. ::
  155. func _ready():
  156. get_node("Button").connect("pressed",self,"_on_button_pressed")
  157. The final script should look basically like this:
  158. ::
  159. extends Panel
  160. func _on_button_pressed():
  161. get_node("Label").text="HELLO!"
  162. func _ready():
  163. get_node("Button").connect("pressed",self,"_on_button_pressed")
  164. Run the scene and press the button. You should get the following result:
  165. .. image:: img/scripting_hello.png
  166. Why hello there! Congratulations on scripting your first scene.
  167. **Note:** A common misunderstanding in this tutorial is how get_node(path)
  168. works. For some given node, get_node(path) searches its immediate children.
  169. In the above code, this means that *Button* must be a child of *Panel*. If
  170. *Button* were instead a child of *Label*, the code to obtain it would be:
  171. ::
  172. # not for this case
  173. # but just in case
  174. get_node("Label/Button")
  175. Also, remember that nodes are referenced by name, not by type.