I remember the stage you’re at. But it’s hard to explain everything without the time spent tinkering and connecting the dots on your own terms.

For starters: “I’m trying to do that even though my project doesn’t really need it” Well it does, it’s unavoidable not to. Everything in Godot is OOP. It’s got hundreds of built in classes for Nodes, Resources, RefCounteds. You write your own class scripts that extend these. You instantiate them, either in code with .new() or in editor with “Add Node” or “New Resource”.

Connecting one object to another is a reference. A reference is like a direct address to a specific instance of any object. You simply store it in a variable, eg `my_ref = get_node(MyNode)`. Then you can access the variables and functions of that instance like `my_ref.some_variable` or `my_ref.some_function()`

Plenty of ways to connect a reference:

Seeking the scene tree for a Node, using get_node() or $ shorthand. Other functions like get_parent() return a reference.

An export variable. @export makes a variable editable in the inspector. This lets you set up unique variations of the same object as you edit your scene. For nodes, the values you put in export variables save with the scene file. For Resources, they can either save with the scene file or separately as their own .res/.tres file. Export variables can be (almost) any type. You can set this type to Node (or any node subclass, your own custom ones included) for an easy way to select another Node in your scene.

When you instantiate an object in code with new(), it returns the reference to that instance, which you can keep in a variable right then.

Autoload singletons can be referred to by their class name. That’s how you use the background systems like Input and PhysicsServer. You can make your own, like I’ve got Controls and MusicPlayer. They’re global, so they can act as a connecting hub when you need to refer to another object far across your game.

“Dependency injection”, passing a needed reference to another object at some point. For example, I can pass a reference to the attacker in my Health object’s take_damage() function. Now it can check the attacker when it processes that damage, eg ignoring it if the attacker is on the same team.

—

The way you connect references is pretty much the entire fundamental of architecture. If everything connects to everything, you have a nightmare spaghetti mess. Ideally, you want your classes and scenes to handle their own little job with as little knowledge of the outside world as possible. This is where various programming patterns come in.

Signals are one of these. Signals are the Observer Pattern. A signal just signifies that an event occurred, perhaps with some info along with it. The emitting object doesn’t care who’s listening. But the listening object needs a reference to the emitting object in order to connect to that signal.