Godot Project Structure for Beginners: Scenes, Scripts, Assets, and Autoloads

Project structure sounds boring until your prototype becomes a pile of Player2FinalNew.gd files. Godot gives you a lot of freedom, which is good, but beginners can mistake freedom for no structure at all. A clean project layout helps you find scenes faster, reuse work safely, and avoid turning one main script into the entire game.

The Simple Layout I Recommend

For a small 2D or 3D Godot project, this structure gives you enough organization without creating ceremony. It also maps cleanly for Unity and Unreal developers who are used to separate asset, script, prefab, and level spaces.

res://
  assets/
    art/
    audio/
    fonts/
  scenes/
    levels/
    actors/
    ui/
    props/
  scripts/
    actors/
    systems/
    ui/
  resources/
    items/
    stats/
    abilities/
  globals/
  addons/

You can rename these folders to match your taste. The important idea is separation by role: imported files go in assets, reusable scene files go in scenes, script files go in scripts, saved data assets go in resources, and always-loaded systems go in globals.

Scenes Are Your Main Building Blocks

In Godot, scenes are not just levels. A Player is a scene. A Coin is a scene. A PauseMenu can be a scene. A single enemy projectile can be a scene. If you are coming from Unity, think beyond Prefabs. If you are coming from Unreal, think beyond Blueprint Classes and placed Actors.

• levels/ holds maps and playable spaces like Forest01.tscn.
• actors/ holds player, enemies, NPCs, projectiles, and interactable gameplay objects.
• ui/ holds HUD, menus, popups, and screen widgets.
• props/ holds reusable world pieces like doors, pickups, checkpoints, and trigger zones.

The production habit is simple: if something has a reusable node tree, make it a scene. Then your level is built by instancing those smaller scenes instead of rebuilding the same nodes over and over.

Scripts Should Follow the Thing They Control

Some teams keep scripts next to scenes. Some keep all scripts under scripts/. For beginners, a dedicated scripts folder is easier to scan. The key is matching names and roles so Player.tscn and Player.gd are not a treasure hunt.

scenes/actors/player/Player.tscn
scripts/actors/player/Player.gd

scenes/ui/HUD.tscn
scripts/ui/HUD.gd

scenes/props/Coin.tscn
scripts/props/Coin.gd

Unity habit: you may want many tiny scripts on one object. Godot can do that with child nodes, but each node should still have a clear reason to exist. Unreal habit: you may look for a large framework class first. Godot usually wants a smaller scene with a direct script and a few purposeful children.

Assets Are Source Material, Not Gameplay Structure

Sprites, textures, models, sounds, fonts, and raw imports belong under assets/. They are ingredients. Scenes are the recipes that turn those ingredients into gameplay objects. Keeping that distinction clean prevents your project from becoming a flat folder of everything.

• Put raw images and sprite sheets in assets/art/.
• Put music, SFX, and voice files in assets/audio/.
• Put fonts and UI texture files in assets/fonts/ or assets/ui/ if your project has enough UI assets.
• Do not put final gameplay scenes inside the same folder as raw art unless the project is tiny.

Resources Are Your Data Assets

Godot Resources are saved data objects. They are excellent for item definitions, enemy stats, ability tuning, weapon configs, dialogue entries, and anything designers might tweak without rewriting code. If you are from Unity, this is close to ScriptableObjects. If you are from Unreal, this overlaps with Data Assets and Data Tables.

Put custom resource files in resources/. A health potion might use resources/items/health_potion.tres. An enemy stat block might use resources/stats/slime_stats.tres. The matching scenes can load or export references to those files.

Use Autoloads Sparingly

Autoloads are scripts or scenes Godot keeps alive across scene changes. They are useful, but they are also easy to overuse. A save manager, settings manager, audio router, or small game session object can be an autoload. A random math helper probably should not be.

Naming Rules That Save Time

• Use PascalCase for scene files that represent reusable objects: Player.tscn, PauseMenu.tscn.
• Use snake_case for resource instances and raw data: health_potion.tres, slime_stats.tres.
• Name scripts after the node or role they control: Player.gd, HealthBar.gd, SaveManager.gd.
• Avoid version names inside the project: PlayerNewFinal2.gd belongs in source control history, not your folder tree.

A Small Production-Ready Example

For a tiny top-down collector game, your first clean structure could look like this. It is small enough to understand, but it already has room for scenes, scripts, resources, UI, and persistent settings.

res://
  assets/art/player.png
  assets/art/coin.png
  assets/audio/coin_pickup.wav
  scenes/levels/MainLevel.tscn
  scenes/actors/Player.tscn
  scenes/props/Coin.tscn
  scenes/ui/HUD.tscn
  scripts/actors/Player.gd
  scripts/props/Coin.gd
  scripts/ui/HUD.gd
  resources/items/coin_value.tres
  globals/SaveManager.gd

Once you understand this layout, open the Learning Hub, practice the Node Tree Explorer, then use the Scene Builder to assemble the same roles visually. Structure only matters when it helps you build.