Exporting Variables & the Inspector
Learn @export and its variants to expose script variables to Godot's editor Inspector, plus @tool scripts for editor-time tooling.
Introduction
One of GDScript's most immediately useful features is how easily a script variable can become an editable field in the Godot editor itself — no separate configuration file, no custom editor plugin, just one annotation.
- How @export exposes a variable to the Inspector panel.
- Why this matters beyond just convenience, especially on teams with non-programmers.
- Useful @export variants for ranges, enums, and multiline text.
- How to export references to other nodes or Resources.
The @export Annotation
Use case: adding @export before a var declaration exposes that variable in the Godot editor's Inspector panel for the node it's attached to, letting you (or a designer) set its value visually, per node instance, with no code changes.
extends CharacterBody2D
@export var speed: float = 200.0@export var max_health: int = 100Click Run to see what this code prints.
Why This Matters for Designers
On a real team, the person tuning a character's movement speed or an enemy's health is often a game designer, not the programmer who wrote the script. @export lets that designer safely tweak specific, intentional values through the editor UI, without ever opening or understanding the underlying GDScript code.
Useful @export Variants
| Annotation | What It Does |
|---|---|
| @export_range(0, 100) | Restricts a number to a range, shown in the Inspector as a slider. |
| @export_enum("Easy", "Normal", "Hard") | Shows a dropdown of fixed string options instead of a free-text field. |
| @export_multiline | Shows a String field as a resizable multi-line text box. |
| @export_category("Combat") | Groups following exported variables under a labeled section in the Inspector. |
@export_range(0, 100) var volume: int = 80@export_enum("Easy", "Normal", "Hard") var difficulty: String = "Normal"Exporting Node and Resource References
You can export a reference to another node or a custom Resource (from lesson 9), letting you wire up relationships between scenes visually instead of hardcoding node paths.
@export var weapon_data: WeaponData@export var target: Node2DIn the editor, these appear as drag-and-drop fields — drag a .tres WeaponData resource or another node in the scene directly onto the Inspector field, and the reference is wired up with zero code.
@tool Scripts, Briefly
Adding @tool at the very top of a script makes it run inside the editor itself, not just during gameplay — useful for building custom editor tooling, like a script that automatically arranges child nodes as you edit a scene. This is an advanced topic worth knowing exists, but not one this course covers in depth.
Common Mistakes
- Exporting every single variable in a script "just in case" — reserve @export for values that genuinely benefit from per-instance tuning.
- Forgetting that changing a script's default value doesn't retroactively update Inspector values already set on existing node instances.
- Adding @tool to a script without understanding it now also runs in the editor, which can have surprising side effects if the script wasn't written with that in mind.
Best Practices
- Export exactly the values a designer or level builder would realistically want to tune per instance — speed, health, colors, references to specific resources.
- Use @export_range and @export_enum instead of a bare exported number or string whenever the valid values are actually constrained.
- Group related exported variables with @export_category for a cleaner, more organized Inspector panel on complex scripts.
Frequently Asked Questions
Most built-in types (numbers, strings, bools, vectors, arrays, node/resource references) support @export directly; a few advanced or custom types may need extra configuration.
They solve different problems — @export exposes a value to the editor for manual tuning; @onready defers a variable's automatic initialization (like a $NodeName lookup) until the node is ready, covered in lesson 7.
Not directly on the same declaration, since they serve different purposes, but it's common to export a value while separately using @onready elsewhere in the same script for node references.
Key Takeaways
- @export exposes a script variable in the Godot editor's Inspector panel, editable per node instance.
- This lets designers and non-programmers safely tune values without touching code.
- Variants like @export_range and @export_enum constrain and improve how a value is edited.
- Node and Resource references can be exported too, wired up visually by dragging into the Inspector.
Summary
Exported variables are a big part of why Godot feels productive for small teams and solo developers alike — code and content tuning stay cleanly separated. In the final lesson, you'll review best practices across the whole course and see where to go next.