Was es wirklich braucht, um eine offene Welt im Browser zu bauen

Von Mariana Muntean, CEO von Cinevva

Das Team von Cinevva hat gerade eines der transparentesten Engineering-Tagebücher der jüngeren Spieleentwicklungs-Geschichte veröffentlicht: eine 12-teilige Serie, die unseren Versuch dokumentiert, eine offene Multiplayer-Welt zu entwickeln, die vollständig im Browser läuft. Kein Download. Kein App-Store. Nur eine URL.

Das Projekt umfasste 24 technische Experimente, die wir „Spikes“ nennen -- kurze, gezielte Prototypen, von denen jeder eine einzelne riskante Frage beantworten sollte. Zu jedem Spike wurde lauffähiger Quellcode veröffentlicht, den man direkt im Browser öffnen und ausführen kann. Die Serie stammt von Oleg Sidorkin, CTO und Mitgründer von Cinevva, und liest sich weniger wie Marketing als wie ein Feldtagebuch von der Front dessen, was Browser im Jahr 2026 tatsächlich leisten können.

Was die Serie lesenswert macht -- selbst wenn man nie vorhat, Terrain-Systeme zu entwickeln --, ist die dahinterliegende Methode. Sie ist eine Fallstudie darüber, wie sich die Risiken eines ambitionierten Projekts reduzieren lassen, bevor man sich auf kostspielige Entscheidungen festlegt.

Mit der schwierigsten Frage anfangen

Die meisten Open-World-Projekte scheitern in einer vorhersehbaren Reihenfolge. Zuerst gibt es ein großartiges Konzept. Dann eine hübsche Szene. Anschließend stellt man fest, dass das gesamte Frame-Budget bereits aufgebraucht war, bevor überhaupt Gameplay existierte.

Unser Team kehrte diese Reihenfolge um. Der erste Spike war absichtlich hässlich: ein 512 Meter großes Terrain-Mesh, 500 instanzierte Objekte, prozedurales Höhenrauschen, eine Wasserfläche und Nebel. Keine Schatten, kein Feinschliff. Die einzige Frage lautete, ob ein Browser eine stabile Bildrate halten konnte, während sich die Kamera durch die Szene bewegte.

Er konnte es. Und dieses „Ja“ etablierte etwas, das Oleg einen „Baseline-Vertrag“ nennt -- gemessene Referenzkosten für eine minimale Szene, gegenüber denen sich jede spätere Funktion rechtfertigen musste. Wenn ein neuer Effekt großartig aussah, aber das Frame-Budget sprengte, wurde er nicht übernommen. Zumindest noch nicht.

Diese Art von Disziplin klingt selbstverständlich. In der Praxis ist sie in schnelllebigen Prototyping-Umgebungen selten, in denen sich alle für den nächsten visuellen Erfolg begeistern.

Das Physik-Wagnis

Das zweite Experiment befasste sich mit einer Architekturfrage, die Browsergame-Entwickler spaltet: Sollte die Physik im Hauptthread laufen, wo die Umsetzung einfacher ist, oder in einem Web Worker, wo sie das Rendering nicht blockieren kann?

Physik in einem Worker ist auf dem Papier sauberer. In der Praxis besteht die Sorge vor Latenz. Jedes Eingabeereignis muss zweimal eine Nachrichtengrenze überqueren: einmal auf dem Weg zum Worker und einmal, um das Ergebnis zurückzubringen. Dauert dieser Hin- und Rückweg zu lange, fühlt es sich träge an, wenn man eine Taste drückt und die Spielfigur sich daraufhin bewegt.

Das Team integrierte die Rapier-Physik-Engine (von Rust nach WebAssembly kompiliert) in einen eigenen Worker, richtete die Nachrichten-Pipeline ein und führte Messungen durch. Der Overhead war vernachlässigbar. Die Steuerung fühlte sich weiterhin unmittelbar an. Wir hielten jedoch bewusst fest, dass wir ein bestimmtes Szenario validiert hatten, keine allgemeingültige Regel. Wenn sich GPU-Last und Streaming-Komplexität später änderten, mussten die Annahmen erneut überprüft werden.

Die langweiligen Spikes, die das Projekt retteten

Teil drei der Serie enthält keine Screenshots. Er behandelt drei Experimente, die unspektakulär wirkten, aber Konsequenzen für das gesamte Produkt hatten.

Das erste prüfte, ob Cloudflare Durable Objects Echtzeitübertragungen von Positionen mit spieltypischen Tick-Raten bewältigen konnten -- das Rückgrat des Multiplayer-Systems. Wäre dies fehlgeschlagen, hätte die gesamte Netzwerkarchitektur von Anfang an auf Sharding statt auf die Verwaltung einzelner Inseln ausgelegt werden müssen.

Das zweite validierte ein mobiles Qualitätsprofil: keine umbenannte Desktop-Voreinstellung, sondern ein ausdrücklich kostengünstiger Rendering-Pfad auf Basis derselben Terrain-Baseline. Die Frage war, ob die Welt unter den Einschränkungen mobiler GPUs lesbar und reaktionsschnell bleiben konnte, ohne den Renderer neu zu schreiben.

Das dritte bewertete, ob KI-generierte Verhaltensskripte für Creator-Workflows zuverlässig genug für den produktiven Einsatz wären.

Keines dieser Experimente lieferte Material für Demo-Reels. Alle drei setzten feste Grenzen, die jede spätere Architekturentscheidung prägten. Oleg schreibt, dass diese „unspektakulären Spikes die Architektur schneller veränderten als die visuellen Spikes“.

Streaming: wo hübsche Projekte auseinanderfallen

In einem Standbild lässt sich vieles verbergen. Einen 40 Millisekunden langen Ruckler beim Überqueren einer Chunk-Grenze im Lauf kann man nicht verbergen.

Das Team testete Streaming, bevor es fortgeschrittenes Terrain entwickelte, und trennte die einzelnen Aspekte bewusst voneinander. Spike 6 validierte das Laden benachbarter Chunks mit einfachen Inhalten. Erst nach diesem eindeutigen Ergebnis führte Spike 11 das Streaming komprimierter Heightmaps mit schrittweiser Verfeinerung ein -- zunächst wurde das Terrain mit einer Auflösung von 17 Samples geladen, dann mit 33 und schließlich als vollständiges Raster mit 65 Samples.

Die Reihenfolge war wichtiger, als wir erwartet hatten. Hätten wir direkt mit komprimierten Heightmap-Chunks begonnen, wäre jeder Ruckler mehrdeutig gewesen. War die Ursache ein Dekodierungsproblem, ein Stillstand beim Textur-Upload oder ein Fehler bei der Geometrieaktualisierung? Indem wir zuerst einfaches Streaming testeten, beseitigten wir eine ganze Kategorie von Unsicherheiten.

Daraus ergab sich eine praktische Lektion: Upload-Stillstände sollten direkt gemessen werden, nicht anhand der durchschnittlichen FPS. Durchschnittswerte verbergen Frame-Spitzen, und genau diese Spitzen spüren die Spieler.

Der Kampf um das visuelle Budget

Drei separate Experimente untersuchten die Rendering-Kosten isoliert, statt sie in einem Paket zusammenzufassen: Dichte und Windanimation der Vegetation, mehrschichtige Terrain-Materialien mit triplanarem Mapping für Felswände und kaskadierte Shadow Maps unter realistischer Terrain-Last.

Der Vegetations-Spike zeigte, dass es wichtiger war, Instanzen in weniger Meshes zu bündeln, als die Polygonzahl pro Grashalm zu reduzieren. Der Material-Spike ergab, dass die triplanare Projektion auf vertikalen Flächen die GPU-Kosten wert war, eine fünfte Texture-Splat-Ebene dagegen nicht. Der Schatten-Spike stellte fest, dass drei Kaskaden mit einer Auflösung von 1024 akzeptable Kontaktschatten lieferten, ohne 2 Millisekunden GPU-Zeit zu überschreiten.

Das Team führte eine unverblümte Regel ein: Eine Funktion kommt nur weiter, wenn sie ihre Kosten mit gemessenen Frame-Time-Daten rechtfertigen kann. Diese früh festgelegte Einschränkung machte spätere Architekturentscheidungen zu volumetrischem Terrain und Clipmaps deutlich klarer.

Der Wendepunkt, der den Verlauf des Projekts veränderte

Vor Spike 10 lautete unser Denkmodell: „Eine größere Welt bedeutet mehr Geometrie.“ Nach Spike 10 hieß es: „Konstantes Geometriebudget, kamerazentrierte Ringaktualisierungen.“

Geometrie-Clipmaps -- konzentrische Terrain-Ringe rund um die Kamera, wobei jeder Ring zunehmend gröber wird -- sorgten dafür, dass die Dreiecksanzahl unabhängig von der Sichtweite ungefähr konstant blieb. Der praktische Kniff war Geomorphing an den Ringgrenzen: Die Vertex-Höhen wurden im Shader weich überblendet, sodass der Wechsel zwischen den Auflösungsstufen in Bewegung unsichtbar blieb.

Eine subtile Erkenntnis betraf die Testmethodik. Clipmaps sehen auf Screenshots gut aus. Ihre Artefakte zeigen sich erst bei kontinuierlicher Kamerabewegung über Ringgrenzen hinweg. Das Team verbrachte viel Zeit mit Durchläufen bei konstanter Geschwindigkeit und achtete dabei auf zeitliches Rauschen. „Screenshots haben gelogen“, schreibt Oleg. „Die Bewegung zeigte die Wahrheit.“

Unter die Erde

Heightmaps können keine Höhlen darstellen. Sie speichern für jeden Punkt eines Rasters einen einzelnen Höhenwert. Sobald Tunnel, Überhänge oder ausgeformte Felswände benötigt werden, braucht man volumetrisches Terrain.

Spike 12 implementierte Marching Cubes auf der GPU mithilfe von WebGPU-Compute-Shadern und extrahierte Dreiecks-Meshes aus einem dreidimensionalen Signed Distance Field. Vier Chunks mit jeweils 64³ Zellen liefen gleichzeitig und erhielten Frame für Frame Mesh-Aktualisierungen aus animierten SDF-Bearbeitungen. Der Compute-Shader erledigte alles -- die Auswertung des Feldes, die Klassifizierung der Zellen und die Ausgabe der Vertices -- ohne jegliches CPU-Readback.

Die Herausforderung bestand nicht darin, es zum Laufen zu bringen. Sie bestand darin, es gemeinsam mit allem anderen zum Laufen zu bringen. Die Integration in den Szenengraphen von Three.js, die Verwaltung des Buffer-Lebenszyklus (WebGPU-Buffer können nicht in ihrer Größe verändert werden), der Umgang mit Fences, um zu verhindern, dass noch verwendete GPU-Ressourcen zerstört werden -- die Serie widmet diesem von uns als „inkrementelle Härtung“ bezeichneten Prozess zwei vollständige Teile: dem unspektakulären Vorgehen, jeweils eine Fähigkeit hinzuzufügen und nach jeder Ergänzung zu überprüfen, ob die vorherige Ebene weiterhin funktioniert.

Der Albtraum mit den Übergängen

Der technisch nervenaufreibendste Abschnitt der Serie erstreckt sich über die Teile 9 bis 11 und behandelt die Frage, was geschieht, wenn Terrain-Chunks mit unterschiedlichen Auflösungen aufeinandertreffen.

Liegt ein detailreicher Chunk neben einem weniger detaillierten Chunk, stimmen ihre unabhängig erzeugten Meshes an der Grenze nicht überein. Das Ergebnis sind sichtbare Risse, flackernde Kanten und T-Kreuzungen, durch die Licht dringt. Der Transvoxel-Algorithmus löst dieses Problem mit speziellen Übergangszellen, die Auflösungsunterschiede überbrücken -- doch die korrekte Implementierung für alle Chunk-Konfigurationen, mit einheitlicher Winding Order, ordnungsgemäßer Buffer-Verwaltung und präzisen Draw Ranges, erforderte sechs separate Experimente.

Die einprägsamste Debugging-Geschichte des Teams: Zwei Tage lang jagten wir einem Übergangsartefakt hinterher, für das wir die Übergangslogik verantwortlich machten. Der tatsächliche Übeltäter waren veraltete Daten. Der GPU-Compute-Shader schrieb N Vertices in einen Buffer, doch der Draw Call war weiterhin so konfiguriert, dass er N+M Vertices aus dem vorherigen Frame renderte. Diese zusätzlichen Vertices enthielten Datenmüll, der flackernde, rasiermesserdünne Dreiecke erzeugte. Die Korrektur bestand aus einer einzigen Zeile: Die Draw Range wurde auf die aktive Vertex-Anzahl des atomaren Zählers begrenzt.

„Rendering-Fehler tarnen sich oft als Meshing-Fehler“, stellt Oleg fest. „Die Geometrie war die ganze Zeit korrekt.“

Vom Chaos zur Steuerung

Nach dem Kampf mit den Übergängen ersetzte das Team das Ad-hoc-Verhalten der Chunks durch ein explizites Regelsystem. Eine zentrale Funktion entschied nun über die LOD-Stufe jedes Chunks, seinen Rendering-Modus (Heightmap oder Marching Cubes) und darüber, welche Flächen Übergangszellen benötigten. Distanzringe bestimmten das grundlegende LOD. Eine Nachbarschaftsregel stellte sicher, dass sich zwei benachbarte Chunks um höchstens eine Auflösungsstufe unterschieden. Eine Bearbeitungs-Bitmap hielt volumetrische Chunks unabhängig von ihrer Entfernung im Marching-Cubes-Modus, wenn sie Änderungen von Creatorn enthielten.

Farbcodierte Debug-Overlays -- Grün für Heightmap-Chunks, Blau für Marching-Cubes-Chunks, Orange für Übergangsflächen -- verwandelten „Ich habe irgendwo in der Nähe dieses Bergrückens einen Fehler gesehen“ in „Der Fehler tritt an Position (142, 12, -67) mit Blick nach Nordwesten auf.“

„Die Regeln haben die Komplexität nicht verringert“, schreibt Oleg. „Sie haben die Komplexität organisiert.“

Was dabei herauskommt

Der letzte Spike kombinierte Clipmap-Ringe, Sky-Fog pro Fragment (wobei die tatsächliche Farbe der Skybox in Richtung jedes Terrain-Fragments abgetastet wurde) und die Three.js-Modulverdrahtung zu einer einheitlichen Demonstration. Das Ergebnis ist ein Terrain-System, das volumetrische Bearbeitung im Nahbereich, Heightmap-Chunks im mittleren Bereich und Clipmap-Ringe im Fernbereich unter einer Regelschicht kombiniert, die Modus, LOD und Übergänge steuert.

Die Serie endet mit Lektionen, die Oleg nach eigener Aussage bei jedem zukünftigen Projekt erneut anwenden würde:

• Beginnt vor der Feature-Entwicklung mit Risiko-Spikes. Klärt die Fragen „Können wir das überhaupt umsetzen?“, bevor ihr in Content-Pipelines investiert.
• Friert bekanntermaßen funktionierende Baselines vor großen Integrationsschritten ein. Der Tag, den ihr in einen sauberen Prüfpunkt investiert, spart später mehrere Tage bei der Eingrenzung von Regressionen.
• Erzwingt klare Regeln und Beobachtbarkeit vor Optimierungsmarathons. Benannte Bedingungen mit Auslöseregeln schlagen rätselhafte Fehler jedes Mal.
• Testet in Bewegung, nicht anhand von Screenshots. Aufploppen, Flackern und Streaming-Ruckler bleiben in Standbildern verborgen.
• Messt die Frame-Zeit pro Feature, nicht die durchschnittlichen FPS. Durchschnittswerte verbergen die Spitzen, die Nutzer tatsächlich spüren.
• Veröffentlicht auch die chaotischen Teile. Die Irrwege, die Jagd nach Phantomfehlern, die zwei Tage, an denen das falsche System verdächtigt wurde. Das sind die Teile, aus denen andere wirklich lernen können.

Warum das über Cinevva hinaus relevant ist

Die Serie ist aus drei Gründen bedeutsam, die über die Terrain-Pipeline eines einzelnen Unternehmens hinausgehen.

Erstens zeigt sie, dass WebGPU-Compute-Shader, WebAssembly-Physik und am Edge bereitgestellte Durable Objects einen Schwellenwert überschritten haben. Eine offene Multiplayer-Welt mit volumetrischem Terrain, Echtzeitbearbeitung und Streaming-LOD ist 2026 in einem Browser-Tab architektonisch realisierbar. Vor zwei Jahren traf das noch nicht zu.

Zweitens bietet die Spike-Methodik -- kleine, gezielte Experimente, die jeweils eine riskante Frage mit lauffähigen, messbaren Ergebnissen beantworten -- eine Vorlage für jedes Team, das etwas versucht, dessen Erfolg nicht sicher ist. Die Disziplin, vor einer Festlegung zu messen, vor der Integration Baselines zu schaffen und Grenzfälle vor der Optimierung zu benennen, ist weit über Terrain-Systeme hinaus anwendbar.

Drittens ist die radikale Transparenz der eigentliche Punkt. Die Veröffentlichung des Quellcodes für alle 24 Experimente, einschließlich der Sackgassen und der zweitägigen Debugging-Umwege, macht daraus mehr als einen technischen Blog. Es ist ein öffentliches Engineering-Notizbuch, das seine Leser als Kollegen statt als Kunden behandelt. Die vollständige Artikelreihe findest du in unserem Serienleitfaden, wobei jeder Prototyp direkt im Browser läuft.

---

Dieser Artikel wurde ursprünglich auf Medium veröffentlicht.