Learn Godot - Nodes, Scenes, & Instancing

#Introduction

Welcome to episode 4 of the Learn Godot series. In episode 3, you installed Godot, created your first project, and ran a simple scene. Now we build the core of gameplay: nodes, scenes, and instancing — three concepts that make you truly feel like you're "assembling a game" instead of "writing a program."

In a moment, you'll understand why Godot is said to have a scene-based architecture: there's almost no boundary between the editor and code. This episode's roadmap: getting to know node types, assembling scenes and hierarchies, instancing scenes as reusable prefabs, then grouping nodes for scene organization.

#Getting to Know Node Types

Godot has hundreds of nodes, but for most games you only need to master a handful of core ones. Don't stress about other nodes you haven't met yet — the following group covers more than ninety percent of your early game needs. Here are the main groups:

• Node2D — the base of all 2D nodes. It has position, rotation, and scale; the ancestor of sprites, physics bodies, and 2D cameras.
• Control — the base of all UI nodes. Buttons, labels, panels, and containers are all Control descendants; we'll dissect them in episode 8.
• Node3D — (formerly named Spatial) the base of all 3D nodes: meshes, lights, and 3D cameras. Episode 7 will cover this.
• Area2D — a detection zone that fires signals when other objects enter or exit. Ideal for item pickups, damage areas, and trigger zones.
• RigidBody2D — a body fully managed by the physics engine; you push it, and physics computes the rest.
• CharacterBody2D — a body you fully control through code; the standard for players and enemies with manual movement.

Choosing the right node determines how much code you have to write. Use CharacterBody2D for characters driven by code, RigidBody2D for objects that need realistic physics, and Area2D for detection without needing real collision physics. To see this at a glance:

#Creating a Basic Scene and Node Hierarchy

A scene is just one root node along with its children. Create a simple character scene: a CharacterBody2D root, then add a Sprite2D child for visuals and a CollisionShape2D for the collision shape. Click the node in the Scene panel, then click the + button to add a child. The final structure:

Player (CharacterBody2D)
├── Sprite2D
└── CollisionShape2D

This arrangement isn't just cosmetic. Because Sprite2D is a child of CharacterBody2D, the sprite automatically moves when the body moves. Add a Camera2D as a child and the camera will follow the character automatically too. This is the power of hierarchy: properties flow from parent to child.

Root node selection matters too: a Player scene rooted in CharacterBody2D can move with move_and_slide in episode 5, while a Room scene only needs Node2D since it's just a container. The simple rule: choose the most specific root that still meets your needs, not always the most general node.

#Instancing Scenes and Reusable Prefabs

Once the Player scene is done, save it as player.tscn. Now you can use it in any scene — this is called instancing: creating an instance of a scene. In Godot 4, the term "prefab" from other engines feels redundant because instancing is already a natural part of the workflow.

There are two ways to instance a scene: visually (drag the scene from the FileSystem to the viewport) and via code. The latter is more flexible, for example to spawn bullets when the player shoots:

Instancing a bullet scene from code

const Peluru = preload("res://scenes/bullet.tscn")
 
func tembak() -> void:
    var peluru = Peluru.instantiate()
    peluru.position = $Muzzle.global_position
    add_child(peluru)

Notice the pattern: preload loads the scene once at the start, instantiate() creates a new copy, properties are set, then add_child adds the instance to the scene tree. Each instance is an independent object — a single bullet scene can spawn hundreds of bullets without conflicts.

One thing to remember: as soon as add_child is called, the node enters the scene tree and the _ready callback in its script runs immediately. So make sure all needed properties are set before add_child, not after. To remove an instance that's no longer used, call queue_free() — the removal is deferred until the end of the frame, keeping it safe from physics conflicts.

The preload + instantiate + add_child pattern is one of the most common idioms in GDScript. Get used to writing it until it sticks, because you'll use it in almost every 2D and 3D game project.

#Grouping Nodes and Scene Organization

The bigger a scene gets, the more important organization becomes. Godot provides two main tools: node folders and groups.

Node folders are just empty nodes that serve as containers — for example, an Enemies node holding all enemies, or a UI node holding all interface elements. This keeps the hierarchy easy to read and enables shared transforms.

Groups are smarter: you can tag any node with a group name, then call all of its members at once. This is far better than looking up nodes one by one. Example usage:

Calling all nodes in one group

func nonaktifkan_semua_musuh() -> void:
    for musuh in get_tree().get_nodes_in_group("enemies"):
        musuh.berhenti()
 
func daftarkan_musuh() -> void:
    add_to_group("enemies")

Groups can be configured from the Inspector (Node tab, then Groups tab) or via add_to_group in code. Tagging enemies with an enemies group makes your code much shorter than manually storing a reference to every enemy.

A node can also belong to many groups at once — for example, an enemy could be in both the enemies and flying groups simultaneously. This is useful when you want to call a specific subset of objects from code. Keep in mind that groups are runtime-based and the call order of members isn't guaranteed, so make sure the called methods don't depend on each other.

#Small Practice: A Room Scene with Enemies

Put it all together: create a Room scene with a Node2D root, add a Player instance, a few enemy instances (just drag the enemy scene a few times), an Area2D as the exit door, and a node folder named Enemies to hold all enemies. Tag each enemy instance with the enemies group via the Inspector. Now you have a clean, reusable scene structure ready to be programmed in episode 5.

Once assembled, press play and make sure the scene stays intact when running. Don't hesitate to use the debug output to check whether the enemies group is correctly populated — we'll learn how in episode 5.

#Conclusion

Nodes, scenes, and instancing are the three pillars you'll use every day. You now know how to choose the right node type (Node2D, Control, Node3D, Area2D, RigidBody2D, CharacterBody2D), build scene hierarchies whose properties flow from parent to child, instance scenes as reusable components, and organize scenes with node folders and groups.

The key takeaways:

• Choose nodes by role: CharacterBody2D for characters, RigidBody2D for passive physics, Area2D for detection.
• Scene hierarchies make properties and transforms flow from parent to child.
• Instancing lets a single scene spawn many independent copies via instantiate().
• preload loads a scene, add_child adds it to the scene tree.
• Node folders for visual organization, groups to call many nodes at once.

In the next episode, episode 5, we bring these scenes to life with GDScript: basic syntax, variables, functions, classes, signals, input handling, lifecycle callbacks, and debugging and logging. This is the episode where you stop merely "assembling" and start "programming" games.