Veröffentliche einen Unity-Web-Build über einen direkten HTTPS-Link für Spieler und Tester. Lade den vollständigen Build-Ordner einschließlich Loader und Daten hoch und aktualisiere weiterhin dieselbe Adresse. Hier spielen die Komprimierungseinstellungen von Unity eine Rolle: Bereite den Build für Lobsite vor, bevor du ihn hochladen.
So funktioniert es
- Build für Web. Wähle die Webplattform von Unity (in älteren Versionen WebGL genannt). Aktiviere in Player Settings → Publishing Settings Decompression Fallback, wenn du Gzip- oder Brotli-Komprimierung verwendest. Erstelle den Build in
build/web. - Prüfe die Dateien und stelle sie bereit. Die meisten Unity-Builds überschreiten die Grenzwerte für anonyme und Free-Dateien. Melde sich daher bei Bedarf mit Standard an. Führe
npx lobsite ./build/webaus oder lade den vollständigen Build über das Dashboard hoch. - Teilen und aktualisiere das Spiel. Sende den Spielern die veröffentlichte URL. Erstelle erneut und stelle es für Updates auf derselben Site bereit oder verwende
npx lobsite --previewfür einen separaten Spieltest.
Komprimierungseinstellungen, die auf Lobsite funktionieren
Lobsite stellt die Dateien .br und .gz wie gespeichert bereit, ohne automatisch einen Content-Encoding-Header hinzuzufügen. Ein komprimierter Unity-Build, der eine native Browser-Dekomprimierung erwartet, wird unter diesen Standardeinstellungen nicht korrekt geladen.
Aktiviere Decompression Fallback, damit Unity einen JavaScript-Dekomprimierer in seinen Build einbezieht. Alternativ kannst du für die Komprimierung Disabled wählen und größere Dateien und Downloads akzeptieren. Prüfe Unitys Bereitstellungsdokumentation auf Deine Editorversion.
Halte index.html, das Verzeichnis Build/, TemplateData/ und alle anderen generierten Ordner zusammen. Das Hochladen nur der Datei .wasm oder .data führt nicht zu einem spielbaren Spiel.
Prüfe Deine größte Unity-Build-Datei
Free und anonymes Hosting ermöglichen 5 MB pro Datei, 50 MB insgesamt und 100 Dateien. Laufzeitdateien und Datendateien der Unity-Engine überschreiten häufig diesen ersten Grenzwert. Standard ermöglicht 100 MB pro Datei, 2 GB insgesamt und 10.000 Dateien. Ein Build kann insgesamt weniger als 2 GB groß sein und trotzdem fehlschlagen, weil eine Datendatei größer als 100 MB ist.
Prüfe den fertigen Build vor dem Hochladen. Wenn eine Datei den Grenzwert von Standard überschreitet, reduziere oder strukturiere den Build vor der Bereitstellung neu. Der oben genannte Datei-Upload-Bereich ist auf 25 MB pro Upload begrenzt; Verwende für größere Builds die CLI oder das Dashboard nach der Anmeldung. Den vollständigen Vergleich findest du im Grenzen für HTML5-Spiele.
Threads und private Spieltests
Wenn du Native C/C++ Multithreading aktivieren, konfiguriere die ursprungsübergreifende Isolierung. Platziere dies in einem lobsite.toml neben Deinem Projekt und stelle es von dort aus mit npx lobsite bereit:
dir = "build/web"
[[headers]]
for = "/*"
[headers.values]
Cross-Origin-Opener-Policy = "same-origin"
Cross-Origin-Embedder-Policy = "require-corp"
Der Datei-Upload-Bereich lautet nicht lobsite.toml. Prüfe, ob alle Ressourcen von Drittanbietern isoliert arbeiten. Für vertrauliche Spieltests bietet Standard ein Passwort für jede Adresse der Website, einschließlich Vorschau-Builds. Multiplayer- und andere Backend-Dienste laufen weiterhin getrennt von Lobsite.
Vorschau ansehen, bevor es live geht. Mit einem Klick zurückrollen, samt Weiterleitungen.
Dateien werden nach ihrem Hash gespeichert. Ein erneutes Deploy einer unveränderten Website lädt 0 Bytes hoch.
Mit Standard fragt jede Adresse der Website nach einem Passwort. Prüfer geben es einmal pro Browser ein.
Auch für kostenlose Konten: Füge einen DNS-Eintrag hinzu, und die Website zieht auf deine Domain um. Jede Website hat HTTPS, in jedem Tarif.
Weiterleitungen, Header und Formulare stehen in lobsite.toml und reisen mit jedem Deploy mit.
Jedes Limit ist veröffentlicht, und jeder Fehler sagt dir, was als Nächstes zu tun ist.
Unity Web-Sharing-Methoden
| Methode | Was es bietet | Was zu überprüfen ist |
|---|---|---|
| Lobsite veröffentlichte URL | Eine eigenständige spielbare Veröffentlichung | Komprimierungseinstellungen und Plangrenzen |
| Lobsite Vorschau-URL | Ein separater Testaufbau | Die gleichen Einstellungen wie veröffentlicht; Die Vorschau ersetzt nicht die veröffentlichte Version |
| Unitys lokaler Build and Run | Testen auf Deiner Entwicklungsmaschine | Öffentliches Hosting kann unterschiedliche Header und Pfade haben |
Informationen zum entsprechenden WebAssembly-Workflow in einer anderen Engine findest du unter Godot-Hosting. Der Leitfaden für HTML5-Spiele deckt Browser-Audio, Einbettung und Caching ab.
Häufige Fragen
Warum kann mein komprimierter Unity WebGL-Build nicht geladen werden?
Prüfe, ob der Loader einen Content-Encoding-Header erwartet. Erstelle mit der standardmäßigen Dateibereitstellung von Lobsite eine Neuerstellung mit aktiviertem Decompression Fallback oder deaktiviere die Komprimierung. Lade den kompletten Neubau zusammen hoch.
Passt jeder Unity WebGL-Build zu Standard?
Nein. Jede Datei darf höchstens 100 MB groß sein und die gesamte Website darf höchstens 2 GB groß sein, mit nicht mehr als 10.000 Dateien. Prüfe die tatsächlichen Engine-Laufzeitdateien, Daten und Asset-Dateien.
Kann ich Unity-Quelldateien anstelle eines Web-Builds veröffentlichen?
Nein. Lobsite stellt einen fertigen Web-Build bereit. Es führt kein Unity aus, kompiliert weder C# noch verwandelt es eine ausführbare Desktop-Datei in ein Browserspiel.
Funktioniert Unity-Multithreading mit einem Browser-Datei-Upload?
Der Standard-Upload-Upload konfiguriert die Isolationsheader nicht. Verwende die CLI und die Header-Konfiguration oben für Builds, die Native C/C++ Multithreading erfordern.