Scenes, nodes, scripts, and signals

These are the four fundamental concepts Godot games rely on: scenes, nodes, scripts, and signals.
We already saw them in action in our first project.
This guide will help you understand those concepts a bit more. You can come back to it anytime for a refresher.
To understand nodes and scenes, we have to differentiate between Godot as an editor and running a game with the Godot engine.
A running Godot game is made of a lot of nodes. Together, all your running game's nodes form the scene tree: nodes with more nodes as their children. But we edit and assemble the entire game's scene tree from slices we call scenes.
Scenes are templates representing a character, an enemy, a level, or any reusable piece of our game. When Godot runs, it reads scene files and recreates the according nodes.
Now, scenes and nodes don't do much without scripts. A script is a file containing code that you attach to nodes. The code executes on the nodes to which you attach the script.
Finally, you can make scripts react to events in the game world using signals. Signals are messages nodes emit when something specific happens to them, like a timer running out, a player pressing a key, or any other event we might want to react to.

A Godot game is made of scenes

In Godot, you will break down your game into multiple scenes. A scene is a saved file representing a tree of nodes.
A scene can be anything meaningful in your game, such as a character, a weapon, a door, a house, or an entire game level.
A scene can be of any size and complexity. When designing a scene, we focus on making a single thing for the game, like a character or a menu. If we need twenty nodes to do so, we use twenty nodes. If we need just three, we use three.
Scenes don't exist in the running game!
Scenes are saved files, which Godot uses as a template to create nodes.
They are an instruction set, like a recipe, that tells Godot what it needs to recreate the piece of gameplay you need: which nodes, which assets (images, sounds, etc.), and so on. That's why Godot technically calls the scene files in your project PackedScene resources. They're files used to store the steps to reproduce components you design in the editor.
In the running game, when you instantiate a scene into another, you are left with a tree of nodes. However, it is common for community members to still refer to scene instances as "scenes". So, people use the word to designate both scene files in the editor and instances created based on those scene files in the running game, like your player's character or a bunch of mobs.

You can nest scenes

Imagine that you have several scenes: a room, a teleporter, and a chest. You could make a playable level scene by combining them into a new scene, as you did in the course introduction.
You can duplicate scenes as many times as you need. For example, your chest scene is a blueprint for making new chests.
We call each chest in your game an instance: a concrete reproduction of the scene. You'll learn more about creating instances throughout the course.

Nodes are your smallest building blocks

To create scenes, you need small building blocks. In Godot, we call them nodes.
Nodes are like Lego blocks. They are the basic construction blocks of a game. Godot provides dozens of them. Here are four examples:
  • The Sprite2D node displays an image and lets you move, rotate, and scale it.
  • AudioStreamPlayer2D can play a sound or music soundtrack.
  • Area2D detects when another area or physics body touches it.
  • Timer counts down the time and emits a signal every time it times out.
Nodes provide you with all the essential features you need to make a game. For example, you can detect when the player is near a chest and tries to open it with an Area2D. You can also use them to know when a character took a hit and should lose health.
Notice how some nodes have the "2D" suffix. Godot supports 2D and 3D games, and many nodes have 2D and 3D versions. The suffix and icon's color distinguish them.
By themselves, nodes often don't do anything. They are part of the library of code Godot provides you. To bring nodes to life, you need to attach a script to them.

Scripts

Scripts are files containing code that you attach to a node in Godot.
We use GDScript code exclusively in this course, but Godot supports multiple programming languages for experienced game developers who need that.
It's best to think of scripts like parasites that attach to compatible hosts and take control of them.
Each node comes with a library of code that doesn't do much by default. This code is waiting for you to use it. To do so, you write instructions in a script.
Your script will typically start with the extends keyword followed by a node type.
What you write on this first line restricts compatible nodes. For example, a script starting with the following code is only compatible with sprites and nodes derived from sprites.
extends Sprite2D
The extends keyword means that "this script extends the code of that node type," giving your script access to all the functions and variables the Godot developers coded for that node.
For example, every Timer node has a start() function that starts the timer. To use this function on the Timer node, you have to:
  1. Create a Timer node.
  2. Attach a script to the Timer node starting with the code extends Timer.

Signals

You can do a lot with just nodes and scripts, but you will quickly face a problem. Imagine a bullet that flies towards a monster. You want to know precisely when the bullet touches the monster and subtract health at that moment.
To solve this problem, Godot has a feature named signals. They are messages you can listen to, which tell you exactly when an event occurs.
You can think of signals like radio broadcasts. The radio sends a message even if no one is listening. Entities that do receive the message can decide to react to it or not.
For example, when boosting the ship, we start a Timer in our project. We want to know when the timer times out and lower the ship's speed back.
To do so, we connect to the timeout signal. When the Timer ends, it emits the signal.
We connect signals to functions. When the timeout signal emits, Godot calls the connected function and runs its code, which is how we react to the signal.

In summary

Signals, scripts, nodes, and scenes. They all work together to help you make games:
In the Godot editor:
  • You create scenes that describe the node structure of your game
  • You combine nodes in scenes, with each node adding some new functionality
  • You add scripts with instructions and logic
  • You connect signals to script functions to react to events
  • You combine smaller scenes into larger scenes to make the game
When a Godot game runs:
  • It recreates node trees according to the blueprint in your scene files
  • It initializes the attached scripts that take control of nodes and "pilot" them
  • It waits for events such as key inputs or timers to run functions in the scripts
Note that these concepts are specific to Godot, as every game engine works differently.
You will not find nodes themselves in other game engines. However, you will find sprites, sound players, areas, and so on. They'll just work differently.

Lesson Q&A

Use this space for questions related to what you're learning. For any other type of support (website, learning platform, payments, etc...) please get in touch using the contact form.

  • Does "extends" have anything to do with traditional inheritance models? EdwardI saw that combination of "class" and "extends" and immediately assumed this was something like what you see in Java classes where the behavior of the class at the bottom of the inheritance tree is the summation of all of the classes above it in the tree as you travel to the root class. So a Camera2D node is a Node2D, which is a Node - so you can get to Node and Node2D methods from a Camera2D node. 4 2 Feb. 04, 2024
  • 2D vs 3DDamianIt appears clear to me why certain nodes have 2D and 3D versions (like for cameras). But for the audio? What difference would it make if I were to use a 2D instead of a 3D node or vice versa? 1 1 Feb. 26, 2024
  • Can my scene extend another scene instead of extending one from the framework?broken-leopardIs it possible to extend a scene we just created? What would happen if I create a scene "TransportShip" with "extends Ship". As it seems we can only extend from one entity...will it still have access to all the Sprite2D features? What about the Scripts attached to the Ship.tscn (ship.gd). How can we inherit this? 1 0 Jun. 29, 2024
  • Typo in the article ? g1lg1lin the **in summary** section **"*When a Godot game runs:*"** > It recreates node trees according to the **bluepring** in your scene files is **bluepring** a typo ? do you mean **blueprint**? 1 0 Apr. 18, 2024
  • Scenes definitionkokolalaTo my opinion provided definition of scenes on this pages lacks clarity. For me the difference between scenes and nodes was not clear until I found definition of scene in official godot docs. > *A tree of nodes is called a scene.* 2 0 Mar. 14, 2024
  • Thanks!tesfalconThis intro gives me the basis I need to get started on my first game. I have a plan for an awesome 2D game, but the documentation that came with Godot was severely lacking and confusing. After taking this course, I think I have enough of a grounding to get started and see how far I can go. Learning the various built-in methods and functions will be the major slow down at this point. Unlike the example games you used, my primary game is much simpler since it combines both Merge mechanics and Match3. I wrote a version of "1024" in JavaScript when I went through that course, so I'm hopeful that between that coding history and Godot's graphical engine I'll be able to make a "Candy Crush" clone in short order. 2 0 Feb. 16, 2024
Site is in BETA!found a bug?