scene_tree.rst 5.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154
  1. .. _doc_scene_tree:
  2. SceneTree
  3. =========
  4. Introduction
  5. ------------
  6. This is where things start getting abstract, but don't panic, as
  7. there's not really more depth than this.
  8. In previous tutorials, everything revolves around the concept of
  9. nodes, scenes are made of them, and they become active once they enter
  10. the *scene tree*.
  11. This concept deserves going into a little more detail. In fact, the
  12. scene system is not even a core component of Godot, as it is possible to
  13. skip it and write a script (or C++ code) that talks directly to the
  14. servers. But making a game that way would be a lot of work.
  15. MainLoop
  16. --------
  17. The way Godot works internally is as follows. There is the
  18. :ref:`OS <class_OS>` class,
  19. which is the only instance that runs at the beginning. Afterwards, all
  20. drivers, servers, scripting languages, scene system, etc are loaded.
  21. When initialization is complete, :ref:`OS <class_OS>` needs to be
  22. supplied a :ref:`MainLoop <class_MainLoop>`
  23. to run. Up to this point, all this is internals working (you can check
  24. main/main.cpp file in the source code if you are ever interested to
  25. see how this works internally).
  26. The user program, or game, starts in the MainLoop. This class has a few
  27. methods, for initialization, idle (frame-syncronized callback), fixed
  28. (physics-synchronized callback), and input. Again, this is really low
  29. level and when making games in Godot, writing your own MainLoop does not
  30. even make sense.
  31. SceneTree
  32. ---------
  33. One of the ways to explain how Godot works, is that it's a high level
  34. game engine over a low level middleware.
  35. The scene system is the game engine, while the :ref:`OS <class_OS>`
  36. and servers are the low level API.
  37. In any case, the scene system provides its own main loop to OS,
  38. :ref:`SceneTree <class_SceneTree>`.
  39. This is automatically instanced and set when running a scene, no need
  40. to do any extra work.
  41. It's important to know that this class exists because it has a few
  42. important uses:
  43. - It contains the root :ref:`Viewport <class_Viewport>`, to which a
  44. scene is added as a child when it's first opened, to become
  45. part of the *Scene Tree* (more on that next)
  46. - It contains information about the groups, and has means to call all
  47. nodes in a group, or get a list of them.
  48. - It contains some global state functionality, such as setting pause
  49. mode, or quitting the process.
  50. When a node is part of the Scene Tree, the
  51. :ref:`SceneTree <class_SceneTree>`
  52. singleton can be obtained by simply calling
  53. :ref:`Node.get_tree() <class_Node_get_tree>`.
  54. Root viewport
  55. -------------
  56. The root :ref:`Viewport <class_Viewport>`
  57. is always at the top of the scene. From a node, it can be obtained in
  58. two different ways:
  59. ::
  60. get_tree().get_root() # access via scenemainloop
  61. get_node("/root") # access via absolute path
  62. This node contains the main viewport, anything that is a child of a
  63. :ref:`Viewport <class_Viewport>`
  64. is drawn inside of it by default, so it makes sense that the top of all
  65. nodes is always a node of this type, otherwise nothing would be seen!
  66. While other viewports can be created in the scene (for split-screen
  67. effects and such), this one is the only one that is never created by the
  68. user. It's created automatically inside SceneTree.
  69. Scene tree
  70. ----------
  71. When a node is connected, directly or indirectly, to the root
  72. viewport, it becomes part of the *scene tree*.
  73. This means that, as explained in previous tutorials, it will get the
  74. _enter_tree() and _ready() callbacks (as well as _exit_tree()).
  75. .. image:: /img/activescene.png
  76. When nodes enter the *Scene Tree*, they become active. They get access
  77. to everything they need to process, get input, display 2D and 3D,
  78. notifications, play sound, groups, etc. When they are removed from the
  79. *scene tree*, they lose access.
  80. Tree order
  81. ----------
  82. Most node operations in Godot, such as drawing 2D, processing or getting
  83. notifications are done in tree order. This means that parents and
  84. siblings with a smaller rank in the tree order will get notified before
  85. the current node.
  86. .. image:: /img/toptobottom.png
  87. "Becoming active" by entering the *Scene Tree*
  88. ----------------------------------------------
  89. #. A scene is loaded from disk or created by scripting.
  90. #. The root node of that scene (only one root, remember?) is added as
  91. either a child of the "root" Viewport (from SceneTree), or to any
  92. child or grand-child of it.
  93. #. Every node of the newly added scene, will receive the "enter_tree"
  94. notification ( _enter_tree() callback in GDScript) in top-to-bottom
  95. order.
  96. #. An extra notification, "ready" ( _ready() callback in GDScript) is
  97. provided for convenience, when a node and all its children are
  98. inside the active scene.
  99. #. When a scene (or part of it) is removed, they receive the "exit
  100. scene" notification ( _exit_tree() callback in GDScript) in
  101. bottom-to-top order
  102. Changing current scene
  103. ----------------------
  104. After a scene is loaded, it is often desired to change this scene for
  105. another one. The simple way to do this is to use the
  106. :ref:`SceneTree.change_scene() <class_SceneTree_change_scene>`
  107. function:
  108. ::
  109. func _my_level_was_completed():
  110. get_tree().change_scene("res://levels/level2.scn")
  111. This is a quick and useful way to switch scenes, but has the drawback
  112. that the game will stall until the new scene is loaded and running. At
  113. some point in your game, it may be desired to create proper loading
  114. screens with progress bar, animated indicators or thread (background)
  115. loading. This must be done manually using autoloads (see next chapter!)
  116. and :ref:`doc_background_loading`.