Web-Spiel-Engines 2026: PlayCanvas vs. Three.js vs. Babylon.js vs. Unity WebGL
Von Oleg Sidorkin, CTO und Mitgründer von Cinevva
Wenn du 2026 ein 3D-Spiel veröffentlichen möchtest, das in einem Browser läuft, hast du vier etablierte und einige neuere Optionen. Sie werden gern gemeinsam als „Web-Game-Engines“ bezeichnet, doch tatsächlich handelt es sich um grundverschiedene Werkzeuge, die unterschiedliche Probleme lösen. Die falsche Wahl kann dich Monate kosten. Dies ist ein aktueller, faktengeprüfter Vergleich von Menschen, die beruflich eine Web-3D-Engine entwickeln und all diese Optionen evaluiert haben, bevor sie ihre eigene Engine bauten.
Wir sehen uns jede Option an und erklären, was sie tatsächlich ist, für wen sie sich eignet und wo ihre Schwächen liegen. Am Ende folgt eine kurze Entscheidungshilfe. Die genannten Versionsnummern entsprechen dem Stand von September 2026 (PlayCanvas Engine 2.22, Three.js r185, Babylon.js 9.25, Unity 6.6).
Du möchtest den vollständigen Marktüberblick? Dieser Beitrag konzentriert sich auf die vier etablierten 3D-Optionen. Einen Vergleich mit Rangliste aller elf Web-Engines – einschließlich 2D-Optionen wie Phaser, Defold und Construct – findest du in unserem Leitfaden zu den besten Web-Game-Engines 2026.
Der Schnellvergleich
| PlayCanvas | Three.js | Babylon.js | Unity WebGL | Cinevva | |
|---|---|---|---|---|---|
| Was es ist | Vollständige Engine + gehosteter Editor | Rendering-Bibliothek | Vollständige Engine + Editor | Desktop-Engine mit Web-Export | KI-native Weltenplattform |
| Architektur | Entity-Component-System (ECS) | Szenengraph | Szenengraph + Komponenten | GameObject/Komponente | Szenengraph + KI-Builder |
| Skripting | TypeScript / JavaScript | JavaScript (den Rest entwickelst du selbst) | TypeScript / JavaScript | C# (zu Wasm kompiliert) | Natürliche Sprache + Code |
| Renderer | WebGL2, WebGPU in Entwicklung | WebGL2, wachsende WebGPU-Unterstützung | WebGL2, fortgeschrittene WebGPU-Unterstützung | WebGL2 (Export), WebGPU seit 6.6 unterstützt (Opt-in) | Nur WebGPU |
| Editor | Gehostet, kommerziell | Keiner | Webbasiert, kostenlos | Desktop, kommerziell | In-World, immersiv |
| Physik | Ammo / Integrationen | Selbst mitbringen | Havok integriert | Integriert (PhysX) | Eigener Character-Solver |
| Lizenz | Engine MIT, Editor proprietär | MIT | Apache 2.0 | Proprietär | Proprietär |
| Am besten geeignet für | Browsergames nach Studio-Workflow | Individuelle 3D-Projekte, volle Kontrolle | Spiele mit Komplettausstattung | Portierung bestehender Unity-Spiele | KI-gestützte In-World-Spielerstellung |
Im weiteren Verlauf dieses Beitrags erklären wir die Tabelle.
PlayCanvas
PlayCanvas kommt einem Unity-ähnlichen Workflow im Web am nächsten. Die Engine ist unter der MIT-Lizenz quelloffen und steht mit Stand September 2026 bei v2.22.0. Version 2.21 führte eine Abstraktion für Physik-Backends und KTX2-Cubemaps ein, Version 2.22 Dual-Source-Blending und besseren volumetrischen Nebel. PlayCanvas nutzt ein Entity-Component-System, die Spiellogik wird in TypeScript oder JavaScript geschrieben, und Assets durchlaufen eine serverseitige Pipeline, die GLB-Dateien erzeugt. Echte kommerzielle Spiele laufen damit, und große Unternehmen setzen es produktiv ein – Snap ist ein öffentlich bekanntes Beispiel.
Zwei verbreitete Missverständnisse über PlayCanvas sollten korrigiert werden. Erstens: Die Engine steht zwar unter der MIT-Lizenz, der gehostete visuelle Editor, den die meisten Teams tatsächlich verwenden, ist jedoch ein kommerzielles Produkt und nicht quelloffen. Du kannst die Engine ohne Einschränkungen auch ohne ihn verwenden, doch der Workflow aus Editor und Cloud ist der kostenpflichtige Teil. Zweitens ist PlayCanvas primär auf WebGL2 ausgerichtet. Es gibt einen WebGPU-Pfad, dieser befindet sich jedoch noch in Entwicklung und ist nicht der Standard-Renderer. Du solltest PlayCanvas heute also nicht in der Erwartung wählen, produktionsreife WebGPU-Compute-Shader zu erhalten.
Ein Bereich, in dem PlayCanvas tatsächlich führend ist, ist 3D Gaussian Splatting. Der quelloffene SuperSplat-Editor samt Viewer gehört zu den besten Werkzeugen überhaupt, um Splat-Szenen zu erfassen und im Web bereitzustellen – einschließlich WebGPU-basiertem Streaming für große Aufnahmen. Wenn fotorealistisch gescannte Umgebungen dein Schwerpunkt sind, ist das ein überzeugender Grund, hier anzufangen.
Wähle PlayCanvas, wenn du einen Unity-ähnlichen Editor und eine verwaltete Asset-Pipeline für den Browser möchtest und ein Spiel entwickelst, wie es typischerweise von einem Studio produziert wird. Sieh dich anderweitig um, wenn du bereits heute WebGPU Compute benötigst oder einen gehosteten kommerziellen Editor vermeiden möchtest.
Three.js
Three.js ist keine Game-Engine. Es ist eine Rendering-Bibliothek – und mit großem Abstand die am weitesten verbreitete in diesem Bereich. Sie stellt dir einen Szenengraphen, Kameras, Lichtquellen, Materialien, Geometrie, Loader und einen Renderer bereit – und endet genau dort. Es gibt keinen Editor, keine Physik, kein Entity-System und keine Vorgaben dafür, wie ein Spiel strukturiert werden sollte. All das fügst du selbst hinzu oder beziehst es aus dem Ökosystem.
Dieser Kompromiss ist der entscheidende Punkt. Du erhältst maximale Kontrolle und die größte Web-3D-Community, musst dafür aber alles oberhalb des Renderers selbst entwickeln oder zusammenstellen. Der WebGPU-Renderer wurde kontinuierlich ausgebaut und ist heute nutzbar – r185 vom Juli 2026 ist die aktuelle Version. Wie bei den anderen Lösungen bleibt der WebGL2-Pfad jedoch der ausgereifte Standard. Three.js steht unter der MIT-Lizenz.
Wähle Three.js, wenn du volle Kontrolle und eine minimale Grundlage möchtest und über die nötige technische Kompetenz verfügst, um deine Spielsysteme darauf aufzubauen. Sieh dich anderweitig um, wenn du einen fertigen Editor und direkt nutzbare Spielsysteme erwartest.
Babylon.js
Babylon.js ist eine vollständige Engine unter der Apache-2.0-Lizenz und wird von einem Team bei Microsoft unterstützt. Anders als Three.js bringt sie die Komponenten mit, die du sonst selbst zusammenstellen müsstest: ein Komponentenmodell, die integrierte Havok-Physik-Engine, einen kostenlosen webbasierten Editor und eine Asset-Pipeline. Die WebGPU-Entwicklung ist schnell vorangeschritten und gehört zu den fortschrittlicheren unter den Allzweck-Engines. Für eine breite Kompatibilität wird jedoch weiterhin WebGL2 unterstützt. Babylon.js 9.0 vom März 2026 – mit Stand September 2026 inzwischen bei 9.25 – baute diesen Vorsprung mit Clustered Lighting auf beiden Backends, volumetrischer Beleuchtung auf Basis von WebGPU-Compute-Shadern und Schattenunterstützung für 3D Gaussian Splats weiter aus.
Wenn deine Vorstellung lautet: „Ich möchte eine vollständige Engine mit integrierter Physik und arbeite gern innerhalb ihrer Konventionen“, ist Babylon eine starke Standardwahl und wohl die funktionsreichste kostenlose Option in diesem Bereich.
Wähle Babylon.js, wenn du eine Komplettausstattung, integrierte Physik und einen kostenlosen Editor möchtest. Sieh dich anderweitig um, wenn du den Umfang deiner Abhängigkeiten möglichst klein halten oder ausdrücklich einen gehosteten Workflow im Unity-Stil nutzen möchtest.
Unity WebGL
Unity WebGL ist keine Web-Engine, sondern ein Exportziel. Du entwickelst im Unity-Desktop-Editor mit C# und kompilierst das Projekt zu einem WebGL-Bundle, das über WebAssembly im Browser läuft. Dadurch ist es die naheliegende Antwort für einen ganz bestimmten Fall: Du hast bereits ein Unity-Spiel und möchtest davon eine Browser-Version erstellen.
Für ein Web-First-Projekt entstehen dadurch echte Nachteile. Runtime und Download sind beträchtlich, der Start dauert länger als bei einer nativen Web-Engine, und die Leistung in mobilen Browsern ist ein bekanntes Problem. Unity ist proprietär, und die standardmäßige Web-Ausgabe zielt auf WebGL2. Das WebGPU-Backend, das in Unity 6 als Experiment begann, hat mit Unity 6.6 vom August 2026 den experimentellen Status verlassen: Es ist nun eine vollständig unterstützte Grafik-API für Web-Builds, bleibt standardmäßig jedoch deaktiviert. Über die Einstellung „Graphics Device Filtering“ kann geräteabhängig auf WebGL2 zurückgefallen werden. Unity 6.6 erhöht außerdem das Wasm-Speicherlimit auf 16 GB. Auf dem Papier schließt das die Lücke bei Compute-Shadern, ändert jedoch weder die Downloadgröße noch die Startzeit auf Mobilgeräten.
Wähle Unity WebGL, wenn du ein bestehendes Unity-Projekt in den Browser bringen möchtest oder dein Team ohnehin vollständig mit Unity arbeitet. Sieh dich anderweitig um, wenn sofortiges Laden auf Mittelklasse-Smartphones zwingend erforderlich ist oder du ein neues, konsequent auf das Web ausgerichtetes Projekt beginnst.
Wo KI-native und In-World-Erstellung einzuordnen sind
Alle bisherigen Optionen basieren auf derselben Annahme: Ein Entwickler erstellt das Spiel am Schreibtisch in einem Editor und veröffentlicht anschließend eine Runtime. Diese Annahme trifft auf die meisten Projekte zu. Wenn das auch dein Projekt beschreibt, wähle eine der vier obigen Optionen.
Du solltest jedoch wissen, dass diese Annahme nicht mehr die einzige Möglichkeit darstellt, denn eine neue Kategorie entsteht. Wir entwickeln Cinevva, eine reine WebGPU-Weltenplattform, auf der Spiele direkt innerhalb der Welt erstellt werden. Anstatt einen Editor zu öffnen, stehst du als Avatar im Raum und beschreibst, was du möchtest. Ein KI-Builder verwandelt deine Beschreibung in Terrain, Objekte und Verhalten, während du dich dort befindest. Erstellen und Spielen finden in derselben Sitzung statt. Technisch erforderte das eine reine WebGPU-Lösung mit Compute-Shader-Terrain, einen eigenen Character-Solver anstelle einer allgemeinen Physik-Engine sowie ein Animations- und Retargeting-System. Mehr dazu erfährst du in unserem Beitrag darüber, warum wir unsere eigene WebGPU-Engine entwickelt haben.
Das ist kein Ersatz für PlayCanvas oder Babylon. Wenn du als Entwickler ein konkretes Spiel entwickelst, sind diese Werkzeuge die richtige Wahl. Cinevva verfolgt ein anderes Ziel: Menschen, die keine Engine-Entwickler sind, sollen spielbare Räume durch Beschreibungen erstellen und teilen können. Wir erwähnen es hier, weil die Frage „Welche Web-Game-Engine sollte ich verwenden?“ zunehmend eine fünfte Antwort hat, bei der es sich gar nicht um eine Engine handelt.
Die vollständige Funktionsmatrix
Die Kurztabelle oben liefert den Überblick. Hier folgt die detaillierte, nach Subsystemen gegliederte Fassung. Vorab einige ehrliche Hinweise zur Interpretation. „Selbst mitbringen“ bedeutet, dass die Engine die Funktion nicht selbst bereitstellt, sie aber durch das Ökosystem oder eigenen Code ergänzt werden kann. Das ist vor allem bei Three.js wichtig: Da es bewusst als Rendering-Bibliothek konzipiert ist, gehört „Selbst mitbringen“ dort zur Philosophie und ist keine Funktionslücke. „Nur Export“ bedeutet bei Unity, dass die Funktion im Desktop-Editor vorhanden ist und in den WebGL-Build übernommen wird, statt nativ für das Web entwickelt worden zu sein. Die Angaben zu Wettbewerbern spiegeln die sofort verfügbare Funktionalität und das gut dokumentierte Verhalten mit Stand September 2026 wider. Die Angaben zu Cinevva beziehen sich auf Funktionen, die in unserem veröffentlichten Build laufen; „geplant“ kennzeichnet Funktionen, die konzipiert, aber noch nicht umgesetzt wurden.
Rendering
| Funktion | Cinevva | PlayCanvas | Three.js | Babylon.js | Unity WebGL |
|---|---|---|---|---|---|
| Primärer Renderer | Nur WebGPU | WebGL2 (WebGPU-Beta) | WebGL2 (wachsende WebGPU-Unterstützung) | WebGL2 (fortgeschrittene WebGPU-Unterstützung) | WebGL2 (WebGPU seit 6.6 unterstützt, Opt-in) |
| Compute-Shader im Produktivbetrieb | Ja (zentrale Abhängigkeit) | Beta | Über WebGPU | Ja (WebGPU) | Ja (WebGPU, Unity 6.6+) |
| Shader-Erstellung | TSL-Nodes + Compute | Shader-Chunks / GLSL | GLSL + Node (TSL) | Node-Material / GLSL / WGSL | ShaderLab / HLSL |
| Clustered / Forward+ Lighting | Ja (Froxel) | Ja | Selbst mitbringen | Ja | Ja |
| Volumetrische Wolken und Wetter | Ja | Selbst mitbringen | Selbst mitbringen | Teilweise | Selbst mitbringen |
| Werkzeuge für 3D Gaussian Splatting | Geplant | Ja (SuperSplat, führend) | Community | Ja | Plugins |
Welt und Terrain
| Funktion | Cinevva | PlayCanvas | Three.js | Babylon.js | Unity WebGL |
|---|---|---|---|---|---|
| Integriertes Streaming großer Welten | Ja (64-m-Chunks) | Selbst mitbringen | Selbst mitbringen | Selbst mitbringen | Nur Export |
| Terrain-System | Hybride Heightmap + Marching Cubes/SDF | Selbst mitbringen | Selbst mitbringen | Erweiterung | Integriert (Desktop) |
| Terrain-Modellierung zur Laufzeit | Ja (GPU) | Selbst mitbringen | Selbst mitbringen | Selbst mitbringen | Nein (nur Bearbeitungszeit) |
| Höhlen und Überhänge (echte 3D-Topologie) | Ja (Marching Cubes) | Selbst mitbringen | Selbst mitbringen | Selbst mitbringen | Selbst mitbringen |
| GPU-instanzierte Vegetation und Gras | Ja | Ja | Selbst mitbringen | Ja | Ja |
Physik und Charaktere
| Funktion | Cinevva | PlayCanvas | Three.js | Babylon.js | Unity WebGL |
|---|---|---|---|---|---|
| Physik-Engine | Eigener kinematischer Solver | Ammo-Integration | Selbst mitbringen (Rapier/Cannon/Ammo) | Havok integriert | PhysX integriert |
| Starrkörperdynamik | Nein (bewusste Entscheidung) | Ja | Selbst mitbringen | Ja | Ja |
| Charaktersteuerung | Ja (Multimode-FSM) | Vorlagen / Ammo | Selbst mitbringen | Ja | Integriert |
| Terrainintegrierte Kollision (SDF) | Ja | Nein | Selbst mitbringen | Nein | Nein |
Animation
| Funktion | Cinevva | PlayCanvas | Three.js | Babylon.js | Unity WebGL |
|---|---|---|---|---|---|
| Skelettanimation | Ja | Ja | Ja | Ja | Ja |
| Blending / Zustandsautomat | Ja (Resolver-FSM) | Ja (Animations-Zustandsgraph) | Mixer (Blending selbst mitbringen) | Ja | Ja (Mecanim) |
| Skelett-Retargeting | Ja (Pipeline) | Eingeschränkt | Community | Teilweise | Ja (Humanoid) |
| Inverse Kinematik | Geplant | Eingeschränkt | Community | Ja | Ja |
Multiplayer und Backend
| Funktion | Cinevva | PlayCanvas | Three.js | Babylon.js | Unity WebGL |
|---|---|---|---|---|---|
| Integrierter Multiplayer | Ja (Edge-autoritativ) | Selbst mitbringen (Photon/Colyseus) | Selbst mitbringen | Selbst mitbringen | Selbst mitbringen (Netcode, nicht webnativ) |
| Persistente gemeinsame Welt | Ja (Durable Objects pro Chunk) | Selbst mitbringen | Selbst mitbringen | Selbst mitbringen | Selbst mitbringen |
| Räumlicher Sprachchat | Ja (WebRTC + HRTF) | Selbst mitbringen | Selbst mitbringen | Selbst mitbringen | Selbst mitbringen |
Erstellung und Authoring
| Funktion | Cinevva | PlayCanvas | Three.js | Babylon.js | Unity WebGL |
|---|---|---|---|---|---|
| Editor | In-World, immersiv | Gehostet, Desktop-Stil (kommerziell) | Keiner (minimal) | Webbasiert (kostenlos) | Desktop (kommerziell) |
| Verkörperte In-World-Erstellung | Ja | Nein | Nein | Nein | Nein |
| Erstellung per natürlicher Sprache / KI | Ja (KI-Builder) | Nein | Nein | Nein | Nein |
| Skripting | Natürliche Sprache + JS | TypeScript / JS | JavaScript | TypeScript / JS | C# |
Assets und Distribution
| Funktion | Cinevva | PlayCanvas | Three.js | Babylon.js | Unity WebGL |
|---|---|---|---|---|---|
| Serverseitige Asset-Pipeline | Ja (GLB + LOD + KTX2 + Draco) | Ja (GLB) | Nur Loader | Importwerkzeuge | Ja |
| Integrierte KI-Asset-Generierung | Ja (3D, Bilder, Audio, Musik) | Nein | Nein | Nein | Nein |
| Anbieterübergreifende Asset-Suche | Ja (elf Anbieter) | Asset-Store | Nein | Nein | Asset-Store |
| Läuft ohne Installation im Browser | Ja | Ja | Ja | Ja | Ja (ressourcenintensiv) |
| Engine-Lizenz | Proprietäre Plattform | Engine MIT, Editor proprietär | MIT | Apache 2.0 | Proprietär |
Das Muster in der Matrix ist die eigentliche Geschichte. Die universell einsetzbaren Engines verteilen ihre Stärken in die Breite: Sie beherrschen jeweils die meisten Dinge solide und überlassen dir die Welt, das Backend und den Erstellungsprozess. Cinevva konzentriert sich dagegen in die Tiefe: Es macht weniger, deckt dafür aber den gesamten Weg vom Renderer bis zu einer gemeinsamen Welt ab, die du von innen heraus erschaffst. Keine der beiden Ausrichtungen ist grundsätzlich besser. Sie beantworten unterschiedliche Fragen.
So triffst du die richtige Wahl
Wähle das Werkzeug passend zur konkreten Situation und nicht anhand einer Funktions-Checkliste.
Wenn du bereits ein Unity-Spiel hast, exportiere es mit Unity WebGL und nimm die Größe in Kauf. Wenn ihr als Studio einen editorbasierten Workflow für Browsergames sucht, verwendet PlayCanvas. Wenn du eine vollständige kostenlose Engine mit integrierter Physik möchtest, verwende Babylon.js. Wenn du volle Kontrolle willst und ein Team hast, das auf einem reinen Renderer aufbauen kann, verwende Three.js. Und wenn dein Ziel nicht darin besteht, ein einzelnes Spiel zu entwickeln, sondern Menschen durch Beschreibungen Dinge in einer gemeinsamen Welt erschaffen und spielen zu lassen, dann ist das die Kategorie, in der wir arbeiten – und du kannst Cinevva ausprobieren.
Wofür du dich auch entscheidest: Teste die Optionen vor der Festlegung anhand echter Prototypen. Jede davon kann ein vollwertiges Spiel tragen, und ein Wechsel auf halber Strecke kostet dich die Monate, die du nicht in die Veröffentlichung investieren konntest.
Häufig gestellte Fragen
PlayCanvas oder Babylon.js: Was sollte ich wählen?
Wähle PlayCanvas, wenn du einen gehosteten Editor im Unity-Stil und eine Asset-Pipeline möchtest und es für dich in Ordnung ist, dass der Editor ein kommerzielles Produkt ist (kostenlos für öffentliche Projekte, kostenpflichtig für private). Wähle Babylon.js, wenn alles kostenlos und offen sein soll (Apache 2.0), du integrierte Havok-Physik möchtest und die fortschrittlichste WebGPU-Darstellung der beiden suchst. Beide Engines stehen unter einer MIT- beziehungsweise Apache-Lizenz und unterstützen WebGL2 mit zusätzlichem WebGPU. Unser Vergleich von Webgame-Engines bewertet sie nach Build-Größe und Ladezeit, während Three.js im Vergleich zu Babylon.js den Unterschied zwischen Bibliothek und Engine behandelt.
PlayCanvas oder Unity für Webgames?
Für ein Web-First-Spiel ist PlayCanvas die bessere Wahl: Seine Runtime ist 1 bis 2 MB groß, während schon ein leeres Unity-Build mehr als 8 MB umfasst. Es startet auf Smartphones schneller und der Editor läuft bereits im Browser. Unity ist im Vorteil, wenn du ein bestehendes Unity-Projekt oder ein C#-Team hast. Zudem hat Unity 6.6 die Lücke bei der Darstellung verkleinert, indem WebGPU zu einem unterstützten Web-Ziel wurde. Vergleiche der beiden kommen meist zum gleichen Ergebnis: PlayCanvas für eine browsernative Bereitstellung, Unity für sein Ökosystem. Unter Unity, Godot oder PlayCanvas für das Web findest du den Vergleich aller drei.
Three.js oder Unity für Browsergames?
Es handelt sich um unterschiedliche Arten von Werkzeugen. Three.js ist eine 150 KB große Rendering-Bibliothek unter MIT-Lizenz. Damit erhältst du die kleinsten Builds und volle Kontrolle, musst die Spielsysteme aber selbst entwickeln oder eine darauf aufbauende Engine wie Cinevva verwenden. Unity ist eine vollständige Engine, die für den Browser exportiert wird. Dadurch stehen Physik, Animation und ein Editor sofort bereit, allerdings auf Kosten eines großen Downloads und eines langsameren Starts auf Mobilgeräten. Beginne mit Three.js, wenn das Spiel primär für das Web gedacht ist und du ein Entwicklerteam hast. Beginne mit Unity, wenn das Spiel bereits als Unity-Projekt existiert. Der vollständige Vergleichsleitfaden enthält die Zahlen.