Godot Fundamentals

Lecture W1T2: Nodes, Scenes, and the Scene Tree

Lucas P. Cordova, Ph.D.
lpcordova@willamette.edu

Willamette University

August 25, 2026

The Engine

Today’s agenda

LECTURE W1T2 // GODOT FUNDAMENTALS

  1. What a game engine is, and what Godot does for you.
  2. Nodes: the atom of everything in Godot.
  3. Scenes: trees of nodes you can save, instance, and compose.
  4. Editor tour, live: docks, running scenes, your first attached script.

One mental model to leave with today: a Godot game is a tree of trees.

What is a game engine?

A game engine is the reusable software layer beneath a game: rendering, physics, audio, input, asset loading, and a scripting layer that lets you write your game instead of rewriting all of that.

Without one, “move the player left” means talking to the GPU. With one, it means:

position.x -= speed * delta

Engines are also an architecture opinion. Learning Godot means learning how its designers think games should be structured, and that structure is the syllabus of this course.

Why Godot?

  • Free and open source (MIT license). No seat licenses, no revenue cut, no install fees. Yours forever.
  • Small and fast: the whole editor is a ~100 MB download that opens in seconds on a laptop.
  • 2D is first-class, not an afterthought, and our projects are 2D.
  • GDScript is Python-flavored and engine-native: minimal ceremony between you and a running game.
  • Its node and scene model is composition-based architecture, the pattern this course is about.
  • Real studios ship commercial games with it. This is not a toy.

The download link is on the course Resources page in Canvas.

The vocabulary for today

Four words carry this whole lecture:

  • Node: the smallest building block; one job each.
  • Scene: a saved tree of nodes; Godot’s unit of reuse.
  • Scene tree: the one big runtime tree your whole game lives in.
  • Instancing: placing a scene inside another scene, as if it were one node.

Everything Is a Node

The atom of Godot

A node is Godot’s smallest unit of behavior: it has a name, properties you can edit, callbacks the engine invokes every frame, and it can have children.

One node, one job:

Node Its one job
Sprite2D Draw an image
Label Draw text
Camera2D Decide what is on screen
CharacterBody2D Move with collisions
Area2D Detect overlaps (pickups, hitboxes)
AudioStreamPlayer Play a sound
Timer Count down and announce it

Nodes are alive

Every node gets lifecycle callbacks from the engine:

extends Node2D

func _ready() -> void:
    # runs ONCE when the node enters the scene tree
    print("Player one, ready!")

func _process(delta: float) -> void:
    # runs EVERY FRAME; delta = seconds since last frame
    rotation += 1.0 * delta

delta is the difference between “spins once per second on every machine” and “spins at whatever speed the laptop feels like.” Always scale motion by delta. Week 2 is all about why.

Parents and children

Nodes form a tree, and the tree is not just organization, it is mechanics:

  • A child’s transform is relative to its parent: move the parent, and the sprite, collision shape, and camera riding on it all move too.
  • Visibility and processing cascade: hide or pause a parent, and the whole subtree follows.
  • A node’s job is often to coordinate its children: a Player node moves; its children draw, collide, and film.

Design question for the whole semester: what should own what? Get the tree right and behavior follows.

Scenes: Trees You Can Reuse

What a scene is

A scene is a tree of nodes saved as a file (.tscn). Any node can be a scene’s root, and any scene can be instanced inside another scene as if it were a single node.

A player, one scene:

Instancing: scenes inside scenes

The level does not contain forty coin implementations. It instances Coin.tscn forty times:

Fix the coin’s animation once, in Coin.tscn, and all forty instances update. That is the reuse story of the entire engine.

This is composition

Godot’s answer to “how do I build a complex game object” is composition: assemble small nodes and scenes that each do one job, rather than inheriting from a giant GameObject class. We will sharpen this into the Component pattern in week 5.

At runtime, every instanced scene unfolds into one big tree: the scene tree. Your whole running game is a tree of trees, and Godot gives you tools to watch it live while the game runs.

Co-op: design a scene tree

With your neighbor: sketch the scene tree for classic Pac-Man.

On paper, decide:

  1. What scenes would you make? (Pac-Man? A ghost? A pellet? The maze? The HUD?)
  2. What nodes does each scene contain, and what is each node’s one job?
  3. What gets instanced many times?

You have 5 minutes, then pairs share and we assemble a class version on the board.

The Editor

Guided tour

Live in the editor, follow along on your laptop if Godot is installed:

  • Scene dock (top left): the node tree you are editing; add, rename, reparent nodes.
  • Inspector (right): every property of the selected node, editable live.
  • FileSystem dock (bottom left): your project’s files, res:// is the project root.
  • Viewport (center): the 2D canvas; select, move, and place nodes visually.
  • Output panel (bottom): where print() lands, and where errors tell you the truth.

Running your game

  • F5 (Cmd+B on Mac) runs the project, starting from its main scene (you pick it the first time).
  • F6 (Cmd+R on Mac) runs the current scene, alone. This is your best prototyping trick: a scene that works by itself is a scene you can test by itself. F8 (Cmd+. on Mac) stops the running game.
  • While running, the Remote tab in the scene dock shows the live scene tree, every instance unfolded. We will lean on it hard in debugging week.

Live demo: make the Bearcat spin

Printing to Output is not a game. Let’s put something on screen and make it move:

  1. Get an image into the project: drag bearcat.png (our mascot, saved from willamette.edu; any PNG works, even the project’s built-in icon.svg) into the FileSystem dock. It lands at res://bearcat.png and Godot imports it automatically.
  2. Put it on screen: add a Sprite2D node, and in the Inspector set its Texture to bearcat.png. Drag the Bearcat to the middle of the viewport.
  3. Give it behavior: right-click the Sprite2D, Attach Script, and add the spin (next slide).
  4. Run Current Scene (F6 / Cmd+R): the Bearcat spins on screen while the greeting prints in Output. F8 / Cmd+. stops it.

The spin script

extends Sprite2D

@export var spin_speed: float = 2.0 # radians per second; editable in the Inspector

func _ready() -> void:
    print("Hello from ", name)

func _process(delta: float) -> void:
    rotation += spin_speed * delta

Stop the game, change Spin Speed in the Inspector (no code!), run again: faster Bearcat. @export is tuning without touching code, and it grows into data-driven design by week 6.

First-week traps

  • Installing the wrong build: you want the standard build, not .NET, and not Godot 3 (tutorials for Godot 3 will quietly mislead you).
  • Forgetting to set a main scene, then wondering why Run Project (F5 / Cmd+B) complains.
  • Committing the .godot/ folder: it is build cache; your .gitignore from Lab 0 excludes it.
  • Editing a scene while the game runs and expecting the running game to change: edit-time and run-time trees are different trees. The Remote tab is the running one.

Checkpoint

What you know now

  • A Godot game is a tree of trees: nodes compose into scenes, scenes instance into bigger scenes, and at runtime it all unfolds into the one scene tree.
  • Every node has one job; parents coordinate children; transforms, visibility, and pausing cascade down.
  • Run Current Scene (F6 / Cmd+R) runs a scene alone, and a scene that runs alone is a scene you can build and test alone. That is modularity you can feel.

Quest log

Lab 0: Press Start is due Tuesday, September 1, 9:59 PM via Canvas: Godot installed, Learn GDScript From Zero completed, your first scene pushed to your lab repo. Everything you saw in today’s tour is everything Lab 0 asks you to do.

Reading for Tuesday (before class, highly recommended): Game Programming Patterns, Game Loop and Update Method.

Next time: from CS 152 to GDScript: typing, collections, and what _process vs _physics_process really means.

References

Sources

  1. Godot Engine documentation, Overview of Godot’s key concepts: docs.godotengine.org.
  2. Godot Engine documentation, Nodes and scenes: docs.godotengine.org.
  3. Nystrom, R. Game Programming Patterns: gameprogrammingpatterns.com.