Godot Source Code explained by Technical Lead 01: Source project folders

Main ideas / concepts conveyed

• The video explains how Godot’s engine source code repository is organized as a folder/file system, and what the dependencies are between those folders.
• Core message: the engine is built in layers:
  • a foundational core layer
  • then server systems
  • then the higher-level scene layer
  • followed by optional/add-on modules
  • then platform/editor/build/support infrastructure.

---

Folder structure and responsibilities (with dependencies)

1) core/ (engine foundation)

• Purpose: “The core of the engine.”
• Dependency role: Everything else depends on core/.

Key subcomponents mentioned

• typed_def.h
  • Described as the topmost/most important include.
  • Historically compared to typical C projects where typedef.h (or similar) holds broadly-used macros and definitions.
  • Holds common macros needed across the codebase.
• core/config/
  • General engine configuration.
  • Includes the project settings singleton: the file behind project.godot is loaded into that singleton.
• crypto/
  • Cryptographic utilities:
    • hashing
    • random number generation
• debugger/
  • Debugger extensions (details deferred).
• error/
  • Macros for error handling (details deferred).
• extension/
  • GD extension support / engine extension mechanism.
• input/
  • Input system: input events, keyboard, mouse, joystick.
• io/
  • Input/output functionality:
    • files
    • networking
    • serialization
    • formats
• templates/
  • Godot’s own templates (compared loosely to STL templates; details deferred).
• object/
  • Base of Godot’s object system:
    • Nodes, Resources, Servers, and other callable entities derive from it (except “basic types” mentioned as handled separately).
• os/
  • Operating system abstractions:
    • mutexes, threads, semaphores
  • The OS class is emphasized as important (details deferred).
• string/
  • Unicode string system (Godot’s own, not std::string).
  • Motivation: Unicode needs and integration simplicity across many platforms.
• variant/
  • A central variant data type used for:
    • exposing basic types across engine layers
    • inspector introspection
    • serialization and saving to disk
    • communication (networking)
  • Framed as a core data-binding type used across subsystems.

---

2) servers/ (low-level subsystems that “make things happen”)

• Purpose: Game-engine-specific systems.
• Key concept: You can directly call server functions to bypass higher-level scene/Node systems for performance/low-level behavior.

Servers listed with roles

• Rendering server: triangles, 2D/3D rendering, rendering operations
• Display server: windowing and window lifecycle
  • create windows
  • input event routing
  • resizing
  • global menu support on supported OSes
  • managing multiple windows/monitors
• Physics servers: separate 2D and 3D physics
• Navigation server: pathfinding/navigation (2D and 3D)
• Audio server: audio configuration and audio driver abstraction
• TEX server: internationalization (fonts, languages)
• XR server: XR/game-engine low-level integration

---

3) scene/ (higher-level engine / Node-based system)

• Purpose: The “higher level” engine where Node/Resource workflows live.

Key items mentioned

• Node base class
  • Most gameplay objects inherit from it (scene graph concept).
• Viewport
• Window node/class
  • Creates OS-level windows when supported
  • Otherwise embeds into the main window
• Examples of node categories: 2D nodes, 3D nodes, Animation nodes, Audio nodes, etc.
• Resources
  • Mesh-related resources (e.g., multi-mesh)
  • Theme-related stuff also referenced

---

4) modules/ (optional engine functionality)

• Purpose: Plugin-like, toggleable engine functionality.
• Key differentiation emphasized:
  • Modules can be enabled/disabled without breaking the engine build.
  • Unlike platform-dependent or core folders, module code is integrated but not required for the engine to exist.

Examples listed

• FBX support (mentioned as “okor V support,” likely a misspoken/garbled name)
• MP3 support
• TGA support
• Interactive music
• Grid map
• Multi-mesh
• Mention that GDScript can be turned off while the core engine remains

---

5) thirdparty/ (bundled external libraries)

• Purpose: External libraries included in the repository.

Examples listed

• inet (multiplayer)
• ETC pack (compressed textures importing)
• CPU ray tracing library (Embry referenced)
• Basis Universal
• squish (compression)
• TVG parsing (SVG parsing referenced)
• ufx (parsing FBX referenced)
• certificates

Why bundle instead of link externally (explicit reasoning)

• Godot targets many platforms (web, Android, iOS, desktop, etc.).
• Many third-party libraries aren’t built/tested for every platform.
• Continuous build-system maintenance across exports would be required.
• Bundling allows libraries to compile like part of Godot’s source on each target platform.

---

6) drivers/ (cross-platform shared platform code)

• Purpose: Platform-adjacent code that works across multiple OSes.

Examples mentioned

• “V can work on Windows and Linux” (text unclear)
• Windows-like threading/mutexes also work on other platforms (e.g., Xbox UWP)
• Some graphics or “GS3” references as multi-platform (text unclear)

---

7) editor/ (the Godot editor; large and complex)

• Purpose: Everything related to the editor (UI, exporting, project management, icons, translations, etc.).
• Key point: The editor uses the rest of the engine and depends on prior folders.
• Stated characteristics:
  • Huge codebase (“half the engine” / “a mess”)
  • Organization is expected to improve later (mentioned as ongoing topic)

---

8) platform/ (supported official platforms)

• Purpose: Platform-specific support.
• Official platforms listed:
  • Android
  • iOS
  • Linux (named “Linux BSD,” with note about BSD users)
  • macOS
  • web
  • Windows
• Mentions of consoles having community ports appear, but not emphasized here.

---

9) main/ (engine entry point and execution)

• Purpose: The “main entry point” of the engine.

Key mentioned interface/flow

• main.h is the header.
• Typical flow described:
  • call setup
  • call setup2
  • then depend on platform and call:
    • iteration/other platform-specific start loop behavior

Platform differences

• Android: Godot doesn’t fully own the main loop; instead there are callbacks “every frame.”
• Other platforms: use start-style control and manual handling.

---

10) tests/ (unit/feature tests)

• Purpose: Unit tests and some feature tests.
• Rationale mentioned: new features generally add unit tests here.

---

11) bin/ (build outputs; generated)

• Purpose: Where binaries are produced during build.
• Detail: Not visible in the repo listing; created when building.

---

12) m/ and doc/ (project integration/CI + documentation)

m/

• Scripts and integration helpers for:
  • CI checks
  • pre-commit workflows
  • project management tasks

doc/

• External documentation storage:
  • translations
  • tools
  • “classes” documentation in XML
• Why docs are external instead of in-code comments:
  • Godot has one binding API for multiple languages:
    • GDScript
    • C++
    • GD extension API
    • plus other languages
  • External docs can be tailored per language while sharing the same API semantics.
  • These docs also appear on the Godot website.

---

Methodology / “instructions”-style content

No explicit step-by-step development methodology is provided.

The closest workflow-like description is the engine startup sequence in main/:

• Call setup
• Call setup2
• Call platform-specific execution/start logic:
  • Use iteration/callbacks on platforms like Android
  • Use start and manual handling on other platforms

---

Speakers / sources featured

• Speaker: “Technical Lead 01” (the narrator explaining the source code; no real name given in subtitles).