singletons_autoload.rst 10 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321
  1. .. _doc_singletons_autoload:
  2. Singletons (Autoload)
  3. =====================
  4. Introduction
  5. ------------
  6. Godot's scene system, while powerful and flexible, has a drawback: there is no
  7. method for storing information (e.g. a player's score or inventory) that is
  8. needed by more than one scene.
  9. It's possible to address this with some workarounds, but they come with their
  10. own limitations:
  11. - You can use a "master" scene that loads and unloads other scenes as
  12. its children. However, this means you can no longer run those scenes
  13. individually and expect them to work correctly.
  14. - Information can be stored to disk in ``user://`` and then loaded by scenes
  15. that require it, but frequently saving and loading data is cumbersome and
  16. may be slow.
  17. The `Singleton pattern <https://en.wikipedia.org/wiki/Singleton_pattern>`_ is
  18. a useful tool for solving the common use case where you need to store
  19. persistent information between scenes. In our case, it's possible to reuse the
  20. same scene or class for multiple singletons as long as they have different
  21. names.
  22. Using this concept, you can create objects that:
  23. - Are always loaded, no matter which scene is currently running.
  24. - Can store global variables such as player information.
  25. - Can handle switching scenes and between-scene transitions.
  26. - *Act* like a singleton, since GDScript does not support global variables by design.
  27. Autoloading nodes and scripts can give us these characteristics.
  28. .. note::
  29. Godot won't make an Autoload a "true" singleton as per the singleton design
  30. pattern. It may still be instanced more than once by the user if desired.
  31. .. tip::
  32. If you're creating an autoload as part of an editor plugin, consider
  33. :ref:`registering it automatically in the Project Settings <doc_making_plugins_autoload>`
  34. when the plugin is enabled.
  35. Autoload
  36. --------
  37. You can create an Autoload to load a scene or a script that inherits from
  38. :ref:`class_Node`.
  39. .. note::
  40. When autoloading a script, a :ref:`class_Node` will be created and the script will be
  41. attached to it. This node will be added to the root viewport before any
  42. other scenes are loaded.
  43. .. image:: img/singleton.webp
  44. To autoload a scene or script, start from the menu and navigate to
  45. **Project > Project Settings > Globals > Autoload**.
  46. .. image:: img/autoload_tab.webp
  47. Here you can add any number of scenes or scripts. Each entry in the list
  48. requires a name, which is assigned as the node's ``name`` property. The order of
  49. the entries as they are added to the global scene tree can be manipulated using
  50. the up/down arrow keys. Like regular scenes, the engine will read these nodes
  51. in top-to-bottom order.
  52. .. image:: img/autoload_example.webp
  53. If the **Enable** column is checked (which is the default), then the singleton can
  54. be accessed directly in GDScript:
  55. .. tabs::
  56. .. code-tab:: gdscript GDScript
  57. PlayerVariables.health -= 10
  58. The **Enable** column has no effect in C# code. However, if the singleton is a
  59. C# script, a similar effect can be achieved by including a static property
  60. called ``Instance`` and assigning it in ``_Ready()``:
  61. .. tabs::
  62. .. code-tab:: csharp
  63. public partial class PlayerVariables : Node
  64. {
  65. public static PlayerVariables Instance { get; private set; }
  66. public int Health { get; set; }
  67. public override void _Ready()
  68. {
  69. Instance = this;
  70. }
  71. }
  72. This allows the singleton to be accessed from C# code without ``GetNode()`` and
  73. without a typecast:
  74. .. tabs::
  75. .. code-tab:: csharp
  76. PlayerVariables.Instance.Health -= 10;
  77. Note that autoload objects (scripts and/or scenes) are accessed just like any
  78. other node in the scene tree. In fact, if you look at the running scene tree,
  79. you'll see the autoloaded nodes appear:
  80. .. image:: img/autoload_runtime.webp
  81. .. warning::
  82. Autoloads must **not** be removed using ``free()`` or ``queue_free()`` at
  83. runtime, or the engine will crash.
  84. Custom scene switcher
  85. ---------------------
  86. This tutorial will demonstrate building a scene switcher using autoloads.
  87. For basic scene switching, you can use the
  88. :ref:`SceneTree.change_scene_to_file() <class_SceneTree_method_change_scene_to_file>`
  89. method (see :ref:`doc_scene_tree` for details). However, if you need more
  90. complex behavior when changing scenes, this method provides more functionality.
  91. To begin, download the template from here:
  92. `singleton_autoload_starter.zip <https://github.com/godotengine/godot-docs-project-starters/releases/download/latest-4.x/singleton_autoload_starter.zip>`_
  93. and open it in Godot.
  94. A window notifying you that the project was last opened in an older Godot version
  95. may appear, that's not an issue. Click *Ok* to open the project.
  96. The project contains two scenes: ``scene_1.tscn`` and ``scene_2.tscn``. Each
  97. scene contains a label displaying the scene name and a button with its
  98. ``pressed()`` signal connected. When you run the project, it starts in
  99. ``scene_1.tscn``. However, pressing the button does nothing.
  100. Creating the script
  101. ~~~~~~~~~~~~~~~~~~~~~
  102. Open the **Script** window and create a new script called ``global.gd``.
  103. Make sure it inherits from ``Node``:
  104. .. image:: img/autoload_script.webp
  105. The next step is to add this script to the autoLoad list.
  106. Starting from the menu, open
  107. **Project > Project Settings > Globals > Autoload** and
  108. select the script by clicking the browse button or typing its path:
  109. ``res://global.gd``. Press **Add** to add it to the autoload list:
  110. .. image:: img/autoload_tutorial1.webp
  111. Now whenever we run any scene in the project, this script will always be loaded.
  112. Returning to the script, it needs to fetch the current scene in the
  113. `_ready()` function. Both the current scene (the one with the button) and
  114. ``global.gd`` are children of root, but autoloaded nodes are always first. This
  115. means that the last child of root is always the loaded scene.
  116. .. tabs::
  117. .. code-tab:: gdscript GDScript
  118. extends Node
  119. var current_scene = null
  120. func _ready():
  121. var root = get_tree().root
  122. # Using a negative index counts from the end, so this gets the last child node of `root`.
  123. current_scene = root.get_child(-1)
  124. .. code-tab:: csharp
  125. using Godot;
  126. public partial class Global : Node
  127. {
  128. public Node CurrentScene { get; set; }
  129. public override void _Ready()
  130. {
  131. Viewport root = GetTree().Root;
  132. // Using a negative index counts from the end, so this gets the last child node of `root`.
  133. CurrentScene = root.GetChild(-1);
  134. }
  135. }
  136. Now we need a function for changing the scene. This function needs to free the
  137. current scene and replace it with the requested one.
  138. .. tabs::
  139. .. code-tab:: gdscript GDScript
  140. func goto_scene(path):
  141. # This function will usually be called from a signal callback,
  142. # or some other function in the current scene.
  143. # Deleting the current scene at this point is
  144. # a bad idea, because it may still be executing code.
  145. # This will result in a crash or unexpected behavior.
  146. # The solution is to defer the load to a later time, when
  147. # we can be sure that no code from the current scene is running:
  148. _deferred_goto_scene.call_deferred(path)
  149. func _deferred_goto_scene(path):
  150. # It is now safe to remove the current scene.
  151. current_scene.free()
  152. # Load the new scene.
  153. var s = ResourceLoader.load(path)
  154. # Instance the new scene.
  155. current_scene = s.instantiate()
  156. # Add it to the active scene, as child of root.
  157. get_tree().root.add_child(current_scene)
  158. # Optionally, to make it compatible with the SceneTree.change_scene_to_file() API.
  159. get_tree().current_scene = current_scene
  160. .. code-tab:: csharp
  161. public void GotoScene(string path)
  162. {
  163. // This function will usually be called from a signal callback,
  164. // or some other function from the current scene.
  165. // Deleting the current scene at this point is
  166. // a bad idea, because it may still be executing code.
  167. // This will result in a crash or unexpected behavior.
  168. // The solution is to defer the load to a later time, when
  169. // we can be sure that no code from the current scene is running:
  170. CallDeferred(MethodName.DeferredGotoScene, path);
  171. }
  172. public void DeferredGotoScene(string path)
  173. {
  174. // It is now safe to remove the current scene.
  175. CurrentScene.Free();
  176. // Load a new scene.
  177. var nextScene = GD.Load<PackedScene>(path);
  178. // Instance the new scene.
  179. CurrentScene = nextScene.Instantiate();
  180. // Add it to the active scene, as child of root.
  181. GetTree().Root.AddChild(CurrentScene);
  182. // Optionally, to make it compatible with the SceneTree.change_scene_to_file() API.
  183. GetTree().CurrentScene = CurrentScene;
  184. }
  185. Using :ref:`Object.call_deferred() <class_Object_method_call_deferred>`,
  186. the second function will only run once all code from the current scene has
  187. completed. Thus, the current scene will not be removed while it is
  188. still being used (i.e. its code is still running).
  189. Finally, we need to fill the empty callback functions in the two scenes:
  190. .. tabs::
  191. .. code-tab:: gdscript GDScript
  192. # Add to 'scene_1.gd'.
  193. func _on_button_pressed():
  194. Global.goto_scene("res://scene_2.tscn")
  195. .. code-tab:: csharp
  196. // Add to 'Scene1.cs'.
  197. private void OnButtonPressed()
  198. {
  199. var global = GetNode<Global>("/root/Global");
  200. global.GotoScene("res://Scene2.tscn");
  201. }
  202. and
  203. .. tabs::
  204. .. code-tab:: gdscript GDScript
  205. # Add to 'scene_2.gd'.
  206. func _on_button_pressed():
  207. Global.goto_scene("res://scene_1.tscn")
  208. .. code-tab:: csharp
  209. // Add to 'Scene2.cs'.
  210. private void OnButtonPressed()
  211. {
  212. var global = GetNode<Global>("/root/Global");
  213. global.GotoScene("res://Scene1.tscn");
  214. }
  215. Run the project and test that you can switch between scenes by pressing
  216. the button.
  217. .. note::
  218. When scenes are small, the transition is instantaneous. However, if your
  219. scenes are more complex, they may take a noticeable amount of time to appear.
  220. To learn how to handle this, see the next tutorial: :ref:`doc_background_loading`.
  221. Alternatively, if the loading time is relatively short (less than 3 seconds or so),
  222. you can display a "loading plaque" by showing some kind of 2D element just before
  223. changing the scene. You can then hide it just after the scene is changed. This can
  224. be used to indicate to the player that a scene is being loaded.