# Ein Spiel ins Web portieren

> Ein Browser-Build hat kein Dateisystem, eine harte Speichergrenze und einen Download, dem der Spieler zusieht. Diese drei Fakten prägen die ganze Portierung.

- URL: https://www.summerengine.com/de/port-a-game-to-web
- Keyword: spiel ins web portieren
- Related: https://www.summerengine.com/de/porting

Ein Spiel ins Web zu portieren heißt, eine Browser-Version eines Spiels zu bauen, das dir gehört und das über WebAssembly und die Grafik-APIs des Browsers läuft. Eine Tatsache gilt speziell für Summer Engine. Summer exportiert einen Web-Build für ein GDScript-Projekt, und du veröffentlichst ihn auf Summer Games, wo Leute das Spiel im Browser spielen. Diese Seite erklärt, was ein Browser-Build braucht.

Das Web ist die einzige Plattform, auf der der Spieler deinem Download zusieht. Jedes Megabyte ist eine Gelegenheit abzuspringen. Der Speicher ist niedriger gedeckelt als auf dem Desktop, besonders in mobilen Browsern. Es gibt kein Dateisystem, Spielstände liegen also im Browser-Speicher, den der Spieler löschen kann. Audio darf erst starten, wenn der Spieler mit der Seite interagiert hat.

Dafür bekommst du sofortiges Spielen, einen Link, den du überall posten kannst, und keine Store-Freigabe. Das macht einen Web-Build zu einem starken Demoformat neben einem Desktop-Release, wenn deine Engine es unterstützt.

## Größe und Ladezeit entscheiden

Lege vor dem Start ein Downloadbudget fest und gestalte darauf hin. Komprimiere Texturen, skaliere alles herunter, was ohnehin nicht in voller Auflösung sichtbar ist, wandle Audio mit sinnvollen Bitraten nach OGG und schneide ungenutzte Inhalte aus dem Export. Lade eine spielbare erste Szene schnell und streame oder lade den Rest verzögert nach. Zeige echten Fortschritt statt eines Ladekringels. Ein Web-Build, der dreißig Sekunden bis zum Start braucht, verliert die meisten, die geklickt haben.

## Browser-Grenzen, um die du herum programmierst

Audio-Kontexte bleiben bis zu einer Nutzergeste angehalten, ergänze also einen Klick-zum-Start-Bildschirm. Der Speicher liegt lokal im Browser und ist löschbar, verlass dich also nicht fest auf Spielstände und biete einen Export oder eine Cloud-Option an, wenn Fortschritt wichtig ist. Tabs wandern in den Hintergrund und werden gedrosselt, pausiere also bei Sichtbarkeitswechsel. Nutze Delta-Zeit, denn die Framerate schwankt stärker als nativ. Vollbild und Pointer Lock brauchen beide eine Nutzergeste. Mobile Browser haben weniger Speicher und keine Tastatur.

## Eingabe auf einer Seite

Unterstütze Tastatur und Maus, Gamepads über die Gamepad-API des Browsers und Touch für Mobilgeräte. Verhindere, dass die Seite scrollt, wenn der Spieler Pfeiltasten nutzt oder auf dem Canvas wischt. Behandle den Fokusverlust, wenn der Spieler neben das Spiel klickt. Mach das Canvas für unterschiedliche Fenstergrößen responsiv, statt eine feste Auflösung anzunehmen, und teste sowohl in einem kleinen Laptop-Fenster als auch auf einem vollen Desktop-Bildschirm.

## Wo du es hosten kannst

Ein Web-Build aus Summer ist eine normale statische .zip mit index.html im Stammverzeichnis, und Summer Games ist der Ort, um ihn zu veröffentlichen. itch.io hostet HTML5-Builds und übernimmt die Einbettung, innerhalb der Grenzen von 500 MB insgesamt, 200 MB pro Datei und 1.000 Dateien. Newgrounds und Portale für Webspiele nehmen weiterhin Browser-Titel und zahlen nach Traffic oder über eine Umsatzbeteiligung. Selbst hosten funktioniert mit jedem statischen Host. Ein Single-Threaded-Build ab Godot 4.3 braucht keine speziellen Header, während ein Build mit Threads Header für Cross-Origin-Isolation braucht. Eine Browser-Demo speist auch eine Steam-Seite, und viele Entwickler veröffentlichen eine kostenlose Web-Demo neben einem kostenpflichtigen Desktop-Release.

## FAQ

### Kann ich C# für einen Browser-Build nutzen?

Nicht mit C#. Godot 4 kann C#-Projekte nicht ins Web exportieren, und das gilt auch in Summer. Ein GDScript-Projekt exportiert in Summer einen Web-Build, und du veröffentlichst ihn auf Summer Games. C# ist im Desktop-Editor von Summer für Desktop-Builds verfügbar.

### Warum lädt mein Web-Build so langsam?

Fast immer wegen der Downloadgröße und unkomprimierter Assets. Verkleinere zuerst Texturen und Audio, entferne ungenutzte Inhalte und teile dann das Laden auf, damit eine spielbare Szene erscheint, bevor der Rest ankommt.

### Funktionieren Web-Builds auf Handys?

Ja, mit Designarbeit. Mobile Browser haben weniger Speicher, keine Tastatur und nur Touch-Eingabe, plane also ein kleineres Asset-Budget und Touch-Steuerung ein, statt das Desktop-Layout auszuliefern.

### Können Spieler in einem Browserspiel den Fortschritt speichern?

Ja, über den Browser-Speicher, aber er kann vom Spieler oder vom Browser gelöscht werden. Ergänze bei langen Spielen einen Export-Code, einen Datei-Download oder einen an ein Konto gebundenen Spielstand.

### Kann dasselbe Projekt auch auf Steam erscheinen?

Ja. Summer exportiert Desktop-Builds für Windows und macOS für Steam, und ein GDScript-Projekt exportiert außerdem einen Web-Build. Eine kostenlose Browser-Demo auf Summer Games kann also neben dem Steam-Release stehen.

[Neuaufbau starten](https://www.summerengine.com/de/download)

---

## Machine-readable resources

- Site index for agents: https://www.summerengine.com/llms.txt
- Full inlined content: https://www.summerengine.com/llms-full.txt
- Porting catalog: https://www.summerengine.com/llms-porting.txt
- Structured catalog: https://www.summerengine.com/agent-catalog.json
- Sitemap: https://www.summerengine.com/sitemap.xml
- Developer resources: https://www.summerengine.com/docs
- Summer API (assets from any agent or code; public per-call model prices): https://docs.summerengine.com/api