Seit Unity 2023 mit seiner Runtime-Fee-Ankündigung für Unruhe unter Indie-Entwicklern sorgte, ist die Zahl der Umsteiger zu Godot spürbar gewachsen. Mit Godot 4.7.1-stable, veröffentlicht am 14. Juli 2026 als Wartungsversion des im Juni 2026 erschienenen 4.7-Zweigs, steht Entwicklern in Deutschland, Österreich und der Schweiz eine ausgereifte, kostenlose Engine zur Verfügung, die weder Lizenzgebühren noch Umsatzbeteiligung verlangt. Dieses Tutorial führt Schritt für Schritt durch Installation, erstes Projekt und Export, inklusive Codebeispielen in GDScript und C#.

Der Reiz von Godot liegt dabei nicht nur im fehlenden Preisschild. Die Engine bringt eine eigene Szenen- und Node-Architektur mit, die sich grundlegend von Unitys Component-System unterscheidet und viele Standardaufgaben, etwa Kollisionserkennung oder UI-Anchoring, bereits eingebaut löst. Für Teams, die zusätzlich Wert auf einen vollständig einsehbaren Engine-Quellcode legen, etwa aus Compliance-Gründen, ist die MIT-Lizenz ein weiterer praktischer Vorteil gegenüber den Closed-Source-Ansätzen von Unity und (teilweise) Unreal.

Auch die Update-Geschwindigkeit spricht aktuell für Godot: Zwischen Godot 4.4 im März 2025, Godot 4.6 im Januar 2026 und Godot 4.7 im Juni 2026 lag jeweils ein Abstand von wenigen Monaten, mit regelmäßigen Wartungsversionen dazwischen. Für Entwickler bedeutet das kürzere Wartezeiten auf Bugfixes, verlangt im Gegenzug aber auch, Release Notes vor jedem größeren Update zu lesen, da sich Standardwerte zwischen Versionen gelegentlich ändern.

Das Godot-Repository auf GitHub zählt mittlerweile rund 95.500 Sterne, etwa 22.000 Forks und knapp 2.900 Mitwirkende, verteilt auf 59 offizielle Releases. Wer jetzt einsteigt, arbeitet mit der aktuell empfohlenen stabilen Basis: Godot 4.7 erhält laufend Bug- und Sicherheitsfixes, während Version 4.8 sich noch im Entwicklungszweig befindet und für das vierte Quartal 2026 geplant ist. Am Ende dieses Guides steht ein lauffähiges 2D-Projekt mit Spielerbewegung, Kollisionserkennung und Export für Windows, Linux und Web.

Dieser Guide richtet sich an Programmieranfänger mit Grundkenntnissen in einer beliebigen Sprache genauso wie an Entwickler, die aus Unity oder Unreal wechseln. Wo es Unterschiede zu bekannten Konzepten gibt, etwa bei GameObjects gegenüber Nodes, wird das im Text explizit benannt. Insgesamt umfasst das Tutorial zwölf Kernschritte plus drei vertiefende Abschnitte zu Assets, Mobile-Export und Versionskontrolle, damit am Ende nicht nur ein Testprojekt, sondern ein sauber strukturiertes Grundgerüst für echte Spiele steht.

Voraussetzungen: Hardware, Software und Versionen

Bevor der erste Download startet, lohnt ein kurzer Check der Systemvoraussetzungen. Godot 4.7 läuft auf allen drei großen Desktop-Betriebssystemen und stellt vergleichsweise geringe Hardware-Anforderungen. Die folgende Liste deckt das ab, was für dieses Tutorial gebraucht wird.

  • Betriebssystem: Windows 10/11 (64-Bit), macOS 10.15 oder neuer, oder eine aktuelle Linux-Distribution (x86_64)
  • Grafikkarte mit Vulkan-1.0- oder OpenGL-3.3-Unterstützung (praktisch jede GPU der letzten zehn Jahre)
  • Mindestens 4 GB RAM, empfohlen werden 8 GB oder mehr für flüssiges Arbeiten mit dem 3D-Editor
  • Rund 200 MB freier Speicher für den Editor, zusätzlich Platz für Projekte und Export-Templates
  • Godot 4.7.1-stable (aktuelle Wartungsversion des 4.7-Zweigs, Stand August 2026)
  • Optional für C#-Projekte: .NET SDK, mindestens Version 8.0, LTS-Version empfohlen
  • Ein Code-Editor mit GDScript-Unterstützung, etwa Visual Studio Code, falls nicht der eingebaute Godot-Editor genutzt wird

Wichtig für Umsteiger aus der Unity-Welt: Godot bietet zwei Editor-Builds. Die Standardversion deckt GDScript, C++ über GDExtension und visuelle Shader ab. Wer in C# entwickeln will, braucht zusätzlich den .NET-Build der Engine, der separat markiert im Download-Bereich steht.

Für die Skript-Arbeit reicht der eingebaute Godot-Editor völlig aus, er bietet Syntax-Highlighting, Autovervollständigung und Sprung-zu-Definition für GDScript direkt ohne Erweiterung. Wer trotzdem lieber in Visual Studio Code arbeitet, etwa weil dort schon andere Projekte laufen, installiert die offizielle „godot-tools”-Erweiterung und aktiviert unter „Editor” → „Editor-Einstellungen” → „Externer Editor” die Verbindung zwischen Godot und VS Code. Beide Wege führen zum gleichen Ergebnis, der eingebaute Editor spart aber einen Installationsschritt.

Schritt 1: Godot 4.7.1 herunterladen

Der Download läuft über die offizielle Godot-Download-Seite. Dort wählt man zwischen dem Standard-Build und dem .NET-Build für C#. Für dieses Tutorial empfiehlt sich direkt der .NET-Build, da beide Codebeispiele (GDScript und C#) darin funktionieren, während der reine Standard-Build kein C# unterstützt.

Die Editor-Binaries für 4.7.1-stable liegen als ZIP-Archiv vor, es gibt keine klassische Installer-Routine. Das hält die Engine portabel: Ein Ordner reicht aus, um Godot auf einem USB-Stick oder in einem Firmen-Netzlaufwerk mitzunehmen. Wer die genauen Release-Notes zur 4.7-Reihe nachlesen will, findet sie auf der Godot-4.7-Release-Seite.

Auf der Download-Seite stehen neben den Editor-Binaries auch SHA-256-Prüfsummen zum Abgleich bereit. Gerade in Firmenumgebungen mit strengen Software-Richtlinien lohnt sich dieser Schritt, um sicherzustellen, dass die heruntergeladene Datei nicht auf dem Weg verändert wurde. Unter Windows lässt sich die Prüfsumme über certutil -hashfile Godot_v4.7.1-stable_win64.exe SHA256 in der PowerShell ermitteln und mit dem veröffentlichten Wert vergleichen.

Wer statt der ZIP-Datei lieber ein Paketmanagement nutzt, findet Godot mittlerweile auch in gängigen Paketquellen wie Winget, Scoop, Homebrew oder Flatpak. Diese Variante erleichtert spätere Updates, da sich die Engine dann über den jeweiligen Paketmanager statt manuell aktualisieren lässt, was besonders bei häufigen Wartungsversionen wie 4.7.1 und potenziell folgenden 4.7.x-Patches Zeit spart.

Schritt 2: Installation unter Windows

Unter Windows entpackt man das heruntergeladene ZIP-Archiv in einen Ordner ohne Sonderzeichen im Pfad, etwa C:\Godot\4.7.1. Die ausführbare Datei trägt einen Namen wie Godot_v4.7.1-stable_mono_win64.exe beim .NET-Build. Ein Doppelklick startet den Editor direkt, eine separate Installation entfällt.

Windows Defender SmartScreen blockiert die Datei beim ersten Start häufig, weil die Binärdatei nicht signiert ist. In diesem Fall auf „Weitere Informationen” und danach „Trotzdem ausführen” klicken. Wer C#-Projekte plant, installiert zusätzlich das .NET SDK 8.0 über den offiziellen Microsoft-Installer und startet danach den Rechner neu, damit die Umgebungsvariablen korrekt gesetzt werden.

Schritt 3: Installation unter Linux

Unter Linux läuft die Installation ähnlich unkompliziert. Nach dem Download des ZIP-Archivs macht ein Terminal-Befehl die Datei ausführbar:

chmod +x Godot_v4.7.1-stable_mono_linux_x86_64
./Godot_v4.7.1-stable_mono_linux_x86_64

Auf Distributionen mit Wayland kann es zu Darstellungsfehlern im Editor kommen. Als Workaround startet man Godot mit dem X11-Backend über --display-driver x11. Wer eine AppImage-Variante bevorzugt, findet diese ebenfalls im Download-Bereich, sie benötigt keine zusätzlichen Berechtigungen außer der Ausführbarkeit.

Schritt 4: Installation unter macOS

Auf dem Mac liegt Godot als .zip mit einer Godot.app darin vor. Nach dem Entpacken zieht man die App in den Ordner „Programme”. Da die Datei nicht über den Mac App Store notarisiert wurde, meldet Gatekeeper beim ersten Start eine Warnung. Ein Rechtsklick auf die App und die Auswahl „Öffnen” umgeht diese Sperre, ohne Systemeinstellungen dauerhaft zu ändern.

Apple-Silicon-Chips (M-Serie) werden nativ unterstützt, eine Rosetta-Emulation ist nicht nötig. Für C#-Projekte gilt auch hier: Das .NET SDK muss separat installiert werden, am einfachsten über brew install dotnet-sdk, sofern Homebrew bereits eingerichtet ist.

Schritt 5: Godot starten und erstes Projekt anlegen

Nach dem ersten Start zeigt Godot den Projekt-Manager. Über den Button „Neues Projekt erstellen” öffnet sich ein Dialog, in dem Projektname, Speicherort und Renderer festgelegt werden. Für dieses Tutorial wählt man den Namen MeinErstesSpiel und als Renderer Forward+, den Standard-Renderer für Desktop-Projekte mit voller Vulkan-Unterstützung.

Wer auf schwächerer Hardware arbeitet oder für Mobilgeräte entwickelt, sollte stattdessen Mobile wählen, das auf reduzierte Grafikfeatures setzt und dafür deutlich weniger GPU-Leistung braucht. Nach der Bestätigung legt Godot automatisch eine project.godot-Datei im gewählten Ordner an, die Engine-Version und Projekteinstellungen speichert.

Direkt nach dem Anlegen lohnt sich ein kurzer Abstecher in die Projekteinstellungen unter „Projekt” → „Projekteinstellungen” → „Anwendung” → „Konfiguration”. Dort lassen sich Fenstertitel, Standard-Fenstergröße und ein Icon für das Projekt hinterlegen, alles Werte, die später auch in den Export-Presets wieder auftauchen. Wer von Anfang an eine feste Zielauflösung wie 1280×720 definiert, erspart sich später Layout-Probleme bei UI-Elementen, die sonst je nach Bildschirmgröße unterschiedlich positioniert erscheinen.

Schritt 6: Den Editor verstehen

Der Godot-Editor gliedert sich in fünf Kernbereiche: die Szenenansicht links oben, den Node-Baum darunter, den zentralen Viewport, das Inspector-Panel rechts und die untere Leiste mit Reitern für Debugger, Ausgabe und Animation. Wer von Unity kommt, findet im Node-Baum eine grobe Entsprechung zur Hierarchy, im Inspector eine Entsprechung zum Unity-Inspector.

Der zentrale Unterschied liegt im Node-System: Statt GameObjects mit Components arbeitet Godot mit einem Baum aus Nodes, wobei jeder Node-Typ bereits spezifisches Verhalten mitbringt. Ein CharacterBody2D etwa kennt Physik und Kollisionen von Haus aus, ohne dass man Komponenten einzeln zusammenstecken muss. Szenen lassen sich zudem ineinander verschachteln, was wiederverwendbare Prefab-ähnliche Strukturen erlaubt.

Im FileSystem-Dock, meist unten links angesiedelt, liegt die komplette Projektstruktur als Dateibaum. Von dort lassen sich Szenen, Skripte und importierte Grafiken per Drag-and-Drop direkt in den Node-Baum oder den Viewport ziehen. Das Ausgabe-Panel am unteren Bildschirmrand zeigt print()-Ausgaben und Fehlermeldungen zur Laufzeit, ein wichtiger erster Anlaufpunkt, wenn ein Skript nicht wie erwartet reagiert. Oben im Viewport wechselt man über die Reiter „2D”, „3D”, „Skript” und „AssetLib” zwischen den Arbeitsbereichen, wobei „AssetLib” direkten Zugriff auf den offiziellen Asset Store bietet.

Schritt 7: Erste 2D-Szene bauen

Über „Szene” → „Neue Szene” und die Auswahl von 2D-Szene entsteht die Basis für das Tutorial-Projekt. Als Root-Node dient ein Node2D, umbenannt in Main. Anschließend fügt man per Rechtsklick einen CharacterBody2D-Node hinzu und benennt ihn Player.

Unter diesem Player-Node braucht es zwei Kind-Nodes: einen Sprite2D für die Grafik und einen CollisionShape2D für die Kollisionsform. Ohne die Kollisionsform ignoriert die Physik-Engine den Node komplett, ein häufiger Anfängerfehler, der weiter unten im Abschnitt zu Stolperfallen genauer erklärt wird. Die Szene speichert man über Strg+S als player.tscn im Projektordner.

Eine saubere Namensgebung im Node-Baum zahlt sich bei wachsenden Projekten schnell aus. Godot verwendet Node-Namen intern auch für Pfade wie $Player/Sprite2D, weshalb spätere Umbenennungen alle darauf verweisenden Skripte zerstören können. Eine bewährte Konvention: Node-Typen wie Sprite2D oder CollisionShape2D als Namen belassen, sofern es nur eine Instanz pro Szene gibt, und nur bei mehreren gleichartigen Nodes eigene, sprechende Namen wie SpriteLinks oder SpriteRechts vergeben.

Schritt 8: GDScript oder C# – die richtige Sprache wählen

Godot 4.7 unterstützt zwei Hauptsprachen für Spiellogik. GDScript ist die eingebaute, Python-ähnliche Sprache der Engine, optimiert für schnelles Prototyping und direkt ohne Zusatzinstallation nutzbar. C# läuft über den .NET-Build und eignet sich für Teams mit .NET-Hintergrund oder Projekte, die von stärkerer statischer Typisierung profitieren.

Für kleinere 2D-Projekte und den Einstieg empfiehlt sich GDScript, da die Iterationszeiten kürzer ausfallen und die Engine-Dokumentation primär darauf ausgelegt ist. Dieses Tutorial zeigt beide Varianten des Bewegungsskripts, damit der Umstieg in beide Richtungen möglich bleibt. Details zur Sprache selbst liefert die offizielle GDScript-Dokumentation.

Schritt 9: Das erste Skript schreiben

Mit einem Rechtsklick auf den Player-Node und „Skript anhängen” öffnet sich der integrierte Skript-Editor. Godot schlägt automatisch einen passenden Dateinamen vor, in diesem Fall player.gd. Das folgende GDScript-Grundgerüst definiert Geschwindigkeit und Sprungkraft als exportierte Variablen, die im Inspector direkt anpassbar sind.

extends CharacterBody2D

@export var speed: float = 300.0
@export var jump_velocity: float = -400.0

var gravity: float = ProjectSettings.get_setting("physics/2d/default_gravity")

func _physics_process(delta: float) -> void:
    if not is_on_floor():
        velocity.y += gravity * delta

    if Input.is_action_just_pressed("ui_accept") and is_on_floor():
        velocity.y = jump_velocity

    var direction := Input.get_axis("ui_left", "ui_right")
    if direction:
        velocity.x = direction * speed
    else:
        velocity.x = move_toward(velocity.x, 0, speed)

    move_and_slide()

Die Methode _physics_process läuft synchron zur Physik-Engine und eignet sich damit besser für Bewegungslogik als das gewöhnliche _process. Der Aufruf move_and_slide() übernimmt Kollisionsauflösung automatisch, inklusive Gleiten entlang von Wänden und Rampen.

Wer die einzelnen Zeilen nachvollziehen will, findet hier die Kurzfassung: @export macht eine Variable im Inspector sichtbar und editierbar, ohne dass man dafür den Code öffnen muss. is_on_floor() fragt ab, ob der Körper aktuell Bodenkontakt hat, und verhindert damit Doppelsprünge in der Luft. Input.get_axis() liefert einen Wert zwischen -1 und 1 aus zwei entgegengesetzten Eingaben, hier für die horizontale Bewegung. move_toward() schließlich bremst die Geschwindigkeit sanft ab, statt sie abrupt auf null zu setzen, was sich in der Praxis deutlich natürlicher anfühlt als ein harter Stopp.

Schritt 10: Kollisionen und Sprites einrichten

Für die eigentliche Kollisionserkennung mit Gegnern oder Sammelobjekten eignet sich ein Area2D-Node besser als CharacterBody2D, da er auf Overlap-Events statt fester Kollisionsauflösung setzt. Das folgende Beispiel zeigt ein Sammelobjekt, das sich beim Kontakt mit dem Spieler selbst entfernt und ein Signal aussendet.

extends Area2D

signal collected(value: int)

@export var point_value: int = 10

func _ready() -> void:
    body_entered.connect(_on_body_entered)

func _on_body_entered(body: Node2D) -> void:
    if body.is_in_group("player"):
        collected.emit(point_value)
        queue_free()

Wichtig ist hier die Gruppen-Zuweisung: Der Player-Node muss im Node-Inspector unter „Node” → „Gruppen” der Gruppe player hinzugefügt werden, sonst greift die Bedingung is_in_group("player") nie. Das Signal collected lässt sich später an einen Score-Manager binden, ohne dass Sammelobjekt und UI direkt voneinander wissen müssen.

Für größere Projekte mit mehreren Kollisionstypen, etwa Spieler, Gegnern und Wänden, lohnt sich ein Blick auf Collision Layers und Masks im Inspector jedes physikbasierten Nodes. Ein Layer legt fest, zu welcher Gruppe ein Node selbst gehört, eine Mask legt fest, mit welchen Layern er reagiert. Trennt man Spieler-Projektile und Gegner-Projektile in eigene Layer, verhindert das versehentliche Kollisionen, etwa dass ein Spieler-Schuss den eigenen Charakter trifft, ohne dass dafür zusätzlicher Code nötig wäre.

Schritt 11: Spielerbewegung und Input-Mapping programmieren

Die im Skript verwendeten Aktionen ui_left, ui_right und ui_accept sind Godot-Standardaktionen und bereits mit Pfeiltasten sowie Leertaste belegt. Für ein eigenes Projekt empfiehlt sich aber eine eigene Input-Map unter „Projekt” → „Projekteinstellungen” → „Input Map”, etwa move_left, move_right und jump, um Tastenbelegungen später ohne Codeänderung anpassen zu können.

Jeder Input-Map-Eintrag akzeptiert mehrere Belegungen gleichzeitig, sodass Tastatur und Controller parallel funktionieren, ohne im Code unterscheiden zu müssen. Ein Klick auf das Plus-Symbol neben der Aktion öffnet einen Dialog, der auch Gamepad-Buttons und Analog-Sticks erkennt, sobald ein Controller angeschlossen ist. Godot erkennt gängige Xbox- und PlayStation-Controller automatisch über das eingebaute Mapping-Datenbank-System, eine manuelle Konfiguration ist für Standard-Controller normalerweise nicht nötig.

Wer C# statt GDScript bevorzugt, erhält mit identischer Logik dieses Äquivalent. Es setzt eine bereits per .NET-Build angelegte Klasse voraus, die über „Skript anhängen” mit Sprache C# erzeugt wird.

using Godot;

public partial class Player : CharacterBody2D
{
    [Export] public float Speed = 300.0f;
    [Export] public float JumpVelocity = -400.0f;

    private float _gravity = ProjectSettings
        .GetSetting("physics/2d/default_gravity").AsSingle();

    public override void _PhysicsProcess(double delta)
    {
        Vector2 velocity = Velocity;

        if (!IsOnFloor())
            velocity.Y += _gravity * (float)delta;

        if (Input.IsActionJustPressed("ui_accept") && IsOnFloor())
            velocity.Y = JumpVelocity;

        float direction = Input.GetAxis("ui_left", "ui_right");
        velocity.X = direction != 0
            ? direction * Speed
            : Mathf.MoveToward(velocity.X, 0, Speed);

        Velocity = velocity;
        MoveAndSlide();
    }
}

Beide Skripte erzeugen identisches Spielverhalten. Der Hauptunterschied liegt in der expliziten Typisierung von C# gegenüber der dynamischeren, aber ebenfalls typisierbaren Natur von GDScript. Details zum C#-Setup liefert die offizielle C#-Dokumentation.

Mit F6 lässt sich die aktuelle Szene direkt testen, ohne den kompletten Projekt-Export durchlaufen zu müssen. Läuft alles korrekt, öffnet sich ein separates Spielfenster, der Charakter reagiert auf Pfeiltasten und Leertaste, und das Ausgabe-Panel im Editor bleibt weitgehend leer bis auf eine Zeile zum Szenenstart. Ein typisches fehlerfreies Ausgabe-Beispiel sieht so aus:

Godot Engine v4.7.1.stable.official
OpenGL API 3.3 (Compatibility) - Using Device: NVIDIA - GeForce RTX 4060
--- Debug adapter server started on port 6006 ---
--- GDScript language server started on port 6005 ---

Erscheint stattdessen eine rote Fehlermeldung wie Invalid get index 'position' (on base: 'null instance'), deutet das fast immer auf einen falsch referenzierten oder noch nicht initialisierten Node hin, meist weil ein per $NodeName referenzierter Node nicht existiert oder umbenannt wurde. Der Debugger stoppt in diesem Fall automatisch an der betroffenen Zeile und zeigt im Stack-Trace-Panel den genauen Aufrufpfad, was die Fehlersuche gegenüber einem reinen Konsolen-Log erheblich beschleunigt.

Schritt 12: Spiel exportieren (Windows, Linux, Web)

Vor dem ersten Export müssen die passenden Export-Templates installiert sein. Godot bietet diese über „Editor” → „Verwalte Export-Templates” direkt zum Download an, passend zur installierten Engine-Version 4.7.1. Anschließend legt man unter „Projekt” → „Exportieren” ein neues Preset für die Zielplattform an, etwa Windows Desktop, Linux/X11 oder Web.

Für automatisierte Builds, etwa in einer CI-Pipeline, lässt sich der Export auch über die Kommandozeile anstoßen, ohne den Editor zu öffnen:

godot --headless --export-release "Windows Desktop" build/MeinErstesSpiel.exe
godot --headless --export-release "Linux/X11" build/MeinErstesSpiel.x86_64
godot --headless --export-release "Web" build/index.html

Der --headless-Flag verhindert, dass Godot eine grafische Oberfläche startet, was den Befehl auch auf Build-Servern ohne Display nutzbar macht. Details zu plattformspezifischen Export-Einstellungen, etwa Icons und Codesigning unter Windows, dokumentiert die offizielle Export-Anleitung.

Der Web-Export eignet sich besonders für schnelles Feedback, da sich das fertige Spiel direkt auf Plattformen wie itch.io hochladen lässt, ohne dass Spieler irgendetwas installieren müssen. Nach dem Export liegen eine index.html, eine .wasm-Datei und mehrere Zusatzdateien im Zielordner, die zusammen als ZIP-Archiv bei itch.io als „HTML”-Projekt hochgeladen werden. Wichtig ist dabei, im itch.io-Uploadformular die Option „This file will be played in the browser” zu aktivieren und die index.html als Startdatei zu markieren, sonst bleibt die Seite leer.

Assets, Plugins und der Godot Asset Store

Über den Reiter „AssetLib” im Viewport erreicht man direkt aus dem Editor den offiziellen Godot Asset Store, ein kuratiertes Verzeichnis kostenloser Plugins, Shader, Icons und kompletter Vorlagen. Anders als Unitys Asset Store gibt es hier keine kostenpflichtigen Einträge, alle Beiträge stehen unter offenen Lizenzen wie MIT oder CC0 zur Verfügung. Für Einsteiger besonders nützlich sind Plugins wie Dialogic für Dialogsysteme, Phantom Camera für Kamera-Steuerung oder GUT für automatisierte Tests.

Plugins landen nach der Installation im Ordner addons/ im Projektverzeichnis und lassen sich unter „Projekt” → „Projekteinstellungen” → „Plugins” einzeln aktivieren oder deaktivieren. Das hält den Editor übersichtlich, da inaktive Plugins keine zusätzlichen Menüs oder Docks anzeigen. Wichtig für Teams: Der addons/-Ordner sollte in die Versionskontrolle aufgenommen werden, damit alle Mitentwickler dieselben Plugin-Versionen nutzen, auch wenn das den Projektordner spürbar vergrößert.

Für Grafik-Assets außerhalb des Asset Stores eignen sich Plattformen wie itch.io oder Kenney.nl, die viele kostenlose 2D-Sprite-Sets unter CC0-Lizenz anbieten und sich direkt in ein Godot-Projekt importieren lassen. Beim Import wandelt Godot PNG- und JPEG-Dateien automatisch in ein internes Textur-Format um, eine manuelle Konvertierung ist nicht nötig. Für Pixel-Art-Projekte lohnt sich ein Blick in die Import-Einstellungen jeder Textur, dort lässt sich der Filtermodus projektweit über die Standardeinstellungen unter „Projekt” → „Projekteinstellungen” → „Rendering” → „Textures” auf „Nearest” umstellen, statt jede Grafik einzeln nachzubearbeiten.

Mobile-Export für Android einrichten

Neben Desktop und Web unterstützt Godot 4.7 auch den Export für Android und iOS, was gerade für Indie-Teams mit begrenztem Budget interessant ist, da keine separate Mobile-Engine-Lizenz nötig wird. Für den Android-Export braucht es zusätzlich das Android SDK sowie ein Java Development Kit, beide lassen sich am einfachsten über Android Studio installieren, das die passenden Umgebungsvariablen automatisch setzt.

Unter „Editor” → „Editor-Einstellungen” → „Export” → „Android” trägt man die Pfade zu Android SDK und Debug-Keystore ein. Godot bringt für Testzwecke einen Debug-Keystore automatisch mit, für eine Veröffentlichung im Play Store braucht es dagegen einen eigenen Release-Keystore, den man einmalig über die Kommandozeile erzeugt:

keytool -genkey -v -keystore release.keystore -alias meinspiel -keyalg RSA -keysize 2048 -validity 10000

Diesen Keystore hinterlegt man anschließend im Android-Export-Preset unter „Release” und behält Passwort sowie Datei sicher außerhalb der Versionskontrolle, da darüber spätere Updates der App signiert werden müssen. Ohne den identischen Keystore lassen sich einmal veröffentlichte Apps im Play Store nicht mehr aktualisieren, ein Fehler, der sich im Nachhinein nicht reparieren lässt. Ein Backup des Release-Keystores an einem separaten, sicheren Ort gehört deshalb von Anfang an zum Workflow, nicht erst kurz vor dem ersten Update.

Für iOS-Exporte gilt ein ähnliches Prinzip mit Apple-eigenen Zertifikaten und Provisioning-Profilen, allerdings zusätzlich mit der Einschränkung, dass der eigentliche Export-Build nur auf einem Mac mit installiertem Xcode möglich ist. Wer ausschließlich unter Windows oder Linux entwickelt, braucht für den finalen iOS-Export also entweder einen physischen Mac oder einen Cloud-Build-Dienst, der Xcode remote bereitstellt.

Versionskontrolle mit Git richtig einrichten

Godot-Projekte bestehen aus Textdateien wie .tscn und .gd, die sich gut mit Git vertragen, da Diffs lesbar bleiben und Merge-Konflikte selten binäre Daten betreffen. Ein sauberes Setup beginnt mit einer passenden .gitignore-Datei, die generierte Cache-Ordner und Nutzer-spezifische Einstellungen ausschließt.

.godot/
.import/
export_presets.cfg
*.translation
build/
.DS_Store

Der Ordner .godot/ enthält reine Editor-Cache-Daten wie Thumbnails und importierte Ressourcen, die Godot beim ersten Öffnen automatisch neu erzeugt. Die Datei export_presets.cfg landet bewusst ebenfalls in der Ignore-Liste, da sie oft lokale Pfade zu Keystores oder SDKs enthält, die sich zwischen Entwicklerrechnern unterscheiden. Wer im Team arbeitet, sollte stattdessen eine export_presets.cfg.example ohne sensible Pfade versionieren und dokumentieren, wie sie lokal angepasst wird.

Godot-Community und Lernressourcen

Über die reine Dokumentation hinaus bietet die Godot-Community mehrere Anlaufstellen für Fragen und Austausch. Das offizielle Forum sowie ein aktiver Discord-Server dienen als Hauptkanäle für technischen Support, während GitHub Discussions sich eher für Feature-Wünsche und Engine-interne Diskussionen eignet. Bug-Reports gehören direkt ins GitHub-Issue-Tracker-System des Hauptrepositorys, wo das Entwicklerteam aktiv Pull Requests aus der Community prüft und mergt.

Für strukturiertes Lernen jenseits der offiziellen Docs bieten sich die kostenlosen „Godot Docs”-Kurse direkt auf der Projektseite an, ergänzt durch Community-Tutorials auf YouTube und in Foren-Threads, die sich meist an einer konkreten Godot-Version orientieren. Bei älteren Tutorials lohnt ein Blick auf die im Video oder Artikel genannte Godot-Version, da sich die API zwischen 3.x und 4.x an mehreren Stellen grundlegend geändert hat, etwa beim Node-Typ für 2D-Physikkörper.

Für deutschsprachige Entwickler gibt es mittlerweile eigene Communitys, etwa deutschsprachige Discord-Server und Foren-Unterforen, in denen Fragen ohne Sprachbarriere gestellt werden können. Wer an konkreten Spielprojekten mit anderen zusammenarbeiten will, findet über die jährlichen Godot-Wild-Jams und andere Game-Jam-Formate einen niedrigschwelligen Einstieg, bei dem sich viele der hier gezeigten Grundlagen innerhalb weniger Tage in einem echten Mini-Projekt anwenden lassen.

Godot 4.7 vs. Unity vs. Unreal: Ein schneller Vergleich

Wer zwischen den drei großen Engines abwägt, sollte vor allem Lizenzmodell und Sprachunterstützung im Blick behalten. Die folgende Tabelle stellt die zentralen Unterschiede gegenüber, ausführlicher behandelt im separaten Godot-Unity-Unreal-Vergleich auf shattered.io.

MerkmalGodot 4.7UnityUnreal Engine
LizenzkostenKostenlos (MIT-Lizenz)Kostenlos bis Umsatzgrenze, danach Abo-PflichtKostenlos, 5 % Tantieme ab Umsatzschwelle
QuellcodeVollständig offen (Open Source)GeschlossenOffen einsehbar (Epic-Lizenz)
HauptsprachenGDScript, C#, C++ (GDExtension)C#C++, Blueprints (visuell)
Editor-Größeca. 200 MBmehrere GB je nach Modulenmehrere GB
Stärke2D-Spiele, leichte 3D-Projekte, Indie-TeamsMobile & Cross-Platform, große Asset-BibliothekAAA-3D-Grafik, Fotorealismus

Für kleine bis mittelgroße 2D-Projekte spricht bei Godot vor allem die geringe Einstiegshürde: kein Konto-Zwang, kein Lizenz-Dashboard, keine Umsatzmeldung. Für aufwendige 3D-AAA-Produktionen bleibt Unreal wegen seiner Grafik-Pipeline meist die naheliegendere Wahl, während Unity durch seine riesige Asset-Store-Bibliothek und Mobile-Reichweite punktet. Die Entscheidung hängt am Ende weniger von einer einzelnen Kennzahl ab als vom Projektumfang: Ein Solo-Entwickler mit einem 2D-Plattformer spart mit Godot vor allem Zeit beim Setup, ein Studio mit bestehender Unity-Codebasis spart dagegen eher durch den Verzicht auf eine Migration.

Häufige Stolperfallen beim Einstieg

Wer die Engine zum ersten Mal nutzt, stößt fast zwangsläufig auf eine Handvoll wiederkehrender Fehlerbilder, die in Godot-Foren regelmäßig als Anfängerfragen auftauchen. Die folgenden fünf Fehler tauchen bei Godot-Einsteigern besonders oft auf und lassen sich mit etwas Vorwissen vermeiden.

  • Fehlende Kollisionsform: Ein CharacterBody2D ohne CollisionShape2D-Kind-Node bewegt sich, kollidiert aber mit nichts. Die Engine gibt dafür keine Fehlermeldung aus, das Verhalten wirkt einfach „kaputt”.
  • Verwechslung von _process und _physics_process: Bewegungscode in _process führt zu inkonsistenter Geschwindigkeit je nach Framerate, weil die Methode nicht an den festen Physik-Takt gebunden ist.
  • Falscher Node-Typ für Kollisionserkennung: Wer Overlap-Events braucht, aber einen StaticBody2D statt Area2D nutzt, wundert sich, warum body_entered nie feuert.
  • Vergessene Gruppen-Zuweisung: Signale und is_in_group()-Abfragen laufen ins Leere, wenn der Player-Node nie der passenden Gruppe zugewiesen wurde.
  • Export-Templates nicht installiert: Der Export-Dialog erlaubt zwar das Anlegen eines Presets, bricht beim eigentlichen Export aber mit einer Fehlermeldung ab, wenn die Templates fehlen.

Fehlerbehebung: Häufige Probleme und Lösungen

Auch nach korrekter Installation tauchen typische Fehlerbilder auf, gerade beim Zusammenspiel aus Betriebssystem, Grafiktreiber und .NET-Umgebung. Die folgende Liste deckt die acht häufigsten Probleme ab, die in Godot-Foren und Community-Kanälen rund um 4.7.x gemeldet werden, jeweils mit der Ursache und dem schnellsten bekannten Workaround.

  • Editor startet nicht unter Linux/Wayland: Mit dem Flag --display-driver x11 beim Start erzwingen, bis der native Wayland-Support stabiler läuft.
  • „C# nicht verfügbar” im Skript-Dialog: Der Standard-Build ohne .NET wurde heruntergeladen. Stattdessen den mit „.NET” markierten Build von der Download-Seite holen.
  • Build schlägt mit „dotnet: command not found” fehl: Das .NET SDK ist nicht installiert oder nicht im PATH. SDK-Version über dotnet --version im Terminal prüfen.
  • Export-Fehler „Template nicht gefunden”: Export-Templates fehlen für die exakte Engine-Version. Über „Editor” → „Verwalte Export-Templates” nachinstallieren, Versionsnummer muss exakt zu 4.7.1 passen.
  • Ruckelnde Bewegung trotz korrektem Code: V-Sync oder eine falsch gesetzte physics_ticks_per_second-Einstellung prüfen, Standard liegt bei 60.
  • Signal wird nicht ausgelöst: Prüfen, ob connect() tatsächlich in _ready() aufgerufen wurde und ob der Node zur Laufzeit überhaupt im Baum aktiv ist.
  • Assets erscheinen unscharf: Der Standard-Filtermodus interpoliert Pixel-Art. Unter Sprite2D-Textureigenschaften den Filter auf „Nearest” stellen, um scharfe Pixel-Kanten zu erhalten.
  • Windows SmartScreen blockiert den Editor dauerhaft: Datei-Eigenschaften öffnen, Haken bei „Zulassen” setzen, danach erneut versuchen. Alternativ eine Ausnahme im Windows-Defender hinzufügen.

Fortgeschrittene Tipps für den Godot-Workflow

Sobald die Grundlagen sitzen, lohnen sich einige Workflow-Anpassungen. Autoloads (in Godot als „Singletons” bekannt) eignen sich für globale Systeme wie Score-Zähler oder Spielzustand, die über mehrere Szenen hinweg erreichbar bleiben müssen. Sie werden unter „Projekt” → „Projekteinstellungen” → „Autoload” registriert und stehen danach überall im Projekt ohne zusätzliche Referenz zur Verfügung.

Für größere Projekte empfiehlt sich zusätzlich der Einsatz von Szenen-Vererbung: Eine Basis-Szene für Gegner-Typen lässt sich mehrfach ableiten, ohne Node-Struktur und Kollisionslogik jedes Mal neu aufzubauen. Wer Versionskontrolle mit Git nutzt, sollte die .godot-Ordnerstruktur in die .gitignore aufnehmen, da sie reine Cache-Daten enthält und bei jedem Öffnen neu generiert wird.

Für Performance-kritische Abschnitte lohnt ein Blick in den eingebauten Profiler unter „Debugger” → „Profiler”, der Frame-Zeiten pro Funktion aufschlüsselt. Gerade bei physics_process-lastigem Code zeigt sich hier schnell, ob Kollisionsprüfungen oder eigene Logik die Framerate drücken.

Statisches Typing in GDScript verbessert sowohl Lesbarkeit als auch Laufzeitgeschwindigkeit spürbar. Statt var speed = 300.0 schreibt man var speed: float = 300.0, wodurch der Editor Typfehler bereits während des Tippens markiert, statt sie erst zur Laufzeit als Absturz zu zeigen. Für Testabdeckung eignet sich das Community-Plugin GUT (Godot Unit Test), das klassische Unit-Test-Patterns mit Assertions direkt im Godot-Workflow abbildet und sich über den Asset Store installieren lässt. Wer Wert auf sauberen Code legt, sollte zudem den eingebauten Warnungs-Modus unter „Projekt” → „Projekteinstellungen” → „Debug” → „GDScript” aktivieren, der etwa ungenutzte Variablen oder unerreichbaren Code markiert.

Das fertige Beispielprojekt im Überblick

Nach Abschluss aller Schritte liegt ein lauffähiges 2D-Projekt vor, das sich als Grundgerüst für eigene Spiele eignet. Die folgende Tabelle fasst die Projektstruktur zusammen, wie sie nach diesem Tutorial im Projektordner liegt.

Datei/OrdnerInhalt
project.godotProjektkonfiguration, Engine-Version, Renderer-Einstellung
player.tscnSpieler-Szene mit CharacterBody2D, Sprite2D, CollisionShape2D
player.gd / Player.csBewegungs- und Sprunglogik (GDScript oder C#)
collectible.tscnSammelobjekt-Szene mit Area2D und Signal-Logik
main.tscnHauptszene, in die Player und Sammelobjekte eingebettet sind
build/Export-Ausgabe für Windows, Linux und Web

Von hier aus lässt sich das Projekt in beliebige Richtungen erweitern: ein zweiter Level über eine weitere .tscn-Datei, ein UI-Overlay für den Punktestand per Autoload-Signal, oder Gegner-KI über einen eigenen Enemy-Node mit ähnlicher Struktur wie der Player. Die Node-basierte Architektur von Godot macht genau diese Art von Wiederverwendung unkompliziert.

Ein sinnvoller nächster Schritt nach diesem Grundgerüst ist ein einfacher Score-Manager als Autoload, der auf das collected-Signal des Sammelobjekts hört und den Punktestand in einem UI-Label anzeigt. Danach folgt meist eine Titelszene mit Start-Button, die über get_tree().change_scene_to_file("res://main.tscn") in die Hauptszene wechselt. Beide Erweiterungen lassen sich mit dem hier gezeigten Signal- und Node-Wissen ohne neue Konzepte umsetzen, was den eigentlichen Lerneffekt dieses Tutorials ausmacht: Sobald Bewegung, Kollision und Export einmal sitzen, bauen fast alle weiteren 2D-Spielmechaniken auf denselben drei Bausteinen auf.

Häufig gestellte Fragen

Ist Godot 4.7 wirklich komplett kostenlos?

Ja. Godot steht unter der MIT-Lizenz, es gibt keine Umsatzgrenze, keine Abo-Pflicht und keine Tantiemen, unabhängig davon, wie viel Umsatz ein damit veröffentlichtes Spiel erzielt.

Welche Godot-Version sollte ich für ein neues Projekt nutzen?

Aktuell empfiehlt sich Godot 4.7.1-stable, die neueste Wartungsversion des aktiven 4.7-Zweigs. Godot 4.8 befindet sich noch im Entwicklungszweig und ist für neue Projekte noch nicht empfehlenswert, bis eine stabile Version erscheint.

Kann ich zwischen GDScript und C# im selben Projekt mischen?

Ja, Godot erlaubt beide Sprachen parallel im selben Projekt, solange der .NET-Build der Engine verwendet wird. Verschiedene Nodes können also unterschiedliche Skriptsprachen nutzen.

Lohnt sich der Umstieg von Unity auf Godot?

Für kleinere 2D- und leichte 3D-Projekte spricht vieles dafür, insbesondere die fehlenden Lizenzkosten und die kompakte Editor-Größe. Für Projekte, die stark auf den Unity Asset Store oder bestehende Unity-spezifische Plugins angewiesen sind, bedeutet ein Umstieg dagegen zusätzlichen Migrationsaufwand.

Unterstützt Godot 4.7 auch 3D-Projekte?

Ja, über den Forward+-Renderer stehen moderne 3D-Features inklusive Global Illumination und Volumetric Fog zur Verfügung. Für sehr aufwendige AAA-3D-Produktionen bleibt die Engine aber hinter Unreal zurück.

Wie groß ist die Godot-Community aktuell?

Das offizielle GitHub-Repository zählt rund 95.500 Sterne und knapp 2.900 Mitwirkende, verteilt auf 59 Releases. Dazu kommen aktive Foren und Discord-Communitys für Support und Showcases.

Läuft Godot auch auf älterer Hardware?

Für 2D-Projekte reichen 4 GB RAM und eine GPU mit OpenGL-3.3-Unterstützung meist aus. Für 3D-Projekte mit dem Forward+-Renderer empfehlen sich 8 GB RAM und eine Vulkan-kompatible Grafikkarte für flüssiges Arbeiten im Editor.

Wo finde ich offizielle Release-Notes und Changelogs?

Die vollständige Historie inklusive aller Wartungsversionen steht im GitHub-Releases-Bereich von Godot, ergänzt durch ausführlichere Erläuterungen im offiziellen Godot-Blog zu jeder Hauptversion.

Kann ich ein Godot-3-Projekt auf Godot 4.7 aktualisieren?

Godot bringt einen eingebauten Projekt-Konverter mit, der beim Öffnen eines 3.x-Projekts in Godot 4 automatisch angeboten wird. Da sich API und Node-Namen zwischen den Hauptversionen an vielen Stellen geändert haben, etwa KinematicBody2D zu CharacterBody2D, bleibt bei größeren Projekten trotzdem manuelle Nacharbeit nötig. Ein Backup vor der Konvertierung ist in jedem Fall Pflicht.

Brauche ich für den Android-Export einen Google-Play-Account?

Zum Testen auf dem eigenen Gerät oder Emulator nicht, dafür reicht der Debug-Export mit dem mitgelieferten Debug-Keystore. Für eine Veröffentlichung im Play Store ist dagegen ein kostenpflichtiges Google-Play-Entwicklerkonto samt eigenem Release-Keystore erforderlich, unabhängig davon, welche Engine für das Spiel genutzt wurde.

Weitere Einsteiger-Tutorials und Vergleiche rund um Gaming-Tools finden sich in der Gaming-Rubrik von shattered.io.