Godot

To you, a game is a world you play in. To a computer, it is a short list of jobs repeated very fast: read what the player is pressing (input), work out what changes (update: the hero moves, a coin is collected, a timer ticks), and paint the new picture on the screen (draw). Then it starts again. One trip round the loop makes one frame. Do it 60 times a second and the pictures blur into motion, like the pages of a flip book.

Game loop

The repeating cycle of input, update and draw that every game runs.

Frame

One trip round the loop, and the single picture it draws.

Frame rate

How many frames are drawn each second, in frames per second (fps).

If a game runs at 60 frames per second, each frame has one sixtieth of a second for all of its work: about 16.7 milliseconds (ms). Take longer and the next picture is late, and the player sees a stutter. Faster screens leave even less time per frame. This budget is why games care so much about doing work efficiently.

You could write the loop yourself, and then also code how to draw images on the graphics card, how to read a gamepad on Windows, macOS and Linux, how to play sound, how to make things bounce off walls, and how to save it all as an app. Every game needs those, and they are hard. A game engine is software that already does them, so you can spend your time on what makes your game yours.

Godot (said “GOD-oh”) was started by Juan Linietsky and Ariel Manzur, who used it in-house for years before releasing it as open source in 2014. Godot 4.0 came out in 2023 with a new renderer and a much improved language. This course teaches Godot 4, and says so when something needs a later 4.x release. Thousands of people contribute to it, and a non-profit, the Godot Foundation, supports its development.

• MIT licence: you may use it for anything, including games you sell, with no fees or royalties, and you own what you make.
• Small and quick: the download is tens of megabytes and opens in seconds, with no account to create.
• Runs everywhere you work: Windows, macOS and Linux, and exports games to those, the web, Android and iOS.
• Open source: you can read every line of the engine, and change it if you need to.

Many engines draw 2D games as flat 3D. Godot has a real 2D engine, measured in pixels, alongside its 3D one, measured in metres. Each has its own nodes (the building blocks you will meet next module), and the names say which is which: Sprite2D and Camera2D for 2D, MeshInstance3D and Camera3D for 3D.

To tell the engine your game’s rules, you write scripts. Godot’s own language, GDScript, was designed for it: it reads a lot like Python, blocks are shown by indenting, and the editor knows every node and property, so it suggests names as you type. Godot can also run C#, a language used widely in other engines and business software, in a separate “.NET” download.

1extends Node2
3func _ready() -> void:4	print("Hello, Godot")

Godot has no installer. You download one file from godotengine.org, unzip it if it is zipped, and open the program inside. That is the whole editor. You can keep several versions side by side, which is handy when an old project needs an old version. It is also on Steam and itch.io if you prefer a store that updates it for you.

A project is a folder holding everything for one game: scenes, scripts, images, sounds. The Project Manager lists your projects and makes new ones. Click Create, give the project a name, choose an empty folder, pick a renderer (how Godot draws), and Godot opens the editor on it.

In the new project, the left of the editor offers to make a root for a scene. Choose 2D Scene: Godot makes a Node2D; double-click its name and rename it Main. Click the plus button over it to add a child, search for Label, and add it. In the Inspector on the right, type “Hello, Godot” into its Text. Save with Ctrl+S (Cmd+S on a Mac) as main.tscn. Press F5 (Cmd+B on a Mac) to run: Godot asks for a main scene, so choose the current one, and a window opens with your words in it.

1[gd_scene format=3]2
3[node name="Main" type="Node2D"]4
5[node name="Label" type="Label" parent="."]6offset_right = 120.07offset_bottom = 23.08text = "Hello, Godot"

• A game is a loop: read input, update the world, draw a frame, many times a second.
• At 60 fps each frame has about 16.7 ms for all of its work.
• An engine provides what every game needs (drawing, physics, sound, input, export), so you write only your game.
• Godot is free and open source under the MIT licence: no fees, and your game is yours.
• It has a true 2D engine in pixels with y pointing down, and a 3D engine in metres with y up.
• You script it in GDScript (built in) or C# (the .NET edition).
• The Project Manager makes projects; a project is a folder with a project.godot file.

The middle of the editor is the viewport, where you see and arrange your game. Around it are docks, panels with one job each. They can be dragged and rearranged, but every Godot install starts with the same layout, and tutorials assume it.

Viewport

The big central area where you see and arrange a scene.

Dock

A panel around the viewport with one job, such as the Inspector.

Inspector

The dock that shows and edits the properties of the selected node.

Across the top of the editor are the workspaces: 2D, 3D, Script, Game (since Godot 4.4, the running game shown inside the editor) and AssetLib (free add-ons made by the community). Godot usually switches for you: select a 2D node and you see the 2D view, click a script and you see the code editor. The bottom panel works the same way: Output shows what your game prints and the errors it hits; Debugger shows errors in detail; Animation appears when you edit an animation.

Everything in a Godot game is made of nodes. Each kind does one thing: a Sprite2D shows an image, a Camera2D decides what part of the world is on screen, a Timer counts down, an AudioStreamPlayer plays a sound. Godot has hundreds of node types. You don’t learn them all; you learn the dozen you use most and look up the rest in the built-in help (press F1).

Nodes are arranged in a tree: each node has one parent and any number of children. Building a player means putting a few nodes together: a body that moves, an image to show, a shape to collide with, a camera to follow. A child’s position is measured from its parent, so when the parent moves, its children move with it.

When you save a tree of nodes, you get a scene: a .tscn file. A scene is Godot’s unit of reuse. Make a player scene once, then put it into a level as many times as you like; each copy is an instance. Levels are scenes, menus are scenes, a coin is a scene. A whole game is scenes inside scenes, and the one running is a single big tree.

Select a node and the Inspector lists its properties, grouped by the class they come from: a Sprite2D shows its own Texture and Offset, then the Transform it gets from Node2D, then what it gets from CanvasItem, such as Modulate (a colour tint) and Visible. A property you changed shows a circular arrow beside it: click it to put the default back. Hover over a property name to read what it does.

Some properties hold a resource, a piece of data such as an image, a shape or a sound. A Sprite2D’s Texture holds an image; a CollisionShape2D’s Shape holds a rectangle or circle. Click a resource to open and edit it in place.

The buttons for these are at the top right of the editor (on macOS the shortcuts differ; hover over a button to see its own). The main scene is set in the project settings, or by right-clicking a scene in the FileSystem dock and choosing Set as Main Scene. Testing a scene on its own with F6 is a habit worth having: if player.tscn runs and moves by itself, it will work in every level.

Open Project, then Project Settings for settings that apply to the whole game: its name, the main scene, the window size, the input actions (module 5), and much more. Turn on Advanced Settings at the top right to see every setting. Only what you change is saved, as text, into project.godot.

1[application]2
3config/name="Space Rocks"4run/main_scene="res://main.tscn"5
6[display]7
8window/size/viewport_width=12809window/size/viewport_height=720

Godot names files with its own paths, so the same path works on every computer. res:// is the project folder: res://player/player.tscn. In an exported game these files are packed inside the game and are read-only. user:// is a folder the game may write to, somewhere in the player’s own files, for save games and settings.

• The viewport is in the middle; the Scene, FileSystem, Inspector, Signals and Groups docks sit around it.
• A node is a building block with one job; node types inherit properties from each other.
• Nodes form a tree. A child’s position is relative to its parent, so it follows it.
• A scene is a saved tree (.tscn); instances of scenes go into other scenes.
• The Inspector edits properties, and some properties hold resources such as textures and shapes.
• F5 runs from the main scene, F6 runs the current scene, F8 stops.
• Project settings live in project.godot; res:// is the project, user:// is writable.

Nodes do their one job by themselves. To give one your own behaviour, attach a script: select the node, click the scroll icon with a plus at the top of the Scene dock (Attach Script), keep the language as GDScript, and press Create. Godot makes a .gd file and opens the Script workspace. A script is a list of instructions the computer follows in order, top to bottom.

1extends Node2D2
3# Runs once, when this node is ready.4func _ready() -> void:5	print("Hello, Godot")6	print(2 + 3)

A variable is a name for a value the game remembers: the score, the player’s name, whether the door is open. You make one with var, a name, and a starting value after =. Later you can change it with = again. Every value has a type, the kind of thing it is; these four are the ones you use all the time.

1var score = 02var player_name = "Ada"3var speed = 200.04var is_alive = true5
6func _ready() -> void:7	score = score + 108	print(player_name, " has ", score, " points")

A plain var can hold any type, and can switch type later. That freedom hides mistakes. Add a type hint with a colon, var score: int = 0, and Godot refuses a value of the wrong type, such as a string, before the game even runs. Writing := asks Godot to infer the type from the starting value: var speed := 200.0 is a float for good. This course types everything, and so should you.

var lives = 3
func lose_life() -> void:	lives = "none"  # allowed, and wrong

var lives: int = 3var speed := 200.0  # inferred: float
func lose_life() -> void:	lives = "none"  # error, caught at once

* and / happen before + and -, as in school maths; use brackets to change the order. + also joins strings, but only strings: "Score: " + str(score) turns the number into text first. A tidier way is a format string, where %d is filled in with a whole number and %s with anything: "Score: %d" % score.

1var score: int = 1002
3func _ready() -> void:4	score  255	print("Score: "  score)

if runs its indented block only when its condition is true. elif (else if) is checked only when everything before it was false, and else catches whatever is left. Exactly one block runs, the first whose condition holds. Each line that opens a block ends with a colon.

1func describe(health: int) -> void:2	if health <= 0:3		print("Defeated")4	elif health < 30:5		print("Badly hurt")6	else:7		print("Fine")

When you compare one value against a list of possibilities, match is tidier than a chain of elifs. Each pattern is followed by a colon and its block. Several values can share one branch, separated by commas, and _ matches anything, so it goes last, as the fallback. Only the first matching branch runs.

1func react(item: String) -> void:2	match item:3		"coin":4			print("+1 coin")5		"heart", "potion":6			print("Healed")7		_:8			print("Nothing happens")

A loop runs a block many times. for goes through a sequence, giving each item a name in turn. range(n) is the numbers from 0 up to, but not including, n; range(a, b, step) counts from a towards b in steps. while repeats as long as its condition stays true, so something inside must eventually make it false. break leaves a loop early and continue skips to the next turn.

1func _ready() -> void:2	for i in range(3):3		print("Wave ", i)     # Wave 0, Wave 1, Wave 24
5	var fuel := 106	while fuel > 0:7		fuel -= 48	print(fuel)              # -2

An array is an ordered list in square brackets. Items are numbered from 0, so items[0] is the first and items[-1] the last. A typed array, Array[String], only accepts strings. A dictionary pairs keys with values, in braces, so you can look a value up by its key, like a word in a dictionary.

1var items: Array[String] = ["sword", "shield"]2var prices := {"sword": 30, "shield": 20}3
4func _ready() -> void:5	items.append("potion")6	print(items.size())            # 37	print(items[0])                # sword8	print("shield" in items)       # true9	print(prices["sword"])         # 3010	print(prices.get("bow", 0))    # 0: no "bow" key11	for item in items:12		print(item)

1var inventory: Array[String] = []2var stock := {"key": 2, "map": 1}3
4func _ready() -> void:5	inventory.("key")6	print(stock.("key", ))

A function is a named, reusable block. It can take parameters, values passed in when it is called, each with a type, and can give back a value with return. The type after -> says what it returns; void means nothing. A parameter can have a default, used when the caller leaves it out.

1func damage_after_armour(damage: int, armour: int = 0) -> int:2	var result := damage - armour3	if result < 1:4		return 15	return result6
7func _ready() -> void:8	print(damage_after_armour(10, 4))   # 69	print(damage_after_armour(10))      # 1010	print(damage_after_armour(3, 9))    # 1

1 is_rich(coins: ) -> :2	 coins >= 100

• A script extends a node type and adds behaviour; _ready runs when the node starts.
• Blocks are marked by indentation with tabs, and a line opening a block ends in a colon.
• int, float, String and bool are the everyday types. 7 / 2 is 3; 7 / 2.0 is 3.5.
• Type everything: var x: int = 0, or var x := 0 to infer.
• if/elif/else and match choose; for and while repeat; range leaves out its end.
• Arrays are lists from index 0; dictionaries map keys to values, and get reads them safely.
• Functions take typed parameters and return a typed value.

A class is a blueprint: it says what data a kind of thing has and what it can do. Every GDScript file is one. Its vars at the top are the class’s properties (each node with the script gets its own copy) and its funcs are methods. extends says which class it builds on. Add class_name and the class gets a global name, usable as a type anywhere in the project, and listed in the Add Node dialog.

1class_name Player2extends CharacterBody2D3
4var health: int = 1005var coins: int = 06
7func collect(amount: int) -> void:8	coins += amount9
10func is_rich() -> bool:11	return coins >= 100

A class that extends another inherits its properties and methods, and may override a method by writing one with the same name. Inside the override, super() calls the parent’s version, so you add to it instead of replacing it. With class_name Enemy on the parent, the child just writes extends Enemy.

1# enemy.gd2class_name Enemy3extends CharacterBody2D4
5var health: int = 306
7func take_damage(amount: int) -> void:8	health -= amount9
10# armoured_enemy.gd, a separate file11extends Enemy12
13func take_damage(amount: int) -> void:14	super(amount / 2)   # half damage, then the usual

1extends Enemy2
3func _ready() -> void:4	health = 3005	print("The boss arrives")

An enum (enumeration) is a set of named constants, for something that can be one of a few things: a state, a direction, a weapon type. A named enum is also a type, so a variable typed with it only takes its values, and the editor completes the names. Behind the names are whole numbers: IDLE is 0, RUN 1, JUMP 2.

1enum State { IDLE, RUN, JUMP }2
3const MAX_SPEED := 300.04var state: State = State.IDLE5
6func describe() -> String:7	match state:8		State.IDLE:9			return "Standing"10		State.RUN:11			return "Running"12	return "In the air"

1 Direction { UP, DOWN, LEFT, RIGHT }2
3var facing:  = Direction.UP4
5func turn_left() -> void:6	facing = 

Words starting with @ are annotations: notes to Godot about the line after them. @export makes a property appear in the Inspector, so you (or a designer) can set it per node without touching code: one enemy fast, one slow. @onready delays a property’s starting value until the node is ready, which is when its children exist. $Sprite2D is short for get_node("Sprite2D"), the child with that name.

1extends CharacterBody2D2
3@export var speed: float = 200.04@export_range(0, 100) var armour: int = 105@export var bullet_scene: PackedScene6
7@onready var sprite: Sprite2D = $Sprite2D8
9func _ready() -> void:10	sprite.modulate = Color.RED

With types on variables, parameters and returns, Godot checks your code as you type: calling a method that doesn’t exist, or passing a String where an int goes, is underlined at once instead of crashing an hour into play. The editor’s suggestions also get much better, and typed code runs faster, because Godot can pick specialised instructions. To make a value a more specific type, use as (it gives null if the value isn’t that type) or check first with is.

1func _on_body_entered(body: Node2D) -> void:2	if body is Player:3		var player := body as Player4		player.collect(1)

Functions whose names start with _ and that Godot calls for you are callbacks (also called virtual methods). You never call them yourself; you write them, and Godot runs them at the right moment of a node’s life.

_process runs once per drawn frame, so how often depends on the computer: 60, 144, or 30 when it struggles. _physics_process runs at a steady rate, independent of drawing, so physics behaves the same everywhere. Movement of physics bodies goes in _physics_process; things that only look (a spinning coin, a timer label) can go in _process.

1func _physics_process(delta: float) -> void:2	position.x += 100.0 * delta   # 100 pixels a second3
4func _unhandled_input(event: InputEvent) -> void:5	if event.is_action_pressed("pause"):6		get_tree().paused = not get_tree().paused

null means “no value”: an object variable that points at nothing. Using null as if it were an object is the most common error in any game: “Cannot call method … on a null value”, or “Invalid access to property or key … on a base object of type ‘Nil’”, Godot says. A related trap: when a node is deleted with queue_free(), variables that pointed at it still hold the freed object, and using it stops the game (“previously freed instance”). is_instance_valid(x) is true only for an object that exists and hasn’t been freed, so it covers both cases.

A function can be stored in a variable and passed around, as a Callable. Writing a method’s name without brackets, jump instead of jump(), gives its Callable; .call() runs it. A lambda is a function with no name, written right where it is needed: func(n: int) -> int: return n * 2. Arrays take them to transform themselves: map changes every item, filter keeps the items for which it returns true.

1func greet(who: String) -> void:2	print("Hello, ", who)3
4func _ready() -> void:5	var action: Callable = greet6	action.call("Ada")                     # Hello, Ada7
8	var double := func(n: int) -> int: return n * 29	print(double.call(21))                 # 4210
11	var prices: Array = [5, 12, 30, 8]12	print(prices.filter(func(p): return p > 10))  # [12, 30]

• A script is a class: properties and methods, built on what it extends. class_name names it globally.
• Overriding replaces the parent’s method; super() calls the parent’s version, _ready included.
• Enums name fixed choices and are types; const values never change.
• @export puts a property in the Inspector; @onready waits for the children, so $ works.
• Types catch mistakes early; is checks a type and as converts or gives null.
• Callbacks: _init, _enter_tree, _ready (children first), _process, _physics_process, _input.
• Use is_instance_valid for nodes that may have been freed. Functions are values: Callables and lambdas.

Your code shouldn’t ask “is the A key down?”. Some players use arrow keys, some a gamepad, some a French keyboard where A is somewhere else. Instead you make actions, named intentions like move_left or jump, and bind keys and buttons to them. Code asks about the action; players (and you) can change the keys without touching code.

1. Open Project, Project Settings, and the Input Map tab.
2. Type an action name, such as move_left, and click Add.
3. Click the + beside it and press a key (A), then add another (the left arrow), and a gamepad stick direction.
4. Repeat for move_right, move_up, move_down, and anything else the game needs.

Action

A named input, like jump, with any number of keys and buttons bound to it.

Input map

The project’s list of actions and their bindings, in the project settings.

Dead zone

How far a stick must move before it counts, so a resting stick reads as zero.

Input.get_axis("move_left", "move_right") gives a number from -1 to 1: -1 for left, 1 for right, 0 for neither (or both), and in between for a half-tilted stick. Input.get_vector does the same for two axes at once, giving a Vector2, a pair of numbers (x, y), that points where the player wants to go. Its four actions are in the order: negative x, positive x, negative y, positive y.

1var turn := Input.get_axis("turn_left", "turn_right")2var direction := Input.get_vector("move_left", "move_right",3		"move_up", "move_down")

A 2D node’s position is a Vector2: x pixels to the right and y pixels down from its parent’s origin (for the root of a scene, the top-left of the window). Vectors add and scale like arrows: adding moves, multiplying by a number makes them longer or shorter. A few methods come up constantly.

1var step := position.(player.position) * 50.02position  step3print(position.(player.position))

_process(delta) gets delta, the seconds since the last frame: about 0.0167 at 60 fps. Move 5 pixels per frame, and a fast computer moves the player further each second than a slow one. Move speed * delta per frame, and the player covers speed pixels per second, whatever the frame rate: fast computers just take smaller steps more often.

Jumping to full speed in one frame feels stiff. Real things accelerate: their velocity (speed with a direction, pixels per second) changes a little each frame. Keep a velocity variable, nudge it towards the speed you want with move_toward, which changes it by at most a given amount, and then move by it. When there is no input, the same call with a target of zero acts as friction.

1var target := direction * max_speed2velocity = velocity.(target, acceleration * )3position +=  * delta

A Node2D’s rotation is an angle in radians: a full turn is TAU (about 6.28), a quarter turn PI / 2. Use rotation_degrees if you think in degrees, and deg_to_rad() to convert. Positive rotation turns clockwise on screen, because y points down. Draw your sprites facing right: at rotation 0 they then face along transform.x, the node’s own forward direction, which is (1, 0) turned by its rotation. look_at(point) turns a node so its forward points at a position.

1# A turret aiming at the mouse2func _process(_delta: float) -> void:3	look_at(get_global_mouse_position())4
5# A ship that turns, then pushes forward6func _process(delta: float) -> void:7	rotation += Input.get_axis("turn_left", "turn_right") * 3.0 * delta8	if Input.is_action_pressed("thrust"):9		position += transform.x * 250.0 * delta

In a game like Asteroids, flying off the right edge brings you back on the left. get_viewport_rect().size is the size of the visible area, and wrapf(value, min, max) wraps a number into a range: past max, it comes back from min. (clamp would stop you at the edge instead.)

• Bind keys and buttons to actions in the Input Map; code asks about actions.
• is_action_pressed is held; is_action_just_pressed is once per press.
• get_axis gives -1 to 1; get_vector gives a direction of length at most 1.
• Positions are Vector2s, with y pointing down.
• Multiply per-second amounts by delta so speed doesn’t depend on the frame rate.
• Keep a velocity and change it with move_toward for acceleration and friction.
• rotation is in radians, clockwise; transform.x is forward; wrapf wraps round the screen.

Moving a sprite’s position walks it through walls. To collide, a thing must be a physics body, which Godot’s physics engine knows about. Which body you choose depends on who moves it: nobody, your code, or the physics engine. A fourth kind, the area, doesn’t collide at all; it notices when things are inside it. The fifth row, AnimatableBody2D, is a static body that code or an animation moves, carrying what stands on it.

Physics body

A node the physics engine moves or collides with.

Collision

Two shapes touching, and the engine stopping them overlapping.

Physics step

One update of the physics world, 60 times a second by default.

A body has no shape of its own. Give it a child CollisionShape2D, and set that node’s Shape to a resource: RectangleShape2D, CircleShape2D or CapsuleShape2D (good for characters: no corners to catch on ledges). For an outline you draw point by point, use CollisionPolygon2D. The shape is drawn in blue in the editor; turn on Debug, Visible Collision Shapes to see them while the game runs.

A CharacterBody2D has a built-in velocity property, in pixels per second. Set it, then call move_and_slide(): Godot moves the body by velocity over one physics step, stops it at anything solid, and slides it along walls and floors instead of sticking. It uses the step’s time itself, so you don’t multiply by delta here. Do it in _physics_process.

Once off the ground, the body slows as it rises, stops at the top, and falls back: a parabola. With a jump speed $v$ and gravity $g$, it reaches the top after $v/g$ seconds, at a height of $\frac{v^2}{2g}$. That formula is useful backwards: decide how high the jump should be (say, three tiles) and work out the speed.

move_and_slide() also records what happened. is_on_floor(), is_on_wall() and is_on_ceiling() say which way the body was blocked; which way is “up” comes from its up_direction, Vector2.UP by default. Each thing it bumped into is a collision, which you can read in a loop.

1move_and_slide()2
3if is_on_wall():4	print("Pressed against a wall")5
6for i in get_slide_collision_count():7	var collision := get_slide_collision(i)8	print("Touched ", collision.get_collider().name)

A RigidBody2D behaves like a real object: it falls, tumbles, bounces off others and is pushed by the player. You don’t set its position; you push it. An impulse is an instant kick (a hit, an explosion); a force is a steady push applied over time (a rocket, wind). Its mass, gravity_scale and a PhysicsMaterial with bounce and friction decide how it reacts.

1extends RigidBody2D2
3func _ready() -> void:4	apply_central_impulse(Vector2(300, -400))  # a toss5
6func blast_from(origin: Vector2) -> void:7	var away := origin.direction_to(global_position)8	apply_central_impulse(away * 600.0)

An Area2D has shapes like a body, but nothing collides with it. Instead it tells you when a body or another area goes in or out, with signals (messages a node sends; module 7 is all about them): body_entered(body), body_exited(body), area_entered(area). That makes it the right tool for coins, checkpoints, spikes and an enemy’s field of view.

1extends Area2D2
3func _ready() -> void:4	body_entered.connect(_on_body_entered)5
6func _on_body_entered(body: Node2D) -> void:7	if body is Player:8		(body as Player).collect(1)9		queue_free()

1extends Area2D2
3func _ready() -> void:4	.connect(_on_body_entered)5
6func _on_body_entered(body: Node2D) -> void:7	if body  Player:8		(body as Player).take_damage(1)

By default everything collides with everything. To choose, each body and area has 32 collision layers and a mask of the same 32. The layer is what this object is. The mask is what it looks for: a body collides with, and an area notices, objects whose layer is in its mask. Name the layers in Project Settings, Layer Names, 2D Physics, so the Inspector shows “player” instead of “2”.

A RayCast2D is an invisible line from the node to its target_position (measured from the ray itself). Every physics step it checks what the line hits first, among the layers in its mask. Uses: can the enemy see the player, or is a wall in the way? Is there floor ahead, or a ledge? is_colliding(), get_collider() and get_collision_point() give the answers.

1@onready var eyes: RayCast2D = $Eyes2
3func can_see(player: Node2D) -> bool:4	eyes. = eyes.to_local(player.global_position)5	eyes.force_raycast_update()6	return eyes.() and eyes.() == player

1var space := get_world_2d().direct_space_state2var query := PhysicsRayQueryParameters2D.create(global_position, target)3query.exclude = [get_rid()]   # don't hit yourself4var hit := space.intersect_ray(query)5if hit:6	print(hit.collider, " at ", hit.position)

• Static bodies stay put, character bodies move by your code, rigid bodies by physics; areas detect.
• Bodies collide through child CollisionShape2Ds; resize shapes, never scale them.
• Set velocity, then move_and_slide(), in _physics_process, without multiplying by delta.
• Gravity adds to velocity.y times delta; a jump sets velocity.y negative once, on the floor.
• Jump height is speed squared over twice gravity.
• Push rigid bodies with impulses and forces; don’t set their position.
• Layer: what I am. Mask: what I look for. Raycasts check what lies along a line.

A doorbell doesn’t know who is home. It rings, and whoever is listening comes to the door. A signal works the same way: a node emits it when something happens (a button was pressed, a body entered an area, a timer ran out), and any node that connected a function to it gets that function called. The node that emits doesn’t need to know who listens, or whether anyone does. This idea is called the observer pattern.

Signal

A named event a node can announce, such as pressed.

Emit

Announce a signal now, calling everything connected to it.

Connect

Ask for a function to be called each time a signal is emitted.

Handler

The function connected to a signal, often named _on_<node>_<signal>.

Select a node and open the Signals dock, a tab beside the Inspector (before Godot 4.6, the Signals tab of the Node dock): it lists every signal the node has, grouped by the class it comes from. The words in brackets are the signal’s arguments, values it passes to the handler: body_entered passes the body that came in.

For nodes that are in the scene from the start, the editor can make the connection for you, and write the handler. A green icon then appears in the script’s margin next to the handler, showing it is connected; the connection itself is saved in the scene file.

In Godot 4 a signal is a value you can reach with a dot: $StartButton.pressed. Its connect method takes a Callable, a function written without brackets. Code connections are visible right in the script, and they are the only way for nodes created while the game runs, such as an enemy you just spawned.

1func _ready() -> void:2	$StartButton..()3
4func _on_start_pressed() -> void:5	print("Starting")

When a signal has arguments, its handler must accept them, in the same order. If a handler needs an extra value of its own, bind adds it after the signal’s arguments: one handler can then serve ten buttons, each telling it which one it was.

1func _ready() -> void:2	for i in range(3):3		var button: Button = $LevelButtons.get_child(i)4		button.pressed.connect(_on_level_chosen.bind(i + 1))5
6func _on_level_chosen(level: int) -> void:7	print("Loading level ", level)

Declare a signal at the top of a script with signal, a name in the past tense (it happened), and typed arguments if it carries values. Emit it with .emit(…). Here a health component announces every change and its owner’s death; it doesn’t care whether a health bar, a sound or a game-over screen is listening.

1class_name Health2extends Node3
4signal health_changed(new_health: int)5signal died6
7@export var max_health: int = 1008
9var health: int:10	set(value):11		health = clampi(value, 0, max_health)12		health_changed.emit(health)13		if health == 0:14			died.emit()15
16func _ready() -> void:17	health = max_health18
19func take_damage(amount: int) -> void:20	health -= amount

1 coin_collected(total: int)2
3var coins: int = 04
5func collect() -> void:6	coins += 17	coin_collected.()

A Timer node waits wait_time seconds, then emits timeout. With one_shot off it starts again by itself, which suits an enemy spawning every 3 seconds; with one_shot on it stops, which suits a cooldown. autostart starts it when the scene starts; otherwise call start(). is_stopped() and time_left tell you where it is.

1# A gun with a 0.25 s cooldown: a one-shot Timer named Cooldown2@onready var cooldown: Timer = $Cooldown3
4func _process(_delta: float) -> void:5	if Input.is_action_pressed("fire") and cooldown.is_stopped():6		shoot()7		cooldown.start()

await waits for a signal, then carries on from the same line. The rest of the game keeps running meanwhile: only this function is paused. get_tree().create_timer(0.1) makes a throwaway timer for this, so a short pause needs no Timer node. A function that awaits becomes a coroutine: whoever calls it carries on at once, unless it awaits the call too.

1func flash_red() -> void:2	modulate = Color.RED3	await get_tree().create_timer(0.1).timeout4	modulate = Color.WHITE5
6func die() -> void:7	$AnimationPlayer.play("death")8	await $AnimationPlayer.animation_finished9	queue_free()

1func _ready() -> void:2	print("A")3	wait_then_print()4	print("C")5
6func wait_then_print() -> void:7	await get_tree().create_timer(1.0).timeout8	print("B")

A rule that keeps scenes reusable: a parent may call methods on its children, because it owns them and knows they exist. A child signals to whoever is above, without knowing who they are. The level, which owns both the player and the HUD, does the wiring. The player then works in any level, and with no HUD at all when you test it with F6.

1extends Node2D2
3func _ready() -> void:4	$Player.coin_collected.connect($HUD.show_coins)