Skip to content

G1.1 — The Editor & the Project

What you'll learn

  • Create a project and orient yourself in the four core docks: Scene, FileSystem, Inspector, Node.
  • Switch between the 2D, Script, and other workspaces.
  • Tell the project file types apart: .tscn, .tres, .gd, .import, and project.godot.
  • Distinguish res:// (shipped, read-only at runtime) from user:// (the writable per-user path).

How it applies

  • Not knowing which dock shows what is pure flailing. Hunting for a property in the wrong panel, or for a signal in the Inspector instead of the Node dock, burns time on every task. The docks have fixed jobs; learning them once removes a constant low-grade friction.
  • Moving files outside Godot breaks references. Renaming a .gd in the OS file explorer leaves every scene that referenced it pointing at nothing. Doing file operations inside the FileSystem dock lets Godot update the references — the difference between a clean rename and a pile of broken links.
  • res:// is read-only in an exported build. Code that writes a save file under res:// works in the editor (where res:// is writable) and fails the moment the game is exported — the "works on my machine" bug in its purest form. Saves and per-user data go under user://.
  • The file types encode what is shared. A value in project.godot ships to every clone; a value only in your editor layout does not. Knowing which file receives a change tells you whether a teammate will see it.

Concepts

Creating a project and the workspaces

The Project Manager is the first window: it lists your projects and creates new ones. Creating a project asks for a folder and a renderer (Forward+, Mobile, or Compatibility); for 2D work the choice is largely invisible — Forward+ is a fine default. The project folder gets a project.godot file, which is the project (open that file, or the folder, to reopen it later).

Across the top center of the editor are the workspace tabs: 2D, 3D, Script, and AssetLib. You will live in 2D (the scene canvas) and Script (the code editor), switching between them constantly.

The four core docks

The editor's panels each have one job:

  • Scene dock (top-left): the tree of nodes in the scene you are currently editing. Add, rename, reparent, and select nodes here. This is the structure of one scene.
  • FileSystem dock (bottom-left): the files on disk under res://. Scenes, scripts, images, resources. Create, move, and rename files here so Godot can keep references intact.
  • Inspector dock (right): the properties of whatever is selected — a node in the Scene dock or a resource in FileSystem. Exported variables (L2.2) appear here.
  • Node dock (right, tabbed near the Inspector): the signals and groups of the selected node. This is where you wire signals in the editor (G2.6) — not the Inspector.

A frequent early mistake is looking for a node's signals in the Inspector; signals are in the Node dock. Properties are in the Inspector; signals and groups are in the Node dock; structure is in the Scene dock; files are in FileSystem.

Example

Where a single task touches each dock: to make a button that changes a label, you add a Button and a Label in the Scene dock, set the button's text in the Inspector, attach a script (a .gd file that appears in FileSystem), and connect the button's pressed signal in the Node dock. Four docks, four distinct jobs, one small feature.

The project file types

  • .tscn — a scene: a saved tree of nodes (G1.2–G1.3). Text-based, source-control friendly.
  • .tres — a resource: saved data (G1.6), such as a custom StatBlock. Also text-based.
  • .gd — a script: GDScript source (Part A).
  • .import — auto-generated metadata for an imported asset (an image, a sound). You do not edit these; Godot manages them next to each imported file.
  • project.godot — the project's configuration, written by Project Settings. Checked into source control; every clone inherits it.

res:// versus user://

Two path prefixes name two different filesystems:

  • res:// is the project's resource filesystem — everything shipped with the game. In the editor it is writable; in an exported build it is read-only.
  • user:// is a per-user writable directory (its real location depends on the OS). It is the only place an exported game may write — saves, logs, settings.

The defect this prevents is writing player data to res://: it appears to work in the editor and fails in the shipped game. Saves go under user://; assets and defaults live under res://.

Walkthrough

  1. From the Project Manager, create a new project (Forward+ renderer). When the editor opens, find the four docks and the workspace tabs along the top.
  2. In the Scene dock, add a Node (you did this in L1.1). Select it and look at the Inspector — those are its properties. Click the Node tab near the Inspector — those are its signals. Note they are different docks.
  3. In the FileSystem dock, observe res:// at the top and the files under it. Right-click → create a new folder (e.g. scripts). Notice file operations here are Godot-aware.
  4. Open Project → Project Settings, change the project name under Application → Config, close the dialog, and confirm the title bar updates. That value was written to project.godot.

Optional sanity check

Attach a script to your node and save the scene. Watch the FileSystem dock: a .gd file and a .tscn file appear. Those two file types — script and scene — are the pair you create most often. Note the project.godot at the root that you do not normally open by hand.

Self-check quiz

Q1 — You want to connect a button's pressed signal in the editor. Which dock?

A. The Inspector, because signals are properties. B. The Node dock, which lists the selected node's signals (and groups). C. The FileSystem dock. D. The Scene dock.

Reveal answer

B. Signals live in the Node dock, tabbed near the Inspector. A is the common mistake — the Inspector shows properties, not signals. C shows files; D shows the scene's node tree. Each dock has one job, and signals belong to the Node dock.

Q2 — Why save player progress to user://save.dat rather than res://save.dat?

A. res:// paths are slower. B. res:// is read-only in an exported build, so writing there fails in the shipped game even though it works in the editor; user:// is the per-user writable location. C. user:// files are automatically encrypted. D. There is no difference; both work everywhere.

Reveal answer

B. An exported build cannot write under res://; that path is read-only at runtime, so a save written there works in the editor and fails once shipped — the "works on my machine" bug. user:// is the writable per-user directory meant for saves. A is not the reason. C invents encryption. D ignores the export-time difference.

Q3 — A teammate clones your project but does not see a window-size change you made. Where was it likely written?

A. In project.godot, so they would see it — the issue is elsewhere. B. In a per-user editor setting on your machine instead of project.godot, so it did not travel with the project. C. In a .import file. D. In the .gd script.

Reveal answer

B. Settings that belong in project.godot ship to every clone; a value that lives only in your local editor configuration does not. If a teammate does not inherit a change, it was most likely stored per-user rather than in the project file. A contradicts the symptom. C and D are wrong file types for a window/project setting.

Integration question

Q4 — open

A teammate renames player.gd to hero.gd using the operating system's file explorer (outside Godot). On next open, several scenes throw "failed to load script" errors. Separately, they wrote the game's settings file to res://settings.cfg and it works fine for them in the editor but players report settings never save. Explain both failures in terms of how Godot manages files and paths, and state the correct way to do each operation.

Reveal expected answer

The rename broke references because scenes refer to scripts by path (and a stable id), and renaming in the OS file explorer changes the file without telling Godot, so every .tscn that pointed at player.gd now points at a path with nothing there. The correct way is to rename inside the FileSystem dock, which is Godot-aware: it updates the references in the scenes that use the file. The settings file fails for players because res:// is read-only in an exported build — writing there succeeds in the editor (where res:// is writable) and silently fails once shipped, so settings never persist for players. The correct location is user://, the per-user writable directory, e.g. user://settings.cfg. Both failures come from the same root idea: Godot's project model treats res:// paths and references as managed, shipped, and read-only-at-runtime, while file operations and writable data must go through the channels that respect that (the FileSystem dock for moves, user:// for runtime writes).