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 willst, das im Browser läuft, hast du vier etablierte und einige neuere Optionen. Sie werden gern unter dem Begriff „Web-Spiel-Engines“ zusammengefasst, sind aber tatsächlich sehr unterschiedliche 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 3D-Web-Engine entwickeln und all diese Optionen geprüft haben, bevor sie ihre eigene bauten.
Wir gehen jede Option durch, erklären, was sie tatsächlich ist, für wen sie gedacht ist und wo ihre Schwächen liegen. Am Ende folgt eine kurze Entscheidungshilfe. Wenn wir Versionsnummern nennen, entsprechen sie dem Stand von Juli 2026.
Du suchst den vollständigen Überblick? Dieser Beitrag konzentriert sich auf die vier etablierten 3D-Optionen. Einen Vergleich mit Rangliste aller 11 Web-Engines – einschließlich 2D-Optionen wie Phaser, Defold und Construct – findest du in unserem Leitfaden zu den besten Web-Spiel-Engines 2026.
Der schnelle Vergleich
| 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) | Ausschließlich 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 | Browser-Spiele mit Studio-Workflow | Individuelles 3D, volle Kontrolle | Spiele mit Komplettausstattung | Portierung vorhandener Unity-Spiele | KI-gestützte In-World-Spielerstellung |
Im restlichen Beitrag erklären wir die Tabelle.
PlayCanvas
PlayCanvas kommt einem Unity-artigen Workflow im Web am nächsten. Die Engine ist unter der MIT-Lizenz quelloffen und liegt mit Stand Juli 2026 in Version v2.20.6 vor. Sie verwendet 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 sie produktiv ein – Snap ist ein öffentlich bekanntes Beispiel.
Zwei verbreitete Missverständnisse über PlayCanvas sollten richtiggestellt werden. Erstens: Die Engine steht zwar unter der MIT-Lizenz, der gehostete visuelle Editor, den die meisten Teams tatsächlich nutzen, ist jedoch ein kommerzielles und nicht quelloffenes Produkt. Du kannst die Engine ohne ihn frei verwenden, doch der Workflow aus Editor und Cloud ist der kostenpflichtige Teil. Zweitens ist PlayCanvas in erster Linie auf WebGL2 ausgelegt. Es gibt einen WebGPU-Pfad, dieser befindet sich jedoch noch in der Entwicklung und ist nicht der standardmäßige Renderer. Du solltest PlayCanvas heute also nicht in der Erwartung wählen, WebGPU-Compute-Shader produktiv einsetzen zu können.
Ein Bereich, in dem PlayCanvas tatsächlich führend ist, ist 3D Gaussian Splatting. Der vom Team als Open Source veröffentlichte SuperSplat-Editor samt Viewer gehört zu den besten Werkzeugen überhaupt, um Splat-Szenen für das Web zu erfassen und auszuliefern – 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-artigen Editor und eine verwaltete Asset-Pipeline für den Browser möchtest und ein Spiel entwickelst, wie es typischerweise ein Studio produzieren würde. Sieh dich nach einer Alternative um, wenn du WebGPU Compute bereits heute benötigst oder einen gehosteten kommerziellen Editor vermeiden möchtest.
Three.js
Three.js ist keine Spiel-Engine. Es ist eine Rendering-Bibliothek – und mit großem Abstand die meistgenutzte in diesem Bereich. Sie stellt dir einen Szenengraphen, Kameras, Lichter, Materialien, Geometrie, Loader und einen Renderer zur Verfügung, und dort endet ihr Umfang. Es gibt keinen Editor, keine Physik, kein Entity-System und keine Vorgaben dazu, wie ein Spiel strukturiert werden sollte. Diese Teile entwickelst du selbst oder beziehst sie aus dem Ökosystem.
Dieser Kompromiss ist die ganze Geschichte. Du erhältst maximale Kontrolle und die größte Community im Web-3D-Bereich, musst dafür aber alles oberhalb des Renderers selbst entwickeln oder zusammenstellen. Der WebGPU-Renderer wurde kontinuierlich ausgebaut und ist heute einsetzbar. 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 Basis möchtest und über das technische Know-how verfügst, deine Spielsysteme darauf aufzubauen. Sieh dich nach einer Alternative um, wenn du einen fertigen Editor und mitgelieferte Spielsysteme möchtest.
Babylon.js
Babylon.js ist eine vollständige Engine unter der Apache-2.0-Lizenz, hinter der ein Team bei Microsoft steht. Im Gegensatz zu Three.js liefert 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 bei den Universal-Engines zu den fortschrittlichsten, wobei WebGL2 weiterhin als Pfad für breite Kompatibilität gepflegt wird. Babylon.js 9.0 (März 2026) 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 dein Ansatz lautet: „Ich möchte eine vollständige Engine mit enthaltener 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 nach einer Alternative um, wenn du eine besonders kleine Abhängigkeit benötigst oder gezielt einen gehosteten Workflow im Unity-Stil suchst.
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. Damit ist es die naheliegende Antwort für einen bestimmten Fall: Du hast bereits ein Unity-Spiel und möchtest eine Browser-Version davon erstellen.
Für ein Web-First-Projekt entstehen dadurch erhebliche Nachteile. Runtime und Download sind groß, 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 seine WebGL-Ausgabe zielt auf WebGL2. Unity 6 verfügt über ein experimentelles WebGPU-Backend, dieses ist jedoch standardmäßig deaktiviert und noch nicht produktionsreif.
Wähle Unity WebGL, wenn du ein vorhandenes Unity-Projekt in den Browser bringen möchtest oder dein Team ohnehin vollständig mit Unity arbeitet. Sieh dich nach einer Alternative um, wenn sofortiges Laden auf Mittelklasse-Smartphones zwingend erforderlich ist oder du ein neues, konsequent für das Web entwickeltes Projekt beginnst.
Wo KI-native und In-World-Erstellung ins Bild passen
Allen oben genannten Lösungen liegt dieselbe Annahme zugrunde: Ein Entwickler erstellt das Spiel am Schreibtisch in einem Editor und veröffentlicht anschließend eine Runtime. Für die meisten Projekte trifft diese Annahme zu. Wenn das auch dein Projekt beschreibt, wähle eine der vier oben genannten Optionen.
Es lohnt sich jedoch zu wissen, dass dies nicht mehr die einzige Möglichkeit ist, denn eine andere Kategorie entsteht gerade. Wir entwickeln Cinevva, eine ausschließlich auf WebGPU basierende Weltenplattform, auf der Spiele direkt innerhalb der Welt erstellt werden. Statt 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. Erstellung und Spielen finden in derselben Sitzung statt. Unter der Haube erforderte dies eine reine WebGPU-Architektur mit Compute-Shader-Terrain, einen eigenen Character-Solver anstelle einer allgemeinen Physik-Engine sowie ein selbst entwickeltes Animations- und Retargeting-System. Darüber berichten wir in 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 die passenden Werkzeuge. 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-Spiel-Engine sollte ich verwenden?“ zunehmend eine fünfte Antwort hat, die überhaupt keine Engine ist.
Die vollständige Funktionsmatrix
Die Kurztabelle oben enthält die wichtigsten Aussagen. Hier folgt die ausführliche Version, nach Subsystemen gruppiert. Vorab einige Hinweise dazu, wie sie zu lesen ist. „Selbst mitbringen“ bedeutet, dass die Engine diese Funktion nicht selbst enthält, sie aber über das Ökosystem oder eigenen Code ergänzt werden kann. Das ist besonders bei Three.js relevant, da es bewusst als Rendering-Bibliothek konzipiert ist. „Selbst mitbringen“ ist dort Ausdruck der Philosophie und keine Lü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 ausgelegt zu sein. Die Zellen der Wettbewerber zeigen die standardmäßig verfügbare Funktionalität und gut dokumentiertes Verhalten mit Stand Mitte 2026. Die Cinevva-Zellen beziehen sich auf Funktionen, die in unserem veröffentlichten Build laufen; „geplant“ kennzeichnet Funktionen, die konzipiert, aber noch nicht umgesetzt sind.
Rendering
| Funktion | Cinevva | PlayCanvas | Three.js | Babylon.js | Unity WebGL |
|---|---|---|---|---|---|
| Primärer Renderer | Ausschließlich WebGPU | WebGL2 (WebGPU-Beta) | WebGL2 (wachsende WebGPU-Unterstützung) | WebGL2 (fortgeschrittene WebGPU-Unterstützung) | WebGL2 (Export) |
| Compute-Shader im Produktivbetrieb | Ja (Kernabhängigkeit) | Beta | Über WebGPU | Ja (WebGPU) | Nur Export, eingeschränkt |
| Shader-Entwicklung | 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-Bearbeitung zur Laufzeit | Ja (GPU) | Selbst mitbringen | Selbst mitbringen | Selbst mitbringen | Nein (nur zur Bearbeitungszeit) |
| Höhlen und Überhänge (echte 3D-Topologie) | Ja (Marching Cubes) | Selbst mitbringen | Selbst mitbringen | Selbst mitbringen | Selbst mitbringen |
| GPU-instanzierte Vegetation und Gräser | 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 (bewusst) | Ja | Selbst mitbringen | Ja | Ja |
| Charaktersteuerung | Ja (Multi-Mode-FSM) | Vorlagen / Ammo | Selbst mitbringen | Ja | Integriert |
| Terrain-integrierte 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 Web-nativ) |
| 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, im 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, Bild, 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 Kernaussage. Die Universal-Engines verteilen ihre Stärken horizontal: Jede erledigt die meisten Aufgaben kompetent und überlässt dir die Welt, das Backend und den Erstellungsablauf. Cinevva konzentriert sich vertikal: Es deckt weniger Bereiche ab, kontrolliert dafür aber den gesamten Weg vom Renderer bis zu einer gemeinsamen Welt, die du von innen heraus erschaffst. Keine dieser Ausrichtungen ist grundsätzlich besser. Sie beantworten unterschiedliche Fragen.
So triffst du die richtige Wahl
Wähle das Werkzeug passend zur jeweiligen Situation statt anhand einer Funktionscheckliste. Wenn du bereits ein Unity-Spiel hast, exportiere es mit Unity WebGL und nimm die Dateigröße in Kauf. Wenn ihr als Studio einen editorbasierten Workflow für Browsergames sucht, verwendet PlayCanvas. Wenn du eine vollständig kostenlose Engine mit integrierter Physik möchtest, verwende Babylon.js. Wenn du vollständige Kontrolle willst und dein Team auf einem reinen Renderer aufbauen kann, verwende Three.js. Und wenn dein Ziel nicht darin besteht, ein einzelnes Spiel zu entwickeln, sondern Menschen zu ermöglichen, durch Beschreibungen in einer gemeinsamen Welt Inhalte zu erschaffen und zu spielen, dann ist das genau die Kategorie, in der wir arbeiten – und du kannst Cinevva ausprobieren.
Wofür du dich auch entscheidest: Teste es vorab mit realistischen Prototypen. Jede dieser Lösungen kann ein echtes Spiel tragen, und ein Wechsel auf halber Strecke kostet dich die Monate, in denen du dein Spiel nicht veröffentlichen konntest.