4. Pick the root node

4 min

Choose the node that should own a scene, and know why the others fail.

0/3 right

You need a player scene that reads input, collides with the world, shows a sprite, and follows with a camera. Which node owns the scene?

Pick the node that should own the scene. The children come after; the root decides what the scene can do.

The root decides what a scene can do, so it is the first decision in every scene you build. Three scene jobs, four candidates each. A wrong pick explains itself, because knowing why Node2D or RigidBody2D is wrong for a player is the actual lesson.

Coming from Unity developers reach for an empty GameObject and attach things; Godot wants the typed node first. Pick the body, then add the shape, the sprite and the camera under it.

To finish: Get all three roots right.

Notes

The written version of this lesson, for after you have done it.

The root decides what a scene can do, so it is the first question in every scene you build. Ask what owns the motion: if your code does, CharacterBody2D; if the physics engine does, RigidBody2D; if nothing moves, StaticBody2D; if the scene only needs to notice things, Area2D. UI gets a Control root, and a bare Node2D is for grouping things that have a position but no behaviour of their own.

Most wrong picks come from Unity's habit of starting with an empty GameObject and attaching components until it works. Godot wants the typed node first. Picking Node2D for a player and then hand-setting position skips collision entirely; picking RigidBody2D for a player hands motion to the simulation and then fights it every frame.

The Node Decision Lab has six of these jobs with every candidate explained, and the Node Explorer lists every common node with its Unity and Unreal counterpart.

Try it in the editor five minutes, in a real project

Create three empty scenes and choose the root for each before adding anything else: a coin, a wall, and a health bar.
Coin: Area2D with a CollisionShape2D. Wall: StaticBody2D with a CollisionShape2D. Health bar: Control with a ProgressBar.
Drop all three into a level scene with the Player from lesson 1 and run it. The player walks through the coin, stops at the wall, and the bar stays on screen.
Now swap the wall's root to Area2D and run again. The player walks through it: the root decided what the scene could do.

2D player controller You need a player scene that reads input, collides with the world, shows a sprite, and follows with a camera. Which node owns the scene?

CharacterBody2D the root: CharacterBody2D owns controlled physics movement. CollisionShape2D defines the body shape, Sprite2D handles visuals, and Camera2D follows the authored player scene.
Node2D not the root: Node2D has a transform and nothing else. Setting position by hand skips collision, floors, and slopes, so the player walks through walls.
RigidBody2D not the root: RigidBody2D lets the physics engine own motion. A player that must stop on a pixel and turn instantly fights the simulation every frame.
Sprite2D not the root: Sprite2D only draws. It has no velocity, no collision, and no floor detection; it belongs as a child of the body, not as the root.

Collectible pickup You need a coin, key, or powerup that reacts when the player enters it, then tells the game. Which node owns the scene?

Area2D the root: Area2D detects overlap without blocking movement. The shape defines the trigger, the animated sprite sells the pickup, and positional audio gives feedback.
StaticBody2D not the root: StaticBody2D blocks movement. The player would bump into the coin instead of passing through it, and it emits no overlap signal.
RigidBody2D not the root: RigidBody2D is a physics object that falls, bounces and pushes. A coin that only needs to notice the player does not need a simulation.
Timer not the root: Timer has no position and no shape. It can wait, but it cannot know that a body arrived.

Health and score HUD You need a screen-space UI that shows score, health, and button prompts while the world moves behind it. Which node owns the scene?

Control the root: Control nodes own responsive UI layout. Labels, ProgressBars, Buttons, and TextureRects should live in UI space instead of the world scene.
Node2D not the root: Node2D lives in world space. Put a Label under it and the score scrolls away with the level, or moves with whichever parent it landed on.
Label not the root: Label is one text field. It cannot lay out a health bar and buttons around itself; a Control container has to own that arrangement.
Camera2D not the root: Camera2D decides what the viewport shows. Children of a camera are not screen-anchored UI; they are world nodes that happen to move with the view.