# Godot — full corpus # LLM Wiki An open-source template for building LLM-powered knowledge bases, following [Andrej Karpathy's "LLM Wiki" pattern](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f). You provide raw sources. The LLM reads them, writes structured wiki pages, cross-links everything, and maintains it over time. You never edit the wiki directly — you curate sources and ask questions. ## How It Works The system has three layers: ``` raw/ Sources you collect (articles, transcripts, notes, PDFs) wiki/ LLM-written & maintained pages (summaries, concepts, entities, syntheses) CLAUDE.md Schema that tells the LLM how to structure everything ``` Three operations drive the workflow: | Operation | Trigger | What happens | |-----------|---------|--------------| | **Ingest** | "ingest raw/my-source.txt" | LLM reads the source, creates a summary page, creates/updates concept and entity pages, adds cross-links, updates the index and log | | **Query** | Ask any question | LLM searches the wiki, synthesizes an answer with citations, optionally creates a synthesis page for novel insights | | **Lint** | "lint" or "health check" | LLM audits all pages for orphans, contradictions, missing links, incomplete sections, and low-confidence claims — fixes what it can, reports the rest | ## Quick Start 1. **Clone this repo** ```bash git clone https://github.com/YOUR_USERNAME/llm-wiki.git my-knowledge-base cd my-knowledge-base ``` 2. **Customize CLAUDE.md** for your domain - Update the Purpose section with your topic - Replace the placeholder tagging taxonomy with your own categories - Adjust confidence level descriptions if needed - Everything else (workflows, page formats, linking rules) works as-is 3. **Drop sources into `raw/`** - Text files, transcripts, articles, notes — any plain text - These are immutable once added; the LLM never modifies them 4. **Tell the LLM to ingest** ``` ingest raw/my-first-source.txt ``` The LLM will create summary pages, concept pages, entity pages, cross-links, and update the index. 5. **Ask questions** ``` What are the key differences between X and Y? ``` The LLM answers from the wiki, citing specific pages. 6. **Run health checks** ``` lint ``` The LLM audits the wiki and fixes issues. ## Directory Structure ``` . ├── CLAUDE.md # Schema — the LLM's instructions ├── raw/ # Your source documents (immutable) └── wiki/ ├── index.md # Master catalog of all pages ├── log.md # Append-only activity log ├── dashboard.md # Dataview dashboard (Obsidian) ├── analytics.md # Charts View analytics (Obsidian) ├── flashcards.md # Spaced repetition cards ├── summaries/ # One page per source document ├── concepts/ # Concept and framework pages ├── entities/ # People, tools, organizations, etc. ├── syntheses/ # Cross-cutting analyses and comparisons ├── journal/ # Research/session journal entries │ └── template.md # Journal entry template └── presentations/ # Marp slide decks ``` ## Enhancements This template includes several extras beyond the core wiki pattern: ### Dataview Dashboard (`wiki/dashboard.md`) Live queries that surface low-confidence pages, recent updates, concepts by tag, and pages with the most sources. Requires the [Dataview](https://github.com/blacksmithgu/obsidian-dataview) Obsidian plugin. ### Charts View Analytics (`wiki/analytics.md`) Visual analytics with pie charts, bar charts, and word clouds. Requires the [Charts View](https://github.com/caronchen/obsidian-chartsview-plugin) Obsidian plugin. ### Mermaid Diagrams Use Mermaid code blocks in any wiki page to create flowcharts, sequence diagrams, or concept maps. Native support in Obsidian and GitHub. ### Marp Slides (`wiki/presentations/`) Create slide decks from markdown using [Marp](https://marp.app/). Drop presentation files in this directory. ### Research Journal (`wiki/journal/`) Track your research sessions, experiments, or applied work with the included template. The LLM can reference journal entries when answering queries. ### Spaced Repetition (`wiki/flashcards.md`) Flashcards in the format used by the [Spaced Repetition](https://github.com/st3v3nmw/obsidian-spaced-repetition) Obsidian plugin. Ask the LLM to generate flashcards from any wiki page. ### MCP Server This repo works with Claude Code's MCP server capabilities. Point an MCP-compatible client at this repo and the LLM can read/write the wiki programmatically. ## Customizing for Your Domain The schema in `CLAUDE.md` is domain-agnostic. To adapt it: 1. **Purpose** — Describe your knowledge domain in one paragraph 2. **Tagging taxonomy** — Replace placeholder categories with your own (e.g., for a cooking KB: `cuisine`, `technique`, `ingredient`, `equipment`) 3. **Confidence levels** — Adjust the descriptions to match your domain's evidence standards 4. **Entity types** — Update the entity page description to match what entities mean in your domain (people, tools, companies, etc.) 5. **Journal template** — Customize `wiki/journal/template.md` for your workflow Everything else — page format, linking conventions, workflows, rules — is universal and works across domains. ## Example Domains This template works for any knowledge-intensive topic: - **Research notes** — papers, experiments, methodologies - **Book analysis** — themes, characters, author techniques - **Competitive analysis** — companies, products, market trends - **Course notes** — lectures, readings, key concepts - **Personal development** — frameworks, habits, book summaries - **Technical documentation** — APIs, architectures, design patterns - **Hobby deep-dives** — any subject you want to master ## License MIT --- title: "Knowledge Base Index" type: index updated: 2026-06-19 --- # Knowledge Base Index Master catalog of all wiki pages. Every page in the wiki must have an entry here. ## Concepts | Page | Tags | Confidence | Updated | |------|------|------------|---------| | [what-is-godot](concepts/what-is-godot.md) | godot, game-engine, overview | high | 2026-06-19 | | [nodes-and-scenes](concepts/nodes-and-scenes.md) | nodes, scenes, scene-tree | high | 2026-06-19 | | [instancing](concepts/instancing.md) | instancing, packedscene | high | 2026-06-19 | | [signals](concepts/signals.md) | signals, events, decoupling | high | 2026-06-19 | | [gdscript](concepts/gdscript.md) | gdscript, scripting, language | high | 2026-06-19 | | [scripting-languages-and-csharp](concepts/scripting-languages-and-csharp.md) | csharp, dotnet, gdextension | high | 2026-06-19 | | [scripting-and-lifecycle](concepts/scripting-and-lifecycle.md) | lifecycle, process, ready | high | 2026-06-19 | | [input](concepts/input.md) | input, inputevent, input-map | high | 2026-06-19 | | [working-in-2d](concepts/working-in-2d.md) | 2d, node2d, sprites | high | 2026-06-19 | | [working-in-3d](concepts/working-in-3d.md) | 3d, node3d, meshes | high | 2026-06-19 | | [physics](concepts/physics.md) | physics, collision, bodies | high | 2026-06-19 | | [animation](concepts/animation.md) | animation, animationplayer, tween | high | 2026-06-19 | | [ui](concepts/ui.md) | ui, control, containers | high | 2026-06-19 | | [exporting](concepts/exporting.md) | export, platforms, templates | high | 2026-06-19 | ## Summaries | Page | Source | Key Topics | Created | |------|--------|------------|---------| | [docs-catalog](summaries/docs-catalog.md) | Godot 4.x manual | area map + class-ref note | 2026-06-19 | ## Syntheses | Page | Pages Compared | Created | |------|----------------|---------| | [best-practices-and-building-a-game](syntheses/best-practices-and-building-a-game.md) | architecture + full build loop | 2026-06-19 | ## Statistics - **Total pages**: 16 - **Concepts**: 14 - **Summaries**: 1 - **Syntheses**: 1 - **Sources ingested**: 22 docs.godotengine.org (4.x stable) HTML pages - **High confidence**: 16 --- title: "Animation" type: concept tags: [animation, animationplayer, tween, keyframes] updated: 2026-06-19 confidence: high sources: [raw/web_community-introduction-to-the-animation-features-godot-engine-stable-d.md] --- # Animation Godot's animation system can animate **almost any property of any node** over time, not just sprites — position, color, scale, shader params, even calling methods. ## AnimationPlayer The **`AnimationPlayer`** node is the core tool: it stores named **animations**, each a set of **tracks** with **keyframes**. Track types include: - **Property tracks** — animate any node property (`position`, `modulate`, `scale`, custom). - **Method call tracks** — invoke functions at a keyframe. - **Audio tracks** and **animation tracks** (nesting animations). You edit animations in the editor's Animation panel: add tracks, set keyframes, and tune interpolation/easing. Play from code with `$AnimationPlayer.play("walk")`; it emits `animation_finished` ([signals](signals.md)). ## AnimationTree For complex characters, **`AnimationTree`** blends and state-machines animations (e.g. idle ↔ walk ↔ run blending, 2D blend spaces) on top of an AnimationPlayer's clips — the tool for non-trivial character animation. ## Tweens (code-driven) For quick, procedural animations create a **`Tween`** (`create_tween()`): interpolate a property over a duration with easing — great for UI transitions, fades, and one-off effects without authoring an animation resource: ```gdscript var t = create_tween() t.tween_property($Sprite2D, "modulate:a", 0.0, 0.5) # fade out over 0.5s ``` ## Sprite animation For frame-by-frame 2D, **`AnimatedSprite2D`** + `SpriteFrames` plays image sequences ([working-in-2d](working-in-2d.md)). Choose: AnimationPlayer for property/keyframe animation, AnimationTree for blending/state, Tween for quick procedural, AnimatedSprite for frame flips. --- title: "Exporting Games" type: concept tags: [export, platforms, templates, deployment] updated: 2026-06-19 confidence: high sources: [raw/web_community-exporting-projects-godot-engine-stable-documentation-in-engl.md] --- # Exporting Games **Exporting** turns your project into a runnable build for a target platform — Godot's "build once, ship everywhere" payoff. ## How it works 1. **Export templates** — install the engine-version-matched export templates (precompiled engine binaries for each platform) via the editor (Manage Export Templates). 2. **Export presets** — Project → Export, add a preset per target (Windows, Linux, macOS, Android, iOS, Web, consoles). Configure per-preset options (icons, features, signing, resource filters). 3. **Export** — produce the executable/package (or "export pack" for just resources). ## Per-platform notes - **Desktop** (Windows/Linux/macOS) — straightforward executables; macOS needs signing/notarization for distribution. - **Android** — needs the Android SDK/keystore; exports an APK/AAB. - **iOS** — needs Xcode/an Apple developer setup. - **Web** — HTML5/WebAssembly build served over HTTPS (with specific COOP/COEP headers for threads). - **C# projects** have additional per-platform export considerations ([scripting-languages-and-csharp](scripting-languages-and-csharp.md)). ## Tips - Match export templates to your **exact engine version**. - Use **feature tags** and per-preset resource options to ship platform-specific builds. - Test the exported build, not just the editor — packaged paths (`res://` vs `user://`), input, and performance can differ. Project structure that exports cleanly is part of [best practices](../syntheses/best-practices-and-building-a-game.md). --- title: "GDScript" type: concept tags: [gdscript, scripting, language, style] updated: 2026-06-19 confidence: high sources: [raw/web_community-gdscript-reference-godot-engine-stable-documentation-in-engl.md, raw/web_community-gdscript-style-guide-godot-engine-stable-documentation-in-en.md] --- # GDScript **GDScript** is Godot's built-in scripting language — a dynamically-typed, Python-like language purpose-built for the engine, with deep editor integration and node-aware syntax. ## Language basics - **Indentation-based** blocks (like Python); `func` for functions, `var`/`const`, `if/elif/else`, `for`, `while`, `match`. - **Variables** are dynamic by default; add **optional static typing** for safety/perf/autocomplete: `var speed: float = 200.0`, `func hit(amount: int) -> void:`. - **`extends`** sets the node type the script attaches to (`extends CharacterBody2D`); the script *is* that node. - **Built-in types** — `Vector2/3`, `Color`, `Rect2`, `Transform`, plus arrays and dictionaries. - **`@export`** exposes a variable to the editor Inspector (`@export var hp: int = 100`); **`@onready`** defers init until the node is ready. ## Node-aware features - **`$NodePath`** / `get_node()` to reference child nodes; `%UniqueName` for scene-unique nodes. - **`signal`** declarations and `.emit()` ([signals](signals.md)). - Engine callbacks `_ready()`, `_process(delta)`, `_physics_process(delta)`, `_input(event)` ([scripting-and-lifecycle](scripting-and-lifecycle.md)). ## Style guide Godot's official style guide standardizes formatting: snake_case for functions/variables, PascalCase for nodes/classes, tabs for indentation, and an ordering convention (signals, enums, constants, exports, vars, then methods with `_ready`/`_process` near the top). Following it keeps projects readable and matches engine examples. ## When to use C# instead GDScript is the default and most tightly integrated. For existing .NET code, heavy CPU logic, or team C# preference, Godot also supports [C#](scripting-languages-and-csharp.md). --- title: "Input Handling" type: concept tags: [input, inputevent, input-map, actions] updated: 2026-06-19 confidence: high sources: [raw/web_community-listening-to-player-input-godot-engine-stable-documentation-.md, raw/web_community-using-inputevent-godot-engine-stable-documentation-in-englis.md] --- # Input Handling Godot handles keyboard, mouse, touch, and gamepad input through **InputEvents** and the **Input Map**. ## Two ways to read input 1. **Event callbacks** — override `_input(event)` or `_unhandled_input(event)`; Godot delivers each **`InputEvent`** (e.g. `InputEventKey`, `InputEventMouseButton`, `InputEventMouseMotion`, `InputEventScreenTouch`, `InputEventJoypadButton`). Best for discrete events (a key press, a click). 2. **Polling** — query `Input` directly in `_process`/`_physics_process` (`Input.is_action_pressed("jump")`, `Input.get_vector(...)`). Best for continuous movement. ## Input actions (the Input Map) Instead of hard-coding keys, define **actions** in Project Settings → Input Map (e.g. `move_left`, `jump`) and bind multiple physical inputs (keyboard + gamepad) to each. Then check actions: ```gdscript if Input.is_action_just_pressed("jump"): velocity.y = JUMP_VELOCITY var dir = Input.get_axis("move_left", "move_right") ``` This decouples gameplay from specific keys — enabling remapping and multi-device support for free. ## Event propagation Input flows through the tree; `_input` sees everything, `_unhandled_input` only sees events not consumed by the [UI](ui.md) or other handlers. Call `get_viewport().set_input_as_handled()` to stop propagation. For movement, read actions in [`_physics_process`](scripting-and-lifecycle.md); for one-shot events, use `_input` or `is_action_just_pressed`. --- title: "Instancing" type: concept tags: [instancing, scenes, packedscene, reuse] updated: 2026-06-19 confidence: high sources: [raw/web_community-creating-instances-godot-engine-stable-documentation-in-engl.md, raw/web_community-instancing-with-signals-godot-engine-stable-documentation-in.md] --- # Instancing **Instancing** creates copies of a [scene](nodes-and-scenes.md) at runtime or in the editor — the mechanism for reuse (many enemies from one Enemy scene, bullets, UI items). ## In the editor Add an instance of another scene as a child via "Instantiate Child Scene." It appears as a single collapsed node you can position and tweak (per-instance property overrides), but edits to the source scene propagate to all instances — edit once, update everywhere. ## In code Load a scene as a **`PackedScene`** and instantiate it: ```gdscript var bullet_scene = preload("res://bullet.tscn") var bullet = bullet_scene.instantiate() add_child(bullet) # add to the running tree bullet.global_position = $Muzzle.global_position ``` `preload` loads at compile time; `load` at runtime. `instantiate()` builds the node subtree; you then `add_child()` it to put it in the [scene tree](nodes-and-scenes.md). ## Instancing with signals A common pattern: an instanced scene **emits a [signal](signals.md)** when something happens (a coin emits `collected`, a mob emits `died`), and the spawner/level connects to it — so instances communicate up without hard references. You can connect the signal right after instantiating, before `add_child`. ## Why it matters Instancing + composition is how Godot scales: design self-contained scenes, then assemble and spawn them. It keeps each scene testable in isolation (run any scene directly) and the project modular ([best-practices-and-building-a-game](../syntheses/best-practices-and-building-a-game.md)). --- title: "Nodes & Scenes" type: concept tags: [nodes, scenes, scene-tree, hierarchy] updated: 2026-06-19 confidence: high sources: [raw/web_community-nodes-and-scenes-godot-engine-stable-documentation-in-englis.md, raw/web_community-overview-of-godot-s-key-concepts-godot-engine-stable-documen.md] --- # Nodes & Scenes Godot games are built from **nodes** organized into **scenes** — the core of the engine. ## Nodes A **node** is the smallest building block. Each has a name, editable properties, a position in a tree, and a type that gives it behavior — e.g. `Sprite2D` (draws an image), `Camera2D`, `CharacterBody2D` (a moving body), `Label`, `AudioStreamPlayer`. Nodes are arranged in a **parent-child tree**; children inherit transforms from parents (move a parent, children follow). ## Scenes A **scene** is a tree of nodes with one **root node**, saved to a `.tscn` file. Crucially a scene is **reusable and composable**: you build a "Player" scene once, then drop instances of it into levels ([instancing](instancing.md)). A scene can be a whole level, a character, a UI panel, or a single reusable widget — there's no hard distinction between "scene" and "object." ## The running scene tree When the game runs, all active scenes live in one big tree — the **`SceneTree`** — with a single root **Window** (Viewport). The **main scene** is what loads on launch (set in project settings). Scripts access the tree via `get_tree()`, the current scene, groups, and node paths (`get_node("Path/To/Node")` or `$Path/To/Node`). ## Why this design Composing behavior from many small single-purpose nodes (composition over inheritance) is Godot's defining approach — you assemble a `CharacterBody2D` + `Sprite2D` + `CollisionShape2D` + `Camera2D` rather than subclassing a giant "GameObject." Give nodes behavior with [scripts](scripting-and-lifecycle.md); connect them with [signals](signals.md). --- title: "Physics & Collision" type: concept tags: [physics, collision, bodies, areas] updated: 2026-06-19 confidence: high sources: [raw/web_community-physics-introduction-godot-engine-stable-documentation-in-en.md] --- # Physics & Collision Godot's physics engine handles movement, collision detection, and response, with parallel node families for 2D and 3D (the `*2D` / `*3D` types behave the same way). ## Body types - **StaticBody** — never moves; immovable world geometry (floors, walls). - **RigidBody** — fully **physics-simulated** (gravity, forces, collisions). You apply forces/impulses; the engine moves it. For realistic dynamic objects. - **CharacterBody** — **script-controlled** movement with collision response via `move_and_slide()`. The go-to for players/enemies where you want precise control, not simulation. - **Area** — detects overlap (bodies/areas entering/leaving) and can apply local gravity/damping; no collision response. For triggers, pickups, hurtboxes — emits `body_entered`/`area_entered` [signals](signals.md). ## Collision shapes, layers & masks Every body needs a child **`CollisionShape`** (or `CollisionPolygon`) defining its shape. **Collision layers** (what a body *is*) and **masks** (what it *scans for*) control which objects interact — e.g. the player layer, the enemy layer, the pickup layer — so you precisely filter collisions. ## Doing it right - Put movement in [`_physics_process`](scripting-and-lifecycle.md) (fixed timestep). - `CharacterBody2D/3D`: set `velocity`, call `move_and_slide()`; check `is_on_floor()`. - Use **Area** + signals for detection (coins, damage zones), **bodies** for solid collision. - Configure layers/masks early — most "they pass through each other" or "everything collides" bugs are layer/mask misconfigurations. (Godot 4 also offers the Jolt physics backend for 3D — see [docs-catalog](../summaries/docs-catalog.md).) --- title: "Scripting & the Node Lifecycle" type: concept tags: [scripting, lifecycle, process, ready, pausing] updated: 2026-06-19 confidence: high sources: [raw/web_community-scripting-godot-engine-stable-documentation-in-english.md, raw/web_community-creating-your-first-script-godot-engine-stable-documentation.md, raw/web_community-pausing-games-and-process-mode-godot-engine-stable-documenta.md] --- # Scripting & the Node Lifecycle A **script** attached to a [node](nodes-and-scenes.md) gives it behavior by overriding engine callbacks. The script extends the node's type and becomes that node. ## Core lifecycle callbacks - **`_ready()`** — called once when the node and its children have entered the [scene tree](nodes-and-scenes.md); do setup, cache node references here. - **`_process(delta)`** — called every rendered frame; `delta` is seconds since last frame. Use for non-physics per-frame logic (UI, timers, input polling). Frame-rate dependent, so scale by `delta`. - **`_physics_process(delta)`** — called at a fixed rate (default 60 Hz) in sync with the [physics](physics.md) engine; do movement and physics here for deterministic behavior. - **`_input(event)` / `_unhandled_input(event)`** — receive [input events](input.md). - **`_enter_tree()` / `_exit_tree()`** — when the node is added/removed from the tree. ## A first script Attach a script to a node, then in `_process`/`_physics_process` read input and move it; in `_ready` grab references (`@onready var sprite = $Sprite2D`). Build behavior from these callbacks plus [signals](signals.md) for events. ## Pausing & process modes Setting `get_tree().paused = true` pauses the game. Each node's **process mode** decides how it behaves while paused: `INHERIT` (default), `PAUSABLE` (stops when paused), `ALWAYS` (keeps running — for pause menus), or `DISABLED`. This lets a pause menu stay interactive while gameplay freezes — set the menu's process mode to `ALWAYS`. ## Frame vs physics Rule of thumb: **movement/physics → `_physics_process`** (fixed timestep, deterministic); **visuals/UI/other → `_process`**. Mixing them up causes jittery or frame-rate-dependent gameplay. --- title: "Scripting Languages & C#" type: concept tags: [csharp, scripting-languages, dotnet, gdextension] updated: 2026-06-19 confidence: high sources: [raw/web_community-scripting-languages-godot-engine-stable-documentation-in-eng.md, raw/web_community-c-basics-godot-engine-stable-documentation-in-english.md] --- # Scripting Languages & C# Godot lets you script in more than one language; you can even mix them in a project. ## The options - **GDScript** — the built-in default: tightest integration, fastest iteration, smallest footprint ([gdscript](gdscript.md)). - **C#** — via the **.NET build** of Godot, for developers who want a statically-typed mainstream language, the .NET ecosystem/NuGet, or to port existing C# code. - **GDExtension** — native (C/C++/Rust/etc.) for performance-critical code or binding existing native libraries (not a "scripting language" but the third path). - **Visual scripting** is no longer built-in in Godot 4. ## C# specifics - Requires the **.NET-enabled** Godot editor and the .NET SDK. - Node scripts subclass the engine type: `public partial class Player : CharacterBody2D`. - Engine callbacks are PascalCase overrides: `_Ready()`, `_Process(double delta)`, `_PhysicsProcess(double delta)`. - Access nodes with `GetNode("Path")`; export with `[Export]`; signals via `[Signal]` delegates and `EmitSignal`. - Naming follows C# conventions (PascalCase), and the API mirrors GDScript's with C# idioms. ## Choosing Default to **GDScript** unless you have a concrete C# reason (existing code, team skills, heavy typed logic). The two interoperate (a C# node and a GDScript node coexist), and both drive the same [nodes/scenes](nodes-and-scenes.md), [signals](signals.md), and [lifecycle](scripting-and-lifecycle.md). Note C# export support varies by platform (e.g. web/mobile have extra considerations) — see [exporting](exporting.md). --- title: "Signals" type: concept tags: [signals, events, observer, decoupling] updated: 2026-06-19 confidence: high sources: [raw/web_community-using-signals-godot-engine-stable-documentation-in-english.md] --- # Signals **Signals** are Godot's built-in observer/event system: a node **emits** a signal when something happens, and any number of other nodes **connect** to react — without the emitter knowing who's listening. This is the primary way to keep nodes decoupled. ## Built-in signals Most nodes ship signals: `Button` emits `pressed`, `Timer` emits `timeout`, `Area2D` emits `body_entered`, an animation player emits `animation_finished`. Connect them in the editor (Node dock → Signals) or in code. ## Connecting ```gdscript func _ready(): $Button.pressed.connect(_on_button_pressed) func _on_button_pressed(): print("clicked") ``` In Godot 4 signals are first-class objects: `node.signal_name.connect(callable)`. The editor can also auto-generate and wire a handler method. ## Custom signals Declare your own with `signal`, optionally typed args, and `emit`: ```gdscript signal health_changed(new_value) func take_damage(amount): health -= amount health_changed.emit(health) ``` A UI health bar connects to `health_changed` — the player doesn't reference the UI at all. ## Why it matters Signals let you build [scenes](nodes-and-scenes.md) that don't depend on their surroundings: an [instanced](instancing.md) coin emits `collected`; the level decides what that means. This decoupling is core Godot [best practice](../syntheses/best-practices-and-building-a-game.md) — prefer signals (call down, signal up) over nodes reaching across the tree. --- title: "UI (Control Nodes)" type: concept tags: [ui, control, containers, themes, anchors] updated: 2026-06-19 confidence: high sources: [raw/web_community-user-interface-ui-godot-engine-stable-documentation-in-engli.md] --- # UI (Control Nodes) Godot's user-interface system is built on **`Control`** nodes — a separate node family from [2D](working-in-2d.md)/[3D](working-in-3d.md), designed for resolution-independent layout. ## Control nodes Everything UI extends **`Control`**: `Label`, `Button`, `TextureRect`, `LineEdit`/`TextEdit`, `Panel`, `ProgressBar`, `RichTextLabel`, etc. Controls have a rect (position + size), **anchors** and **margins/offsets** that pin them relative to their parent so the UI adapts to different screen sizes. ## Layout: anchors & containers - **Anchors** attach an edge of a control to a relative point of its parent (e.g. anchor to bottom-right so it stays in the corner). - **Containers** auto-arrange children: `VBoxContainer`/`HBoxContainer` (stacks), `GridContainer`, `MarginContainer`, `CenterContainer`, `TabContainer`, `ScrollContainer`. Put controls in containers and let them handle sizing/positioning instead of manual placement — the key to robust, scalable UI. ## Theming A **`Theme`** resource centralizes fonts, colors, styleboxes, and icons across controls for a consistent look; override per-node with theme overrides. Use the theme editor to build a cohesive style ([docs-catalog](../summaries/docs-catalog.md) lists the font/theme guides). ## Input & signals Controls consume [input](input.md) first (focus, mouse filter) and emit [signals](signals.md) (`pressed`, `text_changed`, `value_changed`). Put HUDs on a `CanvasLayer` so they render above the game and ignore the [camera](working-in-2d.md). Build menus and HUDs from containers + controls, wire them with signals, and theme them — keeping UI a self-contained [scene](nodes-and-scenes.md) you instance into the game. --- title: "What is Godot" type: concept tags: [godot, game-engine, overview, key-concepts] updated: 2026-06-19 confidence: high sources: [raw/web_community-introduction-to-godot-godot-engine-stable-documentation-in-e.md, raw/web_community-overview-of-godot-s-key-concepts-godot-engine-stable-documen.md] --- # What is Godot **Godot** is a free, open-source (MIT) game engine for making 2D and 3D games, exported to many platforms from one project. It's a full editor + engine + scripting environment in a small download, community-developed and free of royalties or subscription. ## Key concepts (the mental model) Godot's design is built on a few ideas ([nodes-and-scenes](nodes-and-scenes.md) covers them in depth): - **Nodes** — the basic building blocks; each does one thing (sprite, camera, body, label). Hundreds of node types ship in. - **Scenes** — a tree of nodes saved as a reusable unit (a player, a level, a UI). A game is scenes composed of scenes. - **Scene tree** — the running game is one tree of all active nodes (the `SceneTree`). - **Signals** — nodes emit signals on events; other nodes connect to them (observer pattern) — Godot's decoupling mechanism ([signals](signals.md)). - **Scripts** — attach a script (usually [GDScript](gdscript.md), or [C#](scripting-languages-and-csharp.md)) to a node to give it behavior. ## What's in the box The **editor** (scene tree, inspector, 2D/3D viewports, script editor, animation, debugger), [2D](working-in-2d.md) and [3D](working-in-3d.md) engines, a [physics](physics.md) system, [animation](animation.md) tools, a [UI/Control](ui.md) system, an [input](input.md) system, and one-click [export](exporting.md) to desktop, mobile, web, and consoles. ## Versions This wiki tracks the **Godot 4.x** stable line (docs at 4.7). Godot 3.x differs in API. Next: learn the scene system in [nodes-and-scenes](nodes-and-scenes.md), then [scripting](scripting-and-lifecycle.md). Full map: [docs-catalog](../summaries/docs-catalog.md). --- title: "Working in 2D" type: concept tags: [2d, node2d, sprites, canvasitem] updated: 2026-06-19 confidence: high sources: [raw/web_community-introduction-to-2d-godot-engine-stable-documentation-in-engl.md] --- # Working in 2D Godot has a dedicated 2D engine with its own node family rooted at **`Node2D`** (which inherits `CanvasItem`). 2D uses a pixel coordinate system with **+Y pointing down**. ## Core 2D nodes - **`Sprite2D`** — draws a texture; **`AnimatedSprite2D`** — frame animation via SpriteFrames. - **`Node2D`** — base for anything with a 2D transform (position/rotation/scale). - **Bodies** — `CharacterBody2D` (script-controlled movement), `RigidBody2D` (physics-driven), `StaticBody2D`, `Area2D` (detection) — each pairs with a `CollisionShape2D` ([physics](physics.md)). - **`Camera2D`** — viewport framing, follow, limits, zoom. - **`TileMapLayer`** — tile-based levels from a `TileSet`. - **`CanvasLayer`** — render independent of the camera (HUDs). ## Drawing & transforms Everything 2D derives from `CanvasItem`, which provides drawing, visibility, modulate (tint), z-index ordering, and material/shader hooks. Transforms are hierarchical ([nodes-and-scenes](nodes-and-scenes.md)): a child sprite moves with its parent. ## Building a 2D game Compose a player from `CharacterBody2D` + `Sprite2D`/`AnimatedSprite2D` + `CollisionShape2D` + `Camera2D`, script movement in [`_physics_process`](scripting-and-lifecycle.md) using [input actions](input.md), and assemble levels with `TileMapLayer` and [instanced](instancing.md) scenes. UI overlays use [Control nodes](ui.md) on a `CanvasLayer`. The classic "your first 2D game" tutorial walks a full example (see [docs-catalog](../summaries/docs-catalog.md)). --- title: "Working in 3D" type: concept tags: [3d, node3d, meshes, rendering] updated: 2026-06-19 confidence: high sources: [raw/web_community-introduction-to-3d-godot-engine-stable-documentation-in-engl.md] --- # Working in 3D Godot's 3D engine mirrors 2D conceptually but in three dimensions, rooted at **`Node3D`** (formerly Spatial), using a right-handed coordinate system with **+Y up**. ## Core 3D nodes - **`MeshInstance3D`** — renders a mesh (a primitive or imported model); **`MultiMeshInstance3D`** for many instances cheaply. - **`Node3D`** — base for anything with a 3D transform. - **Bodies** — `CharacterBody3D`, `RigidBody3D`, `StaticBody3D`, `Area3D` + `CollisionShape3D` ([physics](physics.md)). - **`Camera3D`** — the view; **lights** (`DirectionalLight3D`, `OmniLight3D`, `SpotLight3D`); **`WorldEnvironment`** for sky, fog, tonemapping, and post-processing. - **`GridMap`** — tile-based 3D levels from a `MeshLibrary`. ## Rendering Godot 4 ships rendering backends (Forward+ for desktop, Mobile, and Compatibility for web/low-end). Materials (`StandardMaterial3D` / shader materials), global illumination options, and the `WorldEnvironment` control look. Importing models (glTF is the recommended format) brings in meshes, materials, and animations. ## Building a 3D game Set up a scene with a `Camera3D`, lights, a `WorldEnvironment`, and your meshes; drive a `CharacterBody3D` in [`_physics_process`](scripting-and-lifecycle.md) with [input](input.md); detect with `Area3D`. The "your first 3D game" tutorial builds a complete example ([docs-catalog](../summaries/docs-catalog.md)). Much of the workflow — [nodes/scenes](nodes-and-scenes.md), [instancing](instancing.md), [signals](signals.md), [scripting](scripting-and-lifecycle.md) — is identical to 2D; only the node types and math change. --- title: "Activity Log" type: log --- # Activity Log Append-only record of all wiki changes. ## Format Each entry follows this format: ``` ### YYYY-MM-DD HH:MM — [Action Type] - **Source/Trigger**: what initiated the action - **Pages created**: list of new pages - **Pages updated**: list of updated pages - **Notes**: any contradictions flagged, decisions made ``` --- ### 2026-04-08 00:00 — Setup - **Source/Trigger**: Repository initialized - **Pages created**: index.md, log.md, dashboard.md, analytics.md, flashcards.md - **Pages updated**: none - **Notes**: Empty knowledge base ready for first source ingestion ### 2026-06-19 00:00 — Initial curation (medium rung) - **Source/Trigger**: 22 docs.godotengine.org (Godot 4.x stable) HTML pages via web_urls - **Pages created**: 14 concepts, 1 summary (docs-catalog), 1 synthesis (best-practices-and-building-a-game) - **Pages updated**: index.md - **Notes**: No llms.txt; godot-docs repo is reStructuredText (.rst, not fetchable as markdown) -> curated HTML doc pages via web_urls. Godot pre-cutoff, sources ground specifics. Class/API reference (huge generated) catalogued not ingested. Category: devtools. --- title: "Docs Catalog" type: summary tags: [catalog, map, reference] updated: 2026-06-19 confidence: high sources: [raw/web_community-introduction-to-godot-godot-engine-stable-documentation-in-e.md, raw/web_community-scripting-godot-engine-stable-documentation-in-english.md] --- # Docs Catalog This wiki distills the core of the Godot 4.x manual (docs.godotengine.org, sourced as HTML pages in `raw/`). The full manual is far larger; this maps what's covered and what to look up live. | Area | Wiki page | Manual section | |---|---|---| | Overview | [what-is-godot](../concepts/what-is-godot.md) | getting_started/introduction | | Scene system | [nodes-and-scenes](../concepts/nodes-and-scenes.md), [instancing](../concepts/instancing.md), [signals](../concepts/signals.md) | getting_started/step_by_step | | Scripting | [gdscript](../concepts/gdscript.md), [scripting-languages-and-csharp](../concepts/scripting-languages-and-csharp.md), [scripting-and-lifecycle](../concepts/scripting-and-lifecycle.md) | tutorials/scripting | | Input | [input](../concepts/input.md) | tutorials/inputs | | 2D / 3D | [working-in-2d](../concepts/working-in-2d.md), [working-in-3d](../concepts/working-in-3d.md) | tutorials/2d, tutorials/3d | | Physics | [physics](../concepts/physics.md) | tutorials/physics | | Animation | [animation](../concepts/animation.md) | tutorials/animation | | UI | [ui](../concepts/ui.md) | tutorials/ui | | Export | [exporting](../concepts/exporting.md) | tutorials/export | | Best practices | [best-practices-and-building-a-game](../syntheses/best-practices-and-building-a-game.md) | tutorials/best_practices | ## Not covered here (look up in the manual) - **Class reference** — the per-class API for every node/type (`@GlobalScope`, `Node`, `CharacterBody2D`, …) is a huge generated reference; use docs.godotengine.org or the editor's built-in help (F1) for exact methods/properties/signals. - **Step-by-step game tutorials** — "Your first 2D game" and "Your first 3D game" build complete examples. - **Specialized topics** — shaders, navigation, networking/multiplayer, XR, audio buses, GDExtension, platform-specific export details, the asset pipeline, and editor plugins each have dedicated manual sections. - **Version** — this wiki tracks Godot **4.x (stable, 4.7)**; Godot 3.x has API differences. --- title: "Best Practices & Building a Game" type: synthesis tags: [best-practices, architecture, workflow, synthesis] updated: 2026-06-19 confidence: high sources: [raw/web_community-introduction-godot-engine-stable-documentation-in-english.md, raw/web_community-overview-of-godot-s-key-concepts-godot-engine-stable-documen.md, raw/web_community-using-signals-godot-engine-stable-documentation-in-english.md] --- # Best Practices & Building a Game How the pieces fit into a real project, plus Godot's recommended architecture habits. ## The build loop 1. **Model the game as scenes** ([nodes-and-scenes](../concepts/nodes-and-scenes.md)) — a Player scene, an Enemy scene, a Level scene, a HUD scene. Each is self-contained and runnable on its own. 2. **Compose from nodes** — assemble behavior from small single-purpose nodes rather than monolithic classes. 3. **Script behavior** ([scripting-and-lifecycle](../concepts/scripting-and-lifecycle.md)) — movement in [`_physics_process`](../concepts/scripting-and-lifecycle.md) via [input actions](../concepts/input.md); setup in `_ready`. 4. **Connect with signals** ([signals](../concepts/signals.md)) — instead of nodes reaching across the tree. 5. **Instance and assemble** ([instancing](../concepts/instancing.md)) — spawn enemies/bullets/items from PackedScenes. 6. **Add systems** — [physics](../concepts/physics.md), [animation](../concepts/animation.md), [UI](../concepts/ui.md). 7. **Export** ([exporting](../concepts/exporting.md)) to your platforms. ## Architecture best practices - **Composition over inheritance** — Godot's core philosophy; build from nodes, not deep class trees. - **"Call down, signal up"** — a parent may call methods on children (it knows them); children should **emit signals** rather than reach up/sideways to specific nodes. This keeps scenes reusable and decoupled. - **Keep scenes self-contained** — a scene shouldn't assume what's outside it; expose behavior via exported properties and signals so it drops into any context. - **Avoid hard node paths across scenes** — `get_node("../../Manager")` is brittle; prefer signals, groups, or dependency injection via `@export`. - **One responsibility per scene/script** — small, testable units; run any scene directly to test it. - **Use the Input Map** — never hard-code keys ([input](../concepts/input.md)). ## Common beginner pitfalls Movement in `_process` instead of `_physics_process` (jitter); forgetting `move_and_slide()` / collision shapes; collision layer/mask misconfig ([physics](../concepts/physics.md)); tightly coupling scenes with absolute node paths; not matching [export templates](../concepts/exporting.md) to the engine version. Start from the official "first 2D/3D game" tutorials ([docs-catalog](../summaries/docs-catalog.md)) to internalize the loop.