I see some people in bluesky having a hard time to understand how to work with godot. As it is difficult to try explaining in detail with a 300 characters per message limit, I decided to write about it on the forum. Feel free to add any note or observation to it.
Godot Paradigm
Unreal, Unity and Godot just uses different paradigms for how to do things. Godot is one of the easiest when you get it. It follows a component approach where everything is a Node (or scene how it’s called in godot). A scene can represent a whole level or it can represent a player component.
A scene is the same as a node, the difference is just for nomenclature. A scene can be put inside another scene and when it’s inside, it’s called a node. You even can have chunks of a level made as a component to reutilize. The component approach is simple and powerful as it allows reutilization.
For clarity I will refer to Levels, Scenaries and Menu screens as Scenes, and for the Menus (inventory, stats menu, etc.), 3D and 2D objects and other objects as Scene Components as they are used just to serve as a component inside a bigger scene.
This is an example of a Scene node representing a Level, it contains other scenes (scene components) as children inside it.
This is an example of a Scene Component node representing a Player, it contains other nodes as children inside it, thos children nodes are used to create the Player scene component. Each child node has a specific reason to be added to this component.
This is an example of a Scene Component that has other Scene Component as a child node. You can have how many Scene Components inside each other, it helps us to organize our project.
Project Organization
Following a component approach needs a kind of organization oriented to it in our File System. I like to have a folder for assets where I can put a folder for textures, other for 3d models (glb), a scene folder for the levels and a component folder for the scenes that will be just reusable components.
So it follows a structure like that:
Having the same asset on the Assets folder and on the 3DModels folder for example can give a problem when you need to make changes on your asset, because you can change a version different from the one being used in your Scene Component. I normally put the files saved from the external program on the assets folder and I export a version on the Scene Component folder to be used in the project. For example, if I’m working on an image on Krita, I will save a .kra file in the Assets folder and a .png file in the ActionBar/Sprites folder (godot doesn’t show the .kra files on his FileSystem tree view, so it can’t be seen on the example image).
If you are working on a Scene Component that doesn’t uses sounds for example, you don’t need to add a folder for it.
This organization approach make easy to work in a team where each member of the team can work in a specific Scene Component and add them to the Scene when they are finished.
Node Hierarchy
Nodes follows a Hierarchy, where the first node is the root of the Scene/Scene Component and others are it’s children.
The children nodes follows the parameters and behaviors described in their parent, so if, for example, you scale the parent node, the children will scale too.
Also, when you are trying to reference a node in a script, you need to get it’s path and it will follow the node Hierarchy order. The path for the reference to get the node that you want will be relative to which node the script is attached.
The node path works similar to the linux path when you use cd command in terminal. So, if you want to get a reference to the node that contains the script you can use a dot, to get to it’s parent you can use double dot, and to reference a child you can just type it’s name.
Node References in Script
When you have multiple Scene Components in your Scene, sometimes you will want to make a script on a Node from a Scene Component to comunicate with a Node in other Scene Component. When you try it, things can start being messy because they don’t see each other.
Imagine that you have this script in your Player Scene Component:
For this problem you can have different approaches as:
1. Get the reference with the node path from your main scene.
Node hiearchy:
Level
CharacterBody3D - Player
Control - HUD
Control - ActionBar
HBoxContainer
TextureButton - Slot1
this approach has a pro that it can work for any case, so you can get a reference to a node on every place from the Scene node tree.
The cons are that it can turn the paths into a very long string depending of the reference, also if the node being referenced changes place in the node tree, the reference will stops working. Also the reference will just work when running just the Scene and not the Scene Component, so it can be more difficult to test the component and it can bring problems when working in a team.
2. Have a Script in your root node from your Scene Component with a @export variable to hold the reference. For this you will need to declare the type of the variable to be the same as the type of the node being referenced.
You can even add a class_name to the script being referenced so you can define the type of your @export variable to be the same as your class.
class being referenced
Use of the reference
after creating a variable with @export the variable will be exposed to the Inspector where you can assing the reference
The pro of this approach is that you can change the position of the node being referenced on your node tree.
The cons is that to get this reference you need to put your script on the root of the Scene Component, so if you have a Hud Scene Component and an Action Bar Scene Component inside of the Hud, you can have problems assigning the reference to a node inside of your Scene Level. (this is why you need to attach the script to your node root).
When you try to assign a reference, you can just get a reference to nodes in the same Scene.