Learn Godot - Core Concepts & Godot Architecture

#Introduction

Welcome to episode 2 of the Learn Godot series. In episode 1, we discussed the history, open-source philosophy, and Godot's advantages over other engines. Now we dive into the heart of its architecture — the concepts that will become your way of thinking while developing games.

One important emphasis: you won't "write a game" in Godot like writing a regular program. You'll assemble scenes from a collection of nodes, then connect them through signals. Understanding this architecture early on will save you from major confusion in the episodes ahead. Roadmap: the scene tree and nodes, the resource system, scene inheritance, the signal system, and export templates.

#Scene Tree and Node Architecture

In Godot, almost everything is a node — characters, cameras, sounds, UI buttons, all are nodes. Nodes are arranged in a hierarchical tree called the scene tree, with a single root node and branching children. Every scene you create is actually one branch of this scene tree; when the game runs, all active scenes merge into one giant tree.

The best way to understand this structure is to read it directly:

GameRoot (Node2D)
├── Player (CharacterBody2D)
│   ├── CollisionShape2D
│   └── Sprite2D
├── Enemies (Node2D)
│   └── Enemy (CharacterBody2D)
└── Camera (Camera2D)

A node's position in the tree determines many things: child nodes inherit the transform of their parent node, and _ready events are called in order from parent to child. This hierarchy is what makes Godot so visual and easy to reason about.

It's worth emphasizing: the scene tree is a runtime concept, not just an editor arrangement. When the game runs, all active scenes — characters, level, UI — enter a single global scene tree accessible from any code via get_tree(). This is the bridge that connects scripts, nodes, and scenes to one another.

#The Resource System

If nodes are the "objects" inside a game, resources are the data that nodes load. Sprite textures, sounds, materials, fonts — all are resources. The difference: resources are reusable and shareable. A single resource can be used by many nodes, and changing the resource once will be visible to all its users.

The most concrete example: a single sprite texture can be used by hundreds of enemies without duplicating data in memory. Within a project, resources are stored as files like .png, .wav, or .tres (text resource). Godot also supports custom resources through the extends Resource keyword — the foundation of stats, item, or card systems in your games later.

A custom resource is stored as a text file you can read directly. An example .tres file for character stats:

[gd_resource type="Resource" script_class="Statistik" load_steps=2]
 
[ext_resource type="Script" path="res://scripts/statistik.gd" id="1"]
 
[resource]
script = ExtResource("1")
nyawa = 100
serangan = 10

Files like this can be created in the editor or written by hand, and their values can be changed at any time without touching code. In episodes 4 and 9, we'll use this pattern for item data and game save/load.

#Scene Inheritance and Reusable Components

The most powerful concept in Godot is scene inheritance. You can create a base scene (for example, a generic enemy), then derive new scenes that inherit its entire structure, properties, and script. Change the parent scene, and all its descendants change too. This is the reuse pattern that keeps large projects maintainable.

There are two kinds of reuse in Godot:

• Instancing: making a copy of a scene inside another scene. A single bullet scene can be instantiated hundreds of times during gameplay.
• Inheritance: creating a child scene that inherits a parent scene, then adding or changing something. For example, an Enemy scene derived into a FlyingEnemy scene with different speed and attack type properties.

In the editor, an inherited scene is created by right-clicking a scene in the FileSystem and choosing New Inherited Scene. Interestingly, a derived scene doesn't store a full copy of its parent's structure — it only stores the differences. This keeps projects lean, and changes to the parent propagate directly to all descendants.

Combining both allows you to build a library of components that assemble like Lego — a pattern we'll practice in detail in episode 4.

#The Signal System and Scripting API

Communication between nodes is a classic puzzle in game engines. Godot solves it with signals — a very simple event system: a node emits a signal, and other nodes may listen and react. Nodes don't need to know about each other directly; they only need to connect through signals.

An example of declaring and using a signal in GDScript:

Declaring and emitting a signal

signal skor_berubah(nilai: int)
 
var skor := 0
 
func tambah_poin(jumlah: int) -> void:
    skor += jumlah
    skor_berubah.emit(skor)

You can declare your own signals, but thousands of built-in signals are already provided by nodes — for example, body_entered for collision detection or pressed for UI buttons. On top of signals, Godot also provides a complete scripting API: every node can be accessed and modified through script, with properties like position, rotation, and scale.

Connecting a signal can be done through the Node tab in the Inspector, or directly in code:

Connecting a signal via code

func _ready() -> void:
    $TombolMulai.pressed.connect(_on_mulai_ditekan)
 
func _on_mulai_ditekan() -> void:
    print("Game dimulai")

Both ways produce the same result; the code route is more flexible because it can be conditional. Note that the receiver method is written without parentheses when passed to .connect — you're passing a reference, not the result of a call.

#Export Templates and Platform Support

Godot supports exporting to many platforms, and the mechanism behind it is export templates — a collection of runtime binaries downloaded separately for each target platform. In Project Settings, you select the platform, choose the matching template, and Godot combines your project with that template into a runnable application.

Godot 4's platform support covers Windows, Linux, macOS, Android, iOS, and web (HTML5). Each platform has additional settings: a keystore for Android, entitlements for iOS, and so on. We'll practice real exports in episodes 3 and 14, so for now just understand the concept: download the template once, and the project can be shipped anywhere.

#Conclusion

Godot's architecture can be summarized in a single sentence: everything is a node, data is a resource, communication happens through signals, and reuse happens through instancing and inheritance. The scene tree arranges nodes hierarchically, resources are shared without duplication, scene inheritance keeps projects maintainable, and signals let nodes communicate without holding onto each other. Export templates seal all of that to any platform.

The key takeaways:

• Nodes compose the game; the scene tree is the hierarchy that organizes them.
• Resources are reusable data shared between nodes.
• Scene inheritance and instancing are the two reuse methods you must master.
• Signals connect nodes in a decoupled way — without direct knowledge of each other.
• Export templates let a single project run on many platforms.

In the next episode, episode 3, we start practicing: installing Godot, creating a new project, understanding the editor layout, resource folders, project settings, and running a project for the first time. Get your computer ready, because from now on we work hands-on in the editor!