Godot 4 Autoload and Singletons: Global Scripts Done Right

Sooner or later you need something every part of your game can reach. The current score. The player's save data. A music player that keeps going when scenes change. Passing those around by hand gets old fast. Godot's answer is the autoload, and it's one of the first "real architecture" tools worth learning.

An autoload is a script (usually with a scene) that Godot loads once at startup and keeps alive for the entire game. It never gets unloaded when you change scenes, and you can reach it from anywhere by name. That's it. People call them "singletons" because there's exactly one, always available.

To make one: write your script, then go to Project Settings, Autoload, pick the script, give it a name, and add it. That name becomes a global you can type anywhere.

Say you want a score that survives scene changes. Make a script:

# game_manager.gd
extends Node
​
var score: int = 0
var current_level: int = 1
​
func add_score(points: int) -> void:
    score += points
​
func reset() -> void:
    score = 0
    current_level = 1

Add it as an autoload named GameManager. Now from any script in any scene:

GameManager.add_score(100)
print(GameManager.score)

No node paths, no passing references through five scripts. It's just there.

The single most useful autoload is an event bus, a script that holds nothing but signals. Any system can emit them, any system can listen, and nobody needs a direct reference to anybody else:

# events.gd  (autoload named "Events")
extends Node
​
signal player_died
signal enemy_killed(enemy_type: String)
signal score_changed(new_score: int)

# anywhere that something happens
Events.enemy_killed.emit("goblin")
​
# anywhere that cares
Events.enemy_killed.connect(_on_enemy_killed)

This is the cleanest way to keep a growing game from turning into spaghetti. I go deep on it in the signals tutorial, and it's worth setting up early.

A handful of things genuinely belong here:

• A game manager for global state like score and progress.
• A signal bus for cross-scene events.
• An audio manager so music keeps playing across scene changes.
• A save system that any scene can call to read or write progress.

Autoloads are global, and global state is the thing that makes big codebases hard to reason about. The temptation is to shove everything into one giant Global script because it's convenient. Resist it. If a value only matters to one scene, keep it in that scene. Reach for an autoload when something truly needs to outlive scene changes or be shared across the whole game. A few small, focused autoloads beat one bloated god object every time.

Autoloads, signals, and a clean save system are what separate a tech demo from a game that holds together. The free Inventory System quest builds systems that use exactly this kind of structure, and pairing it with the save system guide shows where a save autoload fits naturally.

What is an autoload in Godot?

An autoload is a script Godot loads once at startup and keeps alive for the whole game, accessible from anywhere by the name you give it. It's how you store global state, share events through a signal bus, or keep music playing across scene changes.

Is an autoload the same as a singleton?

In Godot, yes, the terms are used interchangeably. An autoload is the engine's built-in way of creating a singleton: a single instance that exists for the entire run and is globally reachable by name.

When should I use an autoload versus a regular node?

Use an autoload when something must outlive scene changes or be shared across the whole game, like score, save data, or a signal bus. Keep everything else in the scene that uses it. Overusing globals makes code harder to follow, so reach for them deliberately.