Wie man ein Godot-Spiel fur das Web exportiert (HTML5-Leitfaden, 2026)

Godot exportiert Spiele als HTML5 und WebAssembly fur das Web, was bedeutet, dass dein Spiel in einem Browser-Tab lauft, ohne Download und ohne Plugin. Das ist der schnellste Weg, um jemandem einen spielbaren Build zu prasentieren: Link einfugen, klicken, spielen.

Der Haken ist, dass "fur das Web exportieren" zwei Aufgaben sind, nicht eine. Die Dateien zu erzeugen ist einfach und dauert etwa eine Minute. Diese Dateien tatsachlich im Browser zum Laufen zu bringen ist das, woran fast alle scheitern, weil moderne Browser zwei spezifische HTTP-Header benotigen, von denen der threaded WebAssembly-Build abhangt. Dieser Leitfaden behandelt beide Halfte, die genauen Einstellungen und die drei Fehler, die fur die meisten fehlgeschlagenen Exports verantwortlich sind.

Er gilt fur Godot 4 und fur Summer Engine, das mit Godot 4 kompatibel ist und dieselbe Export-Pipeline verwendet. Wenn du dein Spiel durch das Beschreiben in normaler Sprache erstellt hast, ist der Export-Schritt identisch mit einem handcodierten Godot-Projekt.

{/* IMAGE: The Godot Export dialog open with a Web preset selected, the Export Project button highlighted. 1200x675 editor screenshot. */}

Was ein Web-Export tatsachlich erzeugt

Wenn du exportierst, erstellt Godot keine einzelne Datei. Es schreibt einen kleinen Ordner mit statischen Assets:

• index.html ist die Seite, die alles ladt. Das ist es, was der Browser offnet.
• Eine .wasm-Datei ist die Godot-Engine selbst, kompiliert zu WebAssembly. Das ist das grosste Stuck.
• Eine .pck-Datei enthalt deine Spieldaten: Szenen, Skripte und Assets, zusammengepackt.
• Eine .js-Datei ist der Lader-Verbindungscode, der die Engine mit der Seite verbindet.
• Oft eine .worker.js und eine .audio.worklet.js fur Threading und Sound.

All diese Dateien mussen zusammen liegen und uber HTTP bereitgestellt werden. Du kannst die index.html nicht doppelklicken und erwarten, dass sie lauft, was der erste Stolperstein fur die meisten ist. Dazu kommen wir noch.

Schritt 1: Export-Templates installieren

Godot liefert den Editor und die Export-Templates separat aus. Die Templates sind die vorgefertigten Engine-Binardateien fur jede Plattform, einschliesslich des WebAssembly-Builds fur den Browser. Eine frische Installation hat sie nicht.

Gehe zu Editor, dann Export-Templates verwalten, und klicke auf Herunterladen und installieren. Das ladt die Templates fur deine genaue Engine-Version.

Das ist die wichtigste Regel im gesamten Prozess: Die Templates mussen genau zu deiner Engine-Version passen. Templates fur 4.3 werden kein Projekt ausfuhren, das aus 4.4 exportiert wurde. Ein Versionskonflikt ist die zweithaufigste Ursache fur einen kaputten Web-Build, direkt nach den Headern. Wenn du deine Engine aktualisierst, installiere die Templates neu.

Schritt 2: Ein Web-Export-Preset hinzufugen

Offne Projekt, dann Exportieren. Klicke auf Hinzufugen und wahle Web.

Ein Optionsbereich erscheint. Die Standardwerte sind vernunftig, aber zwei Einstellungen sind fur das Web besonders relevant:

• Export-Typ. "Regular" gibt dir den threaded Build, der schneller und die Standardoption ist. Fruher gab es einen nicht-threaded Fallback fur Hosts, die keine speziellen Header senden konnten. Unter Godot 4 willst du fast immer den threaded Build und loser das Header-Problem auf der Host-Seite, was wir weiter unten behandeln.
• VRAM-Texturkomprimierung. Hake die Kontrollkastchen fur deine Zielplattformen an. Der Browser verwendet auf den meisten Rechnern den Pfad "Fur Desktop", also lass das aktiviert. Mobile Browser benotigen moglicherweise auch die mobile Komprimierungsoption.

Lasse die Felder Head Include und benutzerdefinierte HTML-Shell leer, es sei denn, du hast einen Grund, sie zu andern. Die Standard-Shell ubernimmt das Laden und den Ladebalken fur dich.

Schritt 3: Das Projekt exportieren

Wahle einen Zielordner. Erstelle einen leeren Ordner mit einem Namen wie web-build, damit die Ausgabedateien nicht mit anderen Dateien durcheinander kommen.

Benenne die Hauptdatei index.html, nicht nach deinem Spiel. Die meisten Hosts, einschliesslich itch.io, suchen nach einer index.html als Einstiegspunkt. Wenn du sie mygame.html nennst, findet der Host sie nicht und du siehst eine leere Verzeichnisauflistung anstelle deines Spiels.

Klicke auf Projekt exportieren. In wenigen Sekunden fullt sich der Ordner mit den zuvor genannten Dateien. Das ist die einfache Halfte erledigt.

{/* IMAGE: A file explorer showing the exported web-build folder contents: index.html, .wasm, .pck, .js files. 1000x500. */}

Schritt 4: Das Header-Problem, klar erklart

Hier ist der Teil, den kein schnelles Tutorial erwahnt, und der Grund, warum die meisten ersten Web-Exports einen schwarzen Bildschirm zeigen.

Godot 4s threaded Build verwendet SharedArrayBuffer, eine Browser-Funktion, die es der WebAssembly-Engine ermoglicht, auf mehreren Threads zu laufen. Aus Sicherheitsgrunden aktivieren Browser SharedArrayBuffer nur, wenn die Seite mit zwei spezifischen HTTP-Response-Headern bereitgestellt wird:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

Diese zwei Header versetzen die Seite in einen Zustand, den Browser als "cross origin isolated" bezeichnen. Ohne sie ist SharedArrayBuffer undefiniert, die Engine kann ihre Threads nicht starten, und du bekommst ein schwarzes Canvas und einen Konsolenfehler, der SharedArrayBuffer is not defined oder crossOriginIsolated is false erwahnt.

Du setzt diese Header nicht in Godot. Du setzt sie auf dem Server, der die Dateien ausliefert. Das ist der entscheidende Punkt. Daraus ergeben sich drei Konsequenzen:

1. Die index.html von deiner Festplatte zu offnen wird nie funktionieren, weil kein Server vorhanden ist, um Header zu senden.
2. Ein Host, der keine benutzerdefinierten Header senden kann (zum Beispiel normales GitHub Pages), kann den threaded Build nicht so direkt ausfuhren.
3. Ein Host, der sie automatisch sendet (itch.io mit dem richtigen Schalter), funktioniert einfach.

Schritt 5: Lokal testen, bevor du hochladst

Debugge einen Web-Export nie, indem du hochladst und aktualisierst. Teste zuerst auf deinem eigenen Rechner mit einem lokalen Server, der die Header setzt.

Die schnellste Option, wenn du Python installiert hast, ist ein kleines Skript, das den Ordner mit beiden Headern bereitstellt. Speichere dies als serve.py in deinem web-build-Ordner:

import http.server, socketserver

class Handler(http.server.SimpleHTTPRequestHandler):
    def end_headers(self):
        self.send_header("Cross-Origin-Opener-Policy", "same-origin")
        self.send_header("Cross-Origin-Embedder-Policy", "require-corp")
        super().end_headers()

with socketserver.TCPServer(("", 8000), Handler) as httpd:
    print("Serving on http://localhost:8000")
    httpd.serve_forever()

Fuhre python serve.py aus und offne http://localhost:8000. Wenn das Spiel hier ladt, ist der Export korrekt und alle weiteren Probleme sind ein Host-Konfigurationsproblem, kein Godot-Problem.

Wenn du kein Skript schreiben mochtest, startet die Option Remote Debug im Editor von Godot (das Dropdown neben dem Play-Button, "Im Browser ausfuhren") einen korrekt konfigurierten lokalen Server fur dich und offnet den Build. Das ist die schnellste Uberprufung wahrend der Entwicklung.

Schritt 6: Hosten

itch.io (am einfachsten, kostenlos)

Das ist der empfohlene Weg zum Teilen und fur Game Jams.

1. Packe den gesamten web-build-Ordner als ZIP. Packe den Inhalt, nicht den ubergeordneten Ordner, sodass index.html auf der obersten Ebene der ZIP-Datei liegt.
2. Erstelle auf itch.io ein neues Projekt und setze Art des Projekts auf HTML.
3. Lade die ZIP-Datei hoch und hake Diese Datei wird im Browser gespielt an.
4. Setze in den Einbettungsoptionen eine Ansichtsgrose, die der Auflosung deines Spiels entspricht, und hake SharedArrayBuffer-Unterstutzung an, wenn itch es anbietet (es setzt die beiden Header fur dich).

itch.io behandelt die Header automatisch, weshalb es der Weg des geringsten Widerstands ist. Wenn dein Spiel lokal mit dem obigen Skript funktioniert, aber nicht auf itch, fehlt fast immer der SharedArrayBuffer-Schalter.

Netlify, Vercel oder dein eigener Server

Diese Hosts erlauben dir, benutzerdefinierte Header zu setzen, sodass der threaded Build nach der Konfiguration problemlos lauft.

Auf Netlify fuge eine _headers-Datei im Deploy-Root hinzu:

/*
  Cross-Origin-Opener-Policy: same-origin
  Cross-Origin-Embedder-Policy: require-corp

Auf Vercel setze dieselben zwei Header in vercel.json unter einer headers-Regel. Auf deinem eigenen nginx- oder Apache-Server fuge sie dem Location-Block hinzu. Das Prinzip ist uberall identisch: Sende diese zwei Header fur die Seite und die Assets.

GitHub Pages

Normales GitHub Pages kann keine benutzerdefinierten Header senden, daher lauft der threaded Build dort nicht direkt. Menschen umgehen das mit einem kleinen Service Worker, der die Header clientseitig injiziert (der "coi-serviceworker"-Ansatz ist der gangige), aber das ist ein Workaround und nicht jeder Browser respektiert ihn. Wenn GitHub Pages eine harte Anforderung ist, rechne damit, diesen Workaround hinzufugen zu mussen. Andernfalls nutze itch.io oder Netlify und spare dir den Aufwand.

Schwarzen Bildschirm beheben: die Drei-Fragen-Checkliste

Wenn du ein schwarzes Canvas siehst, offne die Entwicklerkonsole des Browsers (drucke F12, dann den Tab Konsole) und lies den ersten roten Fehler. Er wird auf eine von drei Ursachen hinweisen.

1. Hast du die Datei direkt geoffnet? Wenn die URL mit file:// beginnt, ist das das Problem. Stelle sie uber HTTP mit dem lokalen Skript oben bereit.
2. Erscheint SharedArrayBuffer oder crossOriginIsolated im Fehler? Die Header fehlen. Fuge sie beim Host hinzu oder schalte den itch.io SharedArrayBuffer-Schalter um.
3. Erwahnt der Fehler eine Version oder einen fehlgeschlagenen Template-Ladevorgang? Deine Export-Templates passen nicht zu deiner Engine-Version. Installiere sie uber "Export-Templates verwalten" neu.

Neunzig Prozent der fehlgeschlagenen Web-Exports sind eines dieser drei. Arbeite sie der Reihe nach durch, bevor du annimmst, dass dein Spiel einen tieferen Fehler hat.

Was sich nicht auf den Browser ubertragen lasst

Web-Export ist real, aber er ist kein Desktop mit einer URL. Einige Dinge verhalten sich anders:

• Dateisystemzugriff ist sandboxed. Speicherdaten gehen in die IndexedDB des Browsers, nicht in einen Ordner auf der Festplatte. Plane dein Speichersystem entsprechend, wenn das Web dein Ziel ist.
• Native Plugins (GDExtension-Bibliotheken, die fur den Desktop kompiliert wurden) funktionieren im Browser meist nicht. Alles, das eine native .dll oder .so verlinkt, benotigt eine webkompatible Alternative oder muss fur den Web-Build weggekurzt werden.
• Ladegrosse zahlt mehr als anderswo. Im Web ladt der Spieler die Engine, das Datenpaket und alle Assets, bevor das Spiel startet. Komprimiere Texturen, entferne ungenutzte Assets und halte den 3D-Umfang realistisch, wenn das Web dein Hauptkanal ist. Ein schweres 3D-Spiel kann einen Erstladevorgang von 30 bis 100 MB bedeuten, was auf mobilen Daten schmerzhaft ist.
• Audio-Latenz ist im Browser etwas hoher als auf dem Desktop. Meist in Ordnung, gelegentlich merklich bei rhythmisch anspruchsvollen Spielen.

Wenn du das Spiel mit Summer Engine gebaut hast

Die obigen Export-Schritte sind identisch, weil Summer Engine mit Godot 4 kompatibel ist und dieselbe HTML5- und WebAssembly-Pipeline verwendet. Der Unterschied liegt weiter oben, in der Art, wie das Spiel erstellt wird. Anstatt den Spieler-Controller, das Szenen-Setup und die Spiellogik von Hand zu schreiben, beschreibst du, was du mochtest, und die KI baut es. Wenn du bereit bist zu teilen, exportierst du fur das Web genau wie hier beschrieben.

Der Web-Export ist Teil des kostenlosen Tarifs. Bauen und Exportieren sind kostenlos, und der bezahlte Plan deckt nur hoheren KI-Verbrauch und Team-Funktionen ab, sodass die gesamte Schleife von der Idee bis zu einem Link, den jemand anklicken kann, nichts kostet, um sie auszuprobieren.

Wenn du noch kein Projekt begonnen hast, ist der schnellste Weg zu einem webbereiten Build, mit einem Template zu beginnen, das bereits Bewegung und eine Kamera eingerichtet hat, die gewunschten Mechaniken daruber zu beschreiben und dann den sechs Schritten oben zu folgen, um es in einem Browser zu zeigen. Die gesamte Schleife, vom leeren Projekt bis zu einem spielbaren itch.io-Link, passt in einen Nachmittag.