3D-Open-World-Technologie im Browser für Multiplayer-Kreativwelten

Wir möchten unsere Kreativen in einer gemeinsamen offenen Welt zusammenbringen. Nicht in einer Lobby. Nicht in einer Galerie. Sondern in einem lebendigen 3D-Raum, in dem Menschen auf Entdeckungsreise gehen, bauen und zufällig auf die Werke anderer stoßen können. Etwas, das in einem Browser-Tab lädt und sich wie ein Ort anfühlt, an dem man gerne Zeit verbringt.

Das ist eine schwierige Aufgabe. In die Entwicklung der Welten von Skyrim und The Witcher 3 flossen Hunderte Millionen Dollar, und trotzdem laufen sie auf dedizierter Hardware und belegen Dutzende Gigabyte auf der Festplatte. Unser Ziel ist ein Browser-Tab mit einem gemeinsamen Zustand für Hunderte von Spielern und einer Welt, die Kreative tatsächlich umgestalten können.

Dieser Leitfaden dokumentiert, was wir bei unserer Recherche zu den Technologien herausgefunden haben: was heute möglich ist, was in Zukunft kommt und mit welcher Architektur wir dieses Ziel erreichen könnten.

Was wir von Skyrim und The Witcher lernen können

Bevor man sich für eine Technologie entscheidet, sollte man verstehen, wie die beiden erfolgreichsten offenen Welten tatsächlich funktionieren. Ihre Verfahren lassen sich überraschend gut auf die Einschränkungen des Browsers übertragen.

Skyrims Zellensystem

Skyrims offene Welt streamt ein 5x5-Raster aus Zellen rund um den Spieler. Entfernte Berge sind niedrig aufgelöste Impostoren. Man bemerkt es nie.

Skyrim unterteilt seine Welt in ein Raster aus 57x37 Außenzellen mit jeweils 4096x4096 Spieleinheiten (etwa 59 Meter). Die Engine lädt jederzeit ein 5x5-Raster aus Zellen rund um den Spieler. Während man sich fortbewegt, werden die Zellen am hinteren Rand entladen, während die Zellen am vorderen Rand nachgeladen werden. Innenräume wie Verliese und Gebäude sind separate Welträume, die durch Tür-Trigger geladen werden.

Das lässt sich direkt auf eine Browserwelt übertragen. Man lädt nicht die gesamte Karte, sondern nur die Umgebung des Spielers und tauscht die Chunks während seiner Bewegung aus. Die entscheidende Erkenntnis: Skyrim zeigt nie die vollständigen Details weit entfernter Landschaften. Stattdessen kommt ein Ansatz mit mehreren Auflösungsstufen zum Einsatz.

LOD-Stufen (Level of Detail) in Skyrim:

• Volle Detailstufe innerhalb von 1–2 Zellen, also im unmittelbaren Bereich des Spielers
• Vereinfachte Meshes auf mittlere Entfernung, wobei Objekte kleine Geometriedetails verlieren
• Billboard-Impostoren für Bäume und Felsen jenseits der mittleren Entfernung
• Das Gelände-LOD verwendet vorab berechnete niedrig aufgelöste Meshes für entfernte Landschaften
• Objektspezifisch abgestimmte Ausblenddistanzen: Gras wird zuerst ausgeblendet, Gebäude zuletzt

Skyrims Landschaft basiert auf einem Heightmap-Gelände mit Patches aus 32x32 Vertices pro Zelle. Jeder Patch kann unterschiedliche Texturen enthalten, die mithilfe von Alpha-Maps ineinander überblendet werden. Das lässt sich mit geringem Speicher- und Rendering-Aufwand umsetzen. Die Geländedaten einer einzelnen Zelle werden in Kilobyte statt Megabyte gemessen.

Was wir übernehmen können: Chunk-basiertes Streaming, Heightmap-Gelände, aggressives LOD, die Trennung von Innen- und Außenbereichen sowie das Prinzip, dass entferntes Gelände nicht geometrisch exakt, sondern nur visuell überzeugend sein muss.

Die Streaming-Architektur von The Witcher 3

Die 136 km2 große Welt von The Witcher 3 nutzt inhaltsabhängiges Streaming. Bäume in mehr als 200 Metern Entfernung sind flache Impostoren. Gebäude werden unabhängig vom Gelände gestreamt.

Die Welt von The Witcher 3 ist größer als die von Skyrim – über alle Regionen hinweg umfasst sie etwa 136 km2 – und verwendet ein komplexeres Streaming-System. CD Projekt RED entwickelte eine eigene Engine namens REDengine 3, in der die Welt nicht in ein starres Raster, sondern in Streaming-Sektoren unterteilt ist.

Jeder Sektor enthält eine Hierarchie von Inhaltsebenen:

• Gelände wird als Patches mit 4 LOD-Stufen gestreamt
• Vegetation nutzt GPU-Instancing mit entfernungsabhängigem Culling
• Statische Geometrie wie Gebäude und Felsen wird unabhängig vom Gelände gestreamt
• Gameplay-Objekte wie NPCs, Gegenstände und Trigger werden abhängig vom Queststatus und von der Entfernung geladen

Der Renderer verwendet Deferred Shading mit physikalisch basierten Materialien. Ein besonders relevanter Trick: The Witcher 3 setzt in großem Umfang Impostoren ein. Ein 200 Meter entfernter Baum ist kein 3D-Modell mit Ästen und Blättern, sondern ein flaches texturiertes Quad, das stets zur Kamera zeigt. Die Engine rendert diese Impostoren aus mehreren Blickwinkeln vor und tauscht sie aus, wenn sich die Kamera bewegt. Weil sie weit genug entfernt sind, fällt das nie auf.

Komposition der Welt: Die offene Welt von The Witcher 3 wurde von mehreren Teams gleichzeitig in Ebenen aufgebaut. Das Gelände-Team formte die Landschaft. Das Environment-Art-Team platzierte Bauwerke. Das Quest-Team richtete Trigger und NPC-Pfade ein. Dank dieses ebenenbasierten Kompositionssystems konnte ein großes Team arbeiten, ohne dass sich die Beteiligten gegenseitig in die Quere kamen.

Was wir übernehmen können: Eine ebenenbasierte Weltkomposition, die für eine Kreativplattform unverzichtbar ist, Impostor-Rendering für entfernte Objekte, Deferred Rendering für viele Lichtquellen und die Erkenntnis, dass Streaming inhaltsabhängig sein sollte: Innenräume, die man nicht sehen kann, müssen nicht geladen und NPCs außerhalb der unmittelbaren Umgebung nicht erzeugt werden.

Die Chemie-Engine von Breath of the Wild

BotW läuft auf Hardware der Tablet-Klasse und sieht beeindruckend aus. Cel-Shading-Stil, aquarellartiger Entfernungsnebel und systemische Interaktionen statt geskripteter Inhalte. Der Goldstandard für stilisierte offene Welten.

Nintendos Ansatz für das Open-World-Design kehrte die übliche Formel um. Statt die Welt mit geskripteten Inhalten zu füllen, entwickelte das Team systemische Regeln und ließ die Spieler daraus entstehende Verhaltensweisen entdecken. Feuer breitet sich auf Gras aus. Metall leitet bei Gewittern Elektrizität. Wind trägt Objekte davon. Durch eine konsistente Physik- und Chemieebene interagiert alles mit allem anderen.

Für eine Kreativwelt ist das wichtig, denn es zeigt, dass die Welt selbst interessanter sein kann als jedes einzelne platzierte Objekt. Wenn Kreative Materialeigenschaften und Interaktionsregeln festlegen können, statt nur statische Meshes zu platzieren, entwickelt die Welt emergente Verhaltensweisen. Dadurch lohnt sich die Erkundung selbst in Bereichen, die niemand ausdrücklich gestaltet hat.

Technische Erkenntnisse aus BotW:

• Relativ niedrige Polygonzahl und Auflösung: Im angedockten Modus läuft das Spiel auf der Switch mit 900p. Der stilisierte Cel-Shading-Look kaschiert die geringe Detailtreue. Eine Browserwelt könnte heute eine ähnliche visuelle Qualität erreichen.
• Für die Darstellung in der Ferne kommt ein im Toon-Stil schattierter Nebel zum Einsatz, der in aquarellartige Skyboxen übergeht. Das Rendering ist günstig und sieht in der Praxis wunderschön aus. Eine solche atmosphärische Perspektive ist in einem Fragment-Shader praktisch kostenlos.
• Die Welt ist ungefähr 84 km2 groß, aber dünn besiedelt. Der größte Teil der Karte besteht aus begehbarem Gelände mit verstreuten interessanten Orten. Dichte Inhalte sind Städten und Schreinen vorbehalten. Dieser Ansatz – weitläufig, aber interessant – reduziert den Bedarf an Assets gegenüber dem dicht bevölkerten Novigrad aus The Witcher 3 drastisch.
• Physikobjekte besitzen Material-Tags wie Holz, Metall, Nahrung oder explosiv, die ihre Interaktionen bestimmen. Die Zahl der eigentlichen Regeln ist gering – vielleicht 20 bis 30 Interaktionstypen –, doch ihre Kombinationen wirken nahezu unbegrenzt.

Die Ebenenarchitektur der Welt von GTA V

Los Santos in GTA V wirkt durch übereinanderliegende Umgebungssysteme lebendig: Verkehr, Fußgänger, Tageszeit und Wetter. Entfernte Gebäude sind zusammengesetzte Fotografien, keine 3D-Modelle.

Rockstars Ansatz für Los Santos vermittelt eine andere Lektion. Die Welt von GTA V wirkt durch mehrere übereinanderliegende Umgebungssysteme lebendig, nicht weil jeder NPC eine Quest anbietet.

Die Stadt verfügt über Verkehrssysteme, die Hunderte von Fahrzeugen auf einem Straßennetz simulieren. Fußgänger folgen Routen, reagieren auf den Spieler und interagieren miteinander. Die Tageszeit verändert die Bevölkerungsdichte, die vorhandenen NPC-Typen und die Umgebungsaktivitäten. Das Wetter beeinflusst die Fahrphysik und das Verhalten der NPCs.

Für eine Kreativwelt lautet die Erkenntnis, dass Umgebungsleben den Unterschied zwischen einer Welt ausmacht, die wie ein Museum wirkt, und einer, die sich wie ein echter Ort anfühlt. Selbst einfache Verhaltensweisen – über den Himmel fliegende Vögel, an ein Ufer schlagende Wellen oder NPCs, die zwischen Gebäuden umhergehen – erzeugen die Illusion einer lebendigen Welt.

Technische Erkenntnisse aus GTA V:

• Die Karte ist 75 km2 groß und nutzt aggressives LOD in Verbindung mit einem Streaming-System, das Inhalte abhängig von der Geschwindigkeit lädt: Bei schneller Fahrt wird in größerer Entfernung vorausgeladen als beim Gehen.
• In GTA Online können sich 30 Spieler gleichzeitig in dieser Welt aufhalten. Selbst bei 30 Spielern stellte Rockstar fest, dass eine räumliche Relevanzverwaltung erforderlich ist: Über Spieler in der Nähe erhält man detaillierte Aktualisierungen, über weiter entfernte Spieler dagegen weniger häufige. Dasselbe Prinzip gilt für unser Ziel von 200 Spielern.
• Die Asset-Pipeline von GTA V gehört zu den effizientesten, die je entwickelt wurden. Das gesamte Spiel belegt dank extremer Texturkompression, gemeinsam genutzter Meshes und prozeduraler Details nur etwa 80 GB. Für Gebäudeinnenräume werden in großem Umfang modulare Elemente wiederverwendet.
• Das Spiel nutzt ein ausgeklügeltes Impostor-System, bei dem entfernte Gebäude tatsächlich aus flachen, zusammengesetzten Fotografien bestehen. Den Spielern fällt das nie auf, weil die Übergangsdistanzen auf bestimmte Blickwinkel abgestimmt sind.

Die nahtlose offene Welt von Elden Ring

Die 79 km2 große Karte von Elden Ring verbindet weitläufiges offenes Gelände mit dichten, von Hand gestalteten Verliesen. Dieselben Umgebungs-Assets tauchen überall in unterschiedlichen Anordnungen auf. Wiederholungen fallen nicht auf, wenn Komposition und Beleuchtung variieren.

FromSoftware entwickelte Elden Ring mit derselben Engine wie Dark Souls, skalierte sie jedoch für eine offene Welt. Das Ergebnis ist interessant, weil es zeigt, wie ein im Vergleich zu Rockstar oder CD Projekt relativ kleines Team eine große offene Welt erschaffen kann.

Der Trick liegt in der variierenden Dichte. Die Karte von Elden Ring ist mit etwa 79 km2 riesig, doch große Abschnitte bestehen aus offenem Gelände mit verstreuten Gegnern und interessanten Orten. Die dichten, von Hand gestalteten Inhalte – sogenannte Legacy Dungeons wie Schloss Sturmschleier – sind in die offene Welt eingebettet und nutzen dieselbe Trennung zwischen Innen- und Außenbereichen wie Skyrim.

Technische Erkenntnisse aus Elden Ring:

• Die Welt wird in großen Kacheln gestreamt. Vom Pferd aus kann man sehr weit sehen, doch das entfernte Gelände ist extrem vereinfacht. Aus der Nähe ist die Detailtiefe mit Dark Souls 3 vergleichbar.
• Ladebildschirme erscheinen nur bei Schnellreisen oder beim Betreten bestimmter Verliese. Die offene Welt selbst wird ohne Unterbrechung gestreamt.
• Das Spiel verwendet Umgebungs-Assets in großem Umfang wieder. Dieselben Baummodelle, Felsformationen und Ruinenelemente tauchen auf der ganzen Karte in unterschiedlichen Anordnungen auf. Bei ausreichender Vielfalt in Anordnung und Beleuchtung fallen Wiederholungen nicht auf. Das lässt sich direkt auf eine Kreativwelt übertragen, in der eine Bibliothek modularer Elemente unendliche Vielfalt erzeugen kann.
• Der Multiplayer-Modus ist sitzungsbasiert: Andere Spieler werden in die eigene Welt beschworen. Er ist nicht persistent. Die asynchronen Funktionen wie Nachrichten, Blutflecken und Geister anderer Spieler erzeugen jedoch ein Gefühl gemeinsamer Existenz, ohne den Netzwerkaufwand eines persistenten Servers zu verursachen. Solche atmosphärischen Multiplayer-Funktionen ließen sich kostengünstig in eine Browserwelt integrieren.

No Man's Sky: Alles prozedural generiert

18 Trillionen Planeten, die aus gemeinsamen Seeds generiert werden. Jeder Spieler sieht dasselbe Universum, ohne dass es auf einem Server gespeichert werden muss. Die Daten für den Basenbau sind kompakt: Bauteil-IDs plus Transformationen.

No Man's Sky ist der Extremfall prozeduraler Generierung. 18 Trillionen Planeten werden aus einem gemeinsamen Seed erzeugt, sodass alle Spieler dasselbe Universum sehen, ohne dass irgendein Teil davon auf einem Server gespeichert werden muss.

Die Generierungspipeline arbeitet in mehreren Stufen: Seeds auf Galaxieebene bestimmen die Positionen der Sterne, Stern-Seeds bestimmen Anzahl und Typen der Planeten, und Planeten-Seeds steuern die Geländegenerierung mit mehroktavigem Rauschen, die Zuweisung von Biomen, Flora- und Faunaarten, Farbpaletten und die Verteilung von Ressourcen. Alles wird deterministisch aus dem Seed berechnet. Deshalb sehen zwei Spieler, die dieselben Koordinaten besuchen, denselben Planeten, ohne Planetendaten austauschen zu müssen. Technische Erkenntnisse aus No Man's Sky:

• Die Terrain-Generierung verwendet voxelbasierte Marching Cubes mit einem Stapel von Rauschfunktionen. Dadurch sind Höhlen, Überhänge und schwebende Inseln möglich, die sich mit Heightmap-Terrain nicht darstellen lassen. Der Nachteil ist ein höherer Rechenaufwand pro Chunk, dafür entsteht visuell interessanteres Terrain.
• Das Basisbausystem kommt unserer Vorstellung am nächsten. Spieler platzieren Bauwerke, die dauerhaft auf dem Server gespeichert und für andere Spieler sichtbar sind. Die Basisdaten sind kompakt (eine Liste von Bauteilen mit Positionen und Rotationen) und werden bei Bedarf gestreamt, wenn jemand den Planeten besucht.
• Das Spiel wurde anfangs trotz seiner unendlichen Vielfalt für repetitive Inhalte kritisiert. Seed-basierte Generierung kann unendlich viel Terrain, aber nur begrenzte Überraschungen hervorbringen. Die Erkenntnis: Prozedurale Generierung eignet sich für die Leinwand, doch erst von Creatorn platzierte Inhalte lassen einen Ort gestaltet und bewusst geschaffen wirken.
• Hello Games ergänzte den Mehrspielermodus erst Jahre nach der Veröffentlichung. Bis zu 32 Spieler teilen sich eine Sitzung und können uneingeschränkt bauen und erkunden. Das Netzwerkmodell ist einfach: Ein Spieler ist der Host, die anderen verbinden sich mit ihm. Für eine Browserwelt mit persistentem Zustand eignet sich ein serverautoritatives Modell besser, doch No Man's Sky beweist, dass gemeinsam genutzte prozedurale Welten technisch beherrschbar sind.

Minecraft: Der Bauplan für Creator-Welten

300 Millionen verkaufte Exemplare. 16x16-Pixel-Texturen. Vollständig bearbeitbares Terrain. Unendlich generiert. Mehrspielerfähig. Die wichtigste Referenz für eine Creator-Welt. Browser-Klone beweisen, dass das Konzept in WebGL funktioniert.

Minecraft ist der wichtigste Bezugspunkt für das, was wir entwickeln – wichtiger als jeder grafisch aufwendige AAA-Titel. 300 Millionen verkaufte Exemplare. Die Welt wird unendlich generiert, ist vollständig zerstörbar und mehrspielerfähig. Creator platzieren in Minecraft nicht nur Objekte. Sie formen das Terrain selbst um.

Technische Erkenntnisse aus Minecraft:

• Die Welt ist in Chunks mit 16x16x384 Blöcken unterteilt. Nur Chunks in der Nähe des Spielers werden geladen (die Sichtweite ist konfigurierbar). Das entspricht demselben Chunk-Streaming-Muster wie in Skyrim, allerdings mit vollständig bearbeitbarem Terrain.
• Jeder Chunk wird als palettenkomprimiertes Array von Block-IDs gespeichert. Ein Chunk mit nur 5 verschiedenen Blocktypen speichert pro Block einen 4-Bit-Palettenindex statt einer vollständigen Block-ID. Dadurch bleiben die Chunk-Daten sehr kompakt (nach der Komprimierung typischerweise 10–50 KB pro Chunk).
• Das Mehrspielerprotokoll von Minecraft ist gut dokumentiert und relativ einfach. Der Server sendet Chunk-Daten, während sich der Spieler bewegt. Blockänderungen werden als kleine Delta-Updates übertragen (Position + neuer Blocktyp). Genau dieses Modell würden wir für Bearbeitungen durch Creator verwenden.
• Das Spiel läuft in Java und verfügt inzwischen über eine Bedrock Edition in C++. Browserbasierte Minecraft-Klone (ClassiCube, eaglercraft) beweisen, dass das Grundkonzept in WebGL funktioniert. Sie bewältigen typischerweise eine Sichtweite von 8–12 Chunks bei 60 fps, was einer Sichtweite von etwa 200–400 Metern entspricht.
• Das Modding-Ökosystem von Minecraft ist sein eigentlicher Wettbewerbsvorteil. Mods fügen neue Blöcke, Entitäten, Biome und Spielsysteme hinzu. Für eine Creator-Welt deutet das darauf hin, dass Erweiterbarkeit ebenso wichtig ist wie das Basiserlebnis. Wenn Creator neue Interaktionstypen definieren können, statt nur Objekte zu platzieren, wird die Welt mit der Zeit immer vielfältiger.
• Redstone (Minecrafts Verkabelungssystem im Spiel) zeigt, dass Creator komplexe Systeme bauen, wenn man ihnen einfache, kombinierbare Grundbausteine gibt. Logikgatter, automatische Farmen, Taschenrechner. Das einfache Regelwerk erzeugt außergewöhnliche Komplexität. Das ist dieselbe Erkenntnis wie bei der Chemie-Engine von BotW.

Gemeinsame Muster in offenen AAA-Welten

Betrachtet man all diese Titel, tauchen immer wieder dieselben Muster auf:

Räumliche Partitionierung ist allgegenwärtig. Ob Zellen (Bethesda), Sektoren (CD Projekt), Chunks (Mojang/Rockstar) oder Kacheln (FromSoftware): Jede offene Welt unterteilt den Raum in separat ladbare Einheiten. Keine Engine versucht, die gesamte Welt im Speicher zu halten.

Alles in mehreren Auflösungsstufen. Terrain, Meshes, Texturen und sogar Audio verfügen über mehrere Qualitätsstufen. Welche Auflösung verwendet wird, hängt davon ab, wie nah man sich befindet und wie wichtig das Objekt ist.

Occlusion Culling ist wichtiger als der reine Dreiecksdurchsatz. Nicht zu rendern, was man nicht sehen kann, spart mehr Leistung, als das Sichtbare zu optimieren. Skyrim verwendet ein einfaches entfernungsbasiertes System. The Witcher 3 nutzt Software-Occlusion mit großen Verdeckungsobjekten (Gebäuden, Klippen). Moderne Engines wie Nanite von UE5 gehen mit Hardware-Occlusion-Queries noch weiter.

Asynchrones Laden kaschiert Übergänge. Diese Spiele zeigen für die offene Welt keine Ladebildschirme an, sondern nur bei Schnellreisen oder beim Wechsel in Innenräume. Sie laden Inhalte in Hintergrund-Threads, dekomprimieren sie parallel und blenden neue Inhalte schrittweise ein.

Art Direction statt Polygonzahl. Skyrim erschien 2011 mit einer Grafik, die selbst damals eher bescheiden war. BotW läuft auf einem Chip der Tablet-Klasse und sieht wunderschön aus. Minecraft verwendet 16x16-Pixel-Texturen und gehört zu den visuell bekanntesten Spielen überhaupt. Für eine Browserwelt ist das enorm wichtig. Ein konsequenter Grafikstil mit geringerer Detailtreue schlägt immer eine technisch fortschrittliche, aber künstlerisch ausdruckslose Welt.

Systemisches Design ist besser als geskriptete Inhalte. Die Chemie-Engine von BotW, die Blockinteraktionen von Minecraft und die Verkehrssysteme von GTA V erzeugen aus einfachen Regeln emergentes Verhalten. Das ist günstiger zu entwickeln, günstiger auszuführen und bringt mehr Spielergeschichten hervor als handgefertigte geskriptete Sequenzen. Für eine Creator-Welt bedeutet systemisches Design, dass die Welt selbst in Bereichen interessant bleibt, die niemand ausdrücklich gestaltet hat.

Von Creatorn platzierte Inhalte müssen persistent und sichtbar sein. Minecraft-Basen, No-Man's-Sky-Basen und Immobilien in GTA Online bleiben sitzungsübergreifend bestehen und sind für andere Spieler sichtbar. Das Datenmodell für Creator-Inhalte ist stets kompakt (Bauteil-IDs + Transformationen), während die visuelle Darstellung reichhaltig ist (der Client erweitert die Daten zu vollständigen 3D-Szenen).

Rendering: Was kann ein Browser tatsächlich leisten?

Three.js

Three.js bildet die Grundlage. Es verfügt über die größte Community (mehr als 100.000 GitHub-Sterne), die meisten Beispiele und die breiteste Kompatibilität. Es abstrahiert WebGL 2 und bietet über WebGPURenderer experimentelle WebGPU-Unterstützung.

Für eine offene Welt bietet Three.js:

• Instanziertes Rendering für Vegetation, Felsen und wiederholte Geometrie (InstancedMesh)
• Integriertes LOD-System (THREE.LOD tauscht Meshes abhängig von der Entfernung aus)
• Automatisches Frustum Culling pro Objekt
• Terrain über benutzerdefinierte BufferGeometry oder Heightmap-basierte PlaneGeometry
• PBR-Materialien über MeshStandardMaterial und MeshPhysicalMaterial
• Post-Processing über EffectComposer (Bloom, SSAO, Tone Mapping)
• Shadow Maps, wobei Cascaded Shadow Mapping durch benutzerdefinierten Code möglich ist
• glTF/GLB als primäres Asset-Format (kompakt, GPU-fertig)

Three.js verfügt außerdem über ein aktives Ökosystem von Werkzeugen, die für offene Welten wichtig sind. three-mesh-bvh beschleunigt Raycasting und räumliche Abfragen über komplexe Meshes. postprocessing (von vanruesc) bietet eine leistungsfähigere Post-Processing-Pipeline als die integrierte Lösung von Three. three-gpu-pathtracing ermöglicht Rendering in Referenzqualität.

Einschränkungen für offene Welten: Three.js besitzt keinen integrierten Szenengraphen, der Streaming, LOD-Verwaltung oder räumliche Partitionierung im großen Maßstab übernimmt. Das muss man selbst entwickeln. Es gibt weder ein integriertes Entity Component System (ECS) noch Physik oder ein Terrain-System. Es ist ein Renderer, keine Engine. Für eine maßgeschneiderte offene Welt ist das tatsächlich ein Vorteil, weil man das Speicherlayout und die Ladestrategie selbst kontrolliert. Es bedeutet jedoch mehr Vorarbeit.

const lod = new THREE.LOD();
lod.addLevel(highDetailMesh, 0);
lod.addLevel(mediumDetailMesh, 50);
lod.addLevel(lowDetailMesh, 200);
lod.addLevel(impostorSprite, 500);
scene.add(lod);

Babylon.js

Babylon.js ist der andere große Kandidat. Es wird von Microsoft unterstützt und verfügt für die spezifischen Anforderungen offener Welten über umfangreichere integrierte Funktionen als Three.js.

Relevante integrierte Funktionen:

• Octree-basierte Szenenpartitionierung für effizientes Culling großer Szenen
• Solid Particle System für massives instanziertes Rendering
• Terrain aus Heightmaps mit integriertem LOD und Multi-Texture-Splatting
• Node Material Editor zur visuellen Shader-Erstellung
• WebGPU-Unterstützung (ausgereifter als bei Three.js, da Babylon früher darin investiert hat)
• Havok-Physikintegration (Wasm-kompiliert, produktionsreif)
• glTF-Streaming mit progressivem Laden

Die Erweiterung DynamicTerrain von Babylon erzeugt Terrain-Chunks dynamisch aus Heightmap-Daten, übernimmt das LOD automatisch und unterstützt Texture Splatting. Das kommt dem Ansatz von Skyrim deutlich näher als alles, was Three.js standardmäßig bietet.

const terrain = new BABYLON.DynamicTerrain("terrain", {
  terrainSub: 100,
  mapData: heightmapData,
  mapSubX: 1000,
  mapSubZ: 1000,
}, scene);
terrain.LODLimits = [4, 3, 2, 1];

Der Kompromiss: Babylon.js ist eine größere Bibliothek (der vollständige Build ist minifiziert etwa 1–2 MB groß, Three.js dagegen etwa 600 KB). Für eine offene Welt wird man Three.js jedoch wahrscheinlich um so viel benutzerdefinierten Code ergänzen, dass der Größenunterschied vernachlässigbar wird. Babylon verfügt außerdem über ein eigenes Node-Material-System, einen Inspector und Entwicklungswerkzeuge, die Iterationen beschleunigen.

Babylon.js 8.0 (veröffentlicht im März 2025) untermauerte seinen Anspruch als Kern-Engine für dieses Projekt. Alle zentralen Engine-Shader werden nun sowohl in GLSL als auch in WGSL ausgeliefert. Dadurch funktioniert WebGPU ohne Konvertierungsschicht, und das WebGPU-Bundle ist ungefähr halb so groß wie zuvor. Dieselbe Version integrierte außerdem den vollständigen Character Controller von Havok in die Engine sowie Flächenlichter, eine neu entwickelte Audio-Engine und Verbesserungen für Gaussian Splatting (SPZ- und komprimierte PLY-Formate, sphärische Harmonische sowie geringerer Speicher- und CPU-Bedarf).

PlayCanvas

PlayCanvas ist erwähnenswert, weil es die produktionserprobteste Web-First-3D-Engine ist. Snap, Facebook und zahlreiche Werbekunden haben damit komplexe 3D-Erlebnisse veröffentlicht. Die Engine ist etwa 1 MB groß, lädt schnell und ermöglicht über den Cloud-Editor die gemeinsame Erstellung von Welten.

Speziell für offene Welten bietet PlayCanvas Batch-Gruppen zur Optimierung von Draw Calls, einen integrierten Lightmapper und Unterstützung für Gaussian Splatting, was für durch Photogrammetrie erfasste reale Umgebungen relevant ist. Die Runtime ist schlank und gut für mobile Browser optimiert.

WebGPU: Der Leistungsschub

WebGPU verändert die Voraussetzungen für offene Browserwelten grundlegend. Zwei Funktionen sind dabei besonders wichtig:

Compute-Shader ermöglichen Terrain-Generierung, Vegetationsplatzierung, Partikelsimulation und sogar einfache Physik direkt auf der GPU. In einer WebGL-Welt läuft all das auf der CPU in JavaScript. Mit WebGPU kann man Terrain-Abschnitte vollständig auf der GPU generieren, LOD-Übergänge auf der GPU berechnen und Culling-Durchläufe auf der GPU ausführen. Dadurch wird die CPU für Netzwerkkommunikation, Spiellogik und Content-Streaming entlastet.

Indirektes Rendering lässt die GPU auf Grundlage der Ausgabe von Compute-Shadern entscheiden, was gezeichnet wird. Man übermittelt einen einzigen Draw Call, und die GPU entscheidet abhängig von der Entfernung, wie viele Instanzen für jede LOD-Stufe gerendert werden. So verarbeiten moderne Engines Millionen von Grashalmen oder Bäumen. Ohne indirektes Rendering, das WebGL nicht unterstützt, muss die CPU alles sortieren und bündeln. In dichten Szenen wird sie dadurch zum Engpass.

WebGPU ist inzwischen in allen großen Browsern verfügbar. Chrome und Edge unterstützen es seit Version 113, Firefox ergänzte es unter Windows (141) und auf Apple-Silicon-Macs (145), und Safari 26 brachte es Ende 2025 auf macOS, iOS, iPadOS und visionOS. Damit liegt die weltweite Unterstützung einschließlich Mobilgeräten bei rund 82 %; auch Chrome für Android und Samsung Internet liefern es aus. Für ältere Browser und Geräte, auf denen WebGPU nicht aktiviert ist, sollte weiterhin ein WebGL-2-Fallback vorhanden sein, doch die Lücke hat sich schnell geschlossen.

@compute @workgroup_size(64)
fn generateTerrain(@builtin(global_invocation_id) id: vec3<u32>) {
    let worldPos = vec2<f32>(f32(id.x), f32(id.y)) * cellSize + worldOffset;
    let height = fbmNoise(worldPos, octaves, persistence);
    heightmap[id.x + id.y * width] = height;
}

Empfohlener Rendering-Stack

Für eine offene Browserwelt, die sich an Creator auf Desktop-Systemen richtet:

Primär: Three.js oder Babylon.js mit WebGPU-Renderer, sofern verfügbar, und WebGL-2-Fallback. Babylon bietet stärkere integrierte Grundbausteine für offene Welten. Three.js verfügt über eine größere Community und mehr Flexibilität.

Unsere Wahl: Babylon.js als Engine-Kern aufgrund des integrierten Terrain-LOD, des Octree-Cullings, der Havok-Physik (Wasm) und der ausgereiften WebGPU-Unterstützung. Wo Babylon Funktionen fehlen, verwenden wir Werkzeuge aus dem Three.js-Ökosystem, etwa Mesh-BVH für räumliche Abfragen. Alles wird in eine eigene World-Streaming-Schicht eingebettet.

Architektur für World-Streaming

Das ist der schwierige Teil. Ein Browser-Tab erhält auf Desktop-Systemen ungefähr 2–4 GB Arbeitsspeicher (aufgrund browserseitiger Beschränkungen), auf Mobilgeräten etwa 1 GB und keinen direkten Festplattenzugriff. Alles wird über das Netzwerk übertragen. Man benötigt eine Architektur, die den sichtbaren Teil der Welt im Speicher hält und Inhalte kurz vor der Bewegungsrichtung des Spielers streamt.

Chunk-basiertes Weltraster

Unterteile die Welt wie beim Zellensystem von Skyrim in ein regelmäßiges Raster aus Chunks. Jeder Chunk ist eine unabhängige Einheit, die separat geladen, gerendert und entladen werden kann.

Die Chunk-Größe ist entscheidend. Sind Chunks zu klein, werden sie ständig mit hohem Verwaltungsaufwand geladen und entladen. Sind sie zu groß, dauert das Herunterladen jedes einzelnen Chunks zu lange. Für eine Browserwelt mit typischen Breitbandverbindungen:

• Chunks von 64x64 Metern auf Bodenebene
• Jeder Chunk enthält: Heightmap-Abschnitt (2–4 KB), Texture-Splat-Map (komprimiert 16–32 KB), statische Meshes als instanzierte Referenzen (1–50 KB Instanzdaten), von Creatorn platzierte Objekte als Manifest (1–10 KB)
• Laderadius: 5x5 Chunks mit vollständigen Details (320 m Sichtweite), 9x9 mit mittlerem LOD, 17x17 nur mit Terrain
• Ziel: weniger als 200 KB Detaildaten pro Chunk, sodass ein 5x5-Bereich unter 5 MB bleibt

Progressive Lade-Pipeline

Lade nicht alle Daten eines Chunks auf einmal. Verwende eine Prioritätswarteschlange:

1. Zuerst die Terrain-Geometrie (nur Höhenkarte, 2–4 KB pro Chunk). Der Spieler sieht den Boden innerhalb von 100 ms.
2. Terrain-Texturen (Splat-Maps, zuerst niedrige Auflösung, dann Upgrade). Der Boden erhält innerhalb von 200 ms Farbe.
3. Große Strukturen (Gebäude, große Felsen). Silhouetten erscheinen innerhalb von 500 ms.
4. Detailobjekte (Vegetation, kleine Requisiten, Creator-Objekte). Die Welt füllt sich innerhalb von 1–2 Sekunden.
5. Hochauflösende Texturen werden zuletzt aktualisiert. Niemand bemerkt, wenn die Textur eines entfernten Gebäudes eine zusätzliche Sekunde benötigt.

Das entspricht der Funktionsweise des menschlichen Auges. Fehlender Boden und fehlende große Strukturen fallen uns auf. Fehlendes Gras bemerken wir nicht.

Speicherverwaltung

Der Browserspeicher ist begrenzt und die Garbage Collection ist dein Feind. Eine einzige GC-Pause kann die Bildrate für einen Frame von 60 fps auf 10 fps senken.

Object-Pooling ist unverzichtbar. Lege im Voraus Pools für häufig verwendete Objekte an (Bäume, Felsen, Grasflächen) und verwende sie beim Laden und Entladen von Chunks erneut. Erzeuge im zeitkritischen Ausführungspfad niemals neue Instanzen von THREE.Mesh oder BABYLON.Mesh. Tausche stattdessen die Geometrie- und Materialreferenzen der gepoolten Objekte aus.

Texturatlanten reduzieren sowohl Draw Calls als auch die Speicherfragmentierung. Fasse alle Terrain-Texturen in einigen wenigen großen Atlanten zusammen. Fasse von Creatorn hochgeladene Texturen serverseitig in Atlanten pro Chunk zusammen und streame sie als einzelne Bilder.

Geometriekomprimierung mit Draco oder Meshopt reduziert die Downloadgröße um das 5- bis 10-Fache. Die Dekomprimierung läuft in einem Web Worker, damit sie den Hauptthread nicht blockiert. Unser GLB-Optimierer wendet den Meshopt-Durchlauf im Browser an, wenn du die Einsparung zunächst anhand deiner eigenen Assets messen möchtest. Speziell für Terrain sind quantisierte Höhenkarten (16-Bit-Werte, die mit einfacher Delta-Kodierung komprimiert werden) kleiner als jedes universelle Mesh-Format.

Die Übertragung des ArrayBuffer-Besitzes zwischen Workern und dem Hauptthread vermeidet Kopiervorgänge. Wenn ein Worker ein Mesh dekomprimiert, überträgst du den Puffer ohne Kopie mit postMessage und übertragbaren Objekten an den Hauptthread.

Asset-Auslieferung

CDN mit Edge-Caching für statische Weltdaten. Terrain-Chunks, Basis-Meshes und Texturatlanten, die sich nicht häufig ändern, sollten aggressiv zwischengespeichert werden (Cache-Control: max-age=31536000, immutable).

Inhaltsadressierte Speicherung bedeutet, dass jede Asset-Version einen eindeutigen Hash in ihrer URL erhält. Wenn ein Creator einen Chunk ändert, erhält die neue Version einen neuen Hash, während die alte für alle im Cache bleibt, die sie noch betrachten. Eine Cache-Invalidierung ist nicht erforderlich.

KTX2-Texturen mit Basis-Universal-Komprimierung. Diese werden in das vom Gerät unterstützte GPU-Format dekomprimiert (BC7, ASTC, ETC2 oder ersatzweise RGBA). Eine unkomprimiert 4 MB große Terrain-Textur mit 1024 × 1024 Pixeln schrumpft in KTX2 auf ungefähr 150 KB. Bei einer Welt mit Tausenden einzigartiger Texturen macht diese Komprimierung den Unterschied zwischen umsetzbar und nicht umsetzbar aus.

glTF Binary (GLB) für alle 3D-Assets. Es ist das JPEG der 3D-Welt. Jede Browser-Engine kann es laden, es ist kompakt und kann Texturen, Materialien und Animationen in einer einzigen Datei einbetten. Verwende Draco- oder Meshopt-Erweiterungen zur Mesh-Komprimierung. Von Creatorn hochgeladene Assets werden serverseitig zu optimierten GLB-Dateien verarbeitet, bevor sie in die Welt gelangen.

Multiplayer-Netzwerk

Hunderte Creator in derselben Welt zusammenzubringen, erfordert eine Netzwerkarchitektur, die Echtzeitbewegungen, persistenten Weltzustand und Creator-Bearbeitungen bewältigt, ohne zusammenzubrechen.

Serverarchitektur

Ein autoritärer Server verwaltet den Weltzustand. Dem Browser wird nicht vertraut. Alle relevanten Aktionen (Objekte platzieren, Terrain verändern, zwischen Chunks wechseln) werden serverseitig validiert. Der Client führt lokale Vorhersagen aus und gleicht sie mit dem Serverzustand ab.

Räumliches Sharding verteilt die Welt auf mehrere Serverinstanzen. Jeder Shard besitzt eine rechteckige Region des Weltrasters. Wenn sich die Spielerdichte verändert, können Shards geteilt oder zusammengeführt werden. So verwaltet EVE Online Tausende Spieler in einem einzigen Universum, und dasselbe Prinzip funktioniert auch in kleinerem Maßstab.

Für eine Creator-Welt, in der die meisten Interaktionen lokal stattfinden (du baust in deinem Bereich und deine Nachbarn können es sehen), eignet sich räumliches Sharding auf natürliche Weise. Ein Spieler an einer Shard-Grenze sieht die Inhalte beider Shards, was Shard-übergreifende Sichtbarkeitsabfragen erfordert. Dafür gibt es jedoch bewährte Lösungen.

Technologieoptionen für den Server:

Technologie	Stärken	Anwendungsfall
Cloudflare Durable Objects	Edge-Bereitstellung, automatische Skalierung, integrierte Persistenz, WebSocket-Unterstützung	Zustand von Welt-Shards, Autorität pro Chunk
Hathora / Rivet	Verwaltetes Game-Server-Hosting, DDoS-Schutz, globale Bereitstellung	Dedizierte Game-Server-Instanzen
Colyseus	Open-Source-Framework für Game-Server auf Node.js-Basis, schemabasierte Zustandssynchronisierung	Raumbasierter Multiplayer mit Zustandsdifferenzen
PartyKit	Edge-Bereitstellung, WebSocket + WebRTC, basiert auf Cloudflare Workers	Echtzeit-Zusammenarbeit, leichtgewichtiger Multiplayer
Benutzerdefiniertes Rust/Go	Maximale Kontrolle, beste Leistung pro Instanz	Shards mit hoher Dichte, die Physik mit niedriger Latenz benötigen

Unser Kontext (Cloudflare-Infrastruktur): Durable Objects sind eine natürliche Wahl. Jeder Welt-Chunk wird zu einem Durable Object, das den autoritativen Zustand der Inhalte dieses Chunks verwaltet. Spieler verbinden sich per WebSocket mit dem Durable Object, das für ihren aktuellen Chunk zuständig ist. Wenn sie sich in einen benachbarten Chunk bewegen, verbinden sie sich mit dem DO dieses Chunks. Durable Objects speichern den Zustand automatisch dauerhaft, sodass die Weltdaten Neustarts überstehen.

Client-Server-Kommunikation

WebSocket für zuverlässige, geordnete Nachrichten (Chat, Weltbearbeitungen, Inventar, Spielzustand). Eine Verbindung pro aktivem Shard, den der Spieler sehen kann (typischerweise 1–4 Verbindungen).

WebRTC DataChannel für unzuverlässige, ungeordnete Nachrichten (Spielerpositionen, Animationen, kurzlebige Effekte). WebRTC unterstützt Peer-to-Peer-Verbindungen, bei einer Welt mit vielen Spielern würde es jedoch über eine SFU (Selective Forwarding Unit) betrieben, um N²-Verbindungen zu vermeiden. Cloudflare Calls oder LiveKit können als SFU dienen.

Die Zustandssynchronisierung verwendet Delta-Komprimierung. Der Server verfolgt, was jeder Client bereits gesehen hat, und sendet nur Änderungen. Für eine Creator-Welt ist das besonders wichtig, da sich der Weltzustand (welche Objekte existieren, wo sie sich befinden und welche Eigenschaften sie haben) deutlich seltener ändert als die Positionen der Spieler. Weltzustandsaktualisierungen können mit 2–5 Hz gesendet werden, während Spielerpositionen mit 20–30 Hz aktualisiert werden.

interface WorldChunkState {
  version: number;
  terrain: TerrainPatch;
  objects: PlacedObject[];
  creators: CreatorPresence[];
}

interface DeltaUpdate {
  chunkId: string;
  fromVersion: number;
  toVersion: number;
  addedObjects: PlacedObject[];
  removedObjectIds: string[];
  modifiedObjects: Partial<PlacedObject>[];
  creatorMoves: CreatorPosition[];
}

Konfliktlösung bei Creator-Bearbeitungen

Wenn zwei Creator gleichzeitig denselben Bereich bearbeiten, benötigst du eine Strategie zur Konfliktlösung. Hier spielt die Wahl des Modells für die Echtzeit-Zusammenarbeit eine entscheidende Rolle.

Last-Write-Wins ist die einfachste Lösung. Jedes Objekt hat zu jedem Zeitpunkt genau einen Besitzer. Wenn du ein Gebäude bearbeitest, kann es niemand anderes bearbeiten, bis du es freigibst. Das ist einfach und konfliktfrei, schränkt aber die Zusammenarbeit ein.

Operational Transform (OT) wird von Google Docs verwendet. Operationen werden unter Berücksichtigung gleichzeitig stattfindender Operationen transformiert, um ein konsistentes Ergebnis zu erzeugen. Bei Text funktioniert das gut, für räumliche 3D-Operationen wird es jedoch komplex. Figma verwendet für seine 2D-Leinwand eine Variante davon.

CRDTs (Conflict-free Replicated Data Types) ermöglichen gleichzeitige Bearbeitungen, die ohne Koordination immer zum selben Zustand konvergieren. Für eine Welt mit diskreten Objekten, die jeweils eine ID und Eigenschaften besitzen, sorgt ein Last-Writer-Wins-Register pro Eigenschaft in Kombination mit einem Add-Wins-Set für die Objektsammlung für automatische Konvergenz. Yjs und Automerge sind produktionsreife CRDT-Bibliotheken für JavaScript.

Unsere Empfehlung: Verwende CRDTs für den Zustand der Weltobjekte (was existiert, wo es sich befindet und welche Eigenschaften es hat) und einen autoritativen Server für die räumliche Validierung (keine zwei Objekte an derselben Stelle, Objekte bleiben innerhalb der Weltgrenzen). Das CRDT übernimmt die Zusammenarbeit. Der Server übernimmt die Physik.

Skalierung bewältigen: Wie viele Spieler?

Browser-MMOs gibt es bereits heute. Hordes.io unterstützt mehr als 200 Spieler in einer Szene im Browser. BrowserQuest, ein Experiment von Mozilla, bewältigte Hunderte Spieler mit einer einfachen kachelbasierten Welt. Die Frage ist nicht, ob Browser Multiplayer bewältigen können, sondern welche visuelle Qualität sich bei steigender Spielerzahl aufrechterhalten lässt.

Rendering-Budget für Spieler: Jeder sichtbare Spieler benötigt ein Mesh, Animationen und möglicherweise ein vom Creator angepasstes Erscheinungsbild. Bei 60 fps stehen 16 ms pro Frame zur Verfügung. Ein realistisches Budget:

• 50 vollständig animierte Spieler im Nahbereich: ~2 ms für Animation und Skinning
• 200 Spieler im mittleren Entfernungsbereich (vereinfachte Animation, instanziert): ~1 ms
• Mehr als 500 Spieler als Punkte/Symbole auf der Minikarte: vernachlässigbar

Damit sind in einer Ansicht etwa 250 Spieler sichtbar, was für eine Creator-Welt mehr als ausreichend ist. Selbst in den Hauptstädten von World of Warcraft werden selten mehr als 200 Charaktere gleichzeitig im Sichtfeld gerendert.

Netzwerkbudget: Wenn jeder Spieler seine Position mit 20 Hz sendet, entspricht das ungefähr 40 Byte × 20 = 800 Byte/Sekunde. Bei 200 Spielern im Sichtfeld sind das 160 KB/s an Positionsdaten. Rechnet man Weltzustand, Chat und Creator-Aktionen hinzu, kommt man auf 200–500 KB/s pro Client. Das liegt problemlos innerhalb der Möglichkeiten einer Breitbandverbindung, sollte aber dennoch komprimiert werden.

Terrain-System

Das Terrain bildet die Grundlage jeder offenen Welt. Hier machen sich die Einschränkungen des Browsers besonders stark bemerkbar, weil Terrain überall vorhanden und ständig sichtbar sein muss.

Höhenkartenbasiertes Terrain

Verwende wie Skyrim eine Höhenkarte. Ein zweidimensionales Raster aus Höhenwerten erzeugt mithilfe eines Vertex-Shaders dreidimensionales Terrain. Das ist erheblich kompakter als beliebiges Mesh-Terrain.

Eine Höhenkarte mit 4096 × 4096 Werten und 16-Bit-Präzision ist unkomprimiert 32 MB groß. Sie wird jedoch nie vollständig auf einmal geladen. Jeder 64-m-Chunk verwendet einen 65 × 65 großen Abschnitt der Höhenkarte (bei 16 Bit etwa 8,4 KB). Mit Delta-Kodierung und zlib komprimiert sind das weniger als 2 KB pro Chunk.

Texture-Splatting malt mehrere Terrain-Materialien (Gras, Fels, Erde, Sand) mithilfe einer Mischkarte auf das Gelände. Jeder Chunk besitzt eine vierkanalige RGBA-Splat-Map, bei der jeder Kanal das Mischungsverhältnis eines Materials steuert. Mit vier Texturen pro Splat-Map und der Möglichkeit, die Splat-Maps für jeden Chunk zu variieren, entsteht in der gesamten Welt visuelle Vielfalt.

Moderne Terrain-Renderer verwenden virtuelle Texturierung (auch Megatexture genannt, nach der Technologie von id Software in Rage). Anstatt die Texturen zur Laufzeit zu mischen, wird die kombinierte Terrain-Textur in hoher Auflösung vorgerendert und beim Bewegen der Kamera kachelweise gestreamt. Dadurch wird Speicherbedarf gegen Laufzeitleistung eingetauscht. Die Compute-Shader von WebGPU können das Feedback und die Seitentabellenverwaltung übernehmen, die für virtuelle Texturierung erforderlich sind.

Clipmap oder Geoclipmapping

Für das Rendern großer Terrain-Flächen im Browser eignen sich CDLOD (C. Dicks LOD) oder Geoclipmapping. Das Terrain wird als eine Reihe konzentrischer Ringe um die Kamera gerendert, wobei jeder Ring die halbe Auflösung des vorherigen besitzt. In Kameranähe erscheint das Terrain in voller Auflösung. In größerer Entfernung wird eine gröbere Version dargestellt. Die Übergänge sind fließend, weil die Geometrie zwischen den Detailstufen morpht.

Diese Technik ist GPU-freundlich (ein Draw Call pro Ring), unterstützt unendliches Terrain mit konstantem Speicherbedarf und funktioniert in WebGL 2. Flight Simulator und die meisten modernen Open-World-Spiele verwenden sie in irgendeiner Form.

Von Creatorn verändertes Terrain

Wenn Creator das Terrain formen können, benötigst du eine Möglichkeit, die Änderungen zusätzlich zur Basis-Höhenkarte zu speichern und zu streamen. Dafür gibt es zwei Ansätze:

Delta-Höhenkarten speichern den Unterschied zwischen dem Basis-Terrain und dem veränderten Terrain. Der größte Teil der Welt bleibt unverändert (die Delta-Werte sind null), weshalb sich das extrem gut komprimieren lässt. Beim Laden eines Chunks wird das Delta auf die Basis angewendet.

Voxel-Overlays eignen sich für drastischere Veränderungen (Höhlen, Überhänge, Bögen). Eine Höhenkarte kann kein Terrain darstellen, bei dem ein Punkt zwei verschiedene Höhen besitzt. Ein dünn besetztes Voxelraster, das nur in veränderten Chunks gespeichert wird, löst dieses Problem. Marching Cubes oder Dual Contouring erzeugt daraus das Mesh. Das ist rechenintensiver, ermöglicht jedoch Terrain-Bearbeitung im Stil von Minecraft.

KI-gestützte Weltgenerierung

Hier werden Cinevvas bestehende Fähigkeiten im Bereich generativer KI zu einem entscheidenden Verstärker. Anstatt jeden Felsen und jeden Baum von Hand zu bauen, können Creator die KI anweisen, die Welt zu bevölkern.

Terrain-Generierung mit neuronalen Feldern

Aktuelle Forschung zur neuronalen Terrain-Generierung (NVIDIAs GET3D, der neuronale Netzwerkmodus von Terragen und wissenschaftliche Arbeiten wie „Terrain Generation Using Procedural Models“) zeigt, dass trainierte Modelle aus Texteingaben oder Skizzen glaubwürdiges Terrain erzeugen können. Ein Creator könnte eine grobe Küstenlinie zeichnen und „bewaldete Hügel, die auf eine felsige Küste treffen“ eingeben, um eine Höhenkarte mit passender Erosion, Vegetationsmasken und Materialzuweisungen zu erhalten.

Für die Auslieferung im Browser erfolgt die Generierung serverseitig und das Ergebnis wird gestreamt. Das Generierungsmodell muss nicht im Browser ausgeführt werden. Es erzeugt Höhenkarten und Splat-Maps, die der Browser mit der standardmäßigen Terrain-Pipeline rendern kann.

Generierung von 3D-Assets

Modelle wie Hunyuan3D, Meshy, Tripo und Rodin können aus Text oder Bildern 3D-Meshes erzeugen. Der Arbeitsablauf für eine Creator-Welt:

1. Der Creator beschreibt oder skizziert, was er benötigt („ein moosbewachsener Steinbogen“ oder „eine futuristische Straßenlaterne“).
2. Der Server führt das Generierungsmodell aus und erzeugt ein High-Poly-Mesh.
3. Der Server verarbeitet es automatisch: Reduzierung auf eine webtaugliche Polygonzahl, Erzeugung von LODs, Backen der Texturen in einen Atlas und Export als GLB mit Draco-Komprimierung.
4. Das Asset erscheint im Inventar des Creators und kann direkt in der Welt platziert werden.

Diese Pipeline existiert bei Cinevva bereits in Teilen. Was noch fehlt, sind der LOD-/Optimierungsschritt und das System zur Platzierung in der Welt.

Prozedurale Verteilung

Selbst mit KI-generierten Assets ist es mühsam, jeden Baum in einem Wald manuell zu platzieren. Prozedurale Verteilungsregeln ermöglichen es Creatorn, Zonen zu definieren („dieser Bereich ist dichter Wald“, „dieser Hang besteht aus felsigem Geröll“), die das System anschließend automatisch bevölkert. GPU-Compute-Shader können die Verteilung im Browser ausführen. Ausgehend von einer Dichtekarte und einer Reihe von Regeln (Mindestabstand, Hangneigungsbeschränkungen, Höhenbereich) erzeugt ein Compute-Pass die Instanzpositionen für einen gesamten Chunk in weniger als 1 ms. Wird die Dichtekarte geändert, generiert sich die Vegetation sofort neu.

Entity Component System (ECS)

Eine offene Welt mit Tausenden von Objekten benötigt ein effizientes System zur Entitätsverwaltung. Das ECS-Muster (in Spiele-Engines seit Unity DOTS und Bevy verbreitet) lässt sich gut auf JavaScript übertragen.

bitECS ist ein leistungsstarkes ECS für JavaScript, das typisierte Arrays und bitweise Operationen verwendet. Entitäten sind einfache Ganzzahlen. Komponenten sind zusammenhängende typisierte Arrays (eines pro Komponententyp). Systeme durchlaufen Arrays sequenziell, was selbst in JavaScript cachefreundlich ist.

import { createWorld, defineComponent, Types, defineQuery, addEntity, addComponent } from 'bitecs';

const Position = defineComponent({ x: Types.f32, y: Types.f32, z: Types.f32 });
const Velocity = defineComponent({ x: Types.f32, y: Types.f32, z: Types.f32 });
const ChunkRef = defineComponent({ chunkX: Types.i16, chunkZ: Types.i16 });

const world = createWorld();
const movingQuery = defineQuery([Position, Velocity]);

function movementSystem(world) {
  const entities = movingQuery(world);
  for (let i = 0; i < entities.length; i++) {
    const eid = entities[i];
    Position.x[eid] += Velocity.x[eid] * dt;
    Position.y[eid] += Velocity.y[eid] * dt;
    Position.z[eid] += Velocity.z[eid] * dt;
  }
  return world;
}

In einer offenen Welt verwaltet das ECS alles: Spielercharaktere, platzierte Objekte, NPCs, Partikel, Trigger und Weltobjekte. Wenn ein Chunk entladen wird, werden seine Entitäten aus dem ECS entfernt. Wenn ein Chunk geladen wird, werden Entitäten hinzugefügt. Dem ECS ist die räumliche Organisation gleichgültig. Es verarbeitet lediglich Komponenten.

Physik

Browser-Physik ist dank WebAssembly überraschend leistungsfähig geworden.

Rapier (Rust -> Wasm)

Rapier ist eine in Rust geschriebene Physik-Engine, die zu WebAssembly kompiliert wird. Sie unterstützt Starrkörper, Collider, Gelenke, Charakter-Controller und Raycasting. Bei typischen Spiele-Workloads liegt ihre Leistung innerhalb des Zwei- bis Dreifachen von nativem Bullet oder PhysX.

In einer offenen Welt übernimmt Rapier:

• Den Spieler-Controller (Gehen auf Terrain, Erklimmen von Stufen, Rutschen an Hängen)
• Kollisionen zwischen Objekten (platzierte Objekte, Projektile)
• Raycasting für Spielerinteraktionen (ein Objekt anklicken, um es auszuwählen)
• Trigger-Volumen (einen Bereich betreten und ein Ereignis auslösen)

Rapier läuft in einem Web Worker, sodass die Physiksimulation das Rendering nicht blockiert. In jedem Frame werden Positionen an den Renderer gesendet und Eingabeereignisse zurückempfangen.

Havok für das Web (über Babylon.js)

Wenn du dich für Babylon.js entscheidest, ist die Havok-Physik als Wasm-Modul integriert. Havok ist die Physik-Engine hinter vielen AAA-Spielen (Half-Life 2, Skyrim, Breath of the Wild). Der Wasm-Build ist produktionsreif und für den Szenengraphen von Babylon optimiert.

Terrain-Kollision

Physik-Engines benötigen Kollisionsgeometrie für das Terrain. Ein voll aufgelöstes Dreiecksnetz für das gesamte sichtbare Terrain zu erzeugen, wäre aufwendig. Erzeuge stattdessen Kollisions-Höhenfelder nur für Chunks in der Nähe des Spielers (die nächsten 3x3 oder 5x5 Chunks) und verwende für alles andere vereinfachte Kollisionen. Rapiers Höhenfeld-Collider ist genau für diesen Anwendungsfall ausgelegt.

Audio

Sound verwandelt einen visuellen 3D-Demoraum in einen echten Ort. Die Web Audio API bietet alles, was für räumliches Audio im Browser benötigt wird.

Räumliches Audio mit HRTF (Head-Related Transfer Function) positioniert Klänge im dreidimensionalen Raum. Ein Wasserfall links von dir klingt, als befände er sich tatsächlich links. Gehst du näher heran, wird er lauter. Gehst du hinter ein Gebäude, klingt er gedämpft (mit zusätzlicher Verarbeitung).

Atmosphärenzonen funktionieren wie Texture Splatting für Audio. Definiere Regionen (Wald, Höhle, Küste, Stadt) und überblende Umgebungs-Klanglandschaften, während sich der Spieler zwischen ihnen bewegt. So lässt Skyrim Wälder lebendig klingen. Kombiniere Wind, Vögel, raschelnde Blätter und entfernte Tiere. Nichts davon ist kompliziert. Alles davon ist räumlich.

Die Leistung von Web Audio reicht für Dutzende gleichzeitig aktive räumliche Klangquellen aus. Der Engpass ist üblicherweise die Asset-Größe, nicht die Verarbeitung. Verwende Opus oder AAC für komprimiertes Audio, streame lange Umgebungsspuren und lade kurze Soundeffekte (Schritte, Interaktionen) vorab.

Wasser, Wetter und Atmosphäre

Jede einprägsame offene Welt hat Wasser und Wetter. Diese Systeme bestimmen die Stimmung und lassen die Welt lebendig wirken. Außerdem lassen sie sich überraschend gut in einem Browser umsetzen.

Wasser-Rendering

Wasser in Browser-3D hat drei Komplexitätsstufen. Du kannst zunächst die einfachste veröffentlichen und später aufrüsten.

Stufe 1: Reflektierende Ebene. Ein flaches Mesh auf Höhe des Wasserspiegels mit einem reflektierenden und lichtbrechenden Material. Rendere die Szene umgedreht in eine Textur (planare Reflexion), mische sie mit einer blauen Tönung und füge scrollende Normal Maps für die Wellenbewegung hinzu. So funktioniert der grundlegende Wasser-Shader von Skyrim. In Three.js implementiert das Beispiel Water im offiziellen Repository dieses Verfahren. In Babylon.js bietet WaterMaterial es standardmäßig. Kosten: ein zusätzlicher Render-Pass für Reflexionen (halbe Auflösung genügt) sowie das Zeichnen der Wasseroberfläche. Auf einer Mittelklasse-GPU erhöht dies die Frame-Zeit um 2–3 ms.

Stufe 2: Screen-Space-Reflexionen + tiefenbasierte Effekte. Anstelle eines separaten Render-Passes für Reflexionen wird der vorhandene Framebuffer für Reflexionen abgetastet (SSR). Ergänze tiefenbasierte Farbabsorption (Wasser ist dunkler, wo es tiefer ist), Schaum an Uferlinien mittels Tiefenvergleich und auf das Unterwasserterrain projizierte Kaustiken. Dieses Verfahren verwendet The Witcher 3. SSR ist sowohl im Postprocessing-Stack von Three.js als auch in der Rendering-Pipeline von Babylon.js verfügbar. Kosten: 1–2 ms für SSR, vernachlässigbar wenig für die Tiefeneffekte.

Stufe 3: FFT-Ozeansimulation. Verwende für offene Ozeane eine schnelle Fourier-Transformation, um Wellenspektren auf der GPU zu simulieren. Jerry Tessendorfs Artikel „Simulating Ocean Water“ (2001) bildet die Grundlage, die jede große Spiele-Engine nutzt. Die FFT läuft als Compute-Shader in WebGPU und erzeugt in jedem Frame eine Displacement Map und eine Normal Map. Der resultierende Ozean wirkt bemerkenswert überzeugend. Dieses Verfahren kommt in Sea of Thieves, Assassin's Creed Black Flag und Uncharted 4 zum Einsatz. In WebGPU läuft ein 256x256-FFT-Ozean auf Desktop-GPUs in weniger als 1 ms.

@compute @workgroup_size(16, 16)
fn fftOceanDisplacement(@builtin(global_invocation_id) id: vec3<u32>) {
    let k = vec2<f32>(f32(id.x) - N/2.0, f32(id.y) - N/2.0);
    let omega = sqrt(length(k) * gravity);
    let phase = omega * time;
    let h = spectrum[id.xy] * vec2<f32>(cos(phase), sin(phase));
    displacement[id.xy] = h;
}

Beginne bei einer Creator-Welt mit Stufe 1 (reflektierende Ebene) und wechsle zu Stufe 2, sobald der Renderer ausgereifter ist. Stufe 3 ist nur erforderlich, wenn die Welt einen offenen Ozean enthält.

Wettersysteme

Das Wetter in Skyrim und BotW wird von einem Zustandsautomaten mit Übergängen gesteuert. Klar > Bewölkt > Regen > Sturm > Klar. Jeder Zustand verändert mehrere Systeme gleichzeitig: Skybox, Nebeldichte, Farbe des Umgebungslichts, Partikeleffekte (Regen/Schnee), Audio (Wind, Regen) und Gameplay-Eigenschaften (nasse Oberflächen sind in BotW rutschig).

Für eine Browser-Welt hat das Wettersystem drei Ebenen:

Himmels-Rendering. Ein prozeduraler Himmels-Shader ist günstiger und flexibler als Skybox-Texturen. Die Himmelsmodelle von Preetham oder Hosek-Wilkie berechnen physikalisch plausible Himmelsfarben allein aus dem Sonnenstand. Füge eine Wolkenschicht hinzu, indem du 3D-Rauschen über eine Ebene scrollen lässt. Babylon.js hat ein integriertes prozedurales Himmelsmaterial. Three.js bietet das Beispiel Sky. Beide liefern bei vernachlässigbaren GPU-Kosten überzeugende Ergebnisse (es handelt sich um ein einzelnes bildschirmfüllendes Quad).

Partikeleffekte. Regen ist ein Partikelsystem mit Tausenden dünner Quads, die von oben herabfallen. Schnee funktioniert ähnlich, jedoch mit langsameren, treibenden Flugbahnen. Nebel ist ein Postprocessing-Pass, der die Szene abhängig von der Tiefe mit einer Nebelfarbe verblendet. All dies sind standardmäßige WebGL-Effekte. Die Kosten hängen von der Partikelzahl ab: 10.000 Regenpartikel erhöhen die Frame-Zeit um etwa 0,5 ms.

Umgebungsreaktion. Nasse Oberflächen weisen stärkere spiegelnde Reflexionen auf. Schneeansammlungen färben nach oben gerichtete Flächen weiß. In konkavem Terrain bilden sich Pfützen. Dabei handelt es sich um Shader-Tricks, nicht um Änderungen der Geometrie. Ein „wetness“-Uniform verändert die Rauheit des Materials. Ein „snow cover“-Uniform mischt Weiß auf Oberflächen, deren Normalen nach oben zeigen. GTA V und The Witcher 3 verwenden genau diesen Ansatz.

Synchronisiertes Wetter. In einer Mehrspielerwelt muss das Wetter auf allen Clients übereinstimmen. Der einfachste Ansatz: Der Server überträgt mit 1 Hz einen Wetterzustand einschließlich des Übergangsfortschritts. Die Clients interpolieren lokal. Da sich das Wetter langsam ändert (ein Übergang von klarem Himmel zu Regen dauert 30–60 Sekunden), wirkt selbst eine verzögerte Aktualisierung flüssig.

Atmosphärische Perspektive

Dies ist die wirkungsvollste visuelle Technik, um eine Welt groß erscheinen zu lassen, und sie ist nahezu kostenlos. Entfernte Objekte wirken aufgrund der Lichtstreuung in der Atmosphäre diesiger, blauer und kontrastärmer. Jede offene Welt nutzt diesen Effekt.

Mische in einem Fragment-Shader entfernte Pixel abhängig von der Tiefe mit der Atmosphärenfarbe:

float fogFactor = 1.0 - exp(-distance * fogDensity);
vec3 finalColor = mix(objectColor, atmosphereColor, fogFactor);

BotW geht mit einem malerischen Nebel noch weiter, der in der Ferne in einen Aquarellstil übergeht. Die Nebelfarbe verändert sich je nach Tageszeit und Wetter. Dieser einzelne Shader-Effekt trägt mehr zum Größenempfinden bei als jede noch so hohe Terraindetailstufe.

Für eine Browser-Welt mit stilisierter Art Direction sollte die atmosphärische Perspektive als erster visueller Effekt implementiert werden. Sie verbirgt LOD-Übergänge (detailärmere entfernte Objekte sehen durch den Dunst gut aus), reduziert das sichtbare Aufpoppen gestreamter Inhalte und lässt Screenshots bereits gut aussehen, bevor die Welt vollständig bevölkert ist.

Avatar-Systeme

Spieler brauchen Körper. In einer Creator-Welt ist der Avatar neben den eigenen Bauten die wichtigste Form des Selbstausdrucks. Das System muss flexibel genug für Personalisierung sein und gleichzeitig die Rendering-Kosten niedrig genug halten, um mehr als 200 sichtbare Spieler darzustellen.

Avatar-Architektur

Basismesh + Anpassungsebenen. Beginne mit einem gemeinsamen humanoiden Basismesh (1.500–3.000 Dreiecke für den Körper). Die Anpassung erfolgt durch:

• Farb- und Texturvarianten (Hautton, Haarfarbe) über Uniform-Änderungen. Keine zusätzliche Geometrie.
• Austauschbare Mesh-Teile (Frisuren, Kleidung, Accessoires), die Abschnitte des Basismeshs ersetzen. Jedes Teil ist ein separates kleines Mesh (200–500 Dreiecke).
• Variationen der Materialeigenschaften (metallische Rüstung gegenüber Stofftunika) durch Änderungen der Materialparameter.

So handhaben Roblox, Fortnite und VRChat Avatare. Die Grundkosten bleiben unabhängig von der Anpassung konstant.

Ready Player Me und Avaturn bieten browserbasierte Avatar-Erstellung und geben glTF-Modelle aus, die mit jeder 3D-Engine kompatibel sind. Sie unterstützen das Scannen von Gesichtern anhand von Fotos, Körperproportionen und Kleidung. Die ausgegebenen Modelle sind für Echtzeit-Rendering optimiert (typischerweise 10.000–20.000 Dreiecke, für die Darstellung in der Ferne reduzierbar auf 3.000–5.000).

Skelettanimation im Browser

Jeder sichtbare Spieler benötigt Animationen: Leerlauf, Gehen, Laufen, Springen und Emotes. Skelettanimation bewegt ein Mesh in jedem Frame anhand einer Reihe von Knochentransformationen.

GPU-Skinning ist für eine gute Leistung unverzichtbar. Sowohl Three.js als auch Babylon.js führen Skinning standardmäßig auf der GPU aus. Die Knochenmatrizen werden als Uniform Buffer oder Textur hochgeladen und der Vertex-Shader wendet die Knochentransformationen an. Die CPU berechnet die Knochentransformationen aus dem Animationsclip. Bei einem Skelett mit 60 Knochen und 30 fps dauert dies ungefähr 0,01 ms pro Charakter. Bei 200 Charakteren sind es insgesamt 2 ms. Das ist akzeptabel.

Animationsüberblendung mischt mehrere Animationen (Gehen + Winken, Leerlauf + Umsehen) anhand von Überblendungsgewichtungen. Sowohl Three.js (AnimationMixer) als auch Babylon.js (AnimationGroup) unterstützen dies. Die Überblendung erfolgt auf der CPU durch Interpolation der Knochentransformationen, bevor das gemischte Ergebnis an die GPU übertragen wird.

Instanzierte Animation ist der Schlüssel zur effizienten Darstellung vieler Charaktere. Anstatt jeden Charakter als separates Mesh zu zeichnen, werden Animationsframes in eine Textur gebacken (Vertex Animation Texture oder VAT). Jede Zeile der Textur speichert die Knochentransformationen eines Frames. Ein Compute-Shader oder Vertex-Shader liest anhand der Animationszeit des Charakters die richtige Zeile. Dadurch lassen sich Hunderte Charaktere mit einem einzigen instanzierten Draw Call darstellen. The Witcher 3 und Assassin's Creed nutzen dieses Verfahren für die Darstellung großer Menschenmengen.

In WebGPU sehen instanzierte animierte Charaktere folgendermaßen aus:

@vertex
fn vs_main(@builtin(instance_index) instanceIdx: u32, @location(0) position: vec3<f32>) -> @builtin(position) vec4<f32> {
    let animFrame = instances[instanceIdx].animationFrame;
    let boneIdx = vertexBoneIndices[vertexIdx];
    let boneTransform = textureLoad(animTexture, vec2<i32>(i32(boneIdx), i32(animFrame)), 0);
    let worldPos = instances[instanceIdx].transform * boneTransform * vec4<f32>(position, 1.0);
    return viewProjection * worldPos;
}

Wechsle bei entfernten Spielern (mehr als 50 Meter) zu Billboard-Impostors: flachen Quads, die ein vorgerendertes Sprite des Charakters aus dem aktuellen Blickwinkel zeigen. Dies ist derselbe Trick, den Skyrim für entfernte Bäume verwendet, nur auf Charaktere angewandt. Der Übergang ist aus der Entfernung nicht wahrnehmbar.

Inverse Kinematik für Interaktionen

Wenn ein Charakter ein Objekt aufhebt, nach einer Türklinke greift oder auf etwas zeigt, lässt prozedurale IK die Aktion natürlich wirken. FABRIK (Forward And Backward Reaching Inverse Kinematics) ist ein einfacher, schneller IK-Solver, der sich gut für Echtzeitanwendungen eignet. Sowohl Three.js (über CCDIKSolver) als auch Babylon.js (über BoneIKController) bieten integrierte IK-Unterstützung.

Für eine Creator-Welt bedeutet IK, dass Charaktere natürlich mit platzierten Objekten interagieren können: auf von Creatorn platzierten Stühlen sitzen, sich an Geländer lehnen oder Gegenstände aufheben. Die Interaktionen benötigen keine objektspezifischen Animationen. Das IK-System passt die Pose des Charakters an die Position des Objekts an.

Fortgeschrittene Netzwerktechnik

Die grundlegende Architektur (WebSocket + WebRTC) wurde bereits behandelt. Im Folgenden geht es genauer um Protokolle, Komprimierung und neuere Transportoptionen.

Binäre Nachrichtenprotokolle

JSON über WebSocket verschwendet im Vergleich zu binärer Codierung das Zehnfache an Bandbreite. Für eine Echtzeit-Multiplayer-Welt sollte jede Nachricht binär sein.

FlatBuffers (von Google) eignet sich am besten für die Netzwerkkommunikation von Spielen. Anders als Protocol Buffers ermöglicht FlatBuffers den Zugriff auf serialisierte Daten ohne Kopieren. Die Nachricht wird nicht in JavaScript-Objekte dekodiert. Stattdessen werden Felder direkt aus dem Puffer gelesen. Dadurch entfallen die Allokationen und der GC-Druck, die Protocol Buffers in einem häufig ausgeführten Codepfad verursachen würde. FlatBuffers bietet einen Codegenerator für JavaScript/TypeScript.

Eine Aktualisierung der Spielerposition in FlatBuffers:

// Schema: PlayerUpdate { id: uint16, x: float32, y: float32, z: float32, yaw: float16, pitch: float16, animState: uint8 }
// Total: 17 bytes per player update
// vs JSON: {"id":42,"x":103.5,"y":12.3,"z":-47.8,"yaw":1.57,"pitch":0.2,"animState":3} = 80+ bytes

Bei 200 Spielern und 20 Hz beträgt der Unterschied 200 * 17 * 20 = 68 KB/s (binär) gegenüber 200 * 80 * 20 = 320 KB/s (JSON). Binärdaten sind 4,7-mal kleiner und vermeiden zudem durch JSON.parse verursachte Allokationen in der zeitkritischen Schleife.

MessagePack ist einfacher als FlatBuffers (kein Schema, keine Codegenerierung), aber immer noch 30–50 % kleiner als JSON. Es ist ein guter Mittelweg, wenn du Binärdaten ohne Schemaverwaltung verwenden möchtest.

Positionsquantisierung und Delta-Komprimierung

Spielerpositionen benötigen keine 32-Bit-Gleitkommagenauigkeit. Wenn deine Welt 4 km × 4 km groß ist, bietet eine vorzeichenlose 16-Bit-Ganzzahl eine Genauigkeit von 6 cm (4000 m / 65536). Für die meisten Spiele ist das nicht von voller Genauigkeit zu unterscheiden. Dadurch halbiert sich die Größe der Positionsdaten.

Bei der Delta-Komprimierung wird nur die Differenz zum letzten bestätigten Zustand gesendet. Wenn sich ein Spieler seit der letzten Aktualisierung um 0,5 Meter bewegt hat, ist das Delta eine kleine Zahl, die sich gut komprimieren lässt. In Verbindung mit einer Codierung variabler Länge (kleinere Deltas benötigen weniger Bytes) sind typische delta-komprimierte Positionsaktualisierungen statt 12 nur 3–6 Byte groß.

Koppelnavigation reduziert die Aktualisierungsfrequenz. Statt die Position mit 20 Hz zu senden, werden Position und Geschwindigkeit übertragen. Der Client extrapoliert die Position zwischen den Aktualisierungen. Eine Korrektur wird nur gesendet, wenn die tatsächliche Position um mehr als einen festgelegten Schwellenwert von der vorhergesagten Position abweicht. Dadurch lässt sich die für Positionsaktualisierungen benötigte Bandbreite bei Spielern, die sich geradlinig bewegen, um 60–80 % reduzieren – und das trifft auf die meisten Bewegungen zu.

RuneScape verwendet eine extreme Variante davon: Spielerbewegungen basieren auf Feldern, sodass ein Bewegungsbefehl lediglich aus einem Zielfeld besteht. Der Client animiert den Laufweg lokal. Für eine kontinuierliche 3D-Welt würdest du eine geglättete Koppelnavigation verwenden, das Prinzip bleibt jedoch dasselbe.

WebTransport

WebTransport ist ein neueres Protokoll, das sowohl WebSocket als auch WebRTC DataChannel für die Netzwerkkommunikation von Spielen ersetzen könnte. Es läuft über HTTP/3 (QUIC) und bietet:

• Zuverlässige, geordnete Streams (wie WebSocket, aber gemultiplext, sodass eine Verzögerung in einem Stream die anderen nicht blockiert)
• Unzuverlässige Datagramme (wie UDP, für Positionsaktualisierungen, die bei einer Verzögerung sofort veraltet sind)
• Gemultiplexte Streams (separate Streams für Chat, Weltzustand und Positionen, ohne Head-of-Line-Blocking)

Das ist genau das, was die Netzwerkkommunikation von Spielen benötigt. WebSocket bietet eine zuverlässige und geordnete Übertragung, aber Head-of-Line-Blocking beeinträchtigt die Latenz bei Positionsaktualisierungen erheblich. WebRTC DataChannel bietet eine unzuverlässige Übertragung, doch die Einrichtung ist komplex und erfordert ICE/STUN. WebTransport bietet beides über eine einzige Verbindung.

Browserunterstützung: Chrome, Edge und Firefox unterstützen WebTransport bereits seit einiger Zeit, und Safari 26.4 führte es im März 2026 ein. Dadurch erreichte WebTransport den Baseline-Status und funktioniert nun in allen wichtigen Browsern – einschließlich iOS, wo sämtliche Browser WebKit verwenden. Ein WebSocket-Fallback lohnt sich weiterhin für ältere Safari-Versionen, doch WebTransport ist heute breit einsetzbar.

Cloudflare unterstützt WebTransport über Workers, was zu unserer Infrastruktur passt.

Interest Management im großen Maßstab

Die Herausforderung bei der Netzwerkkommunikation mit mehr als 200 Spielern ist nicht die Bandbreite pro Spieler. Es ist das quadratische Wachstum: Wenn jeder Spieler Aktualisierungen an jeden anderen Spieler sendet, führen 200 Spieler zu 200 * 199 = 39.800 Aktualisierungsnachrichten pro Tick. Der Server muss sie filtern.

Area-of-Interest-Management (AOI) bedeutet, dass jeder Spieler nur Aktualisierungen zu Entitäten innerhalb seiner Sichtweite erhält. Die Implementierung verwendet dasselbe räumliche Raster wie das Chunk-System: Wenn die Position eines Spielers dem Chunk (3, 7) zugeordnet ist, erhält er Aktualisierungen aus den Chunks (2-4, 6-8), also aus einer 3×3-Nachbarschaft. Entitäten außerhalb dieses Bereichs werden nicht übertragen.

Prioritätsbasierte Aktualisierungen innerhalb des AOI weisen wichtigen Entitäten mehr Bandbreite zu. Ein Spieler, der auf dich zuläuft, erhält Aktualisierungen mit 20 Hz. Ein Spieler, der 200 Meter entfernt stillsteht, erhält Aktualisierungen mit 2 Hz. Ein NPC, der nichts tut, erhält Aktualisierungen mit 0,5 Hz. Der Server verwaltet für jeden Client eine Prioritätswarteschlange und weist Bandbreite anhand der Relevanz einer Entität zu, etwa nach Entfernung, Geschwindigkeit und Interaktionspotenzial.

Ruhezustand. Entitäten, deren Zustand sich seit N Sekunden nicht geändert hat, wechseln in den Ruhezustand und erzeugen überhaupt keinen Netzwerkverkehr mehr. Der Client behält den letzten bekannten Zustand, bis ein Aktivierungsereignis eintrifft. In einer Creator-Welt, in der die meisten platzierten Objekte statisch sind, beseitigt der Ruhezustand den Großteil des potenziellen Netzwerkverkehrs.

Die variable Tickrate von Slither.io (5 Hz in der Ferne gegenüber 30 Hz in der Nähe) ist eine vereinfachte Variante davon. Die „Zeitdilatation“ von EVE Online ist die Extremform: Wenn sich zu viele Spieler in einem Bereich befinden, verlangsamt der Server die Tickrate des Spiels, um die Konsistenz aufrechtzuerhalten. Für unseren Anwendungsfall bietet prioritätsbasiertes AOI mit Ruhezustand das richtige Gleichgewicht.

Gaussian Splatting und neuere Rendering-Technologien

Traditionelles Mesh-Rendering (Dreiecke und Texturen) ist nicht mehr die einzige Option für 3D im Browser. Mehrere neuere Techniken werden inzwischen praxistauglich.

3D Gaussian Splatting

3D Gaussian Splatting (SIGGRAPH 2023): fotorealistische Szenenrekonstruktion aus Fotografien mit Echtzeit-Rendering im Browser. Creators könnten reale Objekte mit einem Smartphone scannen und direkt in der Welt platzieren.

3D Gaussian Splatting (3DGS) rekonstruiert 3D-Szenen aus Fotografien, indem es die Szene als Millionen farbiger 3D-Gaußfunktionen darstellt – ausgerichtete, farbige Ellipsoide. Der Renderer sortiert und rastert diese Splats anstelle von Dreiecken.

Warum das für eine Creator-Welt wichtig ist:

• Photogrammetrie-Aufnahmen werden trivial. Ein Creator nimmt mit dem Smartphone 50 Fotos eines realen Objekts oder Ortes auf. Die serverseitige Verarbeitung mit Werkzeugen wie Nerfstudio oder gsplat erzeugt innerhalb weniger Minuten eine Gaussian-Splat-Szene. Diese Szene wird im Browser geladen und sieht aus jedem Winkel fotorealistisch aus.
• Das Rendering im Browser ist gelöst. Mehrere Open-Source-Implementierungen rendern Gaussian Splats in WebGL und WebGPU. PlayCanvas bietet integriertes Splat-Rendering. Luma AI stellt einen mit Three.js kompatiblen Viewer bereit. gsplat.js ist eine eigenständige Bibliothek. Die Leistung ist gut: 1–3 Millionen Splats werden auf Desktop-GPUs mit 30–60 fps gerendert.
• Das Datenformat ist kompakt. Eine Gaussian-Splat-Szene eines Raums kann komprimiert 10–30 MB groß sein. Einzelne Objekte benötigen 1–5 MB. Das ist mit texturierten Mesh-Assets vergleichbar.

Der Nachteil: Splat-Szenen sind statisch. Sie lassen sich nicht ohne Weiteres animieren oder verändern. Sie eignen sich gut für Umgebungsdetails – etwa einen fotorealistischen Baum, eine erfasste reale Skulptur oder eine gescannte Gebäudefassade –, aber nicht für interaktive Spielobjekte. Der hybride Ansatz verwendet Splats für Umgebungsdetails und traditionelle Meshes für interaktive Objekte.

Für eine Creator-Welt: Creators sollten reale Objekte anhand von Smartphone-Fotos erfassen, serverseitig in Gaussian Splats umwandeln und in der Welt platzieren können. Das schließt die Lücke zwischen KI-generierten Assets und realen Objekten. Creators könnten eigene Kunstwerke, Möbel oder Architektur scannen und direkt in der gemeinsamen Welt platzieren.

Neural Radiance Fields (NeRFs) zu Meshes

NeRFs stellen Szenen als neuronale Netze dar, die für jeden 3D-Punkt Farbe und Dichte ausgeben. Sie erzeugen aus Fotos eine außergewöhnliche visuelle Qualität, sind beim Rendering jedoch rechenintensiv, da für jedes Pixel in jedem Frame ein vollständiger Vorwärtsdurchlauf durch das neuronale Netz erforderlich ist.

Der praktische Ansatz für Browser: Aus Fotos wird ein NeRF trainiert, aus dem anschließend mithilfe von Marching Cubes auf dem Dichtefeld ein Mesh extrahiert wird. Das Ergebnis ist ein traditionelles Dreiecks-Mesh mit gebackenen Texturen, das jede Browser-Engine rendern kann. Werkzeuge wie Instant-NGP, Nerfstudio und Neuralangelo automatisieren diese Pipeline. Die Qualität ist nicht so hoch wie beim direkten Rendering des NeRFs, dafür ist das Ergebnis mit standardmäßigen Rendering-Pipelines kompatibel.

Dies ist ein weiterer Weg, mit dem Creators reale Objekte ohne Modellierungskenntnisse in eine Browserwelt integrieren können.

Mesh-Shader und Rendering im Nanite-Stil

Das Nanite-System von UE5 rendert Milliarden von Dreiecken mithilfe von Mesh-Shadern, GPU-gesteuertem Rendering und virtueller Geometrie, bei der Dreiecke abhängig von ihrer Bildschirmabdeckung auf Cluster-Ebene gestreamt werden. WebGPU unterstützt noch keine Mesh-Shader, doch das zugrunde liegende Prinzip – GPU-gesteuertes Rendering mit Compute-basiertem Culling und LOD-Auswahl – lässt sich umsetzen.

Ein WebGPU-Compute-Shader kann:

1. Die Bounding-Boxen aller Mesh-Cluster lesen (Gruppen von etwa 64 Dreiecken)
2. Jeden Cluster gegen das Sichtfrustum und den Verdeckungspuffer prüfen
3. Anhand der Größe im Bildschirmraum die passende LOD-Stufe auswählen
4. Sichtbare Cluster in einen indirekten Zeichenpuffer schreiben
5. Alles mit einem einzigen indirekten Draw-Call rendern

Dieser Ansatz der „virtuellen Geometrie“ verarbeitet Millionen von Dreiecken bei konstantem CPU-Aufwand – die CPU übermittelt unabhängig von der Komplexität der Szene nur einen Draw-Call. So wird Browser-Rendering künftig große offene Welten bewältigen. Die Implementierung ist komplex, doch die erforderlichen Bausteine sind bereits heute in WebGPU vorhanden.

Shader-Techniken für stilisierte offene Welten

Eine stilisierte Art-Direction erfordert bestimmte Shader-Techniken. Die folgenden erzielen pro GPU-Zyklus die größte visuelle Wirkung.

Windanimation für Vegetation

Bäume und Gras, die sich im Wind wiegen, lassen eine Welt lebendig wirken. Die Technik ist einfach: Im Vertex-Shader werden Vertexpositionen durch eine Kombination von Sinuswellen versetzt, die von Weltposition und Zeit abhängen.

vec3 windOffset = vec3(
    sin(worldPos.x * 0.5 + time * 2.0) * windStrength,
    0.0,
    cos(worldPos.z * 0.3 + time * 1.5) * windStrength
);
float heightFactor = localPos.y / meshHeight;
finalPos += windOffset * heightFactor * heightFactor;

Der heightFactor sorgt dafür, dass die Basis des Baums fest am Boden bleibt, während sich die Spitze am stärksten wiegt. Durch die Verwendung der Weltposition in der Sinusfunktion bewegen sich benachbarte Bäume in leicht unterschiedlichen Phasen. Dadurch entsteht in einem Wald ein natürlicher Welleneffekt. BotW, Skyrim und praktisch jede offene Welt mit Vegetation verwenden diese Technik.

Für Gras gilt dasselbe Prinzip, allerdings mit höherer Frequenz und kürzerer Wellenlänge. Per GPU instanzierte Grashalme – Tausende schmaler Quads – mit zufälligen Phasenverschiebungen pro Instanz erzeugen mit minimalem Aufwand überzeugende Wiesen. WebGPU-Compute-Shader können die Positionen und Ausrichtungen der Grashalme aus einer Dichtekarte erzeugen, wobei der Wind in jedem Frame in die Instanztransformationen eingerechnet wird.

Toon-/Cel-Shading

Wenn die Art-Direction stilisiert ist – und die Hinweise sprechen dafür –, ist Cel-Shading die zentrale Technik. Die Idee: Die Beleuchtung wird statt in sanften Verläufen in diskrete Stufen quantisiert.

float NdotL = dot(normal, lightDir);
float toonShading = step(0.3, NdotL) * 0.5 + step(0.6, NdotL) * 0.5;
vec3 color = baseColor * (ambient + toonShading);

Dadurch entsteht der klassische Look mit zwei oder drei Farbstufen. Ergänze für einen Comic-Effekt einen Kontur-Pass, indem du Rückseiten leicht vergrößert renderst oder als Nachbearbeitung eine Kantenerkennung im Bildschirmraum verwendest.

Das Shading von BotW ist nuancierter als reines Cel-Shading. Es verwendet einen weichen Verlauf mit einer leichten Stufe an der Schattengrenze sowie eine Verschiebung von warmen zu kühlen Farben: Schatten sind bläulich getönt, beleuchtete Bereiche warm. Dieser hybride Ansatz wirkt natürlicher als striktes Toon-Shading, bleibt aber klar stilisiert. Er lässt sich mit einem benutzerdefinierten Shader in jeder 3D-Engine für Browser umsetzen.

Stilisierter Wasser-Shader

Wasser in einer stilisierten Welt benötigt keine realistische Wellensimulation. Eine Kombination aus scrollenden Normal Maps, Erkennung von Schaum an Kanten und tiefenabhängiger Farbgebung liefert Ergebnisse, die visuell zu einer Art-Direction im Stil von BotW passen.

float depth = texture(depthTexture, screenUV).r - fragDepth;
vec3 shallowColor = vec3(0.2, 0.7, 0.8);
vec3 deepColor = vec3(0.05, 0.15, 0.3);
vec3 waterColor = mix(shallowColor, deepColor, saturate(depth * 2.0));

float foam = step(0.05, depth) * (1.0 - step(0.15, depth));
foam *= texture(foamNoise, worldUV * 3.0 + time * 0.1).r;
waterColor = mix(waterColor, vec3(1.0), foam * 0.8);

Damit erhältst du eine tiefenabhängige Farbgebung – flaches Wasser ist heller – sowie Uferschaum, der durch Rauschen animiert wird. Das Ganze läuft in einem einzigen Fragment-Shader-Pass.

Screen-Space Ambient Occlusion (SSAO)

SSAO verdunkelt Ecken, Spalten und Bereiche, in denen Oberflächen aufeinandertreffen. Es verleiht der Szene Tiefe und lässt Objekte besser verankert wirken, ohne eine teure globale Beleuchtung zu erfordern. Sowohl Three.js als auch Babylon.js bieten integrierte SSAO-Implementierungen.

Für eine stilisierte Welt ist SSAO sogar wichtiger als bei realistischem Rendering, da flaches Shading Kontaktschatten nicht auf natürliche Weise darstellt. Ein leichter SSAO-Pass – halbe Auflösung genügt – ergänzt die fehlenden Tiefenhinweise. Kosten: 1–2 ms auf Desktop-GPUs.

Vertiefte Weltgenerierung

Der grundlegende Artikel behandelte prozedurales Terrain auf einer übergeordneten Ebene. Hier folgen die algorithmischen Details.

Rauschfunktionen für Terrain

Jedes prozedurale Terrain beginnt mit Rauschen. Die Rauschfunktion erzeugt pseudozufällige Werte, die sich räumlich gleichmäßig verändern. Mehrere Oktaven beziehungsweise Frequenzen werden übereinandergelegt, um natürlich wirkende Ergebnisse zu erzielen. Perlin-Rauschen ist der Klassiker. Simplex-Rauschen ist schneller und weist weniger richtungsabhängige Artefakte auf. OpenSimplex 2 ist die moderne Variante mit guter Performance in JavaScript. Für WebGPU-Compute-Shader lässt sich Simplex-Rauschen unkompliziert in WGSL implementieren (es umfasst etwa 50 Zeilen Mathematik).

Fraktale Brownsche Bewegung (fBm) überlagert mehrere Rauschoktaven:

height = 0
amplitude = 1.0
frequency = baseFrequency
for each octave:
    height += amplitude * noise(position * frequency)
    frequency *= lacunarity (typically 2.0)
    amplitude *= persistence (typically 0.5)

Mit 6–8 Oktaven erzeugt fBm ein Terrain mit großflächigen Gebirgsformationen, mittelgroßen Hügeln und feinen Unebenheiten – ähnlich wie echtes Gelände. Der Persistenzparameter steuert, wie zerklüftet das Terrain ist (0,3 erzeugt sanfte, wellige Hügel, 0,7 erzeugt schroffe Berge).

Domain-Warping verwendet die Ausgabe einer Rauschfunktion als Eingabekoordinaten einer anderen. Dadurch entsteht Terrain, das erodiert und organisch aussieht statt gleichmäßig uneben. Nach 2–3 Schichten Domain-Warping wirkt das Terrain zunehmend so, als wäre es durch geologische Prozesse geformt worden.

Simulation hydraulischer Erosion

Unbearbeitetes Rausch-Terrain sieht aus wie zerknülltes Papier. Echtes Terrain sieht aus wie zerknülltes Papier, auf das eine Million Jahre lang Regen gefallen ist. Eine Simulation hydraulischer Erosion verwandelt durch Rauschen erzeugtes Terrain in etwas, das geologisch plausibel aussieht.

Der Algorithmus:

1. Ein Wasserpartikel an einer zufälligen Position auf der Höhenkarte absetzen
2. Das Partikel fließt bergab (entlang des Geländegradienten)
3. Bei jedem Schritt nimmt es abhängig von Geschwindigkeit und Gefälle Sediment vom Terrain auf
4. Wenn das Partikel langsamer wird (flacheres Terrain, Wasseransammlung), lagert es Sediment ab
5. Dies für 100.000–500.000 Partikel wiederholen

Das Ergebnis ist Terrain mit Flusstälern, Schwemmfächern, natürlich wirkenden Bergkämmen und sanften Hängen mit logischen Übergängen. Der Algorithmus läuft auf einer 1024x1024-Höhenkarte in JavaScript in etwa 2–5 Sekunden oder in einem WebGPU-Compute-Shader in weniger als 100ms.

Die Implementierung von Sebastian Lague (auf GitHub verfügbar) gilt unter Spieleentwicklern als Standardreferenz. Sie erzeugt Terrain, das mit handmodellierten Ergebnissen mithalten kann. Für eine Creator-Welt würde die Erosion von KI-generiertem Terrain während der serverseitigen Verarbeitung prozedural erzeugte Landschaften wie handgefertigt aussehen lassen.

Zuweisung von Biomen

Reale Welten haben Biome: Wälder, Wüsten, Tundren und Sumpfgebiete. Bei der Zuweisung von Biomen werden Klimaparameter bestimmten Terrainregionen zugeordnet.

Der Ansatz von Minecraft ist aufschlussreich: Biome werden in einem 2D-Raster anhand der Achsen Temperatur und Luftfeuchtigkeit definiert. Die Temperatur nimmt mit Höhe und Breitengrad ab. Die Luftfeuchtigkeit variiert je nach Nähe zu Gewässern und vorherrschender Windrichtung. Jede Rasterzelle erhält ein Biom (Wald, Wüste, Tundra usw.), das Terraintexturen, Art und Dichte der Vegetation, Umgebungsgeräusche und Wettermuster bestimmt.

In einer Creator-Welt sollten sich Biomgrenzen aufmalen lassen. Das System erzeugt anhand der Terraineigenschaften Standardbiome, Creator können diese Zuweisung jedoch überschreiben, indem sie Biomzonen auf ihre eigenen Parzellen malen. Dieser hybride Ansatz verleiht der Welt ein natürlich wirkendes Standardbild und ermöglicht es Creatorn zugleich, ihre eigene Vision umzusetzen.

Wave Function Collapse für Strukturen

Wave Function Collapse (WFC) erzeugt Strukturen wie Gebäude, Dungeons und Straßen aus einem Satz von Kacheln mit Nachbarschaftsregeln. Ausgehend von modularen Bauteilen und Regeln, welche Teile miteinander verbunden werden dürfen, kann WFC ganze Dörfer, Burggrundrisse oder Dungeonkarten erzeugen.

Für eine Creator-Welt ermöglicht WFC:

• Automatisch erzeugte Dörfer, die die Welt mit grundlegenden Inhalten füllen, bevor Creator sie anpassen
• Unterstütztes Bauen, bei dem ein Creator einige Teile platziert und WFC die Lücken füllt (wie Townscaper, aber mit 3D-Bausteinen)
• Dungeon-Generierung für interaktive Erlebnisse, die Creator konfigurieren können (Thema, Schwierigkeitsgrad und Größe festlegen, woraufhin WFC das Layout erzeugt)

Oskar Stalberg (Creator von Townscaper und Bad North) hat gezeigt, dass sich WFC-basierte Generierung für Benutzer magisch anfühlt. Sie platzieren einige Blöcke, und das System erzeugt darum herum ästhetisch stimmige Strukturen. Das entspricht genau dem Prinzip „einfache Werkzeuge, vielseitige Ergebnisse“, das auf Creator-Plattformen erfolgreich ist.

Architektur der Inhaltsmoderation

In einer Welt, in der Creator beliebige 3D-Inhalte platzieren können, die andere sehen, ist Moderation nicht optional. Sie ist ein zentraler Bestandteil der Infrastruktur.

Automatisierte Prüfungspipeline

Jedes Asset, das in die Welt gelangt, durchläuft eine mehrstufige Pipeline, bevor es für andere Spieler sichtbar wird:

1. Geometrieanalyse. Das Mesh wird mithilfe eines trainierten Klassifikators auf anatomisch explizite Formen untersucht. Dadurch wird der Großteil offensichtlich unangemessener 3D-Modelle erkannt. Mehrere kommerzielle APIs (Azure Content Safety, Google Cloud Vision für 3D) übernehmen diese Aufgabe. Der Klassifikator analysiert die Silhouette des Meshes aus mehreren Blickwinkeln, was nur wenig Rechenleistung erfordert.

2. Texturanalyse. Jede Textur wird durch eine gängige API zur Inhaltsmoderation von Bildern verarbeitet (dieselben APIs, die für hochgeladene Fotos verwendet werden). Dadurch werden unangemessene Bilder erkannt, die als Texturen auf ansonsten harmloser Geometrie liegen.

3. Texterkennung. Enthält das Objekt Text (entweder in einer Textur oder als 3D-Text-Mesh), wird dieser per OCR erfasst und anhand der Inhaltsrichtlinien geprüft. Dadurch werden Hassrede, Beleidigungen und andere textbasierte Verstöße erkannt.

4. Automatisierte Freigabe. Wenn alle Prüfungen bestanden werden, wird das Asset sofort sichtbar. Wird das Asset bei einer Prüfung markiert, gelangt es in eine Prüfwarteschlange.

5. Menschliche Prüfung. Markierte Assets werden von einem Moderator geprüft. Bei einer kleinen Plattform kann dies das Team übernehmen. Für größere Maßstäbe lassen sich externe Moderationsdienste beauftragen (dieselben, die Inhalte in sozialen Medien moderieren).

Räumliche Moderation

Neben einzelnen Assets kann auch die räumliche Anordnung von Objekten unangemessen sein, selbst wenn jedes Objekt für sich unbedenklich ist. Dies lässt sich schwieriger automatisch erkennen. Der praktikable Ansatz:

• Meldungen durch Spieler. Jeder Spieler kann einen Ort melden. Die Meldung enthält einen Screenshot (der automatisch an den gemeldeten Koordinaten aufgenommen wird) und das Konto des meldenden Spielers. Meldungen lösen eine menschliche Prüfung aus.
• Heatmaps. Es wird erfasst, in welchen Bereichen Meldungen auftreten. Erzeugt die Parzelle eines Creators regelmäßig Meldungen, wird sie zur Prüfung eskaliert. Verstößt ein Creator wiederholt gegen die Regeln, werden seine Bearbeitungsrechte eingeschränkt.
• Parzellenbewertungen. Wie in Second Life können Creator ihre Parzellen selbst einstufen. In der Standardansicht werden Parzellen ausgeblendet, deren Bewertung über „Allgemein“ liegt. Spieler müssen der Anzeige nicht jugendfreier Inhalte ausdrücklich zustimmen. Das verhindert zwar keine Verstöße, verringert aber die Sichtbarkeit.

Überlegungen zur Latenz

Wenn die automatisierte Prüfung pro Asset 5–10 Sekunden dauert, entsteht eine merkliche Verzögerung zwischen dem Platzieren eines Objekts durch einen Creator und seiner Anzeige für andere Spieler. Mögliche Lösungen:

• Optimistische lokale Anzeige. Der Creator sieht seine Platzierung sofort. Andere Spieler sehen sie nach der Freigabe. Wird das Asset abgelehnt, verschwindet es und der Creator wird benachrichtigt.
• Vorab freigegebene Asset-Bibliothek. Die meisten Platzierungen verwenden vorab geprüfte Assets aus der Bibliothek der Plattform (einschließlich KI-generierter Assets, die bereits bei ihrer Erzeugung geprüft wurden). Benutzerdefinierte Uploads durchlaufen die Prüfung. Dadurch erscheinen die meisten Platzierungen sofort.
• Reputationsbasierte Schnellfreigabe. Creator, deren Inhalte in der Vergangenheit freigegeben wurden, erhalten eine automatische Freigabe für neue Platzierungen. Neue oder bereits auffällig gewordene Creator durchlaufen die vollständige Prüfung.

Browser-3D-Performance: Reale Zahlen

Theoretische Budgets sind nützlich. Tatsächlich gemessene Performance ist noch nützlicher. Hier sind reale Zahlen aus Browser-3D-Szenen auf handelsüblicher Hardware.

Rendering-Benchmarks

Three.js-Szene mit 10.000 instanziierten Objekten (Bäume, Felsen, jeweils 500 Dreiecke):

• MacBook Pro M1 (Chrome, WebGL2): 58-60fps
• RTX-3060-Desktop-PC (Chrome, WebGL2): stabile 60fps
• Laptop mit Intel UHD 620 (Chrome, WebGL2): 25-35fps
• iPhone 13 (Safari, WebGL2): 30-40fps

Three.js-Szene mit 100.000 instanziierten Grashalmen (jeweils 6 Dreiecke, insgesamt 600K Dreiecke):

• M1 MacBook: 55fps
• RTX 3060: 60fps
• Intel UHD 620: 12fps
• iPhone 13: 15fps

Babylon.js-Terrain mit 1M Dreiecken, 4 LOD-Stufen und Havok-Physik:

• M1 MacBook (WebGPU): 60fps
• M1 MacBook (WebGL2): 45fps
• RTX 3060 (WebGPU): 60fps
• RTX 3060 (WebGL2): 55fps

Gaussian-Splat-Szene mit 2M Splats (über gsplat.js):

• M1 MacBook (WebGL2): 30fps
• RTX 3060 (WebGL2): 45fps
• RTX 3060 (WebGPU): 60fps

Speichermessungen

Minimale Three.js-Szene (Skybox, Terrain, 100 Objekte): 80-120 MB GPU-Speicher, 150-200 MB JS-Heap Babylon.js mit Havok-Physik: 200-300 MB GPU-Speicher, 250-350 MB JS-Heap (Havok Wasm benötigt zusätzlich etwa 50 MB) Speicherlimits von Browser-Tabs (gemessen, nicht dokumentiert):

• Chrome Desktop: stürzt üblicherweise bei etwa 4 GB ab
• Chrome Android: stürzt üblicherweise bei etwa 1-1.5 GB ab
• Safari iOS: stürzt üblicherweise bei etwa 1 GB ab
• Firefox Desktop: stürzt üblicherweise bei etwa 3-4 GB ab

Netzwerkmessungen

WebSocket-Roundtrip-Latenz (Browser zum Cloudflare-Edge):

• Auf demselben Kontinent: 10-30ms
• Kontinentübergreifend: 80-200ms
• Mit Cloudflare Durable Objects: zusätzlich 5-10ms für das Aufwecken des DO bei der ersten Anfrage

WebRTC-DataChannel-Latenz (Browser zu Browser über TURN):

• In derselben Stadt: 5-15ms
• Auf demselben Kontinent: 20-50ms
• Kontinentübergreifend: 100-250ms

Die Latenz von WebTransport (HTTP/3 QUIC) ist mit WebSocket vergleichbar, jedoch ohne Head-of-Line-Blocking. Dadurch ist die P99-Latenz deutlich besser (keine Unterbrechungen durch ein einzelnes verlorenes Paket).

Ladezeitmessungen

Leere Three.js-Szene (nur die Bibliothek): 350ms bis zum ersten Frame Leere Babylon.js-Szene: 500ms bis zum ersten Frame 1-MB-GLB-Modell über Abruf und Parsing: 200-400ms über Breitband KTX2-Textur, 1024x1024, Basis Universal: 50-100ms zum Dekodieren auf der GPU Draco-komprimiertes Mesh mit 50K Dreiecken: 30-80ms zum Dekodieren in einem Web Worker

Diese Zahlen bestätigen, dass das Performance-Budget aus dem Architekturabschnitt erreichbar ist. Ein Desktop-PC der Mittelklasse kann eine komplexe Open-World-Szene mit 60fps rendern. Mobilgeräte sind der begrenzende Faktor: Um auf Smartphones 30fps aufrechtzuerhalten, wären aggressive LOD-Einstellungen und eine kürzere Sichtweite erforderlich.

Der vollständige Stack

Zusammengeführt ergibt sich daraus die folgende Architektur für eine browserbasierte offene Multiplayer-Creator-Welt:

Client (Browser)

Ebene	Technologie	Aufgabe
Renderer	Babylon.js (WebGPU + WebGL2-Fallback)	Szenenrendering, Terrain, LOD, Nachbearbeitung
Terrain	Benutzerdefiniertes Höhenkartensystem + Babylon DynamicTerrain	Chunkbasiertes Streaming-Terrain mit Splatting
Physik	Rapier (Wasm) oder Havok (über Babylon)	Charaktersteuerung, Kollisionen, Raycasting
ECS	bitECS	Entitätsverwaltung für alle Weltobjekte
Netzwerk	WebSocket + WebRTC DataChannel	Zustandssynchronisierung, Positionsaktualisierungen, Sprachchat
Zustand	Yjs (CRDT)	Gemeinsame Weltbearbeitung, Konfliktlösung
Audio	Web Audio API	Räumliches Audio, Atmosphäre, Musik
UI	HTML/CSS-Overlay	HUD, Inventar, Chat, Creator-Werkzeuge
Worker	Web Workers	Asset-Dekomprimierung, Physik, Terrain-Generierung

Server

Ebene	Technologie	Aufgabe
Welt-Shards	Cloudflare Durable Objects	Autoritativer Zustand pro Chunk, WebSocket-Endpunkte
Asset-Speicher	Cloudflare R2	GLB-Modelle, KTX2-Texturen, Höhenkarten, Audio
Asset-CDN	Cloudflare CDN (öffentlicher R2-Bucket)	Edge-gecachte Bereitstellung von Welt-Assets
KI-Generierung	GPU-Instanzen (Hetzner/Lambda/RunPod)	Generierung von 3D-Modellen, Terrain und Texturen
Asset-Pipeline	Cloudflare Queue + Workers	LOD-Generierung, Mesh-Optimierung, Formatkonvertierung
Authentifizierung	Auth0	Creator-Identität, Berechtigungen
Datenbank	Cloudflare D1	Weltmetadaten, Creator-Inventare, Berechtigungen
Echtzeit	Cloudflare Durable Objects + Pub/Sub	Spielerpräsenz, Chat, Ereignisübertragung

Datenfluss

1. Der Spieler öffnet die Welt in seinem Browser
2. Der Client authentifiziert sich und verbindet sich mit dem nächstgelegenen Durable Object für den Spawn-Chunk
3. Das DO sendet den aktuellen Chunkzustand (Terrain + Objekte + Spieler in der Nähe)
4. Der Client beginnt mit dem Rendering und fordert benachbarte Chunks von R2/CDN an
5. Während sich der Spieler bewegt, verbindet sich der Client mit benachbarten DOs und trennt die Verbindung zu weiter entfernten
6. Ein Creator platziert ein Objekt: Der Client sendet die Bearbeitung an das DO, das DO validiert sie und überträgt sie als CRDT-Delta an alle verbundenen Clients
7. Das DO speichert den Chunkzustand nach jeder Bearbeitung dauerhaft (entprellt)
8. Andere Spieler sehen das neue Objekt innerhalb von 100-200ms erscheinen

Performance-Budget

Für ein Erlebnis mit 60fps auf einem Desktop-PC der Mittelklasse (RTX 3060 / M1 Mac / 16GB RAM):

Ressource	Budget	Hinweise
Draw Calls	< 500 pro Frame	Batching, Instancing, LOD
Dreiecke	< 2M pro Frame	LOD hält den Wert unter Kontrolle
Texturspeicher	< 512 MB	KTX2-Komprimierung, Streaming, Atlas-Pooling
Geometriespeicher	< 256 MB	Gemeinsam genutzte Puffer, Pooling, aggressives Entladen
JavaScript-Heap	< 512 MB	ECS verwendet typisierte Arrays statt Objekten
Netzwerk	< 500 KB/s dauerhaft	Delta-Komprimierung, Filterung nach räumlicher Relevanz
Erstmaliges Laden	< 10 MB, < 5 Sekunden	Progressives Laden, Terrain zuerst
Chunk-Ladevorgang	< 200 KB, < 200ms	Benachbarte Chunks vorab abrufen

Erfolgreiche Browserspiele und was sie beweisen

Browserspiele sind keine Nische. Sie gehören zu den größten Spielemärkten. Poki erreicht monatlich mehr als 100 Millionen Spieler. CrazyGames, Newgrounds und itch.io erreichen weitere Millionen. Die im Browser erfolgreichen Spiele nutzen bestimmte Architekturmuster, deren Untersuchung sich lohnt.

Browserbasierte 3D-Spiele, die heute verfügbar sind

Hordes.io: Über 200 Spieler in einem persistenten 3D-Browser-MMO. Eigenes WebGL, Low-Poly-Stil, lädt in weniger als 5 Sekunden. Von einem einzelnen Entwickler entwickelt.

**Hordes.io** ist das relevanteste Browser-MMO. Es wurde von einem einzelnen Entwickler mit einem eigenen WebGL-Renderer entwickelt und versetzt über 200 Spieler in eine persistente 3D-Welt mit Echtzeitkämpfen, Gilden, Klassen und PvP. Das gesamte Spiel lädt in weniger als 5 Sekunden. Die Welt ist in Zonen mit aggressivem Culling unterteilt. Die Spielermodelle sind einfach gehalten (Low-Poly mit Flat Shading), doch Partikeleffekte und Animationen sorgen dafür, dass sich die Kämpfe reaktionsschnell anfühlen. Hordes.io beweist drei Dinge: Browser-MMOs können Hunderte gleichzeitiger Spieler in einer Szene bewältigen, ein einzelner Entwickler kann ein solches Spiel erschaffen und stilisierte Grafik läuft im Browser besser als realistische.

Krunker.io: 10 Mio. monatliche Spieler, entwickelt mit Three.js, mit einem vollständigen Karteneditor im Browser und einem Marktplatz für nutzergenerierte Inhalte.

Krunker.io erreichte in Spitzenzeiten über 10 Millionen monatliche Spieler und wurde von FRVR übernommen. Es ist ein browserbasierter FPS mit einem vollständigen Karteneditor, benutzerdefinierten Spielmodi, nutzergenerierten Inhalten und einem Marktplatz. Das mit Three.js entwickelte Spiel läuft selbst auf leistungsschwacher Hardware mit über 60 FPS, was seinem blockartigen Grafikstil und der aggressiven Optimierung zu verdanken ist. Besonders relevant ist der Level-Editor. Spieler bauen Karten mit einem voxelartigen Blocksystem, teilen sie auf dem Marktplatz und andere spielen darauf. Das ist der Kreislauf einer Creator-Welt im Kleinformat: etwas bauen, es teilen und andere es erleben lassen. Krunker hat bewiesen, dass nutzergenerierte 3D-Inhalte im Browser funktionieren können, wenn die Erstellungswerkzeuge einfach genug sind.

ev.io ist ein mit Babylon.js entwickelter Browser-FPS. Er läuft auf der meisten Hardware gut, unterstützt benutzerdefinierte Karten und zeigt, dass der WebGL-Renderer von Babylon schnelle 3D-Action in einem Browser-Tab bewältigen kann. Das Spiel setzt auf aggressive Texturkomprimierung und Low-Poly-Umgebungen, um das Performance-Budget einzuhalten.

Shell Shockers (über 5 Millionen monatliche Spieler) ist ein 3D-Multiplayer-Shooter, in dem man als Ei spielt. Das mit Three.js entwickelte Spiel bewältigt Echtzeit-Multiplayer mit reaktionsschneller Treffererkennung im Browser. Der cartoonartige Grafikstil hält die Asset-Anforderungen gering und wirkt dennoch ausgereift.

Townscaper: Gebäude per Klick platzieren, während das System automatisch Straßen, Bögen und Treppen erzeugt. Keine Menüs, keine Ziele. Über 1 Million verkaufte Exemplare allein dank kreativer Spielfreude.

Townscaper ist kein Browser-Spiel, doch sein Ansatz beim Weltenbau ist äußerst relevant. Spieler klicken, um Gebäude auf einer Wasserfläche zu platzieren. Das Spiel erzeugt anhand der Platzierungsmuster automatisch architektonische Details, Straßen, Bögen und Treppen. Keine Menüs, keine Einstellungen, keine Ziele. Einfach klicken und bauen. Es wurde über 1 Million Mal verkauft. Die Erkenntnis: Manchmal bringen die einfachsten Kreativwerkzeuge die fesselndsten Erlebnisse hervor. Wenn wir das Platzieren von Objekten in der Welt so unmittelbar gestalten können wie in Townscaper, werden Creator stundenlang bauen.

A-Frame-/8th-Wall-Erlebnisse. A-Frame (auf Three.js aufgebaut) bildet die Grundlage für Tausende webbasierte 3D-Erlebnisse. 8th Wall, die langjährig betriebene und von Niantic übernommene WebAR-Plattform, zeigte, dass komplexe kamerabasierte AR ohne Plug-ins in mobilen Browsern läuft. Niantic kündigte allerdings Ende 2025 an, den Dienst einzustellen; gehostete Erlebnisse bleiben noch bis 2027 verfügbar. Dabei handelt es sich nicht um Spiele, doch sie zeigen, dass komplexes 3D-Rendering mit Physik und Interaktion ohne Plug-ins in einem Browser-Tab funktioniert. Viele dieser Erlebnisse laden in 2–3 Sekunden und laufen auf Mittelklasse-Smartphones.

Vuntra City: Ein aktives Labor für prozedurale Städte

Vuntra City ist ein natives UE5-Projekt und kein Browser-Spiel, daher stellt es keinen direkten Performance-Benchmark für unseren Stack dar. Dennoch ist es eine der nützlichsten öffentlich verfügbaren Fallstudien für unsere Open-World-Architektur, weil die Devlogs ungewöhnlich konkrete Einblicke in Abwägungen beim Systemdesign unter realem Produktionsdruck geben.

Eine wichtige Erkenntnis ist eine geschwindigkeitsabhängige Detailstrategie. In den Videos zu Transport und Optimierung wird die Fortbewegung bei hoher Geschwindigkeit über die Dächer verlagert. Gleichzeitig sinkt der Detailgrad der Welt mit steigender Geschwindigkeit, damit der Stream-Manager nicht durch das ständige Laden und Entladen von Innenräumen überlastet wird (schneller Transport, Optimierungstechniken). Das lässt sich direkt auf unseren Browser-Plan übertragen, bei dem die Geschwindigkeit unmittelbar den Prefetch-Radius, den Aktivierungsbereich für Innenräume und das Spawn-Budget pro Frame steuern sollte.

Eine weitere Erkenntnis ist die strikte Trennung zwischen Topologiedaten und gerenderten Objekten. Die Implementierung von Karten und Adressen verwendet einen globalen Topologie-Controller, der Orts- und Adressabfragen auch für nicht geladene Regionen beantworten kann (Karten und Adressen). Genau dieses Muster benötigen wir für serverautoritatives Routing, POI-Suchen und weltweite Abfragen, die nicht davon abhängen sollten, was ein einzelner Client gerade im Speicher hält.

Auch die Arbeit an den NPCs ist höchst relevant. Das System für eine Million NPCs berechnet den groben Zeitplanstatus global und simuliert kostspieliges Verhalten nur in der Nähe von Spielern (eine Million persistente NPCs, Blick hinter die Kulissen). Für uns bestätigt das ein zweistufiges Simulationsmodell: kostengünstiger deterministischer Zustand im Fernbereich und komplexes Verhalten im Nahbereich innerhalb des AOI.

Schließlich unterstreicht die Umgebungsgestaltung von Vuntra City etwas, das bei der technischen Planung leicht vergessen wird: Verteilungsdesign ist Inhaltsdesign. Das Projekt vermeidet gleichmäßige zufällige Platzierung, setzt gewichtete Ausreißer für Überraschungsmomente ein und fördert die Erkundung durch diegetische Karten und Adressen statt durch allgegenwärtige Minikarten-Markierungen (prozedurale Umgebungen müssen nicht langweilig sein, wo wir hingehen, brauchen wir keine Minikarte).

Browser-Spiele mit riesigem Erfolg

Agar.io (2015) bewies, dass Browser-Multiplayer Millionen Menschen erreichen kann. Auf seinem Höhepunkt hatte es serverübergreifend mehr als 100.000 gleichzeitige Spieler. Das Spiel ist zweidimensional und mechanisch einfach – man wächst, indem man kleinere Zellen absorbiert –, doch die Netzwerkarchitektur bewältigt dank räumlicher Partitionierung enorme Spielerzahlen. Jeder Server betreibt eine Region der Spielwelt. Spieler erhalten nur Aktualisierungen zu Entitäten in ihrem Sichtbereich. Das ist dasselbe Interest-Management-Muster, das eine offene 3D-Welt benötigt, nur in 2D.

Slither.io baute auf dem Erfolg von Agar.io auf und bewies die Skalierbarkeit des Modells. Auf seinem Höhepunkt hatte es 67 Millionen monatlich aktive Nutzer. Das Spiel verwendet WebSocket für die Echtzeitsynchronisierung von Positionen und räumliche Partitionierung zur Begrenzung des Netzwerkverkehrs. Ein bemerkenswertes Detail: Die serverseitige Kollisionserkennung von Slither.io läuft für weit entfernte Spieler mit einer niedrigeren Tickrate (5 Hz) als für Spieler in der Nähe (30 Hz). Diese entfernungsabhängige variable Tickrate lässt sich auf eine offene 3D-Welt übertragen.

Surviv.io war ein browserbasiertes Battle Royale, das vor der Übernahme durch Kongregate 50 Millionen monatliche Spieler erreichte. Es führte vollständige Battle-Royale-Partien mit 80 Spielern komplett im Browser aus – mit vernetzter Echtzeitphysik, zerstörbaren Umgebungen und aufsammelbaren Gegenständen. Die Karte wurde prozedural aus vorgefertigten Gebäudevorlagen angeordnet, ein Muster, das wir für von Creatorn platzierte Strukturen nutzen könnten.

Zombs Royale bot ein Battle Royale mit 100 Spielern im Browser, kurzen Ladezeiten und reaktionsschneller Netzwerkkommunikation. Wie Surviv.io bewies es, dass hohe Spielerzahlen in Echtzeit-Browser-Spielen nicht nur technisch möglich, sondern auch kommerziell tragfähig sind.

Die Gemeinsamkeit all dieser Browser-Hits: Sie laden schnell (in weniger als 5 Sekunden), funktionieren auf jedem Gerät, haben einen einfachen, aber konsistenten Grafikstil und verwenden eine auf das jeweilige Gameplay zugeschnittene Netzwerkoptimierung – räumliche Partitionierung, variable Aktualisierungsraten und aggressives Culling weit entfernter Zustände.

RuneScape: Ein MMO, das in den Browser wechselte

RuneScape: ein vollständiges MMO mit Inhalten aus über 20 Jahren, das in einem Browser-Tab läuft. Benutzerdefiniertes Binärprotokoll, kachelbasiertes Streaming und 2.000 gleichzeitige Spieler pro Server. Der Beweis, dass Browser-MMOs in großem Maßstab funktionieren.

RuneScape ist die wichtigste Fallstudie für eine browserbasierte offene Welt, weil genau das tatsächlich umgesetzt wurde. Jagex brachte ein vollständiges MMO mit Inhalten aus 20 Jahren in den Browser.

RuneScape lief ursprünglich als Java-Applet. Als Browser die Java-Unterstützung einstellten, entwickelte Jagex den Client in C++ neu und veröffentlichte außerdem einen voll funktionsfähigen HTML5-/WebGL-Client. Old School RuneScape, die Retro-Version, läuft heute vollständig im Browser über einen Client, der mit Emscripten zu WebAssembly kompiliert wurde. Das Spiel bewältigt große persistente Welten, Echtzeit-Multiplayer mit Hunderten Spielern pro Server, eine Wirtschaft mit einer funktionierenden Großen Markthalle (Auktionshaus) und 23 Fertigkeiten mit tiefgreifenden Fortschrittssystemen.

Wichtige technische Details:

• Die Welt ist in Kartenquadrate unterteilt (Regionen mit 64 × 64 Kacheln). Der Client lädt ein Raster aus 13 × 13 Regionen rund um den Spieler (104 × 104 sichtbare Kacheln). Regionen außerhalb dieses Rasters werden vollständig ausgeblendet.
• Das Terrain basiert auf Kacheln mit Höhenwerten für jede Kachelecke. Terrain-Overlays wie Wege, Wasserränder und Strandübergänge verwenden ein Formensystem mit 12 Rotationsvarianten pro Form. Das ist stärker eingeschränkt als eine Höhenkarte, aber äußerst kompakt und schnell zu streamen.
• Das Netzwerkprotokoll ist ein benutzerdefiniertes Binärprotokoll über WebSocket. Jeder Pakettyp hat eine festgelegte Struktur. Aktualisierungen der Spielerposition verwenden 2 Byte für die Koordinaten des Kartenquadrats und eine Kodierung variabler Länge für die Bewegungsart. Chat-, Handels- und Kampfereignisse haben eigene kompakte Binärformate. Das gesamte Protokoll ist stark auf minimale Bandbreite optimiert.
• Das Rendering von Objekten verwendet ein Modellsystem, bei dem der Server eine Modell-ID sendet und der Client das zwischengespeicherte Modell rendert. Die meisten Modelle werden einmal geladen und wiederverwendet. Dadurch wird die Welt als Metadaten gestreamt – welches Modell an welcher Stelle steht – statt als Geometrie.
• Jede Serverinstanz bewältigt 2.000 gleichzeitige Spieler in der gesamten Spielwelt. Die Welt ist nicht räumlich in Shards unterteilt. Ein einzelner Serverprozess verwaltet alle Spieler, alle NPCs und die gesamte Spiellogik mit einem Spieltick von 600 ms. Das funktioniert, weil die Spiellogik pro Tick einfach ist: Spieleraktionen verarbeiten, NPC-KI aktualisieren, Kämpfe abwickeln und Zustandsänderungen übertragen.

Was RuneScape für unseren Anwendungsfall beweist: Ein vollständiges MMO mit persistentem Weltzustand, Tausenden Spielern, komplexen Spielsystemen und einer echten Wirtschaft kann in einem Browser-Tab laufen. Der Client umfasst weniger als 50 MB Downloadvolumen, lädt in wenigen Sekunden und läuft auf Laptops. Wenn ein 20 Jahre altes Java-MMO diesen Übergang schaffen kann, unterliegt eine gezielt für den Browser entwickelte Welt noch weniger Einschränkungen.

Wo der Ansatz von RuneScape nicht passt: RuneScape verwendet eine isometrische beziehungsweise feste Kamera und keine 3D-Perspektive aus der ersten oder dritten Person. Die visuelle Qualität ist nach heutigen Maßstäben gering. Außerdem kann die Welt nicht von Creatorn bearbeitet werden. Die Netzwerkarchitektur, das kachelbasierte Streaming und der Beweis, dass Browser-MMOs Spieler über Jahrzehnte binden können, sind jedoch unmittelbar relevant.

Habbo Hotel: Soziale Räume mit 25 Jahren Bestand

Habbo Hotel erschien im Jahr 2000 und ist noch immer in Betrieb. Es ist eine isometrische 2D-Sozialwelt, in der Nutzer Räume erstellen und dekorieren, die Räume anderer besuchen und Kontakte pflegen. Auf seinem Höhepunkt hatte es 9 Millionen monatliche Nutzer. Das gesamte Erlebnis lief in Flash und verwendet seit der Einstellung von Flash HTML5.

Habbo ist deshalb wichtig, weil es über einen so langen Zeitraum eine Creator-Community erhalten hat. Das Raumsystem ist im Grunde eine 2D-Version dessen, was wir entwickeln: Nutzer platzieren Möbelobjekte in einem Raster, gestalten das Layout und laden andere zu einem Besuch ein. Das Wirtschaftsmodell – Nutzer kaufen virtuelle Möbel mit echtem Geld – hat über die gesamte Laufzeit mehr als 1 Milliarde US-Dollar Umsatz erzielt.

Was wir von Habbo lernen können:

• Raumbasierte Bereiche mit nutzergestalteten Innenräumen können jahrzehntelang als soziale Plattform funktionieren, wenn die Erstellungswerkzeuge einfach und die sozialen Funktionen stark sind.
• Eine Wirtschaft rund um virtuelle Möbel fördert langfristiges Engagement. Nutzer kaufen, handeln und sammeln Gegenstände. Die Gegenstände haben keinen spielerischen Nutzen. Sie dienen ausschließlich dem Selbstausdruck und Status.
• Die Moderation sozialer Räume erfordert kontinuierliche Investitionen. Habbo hat mehrere Moderationskrisen durchlaufen. Automatisierte Inhaltsfilterung in Kombination mit menschlichen Moderatoren und Meldungen aus der Community ist der minimal tragfähige Ansatz.
• Der Wechsel von Flash zu HTML5, der etwa 2020–2021 abgeschlossen wurde, bewies, dass eine große Sozialwelt ihre Rendering-Technologie migrieren kann, ohne ihre Community zu verlieren. Den Nutzern sind ihre Räume und Freunde wichtig, nicht die zugrunde liegende Technik.

Among Us und räumliche Social Games

Among Us ist keine offene Welt, doch sein Erfolg offenbarte etwas Wichtiges über Multiplayer-Räume: Spieler möchten gemeinsam an einem Ort sein und nicht nur gemeinsam an einem Spiel teilnehmen. Die viral gewordenen Mods für räumlich begrenzten Näherungs-Voice-Chat zeigten, dass der Aufenthalt im selben virtuellen Raum mit richtungsabhängigem Audio Multiplayer von einer Spielmechanik in ein soziales Erlebnis verwandelt. Räumliche soziale Funktionen, die eine Creator-Welt bereichern:

• Räumlicher Sprachchat, bei dem die Lautstärke mit zunehmender Entfernung abnimmt. Gehe auf jemanden zu, um mit der Person zu sprechen. Entferne dich, und ihre Stimme wird leiser. So entstehen auf natürliche Weise soziale Gruppen, ohne dass Sprachkanäle verwaltet werden müssen.
• Emote- und Gestensysteme ermöglichen es Spielern, sich ohne Sprache auszudrücken. Ein Winken, ein Tanz, eine Zeigegeste. Sie sind kostengünstig umzusetzen (Animationen des Spieleravatars) und steigern die soziale Interaktion überproportional.
• Gemeinsame Aktivitäten, die innerhalb der Welt stattfinden (statt über Menüs), machen einen Raum zu einem Treffpunkt. Wenn zwei Kreative an einem virtuellen Tisch sitzen und gemeinsam 3D-Modelle betrachten können, hat die Welt einen Zweck, der über das Anzeigen statischer Inhalte hinausgeht.

Browsergames, die auf Poki und CrazyGames erfolgreich skaliert haben

Poki und CrazyGames erreichen zusammen mehr als 150 Millionen Spieler pro Monat. Die Spiele, die auf diesen Plattformen am besten abschneiden, liefern Erkenntnisse darüber, was speziell im Browser funktioniert.

Erfolgsmuster führender Spiele auf Browsergame-Portalen:

• Sofort spielbar (in weniger als 3 Sekunden interaktiv). Keine Anmeldung erforderlich. Kein Tutorial erforderlich. Das Spiel sollte innerhalb von 5 Sekunden nach dem Aufrufen verständlich sein.
• Flexible Sitzungsdauer. Spieler kommen für 2 Minuten oder 2 Stunden vorbei. Das Spiel ist auf beides ausgelegt. Für eine Creator-Welt bedeutet das, dass die Welt ohne Verpflichtung zu einer längeren Sitzung erkundet werden können sollte. Herumlaufen, interessante Dinge ansehen, wieder gehen. Oder bleiben und stundenlang bauen.
• Mobile Kompatibilität. Mehr als 60 % des Traffics von Poki stammt von Mobilgeräten. Eine Browserwelt, die nur auf Desktop-Rechnern funktioniert, verliert die Mehrheit potenzieller Besucher.
• Soziale Funktionen, für die keine Freunde erforderlich sind. Bestenlisten, Reaktionen auf die Inhalte anderer Spieler und asynchrone Funktionen (ansehen, was andere Spieler gebaut haben, ohne gleichzeitig online zu sein).

Die erfolgreichsten 3D-Spiele auf diesen Portalen (wie Shell Shockers, 1v1.LOL und Smash Karts) halten die Polygonzahl niedrig, die Texturen einfach und die Bildrate hoch. Sie beweisen, dass Spieler einfache Grafik akzeptieren, wenn das Erlebnis flüssig und reaktionsschnell ist.

Browserbasierte Creator-Plattformen

Hubs von Mozilla (inzwischen von der Community gepflegt). Mehrbenutzer-3D-Räume im Browser, die auf Three.js und A-Frame basieren. Unterstützt Sprachchat, Avatare und gemeinsam genutzte Objekte. Keine offene Welt (sondern raumbasiert), doch die Netzwerk- und Rendering-Architektur ist relevant. Mozilla stellte das Projekt als Open Source bereit, bevor der gehostete Dienst eingestellt wurde, sodass die vollständige Codebasis untersucht werden kann. GitHub.

Hyperfy. Eine webbasierte Metaverse-Plattform, die vollständig im Browser läuft. Three.js-Rendering, Mehrspielermodus, Avataranpassung und Weltenbau. Näher an unserem Ziel als Hubs, da der Schwerpunkt auf Creator-Tools liegt. Welten werden ohne erforderlichen Download in einem Browser-Tab geladen. hyperfy.io.

Ethereal Engine (ehemals XREngine). Open-Source-Engine für Mehrbenutzerwelten, aufgebaut auf Three.js und bitECS. Unterstützt WebXR, räumliches Audio und die Bearbeitung von Welten. Verfügt über eine integrierte ECS-Architektur, eine Netzwerkschicht und Editorwerkzeuge. Das bestehende Open-Source-Projekt, das unserer Beschreibung am nächsten kommt. Es lohnt sich zu untersuchen, wie bitECS zur Entitätsverwaltung in Three.js integriert wird und wie das Netzwerk räumliche Zustände verarbeitet. GitHub.

Dusk (ehemals Rune). Mehrspieler-SDK für Webgames. Übernimmt die Netzwerkschicht, damit sich Entwickler auf das Gameplay konzentrieren können. Der Ansatz zur Zustandssynchronisierung nutzt vorhergesagte Zustände mit serverseitigem Abgleich, das Standardmodell für reaktionsschnelle Mehrspieler-Erlebnisse. Das SDK abstrahiert die Komplexität von Rollback-Netcode. Die Developer Experience ist eine nähere Betrachtung wert.

Niantic Studio. Ein browserbasierter visueller Editor und eine Webgame-Engine (der Nachfolger der Werkzeuge von 8th Wall), mit denen sich 3D- und XR-Erlebnisse erstellen lassen, die andere in einem Browser besuchen können. Es zeigt, dass auch Kreative ohne technische Kenntnisse 3D-Szenen in einem Browser erstellen können, wenn die Werkzeuge zugänglich sind. (Niantic gliederte seine Geodaten-Aktivitäten als Niantic Spatial aus und verkaufte 2025 sein Spielegeschäft einschließlich Pokemon GO an Scopely.)

PlayCanvas Editor. Selbst kein Spiel, doch der cloudbasierte 3D-Editor von PlayCanvas zeigt, dass Werkzeuge zum kollaborativen Weltenbau im Browser ausgeführt werden können. Mehrere Teammitglieder bearbeiten gleichzeitig dieselbe Szene. Der Editor überträgt Änderungen über eine Echtzeit-Synchronisierungsschicht. Dies ist das von uns benötigte Modell für gemeinsames Erstellen – allerdings mit unserer Welt statt eines Spieleeditors als Arbeitsfläche.

Native Creator-Plattformen (Lektionen für den Browser)

Diese Plattformen laufen als native Apps, doch ihre Designentscheidungen zu Creator-Tools, Beständigkeit der Welt und sozialer Dynamik sind direkt übertragbar.

Roblox: mehr als 80 Mio. tägliche Nutzer, 740 Mio. US-Dollar im Jahr 2023 an Kreative ausgezahlt. Die Erstellung erfolgt innerhalb der Engine. Entdeckung funktioniert sozial. Das Geschäftsmodell beweist, dass Creator-Plattformen sich selbst tragen können.

Roblox ist die mit Abstand wichtigste Referenz für eine Creator-Welt. Mehr als 80 Millionen täglich aktive Nutzer. Kreative bauen vollständige 3D-Erlebnisse (Spiele, soziale Räume, Geschäfte), die andere Spieler besuchen. Die Plattform übernimmt Hosting, Netzwerkbetrieb, Entdeckung und Monetarisierung.

Was Roblox richtig macht:

• Die Erstellung findet innerhalb der Engine statt. Roblox Studio ist dieselbe Umgebung, die Spieler erleben. Kreative testen ihre Arbeit sofort. Es gibt keinen Kreislauf aus Exportieren, Hochladen und Warten. Bei einer Browserwelt sollte der Editor die Welt selbst sein.
• Skripting ist zugänglich. Lua (die Skriptsprache von Roblox) ist so einfach, dass Kinder sie erlernen können. Komplexes Verhalten ist möglich, aber optional. Die Einstiegshürde ist niedrig und das Potenzial groß.
• Entdeckung funktioniert sozial. Du findest Erlebnisse, weil Freunde sie spielen. Die Startseite zeigt angesagte Erlebnisse. Bei einer Browserwelt ist die Welt selbst die Entdeckungsoberfläche. Du erkundest sie und findest Dinge, indem du herumläufst.
• Monetarisierung funktioniert. Kreative verdienen echtes Geld (Roblox zahlte 2023 insgesamt 740 Millionen US-Dollar an Kreative aus). Das zieht ernsthafte kreative Arbeit an. Ohne wirtschaftlichen Anreiz werden Creator-Plattformen zu Hobbyprojekten, die mit der Zeit verschwinden.
• Die Rendering-Engine von Roblox ist eine Eigenentwicklung und läuft in einer nativen App, nicht in einem Browser. Die Asset-Budgets pro Erlebnis sind nach modernen Maßstäben jedoch bescheiden (maximal 100 MB empfohlen). Die meisten erfolgreichen Roblox-Erlebnisse verwenden stilisierte Low-Poly-Grafik, was den Rendering-Einschränkungen des Browsers entgegenkommt.

Fortnite Creative / UEFN (Unreal Editor for Fortnite). Epic stellte Fortnite-Kreativen den vollständigen Editor der Unreal Engine zur Verfügung. Das Ergebnis ist eine Plattform, auf der Menschen mit professionellen Werkzeugen Inseln (eigenständige Welten) bauen. Fortnite übernimmt Hosting, Mehrspielermodus und Distribution.

Relevante Erkenntnisse:

• Professionelle Werkzeuge ziehen professionelle Inhalte an. UEFN bringt visuell beeindruckende Erlebnisse hervor, weil Kreative Zugriff auf den vollständigen Funktionsumfang von UE5 haben. Der Nachteil ist die Komplexität. UEFN hat eine steile Lernkurve.
• Inselbasierte Instanziierung (jede Kreation ist eine separate Welt) vermeidet die Moderations- und Konfliktprobleme einer einzigen gemeinsam genutzten Welt. Sie bedeutet jedoch auch, dass Kreative die Arbeiten anderer nicht auf natürliche Weise beim Erkunden entdecken. Inseln werden über Menüs besucht, nicht zu Fuß.
• Das Geschäftsmodell funktioniert. Das Creator-Programm von Fortnite bezahlt auf Grundlage der Interaktion. Führende Kreative verdienen mehrere Millionen pro Jahr. Auch hier fördert der wirtschaftliche Anreiz die Qualität.

Dreams (Media Molecule / PlayStation). Dreams bot Konsolenspielern eine vollständige 3D-Creation-Suite (Modellierung, Animation, Musik, Logik und Leveldesign) sowie eine Plattform zum Teilen ihrer Kreationen. Gemessen an der Tiefe seiner Werkzeuge ist es die ambitionierteste Creator-Plattform, die je entwickelt wurde.

Relevante Erkenntnisse:

• Skulpturbasierte Modellierung statt Polygonbearbeitung. Kreative formen weiche Volumen mit Werkzeugen zum Verschieben, Greifen und Glätten – ähnlich wie in ZBrush, aber intuitiver. Die Lernkurve ist flach. Dieser Ansatz eignet sich gut für die Erstellung im Browser, da keine Kenntnisse über Vertices und UV-Maps erforderlich sind.
• Alles ist ein gemeinsam nutzbares Asset. Wenn jemand ein Baummodell erstellt, kann es jeder in seiner eigenen Kreation verwenden (mit Namensnennung). Dadurch entsteht ein sich verstärkendes kreatives Ökosystem, in dem jede Kreation die Plattform wertvoller macht.
• Dreams hatte trotz Kritikerlob wirtschaftliche Schwierigkeiten. Das Problem war die Distribution: Es war auf PlayStation beschränkt, und die Erstellungswerkzeuge waren so umfangreich, dass die meisten Spieler nie über den reinen Konsum von Inhalten hinauskamen. Die Lektion: Die Erstellungswerkzeuge müssen so einfach sein, dass die Mehrheit der Nutzer sie ausprobiert, selbst wenn nur eine Minderheit zu ernsthaften Weltenbauern wird.

Core (Manticore Games). Eine kostenlose Plattform zum Erstellen und Spielen von Mehrspielerspielen, die auf der Unreal Engine basiert und einen vereinfachten Editor bietet. Der Editor von Core läuft als native App, doch die zugrunde liegende Philosophie ist relevant. Vorlagen und von der Community geteilte Skripte ermöglichen es Einsteigern, Spiele aus vorgefertigten Komponenten zusammenzusetzen. Fortgeschrittene Kreative können Lua-Skripte für individuelles Verhalten schreiben. Core hatte Schwierigkeiten, ein großes Publikum zu finden – teilweise, weil die Spiele über den Core-Launcher gespielt werden mussten. Eine browserbasierte Version hätte diese Hürde nicht.

VRChat und Rec Room sind soziale Plattformen, auf denen Kreative Räume bauen, die andere besuchen. VRChat nutzt Unity und läuft auf PC und VR-Geräten. Rec Room läuft auf praktisch allen Plattformen, einschließlich Mobilgeräten. Beide beweisen, dass nutzergenerierte 3D-Welten große Communitys dauerhaft tragen können. VRChat ist technisch beeindruckender (benutzerdefinierte Shader, komplexe Avatare). Rec Room ist zugänglicher (integrierte Erstellungswerkzeuge, einfachere Grafik, breitere Plattformunterstützung). Für eine Browserwelt ist der Ansatz von Rec Room mit einfachen integrierten Erstellungswerkzeugen besser geeignet als der externe Tool-Workflow von VRChat.

Second Life: 2003 gestartet und mit mehr als 200.000 täglichen Nutzern noch immer aktiv. Vollständig nutzergeneriert. Parzellenbasierter Besitz und eine virtuelle Wirtschaft im Wert von rund 500 Mio. US-Dollar pro Jahr. 20 Jahre voller Erkenntnisse zu Beständigkeit und Moderation.

Second Life ist der Urvater aller Creator-Welten. Es wurde 2003 gestartet und zählt noch immer mehr als 200.000 täglich aktive Nutzer. Die gesamte Welt ist nutzergeneriert. Land befindet sich in Privatbesitz und wird gehandelt. Kreative verkaufen Objekte, Kleidung und Gebäude. Die weltinterne Skriptsprache (LSL) ermöglicht interaktive Inhalte.

Was Second Life nach mehr als 20 Jahren lehrt:

• Beständigkeit ist wichtiger als Grafik. Die Optik von Second Life ist veraltet, aber die Welt bleibt bestehen. Kreationen bleiben dort, wo sie platziert wurden. Beziehungen und Geschichte sammeln sich an. Diese Beständigkeit bringt Menschen immer wieder zurück.
• Eine Wirtschaft fördert die Erstellung. Das BIP von Second Life wird auf 500 Millionen US-Dollar pro Jahr geschätzt. Kreative bauen, weil sie verkaufen können. Ohne wirtschaftlichen Anreiz sinken Umfang und Qualität der erstellten Inhalte.
• Nutzergenerierte Inhalte erfordern eine Moderationsinfrastruktur. Second Life blickt auf 20 Jahre voller Moderationsprobleme zurück. Jede Plattform, auf der Nutzer beliebige Inhalte in einem gemeinsam genutzten Raum platzieren können, benötigt automatisierte Prüfungen, Meldewerkzeuge und menschliche Kontrolle.
• Landbasierte räumliche Organisation funktioniert. Second Life unterteilt seine Welt in Parzellen, die Nutzern gehören. Für jede Parzelle gilt ein Prim-Limit (Objektlimit). Dadurch wird auf natürliche Weise verhindert, dass ein einzelner Kreativer sämtliche Ressourcen verbraucht. Für eine Browserwelt ist chunkbasierter Besitz mit Objektbudgets pro Chunk das entsprechende Muster.

Vergleichende Analyse: Was wir von jedem Spiel lernen können

Spiel	Wichtigste Erkenntnis	Anwendbare Technologie	Risiko bei Nichtbeachtung
Skyrim	Chunk-basiertes Streaming mit Zellraster	Heightmap-Terrain, LOD-Stufen, Trennung von Innen- und Außenbereichen	Die Welt passt nicht in den Browserspeicher
The Witcher 3	Schichtweiser Aufbau der Welt durch getrennte Teams	Inhaltsabhängiges Streaming, Impostor-Rendering	Kreative können nicht unabhängig voneinander arbeiten
Breath of the Wild	Systemische Regeln sind besser als geskriptete Inhalte	Materialinteraktionssystem, physikbasiertes Gameplay	Die Welt wirkt statisch und leblos
GTA V	Lebendige Umgebungen lassen Welten real wirken	NPC-Verhaltenssysteme, Verkehr, Tageszeiten	Die Welt der Kreativen wirkt wie ein leeres Museum
Elden Ring	Unterschiedliche Dichten und Wiederverwendung von Assets	Modulare Asset-Bibliothek, dünn und dicht besiedelte Zonen	Entweder zu leer oder zu aufwendig zu füllen
No Man's Sky	Prozedurale Generierung für die Leinwand, von Kreativen erstellte Inhalte für die Seele	Seed-basiertes Terrain, kompaktes Datenmodell für Basen	Unendliches, aber langweiliges Terrain
Minecraft	Vollständig bearbeitbare Welt, einfache Werkzeuge, unendliche Tiefe	Chunk-Streaming, Palettenkomprimierung, Blockbearbeitungsprotokoll	Kreative können die Welt selbst nicht umgestalten
Roblox	Die Erstellung erfolgt innerhalb der Engine, die Ökonomie steigert die Qualität	In-World-Editor, Monetarisierung für Kreative	Niemand baut etwas, weil es keinen Anreiz gibt
Krunker.io	Browser-UGC funktioniert mit einfachen Werkzeugen in großem Maßstab	Three.js-Rendering, voxelbasierter Editor, Marktplatz	Erstellungswerkzeuge sind für gelegentliche Kreative zu komplex
Hordes.io	Mehr als 200 Spieler in Browser-3D, auch für Solo-Entwickler machbar	Eigenes WebGL, räumliches Culling, stilisierte Grafik	Die Mehrspielerebene wird überentwickelt
Vuntra City (native Referenz)	Geschwindigkeitsabhängiges Streaming und eine zweistufige Weltsimulation sorgen für eine kohärente riesige prozedurale Stadt	Geschwindigkeitsgekoppelte LOD-Richtlinie, Topologie-Abfrageschicht, Fernbereichs-Terminplansimulation + Nahbereichsverhalten	Hochgeschwindigkeitsbewegungen verursachen Pop-ins und Simulationsspitzen
Agar.io / Slither.io	Räumliche Partitionierung ermöglicht massive Nebenläufigkeit	Variable Tickrate nach Entfernung, Interessenverwaltung	Das Netzwerk bricht bei großer Skalierung zusammen
Second Life	Persistenz und Ökonomie tragen Gemeinschaften über 20 Jahre	Parzellenbasierter Besitz, Objektbudgets, Marktplatz	Keine langfristige Bindung
Dreams	Skulpturbasiertes Erstellen ist intuitiver als Polygonbearbeitung	Volumenbasierte Modellierung, gemeinsame Asset-Bibliothek	Erstellungswerkzeuge fühlen sich wie ein CAD-Programm an
Fortnite Creative	Professionelle Werkzeuge ziehen professionelle Inhalte an	Vollständige Editorfunktionen innerhalb der Plattform	Die Obergrenze der Inhaltsqualität ist zu niedrig
RuneScape	Ein vollständiges MMO funktioniert dank Wasm und Binärprotokollen im Browser	Emscripten, eigenes binäres WebSocket-Protokoll, Tile-Streaming	Die Leistungsfähigkeit von Browsern wird unterschätzt
Habbo Hotel	Einfache Raumerstellung trägt eine Gemeinschaft seit 25 Jahren	Rasterbasierte Platzierung, Ökonomie für virtuelle Möbel	Die Erstellungswerkzeuge werden unnötig verkompliziert

Für unseren konkreten Anwendungsfall – browserbasiert, auf Kreative ausgerichtet und im Mehrspielermodus – sind Minecraft (bearbeitbare Welt, kompakte Daten), Roblox (Erstellung innerhalb der Engine, Ökonomie), Krunker (Browser-UGC in großem Maßstab) und Hordes.io (Browser-MMO-Architektur) am wichtigsten. Die AAA-Titel (Skyrim, BotW, Witcher 3) vermitteln Erkenntnisse über Rendering und Streaming. Die Browser-Erfolge (Agar.io, Slither.io, Surviv.io) zeigen, wie Netzwerke in großem Maßstab funktionieren. Die Kreativplattformen (Roblox, Dreams, Second Life) vermitteln die Dynamik von Gemeinschaften. Vuntra City liefert zusätzlich eine aktuelle, implementierungsnahe Referenz für geschwindigkeitsabhängiges Streaming, diegetische Navigation und Simulationsmuster für Millionen von Agenten in einer modernen prozeduralen Stadt.

Wie Skyrim und The Witcher in einem Browser aussehen würden

Werden wir konkret. Wenn man Weißlauf aus Skyrim für die Bereitstellung im Browser neu aufbauen würde:

Terrain: Das Gebiet um Weißlauf ist ungefähr 2 km x 2 km groß. Bei unserer Chunk-Größe von 64 m entspricht das etwa 32 x 32 = 1024 Chunks. Bei 2–4 KB pro Chunk-Heightmap ergeben sich 2–4 MB Terraindaten. Die Terraintexturen für Gras, Erde, Felsen und Schnee könnten als KTX2-Atlas-Tiles weitere 5 MB beanspruchen. Gesamtes Terrain: weniger als 10 MB für die gesamte Region.

Bauwerke: Weißlauf selbst umfasst vielleicht 40–50 Gebäude. Jedes Gebäude könnte als optimierte GLB-Datei mit drei LOD-Stufen in der höchsten Detailstufe 200–500 KB groß sein. Volle Details werden jedoch nur für die 5–10 nächstgelegenen Gebäude benötigt. Für den Rest reichen mittlere oder niedrige LOD-Stufen mit jeweils 50–100 KB. Insgesamt gleichzeitig sichtbare Bauwerke: 2–5 MB.

Vegetation: Die Bäume und das Gras rund um Weißlauf werden in Skyrim vollständig per Instancing dargestellt. Man benötigt vielleicht 10 einzigartige Baummodelle mit jeweils 200 KB im höchsten LOD und 20 KB als Billboard-Impostors sowie ein Grassystem, das anhand einer Dichtekarte auf der GPU Grashalme erzeugt. Gesamte Vegetations-Assets: 2–3 MB. Die Instancing-Daten für Positionen, Rotationen und Skalierungen eines Gebiets von 5 x 5 Chunks: weniger als 500 KB.

NPCs: Weißlauf hat ungefähr 70 namentlich bekannte NPCs sowie Wachen. Jeder Avatar in mittlerer Qualität benötigt 100–200 KB. Gleichzeitig sichtbar sind jedoch nur 10–20. Gesamte Rendering-Daten der NPCs: 2–4 MB.

Gesamtsumme für ein Gebiet von der Größe Weißlaufs, das zu einem beliebigen Zeitpunkt sichtbar ist: 15–25 MB. Das ist in einem Browser absolut machbar. Beim initialen Laden würden Terrain und wichtige Bauwerke über eine Breitbandverbindung innerhalb von 3–5 Sekunden erscheinen, während weitere Details in den darauffolgenden Sekunden geladen werden.

Novigrad aus The Witcher 3 ist größer und dichter bebaut, doch es gelten dieselben Prinzipien. Aggressiveres LOD und Streaming wären erforderlich, aber die insgesamt gleichzeitig sichtbaren Daten blieben innerhalb der Speichergrenzen des Browsers.

Was wir zuerst entwickeln würden

Eine vollständige offene Welt ist ein mehrjähriges Projekt. So könnten wir Kreativen schnell etwas Reales an die Hand geben:

Phase 1: Gemeinsame Insel (3 Monate). Ein einzelner Terrain-Chunk – eine 512 x 512 m große Insel – mit Heightmap-Terrain, Wasser, grundlegender Vegetation und Tag-Nacht-Zyklus. Mehrspielermodus über Durable Objects für bis zu 50 gleichzeitige Benutzer. Kreative können KI-generierte 3D-Assets aus ihrer bestehenden Cinevva-Bibliothek platzieren. Man kann es sich als gemeinsames Diorama vorstellen.

Phase 2: Erweiterbare Welt (3 Monate). Chunk-Streaming für eine 4 x 4 km große Welt. Parzellen im Besitz von Kreativen, für die sie Bearbeitungsrechte besitzen. LOD-System für Terrain und Objekte. Persistenter Weltzustand. Bis zu 200 gleichzeitige Benutzer in der gesamten Welt.

Phase 3: Lebendige Welt (6 Monate). KI-gestützte Terrainmodellierung. Prozedurale Vegetation und Atmosphäre. Quest- und Ereignissystem, mit dem Kreative interaktive Erlebnisse statt nur statischer Szenen entwickeln können. Sprachchat. Avatar-Anpassung. Die Welt wird zu einem Ziel und nicht nur zu einer Demo.

Offene Fragen

Grafikstil. Ein stilisierter Ansatz mit Low-Poly- oder Cel-Shading-Grafik ist günstiger zu rendern und verzeiht mehr bei KI-generierten Assets. Realismus erfordert hochwertigere Assets und ein größeres Rendering-Budget. Skyrim funktionierte trotz veralteter Grafik, weil die künstlerische Gestaltung konsistent war. BotW sieht auf Hardware der Tablet-Klasse großartig aus, weil der Cel-Shading-Stil niedrige Polygonzahlen kaschiert. Minecraft verwendet 16-x-16-Texturen und ist eines der bekanntesten Spiele aller Zeiten. Krunker.io und Hordes.io sind beide mit einfacher, stilisierter Browsergrafik erfolgreich. Die Erkenntnisse sprechen überwältigend für eine stilisierte Ausrichtung einer Browserwelt. Wir müssen frühzeitig eine konkrete visuelle Identität festlegen und die Konsistenz aller KI-generierten Assets durchsetzen.

Weltpersistenz vs. Instanziierung. Teilen sich alle eine einzige Welt wie in einem MMO oder Second Life, oder erhält jeder Kreative eine eigene Instanz, die andere besuchen können, wie bei Minecraft-Servern oder Fortnite-Inseln? Die Technologie unterstützt beides, doch die soziale Dynamik unterscheidet sich grundlegend. Die persistente gemeinsame Welt von Second Life ermöglicht zufällige Entdeckungen: Man stößt beim Herumlaufen auf die Werke anderer. Die instanziierten Inseln von Fortnite benötigen für die Entdeckung ein Menü- oder Portalsystem. Roblox verwendet einen Hub-basierten Ansatz: Die Spiele sind voneinander getrennt, werden aber über eine gemeinsame Oberfläche durchsucht und entdeckt. Ein hybrider Ansatz könnte funktionieren: eine persistente gemeinsame Oberwelt mit Parzellen im Besitz von Kreativen, ähnlich den Parzellen in Second Life, sowie der Möglichkeit, über Portale eigenständige Erlebnisse zu betreten.

Tiefe der Erstellungswerkzeuge. Dreams hat gezeigt, dass tiefgreifende Erstellungswerkzeuge Kritiker beeindrucken, Benutzer jedoch einschüchtern. Townscaper hat bewiesen, dass sich mit minimalen Werkzeugen eine Million Exemplare verkaufen lassen. Roblox Studio liegt dazwischen: einfach genug für Kinder, leistungsfähig genug für Profis. Krunkers Voxel-Editor ist noch einfacher. Für eine Browserwelt sollten wir mit der Einfachheit von Townscaper beginnen – Objekte platzieren, die automatisch einrasten und sich verbinden – und im Lauf der Zeit mehr Tiefe hinzufügen. Das erste Objekt sollte sich innerhalb von weniger als 30 Sekunden in der Welt platzieren lassen.

Ökonomie. Roblox, Second Life und Fortnite Creative beweisen allesamt, dass wirtschaftliche Anreize aus einem Spielzeug eine Plattform machen. Ohne eine Möglichkeit, mit ihrer Arbeit Geld zu verdienen, werden die talentiertesten Kreativen anderswo entwickeln. Das muss nicht am ersten Tag starten, aber die Architektur sollte es unterstützen, etwa durch Objektbesitz, Besuchserfassung und Zuordnung zu den Kreativen.

Mobilgeräte. Bis WebGPU auf Mobilgeräten zuverlässig funktioniert, werden noch Jahre vergehen. Eine mobile Erfahrung müsste eine reduzierte Version sein: einfacheres Terrain, weniger Objekte und eine kürzere Sichtweite. Der Ansatz von Rec Room, mit adaptiver Qualität auf allen Geräten zu laufen, ist eine nähere Untersuchung wert. Alternativ veröffentlichen wir eine native App für Mobilgeräte und belassen die vollständige Erfahrung im Browser.

Moderation. Eine offene Welt, in der jeder alles platzieren kann, ist ein Albtraum für die Moderation. Second Life beschäftigt sich seit 20 Jahren damit. Jedes platzierte Asset muss einer automatisierten Inhaltsprüfung unterzogen werden, bevor es für andere sichtbar wird. Das verzögert den kreativen Prozess, ist aber nicht verhandelbar. Wir sollten außerdem parzellenbasierte Inhaltsbewertungen in Betracht ziehen, ähnlich dem System „General/Moderate/Adult“ von Second Life, damit Kreative die Grenzen ihrer Inhalte selbst festlegen können.

Systemische Interaktionen. Sowohl BotW als auch Minecraft zeigen, dass materialbasierte Interaktionssysteme exponentiell interessantere Welten hervorbringen als die bloße Platzierung statischer Objekte. Wenn ein Kreativer eine Holzbrücke platziert und ein anderer in der Nähe ein Feuer entfacht, sollte die Brücke dann brennen? Wenn jemand einen Damm errichtet, sollte sich dahinter Wasser aufstauen? Solche Interaktionen lassen die Welt lebendig wirken, setzen jedoch einheitliche Physik- und Materialregeln für sämtliche Inhalte der Kreativen voraus. Wie weit wir beim systemischen Design gehen wollen, ist eine frühe Architekturentscheidung.

Wichtigste Erkenntnisse

Offene 3D-Browserwelten sind heute machbar. Hordes.io unterstützt mehr als 200 Spieler in einer 3D-Welt im Browser. Krunker.io erreichte mit einem vollständigen 3D-Karteneditor 10 Millionen monatliche Spieler. Die .io-Spiele haben bewiesen, dass Browser-Mehrspielerspiele auf Millionen von Spielern skalieren können. Die Technologie ist nicht spekulativ.

Das Rendering ist bereit. Three.js und Babylon.js bewältigen 3D-Szenen, die mit AAA-Spielen aus den frühen 2010er-Jahren vergleichbar sind. WebGPU ermöglicht Compute-Shader für Terrain und Vegetation. Wasm-Physik-Engines laufen nur zwei- bis dreimal langsamer als native Lösungen. Ein Gebiet von der Größe Weißlaufs kommt mit 15–25 MB sichtbarer Daten aus.

Die Netzwerktechnik ist bereit. Cloudflare Durable Objects ermöglichen autoritative Server pro Chunk am Netzwerkrand. CRDTs bewältigen kollaborative Bearbeitung ohne Konflikte. Räumliche Partitionierung – bewährt in sämtlichen Spielen von Agar.io bis Skyrim – hält den Netzwerkverkehr selbst bei Hunderten gleichzeitigen Spielern beherrschbar.

Die offenen AAA-Welten aus Skyrim, Witcher 3, BotW, Elden Ring, Minecraft und No Man's Sky sind nicht nur grafische Maßstäbe. Sie sind Lehrbücher für Chunk-Streaming, LOD-Verwaltung, prozedurale Generierung, systemisches Design und Weltkomposition. Für jede von ihnen eingesetzte Technik gibt es eine browserkompatible Entsprechung.

Die Kreativplattformen Roblox, Second Life, Fortnite Creative und Dreams vermitteln die sozialen und wirtschaftlichen Erkenntnisse. Die Erstellung muss innerhalb der Welt und nicht in einem externen Werkzeug erfolgen. Wirtschaftliche Anreize steigern die Qualität. Persistenz erzeugt Bindung. Einfache Werkzeuge erreichen mehr Kreative als leistungsstarke.

Bei der kreativen Pipeline hat Cinevva einen Vorteil. Wir generieren bereits 3D-Assets, Texturen und Audio. Das fehlende Puzzleteil ist die Verbindung dieser Pipeline mit einem System zur Platzierung in der Welt. KI-generierte Inhalte füllen die Welt. Die Auswahl und Anordnung durch Kreative verleiht ihr eine Seele.

Das Ergebnis wäre nicht Skyrim im Browser. Es läge eher an der Schnittstelle von Minecraft mit seiner bearbeitbaren Welt, Roblox mit seiner Kreativökonomie und BotW mit seinen systemischen Interaktionen – ausgeführt in einem Browser-Tab und ausgestattet mit KI-gestützten Erstellungswerkzeugen. Die Technologie dafür existiert. Entscheidend ist die Umsetzung.

Forschungsarbeiten und akademische Referenzen

Die Techniken in diesem Leitfaden wurden nicht von Grund auf neu erfunden. Sie beruhen auf jahrzehntelanger Forschung. Dies sind die wichtigsten Arbeiten für jedes Teilsystem, jeweils mit Hinweisen dazu, wie sie sich auf eine offene Browserwelt anwenden lassen.

Terraingenerierung und -Rendering

"An Image Synthesizer" -- Ken Perlin (SIGGRAPH 1985). DOI. Diese Arbeit führte Perlin Noise ein. Jeder prozedurale Terraingenerator in jedem Spiel seit 1985 lässt sich darauf zurückführen. Die Rauschfunktion erzeugt sanfte Zufälligkeit, die bei einer Schichtung in Oktaven – fraktionaler brownscher Bewegung – natürlich wirkende Heightmaps hervorbringt. Simplex Noise (Perlin, 2001) ist der schnellere Nachfolger. Für unsere Terrain-Pipeline bildet dies die Grundlage: Die rauschbasierte Heightmap-Generierung läuft in einem WebGPU-Compute-Shader mit interaktiver Geschwindigkeit.

"Texturing and Modeling: A Procedural Approach" -- Ebert, Musgrave, Peachey, Perlin, Worley (1994, 3. Auflage 2003). Das Standardwerk zur prozeduralen Generierung. Musgraves Kapitel zur Terrainmodellierung, darunter multifraktales Terrain mit erosionsähnlichen Merkmalen, bilden die direkte Grundlage moderner Terraingeneratoren für Spiele. Die dort beschriebenen fBm-Parameter – Lakunarität, Persistenz und Anzahl der Oktaven – sind dieselben, die wir Kreativen zur Anpassung des Terrains bereitstellen würden.

"Geometry Clipmaps: Terrain Rendering Using Nested Regular Grids" -- Losasso and Hoppe (SIGGRAPH 2004). DOI. Diese Arbeit löste das Problem, wie sich riesige Terrains mithilfe konzentrischer LOD-Ringe – sogenannter Clipmaps – mit interaktiven Bildraten rendern lassen. Das Terrain-Mesh besteht aus einem festen Satz ineinander verschachtelter Raster, die um die Kamera zentriert sind. Wenn sich die Kamera bewegt, verschieben und aktualisieren sich die Raster. Diese Technik wird in unserem Terrainabschnitt für WebGL 2 empfohlen und funktioniert, weil die GPU-Arbeitslast unabhängig von der Größe der Welt konstant bleibt. Die ursprüngliche Implementierung entstand vor WebGL, lässt sich aber direkt darauf übertragen. „Fast Hydraulic Erosion Simulation and Visualization on GPU“ – Mei, Decaudin, Hu (2007). PDF. Verlagerte die hydraulische Erosion von einem CPU-gebundenen Offline-Prozess zu einer GPU-Echtzeitberechnung. Das Flachwassersimulationsmodell der Arbeit, bei dem Wasser als Höhenfeld behandelt und die Strömung zwischen Rasterzellen berechnet wird, läuft in einem Compute-Shader. In unserer Pipeline kann serverseitige GPU-Erosion aus Rauschen erzeugtes Terrain in weniger als einer Sekunde in geologisch plausible Landschaften verwandeln, sodass KI-generiertes Terrain wie von Hand modelliert aussieht.

„Real-Time Rendering of Procedurally Generated Planets“ – Hybride Ansätze aus den GDC-Vorträgen zu No Man's Sky und den Beschreibungen von Sean Murray. Es handelt sich zwar nicht um eine einzelne Veröffentlichung, doch der GDC-Vortrag „Building Worlds Using Maths“ von Innes McKendrick (Hello Games) aus dem Jahr 2017 erläutert, wie No Man's Sky planetengroßes Terrain mithilfe gestapelter Rauschfunktionen, einer Voxeldarstellung mit Marching Cubes und GPU-seitiger Generierung erzeugt. Dies ist für unseren Ansatz zur prozeduralen Terrain-Erzeugung unmittelbar relevant, insbesondere bei der Generierung von Terrainmerkmalen, die sich mit Höhenkarten nicht darstellen lassen, etwa Höhlen und Bögen.

„C-DBLOD: Hybrid LOD for Terrain Rendering“ – Filip Strugar (2014). Veröffentlichung. Eine Verbesserung von Geometry Clipmaps, die eine Quadtree-basierte Auswahl hinzufügt, um die Anpassungsfähigkeit in der Umgebung der Kameraposition zu erhöhen. Die zentrale Erkenntnis: Statt fester konzentrischer Ringe wird ein Quadtree verwendet, um Terrainsegmente mit unterschiedlichen Auflösungen auszuwählen. Bei unregelmäßigem Terrain, in dem manche Bereiche mehr Details benötigen als andere, funktioniert dies besser als reine Clipmaps. In WebGL 2 mit einer kleinen CPU-seitigen Quadtree-Traversierung umsetzbar.

3D Gaussian Splatting und neuronales Rendering

„3D Gaussian Splatting for Real-Time Radiance Field Rendering“ – Kerbl, Kopanas, Leimkühler, Drettakis (SIGGRAPH 2023). Projektseite. Die Veröffentlichung, die die Gaussian-Splatting-Revolution auslöste. Eine Szene wird durch Millionen dreidimensionaler Gauß-Funktionen dargestellt, jeweils mit Position, Kovarianz (Form), Deckkraft und sphärisch-harmonischen Farbkoeffizienten. Beim Rendering werden die Splats nach Tiefe sortiert und als zweidimensionale Gauß-Funktionen rasterisiert. Dieser Ansatz lässt sich 100- bis 1.000-mal schneller trainieren als NeRFs und ermöglicht Rendering in Echtzeit. Es gibt mehrere WebGL- und WebGPU-Implementierungen. Auf unserer Plattform können Kreative damit reale Objekte anhand von Smartphone-Fotos erfassen und in der Browserwelt platzieren.

„NeRF: Representing Scenes as Neural Radiance Fields for View Synthesis“ – Mildenhall et al. (ECCV 2020). Projektseite. Die grundlegende Veröffentlichung zur neuronalen Szenenrepräsentation. Ein neuronales Netz bildet 3D-Koordinaten auf Farbe und Dichte ab und ermöglicht so die fotorealistische Synthese neuer Ansichten aus einer Reihe von Eingabefotografien. Obwohl NeRFs für direktes Rendering im Browser zu rechenintensiv sind, da sie eine Netzwerkauswertung pro Pixel erfordern, erzeugt die NeRF-zu-Mesh-Extraktionspipeline hochwertige texturierte Meshes aus Fotos. Dabei wird zunächst ein NeRF trainiert und anschließend Marching Cubes auf das Dichtefeld angewendet.

„Instant Neural Graphics Primitives with a Multiresolution Hash Encoding“ – Müller, Evans, Schied, Keller (SIGGRAPH 2022). Projektseite. Reduzierte die Trainingsdauer von NeRFs durch eine Hash-Tabelle mit mehreren Auflösungen für die räumliche Kodierung von Stunden auf Sekunden. Dadurch wurden NeRFs für den Produktionseinsatz praktikabel. Die Hash-Kodierungstechnik lässt sich auch auf andere räumliche Daten in einer Browserwelt anwenden, etwa für schnelle Abfragen in großen 3D-Datensätzen.

„Neuralangelo: High-Fidelity Neural Surface Reconstruction“ – Li et al. (CVPR 2023). Projektseite. Extrahiert mithilfe von Hash-Kodierung mit mehreren Auflösungen und numerischen Gradienten zur Schätzung von SDFs (vorzeichenbehafteten Abstandsfunktionen) hochwertige Dreiecksmeshes aus neuronalen Repräsentationen. Die ausgegebenen Meshes lassen sich direkt in 3D-Browser-Engines verwenden. Für unsere Asset-Pipeline kann Neuralangelo oder ein ähnliches Werkzeug wie NeuS2 NeRF-Aufnahmen in webfähige GLB-Dateien mit sauberer Geometrie und gebackenen Texturen umwandeln.

Multiplayer-Netzwerkkommunikation und Zustandssynchronisierung

„Interest Management in Massively Multiplayer Online Games“ – Boulanger, Kienzle, Verbrugge (2006). DOI. Eine umfassende Übersicht über Techniken zur Verwaltung von Interessenbereichen (Area of Interest, AOI) in MMOs. Behandelt rasterbasierte, aurabasierte und hybride Ansätze zur Filterung von Netzwerkaktualisierungen nach räumlicher Relevanz. Der rasterbasierte Ansatz, der unserem Chunk-System entspricht, ist bei Welten mit gleichmäßiger Dichte am effizientesten. Der aurabasierte Ansatz mit einem Einflussradius pro Entität eignet sich besser für variable Dichten. Unsere Empfehlung eines Chunk-basierten AOI mit prioritätsabhängigen Aktualisierungsraten innerhalb des AOI baut auf dieser Forschung auf.

„Dead Reckoning: Latency Hiding for Networked Games“ – Pantel und Wolf (2002). DOI. Formalisiert Dead Reckoning, also die Vorhersage von Entitätspositionen anhand der zuletzt bekannten Geschwindigkeit, für vernetzte Spiele. Die Veröffentlichung quantifiziert den Zielkonflikt: Höhere Vorhersageschwellen verringern die Bandbreitennutzung, erhöhen jedoch den bei Korrekturen sichtbaren Positionsfehler. Bei Browserspielen mit einer Latenz von 50–200 ms sorgt eine Vorhersageschwelle von 0,5–1,0 Metern dafür, dass Korrekturen unsichtbar bleiben, während die Bandbreite für Positionsaktualisierungen um 60–80 % sinkt.

„Conflict-free Replicated Data Types“ – Shapiro, Preguiça, Baquero, Zawirski (2011). DOI. Die grundlegende CRDT-Veröffentlichung. Definiert zustands- und operationsbasierte CRDTs, die ohne Koordination konvergieren. Für unser Weltbearbeitungssystem sind folgende CRDTs relevant: LWW-Register (Last-Writer-Wins Register) für Objekteigenschaften mit einem einzelnen Wert wie Position, Rotation oder Farbe sowie OR-Set (Observed-Remove Set) für die Sammlung von Objekten in einem Chunk, das gleichzeitiges Hinzufügen und Entfernen konfliktfrei verarbeitet. Yjs implementiert diese effizient in JavaScript.

„Time Warp: A Mechanism for Distributed Simulation“ – Jefferson (1985). DOI. Die ursprüngliche Veröffentlichung zur optimistischen verteilten Simulation. Time Warp selbst ist für ein Browserspiel zwar zu komplex, doch die zentrale Erkenntnis – Ereignisse optimistisch zu verarbeiten und sie zurückzusetzen, wenn ein Konflikt von einem anderen Knoten eintrifft – bildet die Grundlage moderner clientseitiger Vorhersage mit Serverabgleich. So funktioniert jedes reaktionsschnelle Multiplayer-Spiel: Der Client führt lokale Vorhersagen durch, sendet Aktionen an den Server und nimmt Korrekturen vor, wenn der Server zu einem anderen Ergebnis kommt.

„The TRIBES Engine Networking Model“ – Frohnmayer und Gift (GDC 1999). Eine der ersten praxisnahen Beschreibungen von Client-Server-Spielnetzwerken mit Interessenverwaltung, priorisierten Zustandsaktualisierungen und Bandbreitenbudgetierung. Das Konzept des „Ghost Manager“, bei dem der Server für jeden Client eine eigene Ansicht des Wissensstands dieses Clients verwaltet und nur Abweichungen davon sendet, entspricht genau dem, was unsere Chunk-basierte Durable-Object-Architektur implementiert. Dieser GDC-Vortrag ist der geistige Vorläufer der meisten modernen Spielnetzwerktechniken.

„Source Multiplayer Networking“ – Valve (2009). Entwicklerdokumentation. Valves Dokumentation des Netzwerkmodells der Source-Engine, die in Half-Life 2, CS:GO und Team Fortress 2 verwendet wird. Behandelt clientseitige Vorhersage, Entitätsinterpolation, Latenzkompensation und das „Snapshot“-System, bei dem der Server in regelmäßigen Abständen den vollständigen Weltzustand sendet, während der Client zwischen den Snapshots interpoliert. Dies ist der Goldstandard für autoritative Servernetzwerke und direkt auf unsere Architektur anwendbar.

Prozedurale Generierung

„Model Synthesis: A General Procedural Modeling Algorithm“ – Merrell (2007). DOI. Einer der Vorläufer von Wave Function Collapse. Erzeugt 3D-Strukturen aus Beispielmodellen, indem lokale Einschränkungen propagiert werden. Der Algorithmus gewährleistet globale Konsistenz, indem er iterativ die Zellen mit den wenigsten Möglichkeiten kollabieren lässt, also eine Heuristik minimaler Entropie verwendet. Auf diese Weise erzeugen Townscaper und ähnliche Generatoren aus einfachen Benutzereingaben schlüssige Strukturen.

„WaveFunctionCollapse“ – Maxim Gumin (2016). GitHub. Keine traditionelle wissenschaftliche Veröffentlichung, sondern ein wegweisendes Open-Source-Projekt mit umfangreicher Dokumentation. Der Algorithmus verwendet ein kleines Beispielbild oder Tileset und erzeugt größere Ausgaben, die dem Ausgangsmaterial lokal ähneln. Für eine von Kreativen gestaltete Welt kann WFC Gebäudelayouts, Straßennetze, Dungeon-Karten und Terraindetails aus einer kleinen Menge von Regeln generieren, die Kreative selbst definieren. Es gibt mehrere JavaScript-Implementierungen.

„Wave Function Collapse is Constraint Solving in the Wild“ – Karth und Smith (FDG 2017). DOI. Eine wissenschaftliche Analyse von WFC, die dessen Beziehung zur Constraint-Erfüllung erläutert und zeigt, wie sich der Algorithmus analysieren und erweitern lässt. Relevant für das Verständnis der Grenzen von WFC – der Algorithmus kann stecken bleiben und Backtracking erfordern – und dafür, wie Tilesets gestaltet werden müssen, um diese Probleme zu vermeiden.

„Superposition Theorem and Its Implications for the Procedural Generation of Game Content“ – Sandhu et al. (2022). Untersucht die Verwendung quanteninspirierter Superpositionskonzepte für die prozedurale Generierung von Inhalten. Obwohl der Ansatz spekulativ ist, entspricht das mathematische Modell, mehrere mögliche Zustände beizubehalten, bevor sie zu einer endgültigen Konfiguration „kollabieren“, genau der Funktionsweise von WFC und könnte als Grundlage für anspruchsvollere Generierungssysteme dienen.

Echtzeit-Renderingtechniken

„Real-Time Rendering“ – Akenine-Möller, Haines, Hoffman (4. Auflage, 2018). Das Standardlehrbuch. Kapitel 19 (Beschleunigungsstrukturen), Kapitel 20 (Effizientes Shading) und Kapitel 21 (Virtuelle und erweiterte Realität) sind besonders relevant. Die dort beschriebenen Algorithmen für Frustum Culling, Occlusion Culling und LOD werden von Three.js, Babylon.js und jeder Spiele-Engine implementiert. Keine wissenschaftliche Veröffentlichung, aber das maßgebliche Standardwerk.

„A Survey on Baking Neural Radiance Fields for Real-Time View Synthesis“ – Reiser et al. (2023). DOI. Gibt einen Überblick über Methoden zur Umwandlung von NeRFs in Formate, die sich in Echtzeit rendern lassen, darunter Meshes, Texturen und dünn besetzte Voxelraster. Dies ist für unsere Asset-Pipeline unmittelbar relevant, in der serverseitige neuronale Erfassung eine im Browser renderbare Ausgabe erzeugen muss.

„Scalable and Accurate Online Feature Matching Using 3D Gaussian Splatting“ – Verschiedene Forschungsgruppen (2024–2025). Mehrere aktuelle Veröffentlichungen untersuchen die Bearbeitung, Komposition und Darstellung dynamischer Szenen mit Gaussian Splats. Dies ist relevant, weil in von Kreativen erstellten Welten mehrere Splat-Szenen, etwa die erfassten Objekte verschiedener Kreativer, zu einer einzigen schlüssigen Szene zusammengesetzt werden müssen. Methoden zur Bearbeitung von Splats, darunter Umfärbung, Verformung und Komposition, sind aktive Forschungsgebiete.

„Efficient GPU Screen-Space Ray Tracing“ – McGuire und Mara (JCGT 2014). DOI. Die Veröffentlichung hinter den Screen-Space-Reflexionen aus unserem Abschnitt zum Wasser-Rendering. Sie verfolgt Strahlen durch den Tiefenpuffer, um näherungsweise Reflexionen ohne die Kosten vollständigen Raytracings zu erzeugen. Die Variante mit „hierarchischer Strahlverfolgung“, die eine Min-Max-Tiefen-Mipmap verwendet, läuft effizient unter WebGL 2.

„Simulating Ocean Water“ – Jerry Tessendorf (2001). PDF. Die grundlegende Veröffentlichung zur FFT-basierten Ozeansimulation. Beschreibt das Phillips-Spektrum, ein statistisches Modell von Meereswellen, und dessen Umwandlung in eine räumliche Verschiebungskarte mittels inverser FFT. Wird von jedem großen Spiel mit realistischem Ozean verwendet, darunter Sea of Thieves, Assassin's Creed und Uncharted. Die FFT-Berechnung lässt sich direkt auf WebGPU-Compute-Shader übertragen.

„Precomputed Atmospheric Scattering“ – Bruneton und Neyret (EGSR 2008). DOI. Die Veröffentlichung hinter physikalisch korrektem Himmel-Rendering. Sie berechnet die atmosphärische Streuung in Lookup-Tabellen vor, die ein Fragment-Shader in Echtzeit abfragt. Auf Grundlage physikalischer Prinzipien entstehen korrekte Himmelsfarben, atmosphärische Perspektive – entfernte Objekte wirken bläulich oder dunstig – sowie Farben für Sonnenauf- und -untergänge. Die vorberechneten Tabellen sind klein, nur einige Hundert KB, und der Laufzeit-Shader ist ressourcenschonend. Sowohl der Sky-Shader von Three.js als auch der prozedurale Himmel von Babylon.js sind vereinfachte Versionen dieses Ansatzes.

„Ambient Occlusion Volumes“ – McGuire (HPG 2010) und „Scalable Ambient Obscurance“ – McGuire, Mara, Luebke (HPG 2012). PDF. Die Veröffentlichungen hinter modernen SSAO-Implementierungen. SAO ist die in 3D-Browser-Engines am häufigsten implementierte Variante, da sie effizient ist – eine Tiefenpuffer-Abfrage pro Pixel – und plausible Kontaktschatten erzeugt. Der Algorithmus tastet den Tiefenpuffer rund um jedes Pixel ab, um zu schätzen, wie stark es durch nahe Geometrie verdeckt wird. Sowohl Three.js als auch Babylon.js implementieren aus SAO abgeleitete SSAO-Verfahren.

Crowd-Rendering und Animation

„GPU Crowd Rendering“ – Dudash (2007) und nachfolgende GDC-/SIGGRAPH-Präsentationen zum instanzierten Crowd-Rendering. Die zentrale Technik: Frames einer Skelettanimation werden in Texturen gebacken (Vertex Animation Textures), anschließend werden Menschenmengen als instanzierte Meshes gerendert, wobei jede Instanz ihre Knochentransformationen anhand ihres aktuellen Frames aus der Animationstextur liest. Dadurch wird die Animationsauswertung von den Draw Calls entkoppelt, sodass ein einzelner instanzierter Draw Call Hunderte individuell animierter Figuren rendern kann.

„Position Based Dynamics“ – Müller et al. (2007). DOI. Die grundlegende Veröffentlichung zu PBD, dem Verfahren, mit dem moderne Spiele-Engines Stoff, Haare und weiche Körper simulieren. Rapier, unsere empfohlene Wasm-Physik-Engine, verwendet von PBD abgeleitete Solver. Bei der Avatar-Anpassung, etwa für Umhänge, fließendes Haar und lockere Kleidung, ermöglicht PBD reaktionsschnelle Simulationen mit spieltypischen Frameraten. Durch die Wasm-Implementierung läuft die Berechnung außerhalb des JavaScript-Hauptthreads. „FABRIK: Ein schneller, iterativer Löser für das Problem der inversen Kinematik“ -- Aristidou und Lasenby (2011). DOI. Die wissenschaftliche Arbeit hinter dem in unserem Avatar-Abschnitt empfohlenen IK-Löser. FABRIK arbeitet abwechselnd vom Endeffektor zur Wurzel und von der Wurzel zum Endeffektor und konvergiert innerhalb von 3–5 Iterationen. Das Verfahren ist schneller als Jacobian-basierte IK, berücksichtigt Gelenkbeschränkungen auf natürliche Weise und ist einfach zu implementieren (etwa 50 Codezeilen für den grundlegenden Löser). Sowohl die IK-Implementierungen von Three.js als auch jene von Babylon.js basieren auf FABRIK.

Virtuelle Welten und kollaborative Umgebungen

„Massively Multiplayer Online Games: Eine Übersicht über den aktuellen Stand der Technik“ -- Yahyavi und Kemme (2013). DOI. Umfassender Überblick über MMO-Architekturen, der Client-Server-Modelle, Peer-to-Peer-Ansätze, Interessenmanagement, Konsistenzmodelle, Skalierungstechniken und Betrugsprävention behandelt. Die Taxonomie der Konsistenzmodelle (strikt, letztendlich, kausal) lässt sich auf unseren CRDT-basierten Ansatz übertragen (eventuelle Konsistenz mit kausaler Reihenfolge durch Vektoruhren).

„Eine verteilte Architektur für interaktive Mehrspieleranwendungen im Internet“ -- Diot und Gautier (1999). DOI. Frühe Forschung zu verteilten virtuellen Umgebungen, die den grundlegenden Zielkonflikt identifizierte: Strikte Konsistenz erfordert Koordination und erhöht dadurch die Latenz, während schwache Konsistenz schnelle Reaktionen ermöglicht, aber sichtbare Inkonsistenzen riskiert. Die Arbeit schlägt als Mittelweg eine „lokale Verzögerung“ vor, bei der die lokale Darstellung kurz verzögert wird, damit entfernte Aktualisierungen eintreffen können. Bei Änderungen an der Welt, etwa beim Platzieren von Objekten, ist eine lokale Verzögerung von 100–200 ms nicht wahrnehmbar und gibt dem Server Zeit zur Validierung.

„Das Second-Life-Grid: Die Architektur einer nahezu zeitgenössischen virtuellen Open-Source-Welt“ -- Technische Dokumentation von Linden Lab und Reverse Engineering durch die Community. Obwohl es sich nicht um eine einzelne wissenschaftliche Arbeit handelt, ist die technische Analyse der Second-Life-Architektur umfassend dokumentiert. Die wichtigsten Erkenntnisse: Jede 256 × 256 m große Region läuft auf einer eigenen Serverinstanz. Objekte werden als Baum aus „Primitiven“ gespeichert, also Grundformen mit Transformationen, Texturen und Skripten. Der Viewer streamt Objektbeschreibungen und Texturen bei Bedarf. Dieses parzellenbasierte Modell mit objektbezogener Persistenz kommt der von uns entwickelten Architektur am nächsten, und der mehr als 20-jährige Betrieb von Second Life beweist, dass es skalierbar ist.

Webgrafik und Browserleistung

„WebGPU: Eine leistungsstarke Grafik-API für das Web“ -- W3C GPU for the Web Working Group (seit 2023). Spezifikation. Die formale Spezifikation von WebGPU. Sie ist keine wissenschaftliche Arbeit, aber das maßgebliche technische Dokument für die GPU-Programmierung im Browser. Die Spezifikation für Compute-Shader (Abschnitt 23) ist besonders relevant für die in diesem Leitfaden beschriebene Geländegenerierung, Vegetationsverteilung und Partikelsysteme.

„WebAssembly: Ein Framework zum Ausführen kompilierten Codes im Browser“ -- Haas et al. (PLDI 2017). DOI. Die ursprüngliche WebAssembly-Arbeit der Browserhersteller. Sie zeigt, dass Wasm bei rechenintensiven Aufgaben eine Leistung erreicht, die höchstens um den Faktor 2 unter nativer Ausführung liegt. Dies bestätigt unsere Empfehlung, für offene Browserwelten nach Wasm kompilierte Physik-Engines wie Rapier und Havok einzusetzen. Die Leistungsanalyse zeigt, dass der Overhead hauptsächlich durch Bereichsprüfungen und indirekte Funktionsaufrufe entsteht, nicht durch das Kompilierungsmodell selbst.

„Nicht so schnell: Analyse der Leistung von WebAssembly im Vergleich zu nativem Code“ -- Jangda et al. (USENIX ATC 2019). PDF. Ein strenger Leistungsvergleich von Wasm und nativer Ausführung. Er kommt zu dem Ergebnis, dass Wasm in der SPEC-CPU-Benchmark-Suite durchschnittlich 1,45- bis 1,55-mal langsamer als natives C ausgeführt wird. Bei Spielphysik, die viele Gleitkommaberechnungen und wenige Systemaufrufe umfasst, liegt der Overhead am unteren Ende dieses Bereichs (etwa Faktor 1,3). Dies bestätigt, dass Wasm-Physik im Browser für Echtzeit-Spielanwendungen praktikabel ist.

„Das Web mit WebAssembly auf Geschwindigkeit bringen“ -- Rossberg et al. (2018). DOI. Beschreibt die Entwurfsgrundlagen und die formale Semantik von WebAssembly. Besonders relevant ist die Erläuterung der Speichersicherheitsgarantien in Abschnitt 3. Sie erklärt, warum Wasm-Module sicher gemeinsam mit JavaScript in einem Browser-Tab ausgeführt werden können, ohne die Sicherheitsrisiken nativer Plug-ins mitzubringen. Dadurch lassen sich Physik-Engines, die traditionell als C++-Bibliotheken entwickelt wurden, sicher im Browser ausführen.

KI-gestützte Inhaltsgenerierung

„Text-zu-3D-Generierung mit bidirektionaler Diffusion unter Verwendung von 2D- und 3D-Prioren“ -- Verschiedene Forschungsgruppen (2023–2025). Mehrere aktuelle Arbeiten wie DreamFusion, Magic3D, ProlificDreamer, MVDream und Zero-1-to-3++ untersuchen die Generierung von 3D-Assets aus Texteingaben, indem sie 2D-Diffusionsmodelle als Prioren für die 3D-Optimierung verwenden. Die Qualität hat sich von Anfang 2023 bis 2025 drastisch verbessert: von unförmigen Gebilden hin zu detaillierten, texturierten Meshes. Für unsere Plattform bilden diese Modelle, die serverseitig auf GPUs ausgeführt werden, den Schritt der „KI-Generierung“ in der Asset-Pipeline für Kreative.

„DreamFusion: Text-zu-3D mithilfe von 2D-Diffusion“ -- Poole et al. (ICLR 2023). Projektseite. Die grundlegende Arbeit zu Score Distillation Sampling (SDS), bei dem ein vortrainiertes 2D-Diffusionsmodell zur Steuerung der 3D-Optimierung eingesetzt wird. Die zentrale Erkenntnis: Es werden keine 3D-Trainingsdaten benötigt, wenn ein vorhandenes 2D-Modell bewerten kann, ob gerenderte Ansichten eines 3D-Objekts zu einer Texteingabe passen. Dies ebnete den Weg für die Text-zu-3D-Generierung und bildet die Grundlage für nachfolgende Arbeiten wie Magic3D und ProlificDreamer, die Qualität und Geschwindigkeit verbessert haben.

„LRM: Großes Rekonstruktionsmodell für die Umwandlung eines einzelnen Bildes in 3D“ -- Hong et al. (ICLR 2024). Projektseite. Rekonstruiert auf einer einzelnen GPU innerhalb von fünf Sekunden ein 3D-Modell aus einem einzigen Bild. Das Modell gibt eine NeRF-ähnliche Repräsentation aus, die in ein Mesh umgewandelt werden kann. Für eine von Kreativen gestaltete Welt bedeutet das, dass jemand ein beliebiges reales Objekt fotografieren und innerhalb weniger Sekunden ein 3D-Modell erhalten könnte. Dank dieser Geschwindigkeit eignet sich das Verfahren als interaktives Werkzeug statt nur für die Stapelverarbeitung.

„Prozedurale Inhaltsgenerierung durch maschinelles Lernen (PCGML)“ -- Summerville et al. (2018). DOI. Ein Überblick über den Einsatz maschinellen Lernens zur prozeduralen Inhaltsgenerierung in Spielen. Behandelt werden die Generierung von Levels, Gegenständen, Erzählungen und Welten. Besonders relevant ist die Diskussion über „steuerbare Generierung“, bei der Designer übergeordnete Parameter festlegen und das ML-Modell die Details ergänzt. Dies ist das Paradigma für KI-gestützten Weltenbau: Kreative geben die Absicht vor („Mach dieses Gebiet zu einem unheimlichen Wald“), und die KI ergänzt Geometrie, Texturen und Bevölkerung.

Wie diese Arbeiten mit unserer Architektur zusammenhängen

Die Forschung lässt sich mehreren Schichten unserer Architektur zuordnen:

Gelände-Pipeline: Perlin-/Simplex-Rauschen (Perlin 1985, 2001) erzeugt die grundlegende Höhenkarte. Hydraulische Erosion (Mei et al. 2007) sorgt für geologischen Realismus. Geometry Clipmaps (Losasso und Hoppe 2004) oder CDLOD (Strugar 2014) rendern das Gelände effizient im Browser. Atmosphärische Streuung (Bruneton und Neyret 2008) sorgt dafür, dass weit entferntes Gelände korrekt aussieht.

Asset-Pipeline: Text-zu-3D (DreamFusion et al.) und Bild-zu-3D (LRM) erzeugen Assets serverseitig. Gaussian Splatting (Kerbl et al. 2023) ermöglicht photogrammetrische Erfassung. Neuralangelo (Li et al. 2023) extrahiert saubere Meshes aus neuronalen Aufnahmen. Alle Ausgaben werden zu browserfertigen GLB-/KTX2-Dateien verarbeitet.

Rendering: SSAO (McGuire 2012) verleiht der Szene Tiefe. Screen-Space-Reflexionen (McGuire und Mara 2014) ermöglichen die Wasserdarstellung. FFT-Ozeane (Tessendorf 2001) simulieren Wasser. Vertex-Animation-Texturen (Dudash 2007) rendern Menschenmengen. FABRIK (Aristidou und Lasenby 2011) steuert die Charakter-IK.

Netzwerk: Interessenmanagement (Boulanger et al. 2006) filtert Aktualisierungen nach räumlicher Relevanz. Koppelnavigation (Pantel und Wolf 2002) reduziert die benötigte Bandbreite. CRDTs (Shapiro et al. 2011) ermöglichen kollaboratives Bearbeiten. Clientseitige Vorhersage mit Serverabgleich (Jefferson 1985, Valve Source Networking) gewährleistet schnelle Reaktionen.

Weltgenerierung: WFC (Gumin 2016, Karth und Smith 2017) erzeugt Strukturen und Layouts. PCGML (Summerville et al. 2018) liefert das Framework für KI-gestützte Generierung, bei der Kreative ihre Absicht vorgeben und Modelle die Details ergänzen.

Die Forschung ist ausgereift. Die meisten dieser Techniken werden seit Jahren in veröffentlichten Spielen eingesetzt. Die Innovation bei ihrer Übertragung in den Browser liegt nicht in den Algorithmen. Sie liegt in der technischen Umsetzung, durch die sie innerhalb der Speicher-, GPU- und Netzwerkbeschränkungen des Browsers funktionieren – und genau damit befasst sich der Rest dieses Leitfadens.

Weiterführende Literatur

• Technologie-Stack für Webspiele im Jahr 2026 behandelt die Grundlagen von WebGL, WebGPU und WebAssembly
• Vergleich von Webspiel-Engines vergleicht Engines für die Ausführung im Browser
• Technischer Bericht zu Three.js + USDC über das Laden von 3D-Assets im Browser
• Führende Open-Source-Modelle für generative KI für die KI-Generierungspipeline
• Koop-Spieldesign über Mehrspieler-Designmuster, die Spieler langfristig motivieren
• Landschaftsgenerierung für offene Browserwelten — Gelände-, Erosions- und Vegetations-Rendering
• Grundlagen für Mehrspieler-WebSocket-Spiele — Einstieg in die Mehrspieler-Vernetzung im Browser
• Erste Schritte mit WebGPU — die Rendering-API für die nächste Generation von 3D im Browser
• Streaming-basiertes Laden von Assets — progressive Lademuster für große 3D-Welten

Probier es gleich ausProbiere jetzt direkt in deinem Browser eine offene Welt aus

Ein Satz hinein, eine begehbare 3D-Welt heraus.

Kostenlos erstellen →Kostenlos, läuft im Browser, keine Installation nötig.