Eine offene Welt im Browser entwickeln, Teil 3: Die unscheinbaren Spikes, die uns gerettet haben

Von Oleg Sidorkin, CTO und Mitgründer von Cinevva

Neu hier? Nutze den Serienleitfaden. Er erklärt, was ein Spike ist, und verlinkt alle Teile.

Dieser Teil enthält weniger glänzende Screenshots und mehr Absicherung für unsere Architektur.

Nach den Spikes 1 und 2 führten wir drei Risikoprüfungen durch, die klein wirkten, aber Auswirkungen auf Produktebene hatten.

Die erste betraf den Broadcast-Fan-out mit Durable Objects. Wir testeten die Verteilung von Positionen an mehrere Clients bei spieltypischen Tick-Raten und erfassten die Latenzverteilung, die CPU-Auslastung pro Tick und die Zustellintegrität. Wäre dieser Test gescheitert, hätten wir frühzeitig auf Sharding umgestellt, statt jede Insel einer einzelnen Instanz zuzuweisen.

Die zweite Prüfung galt den Einschränkungen auf Mobilgeräten. Kein in „Mobil“ umbenanntes Desktop-Preset, sondern ein ausdrücklich auf geringe Kosten ausgelegtes Profil, das auf demselben Ausgangsterrain basierte.

Mobiles Profil in einem neuen Tab öffnen ↗ · Quellcode ansehen

Wir reduzierten die Segmentdichte, die Objektanzahl, die Belastung durch die Renderauflösung und die Nebelreichweite. Die Frage war einfach: Kann diese Welt unter den Einschränkungen mobiler Geräte lesbar und reaktionsschnell bleiben, ohne den gesamten Renderer neu zu schreiben?

Die dritte Prüfung betraf die Zuverlässigkeit der Verhaltensgenerierung in den Arbeitsabläufen von Creators. Wir bewerteten die Rate gültiger JSON-Ausgaben, die semantische Korrektheit gegenüber den erwarteten Grundbausteinen und die Antwortlatenz. Wäre dieser Test gescheitert, hätten wir auf eine strikt formularbasierte Erstellung von Verhaltensweisen umgestellt.

Die wichtigste Erkenntnis aus diesem Kapitel ist, dass diese unscheinbaren Spikes die Architektur schneller veränderten als die visuellen Spikes. Sie setzten klare Grenzen für die Netzwerktopologie, unsere Versprechen für Mobilgeräte und die UX der Werkzeuge.

In Teil 4 kehren wir zur sichtbaren Arbeit am Terrain zurück und testen das Streaming-Verhalten während der Bewegung, nicht nur Screenshots statischer Ladevorgänge.

In diesem Kapitel erwähnte Technologien

Cloudflare Durable Objects. Zustandsbehaftete, serverlose Instanzen, die am Edge bereitgestellt werden und integrierte Persistenz sowie WebSocket-Unterstützung bieten. Jedes Durable Object enthält den autoritativen Zustand eines Welt-Shards (oder Chunks). Spieler verbinden sich per WebSocket und empfangen Positions-Broadcasts anderer Spieler im selben Shard. Bewegt sich ein Spieler in einen benachbarten Chunk, stellt er eine Verbindung zum Durable Object dieses Chunks her. Durable Objects speichern ihren Zustand automatisch persistent und skalieren auf Tausende gleichzeitig aktive Instanzen. Siehe die Dokumentation zu Cloudflare Durable Objects und unseren Leitfaden zu 3D-Technologien im Browser über Multiplayer-Netzwerke.

Räumliches Sharding. Die Aufteilung der Welt nach geografischen Regionen auf mehrere Serverinstanzen. Jeder Shard verwaltet einen rechteckigen Bereich des Weltrasters. Wenn sich die Spielerdichte verändert, können Shards geteilt oder zusammengeführt werden. Spieler in der Nähe einer Shard-Grenze sehen durch Shard-übergreifende Sichtbarkeitsabfragen die Inhalte beider Shards. So kann EVE Online Tausende von Spielern in einem einzigen Universum verwalten.

WebSocket-Broadcast-Fan-out. Die Verteilung von Positionsaktualisierungen in Echtzeit von einem Server an viele verbundene Clients. Die ausgehende Bandbreite pro Client skaliert linear mit der Anzahl sichtbarer Spieler:

$$B_{\text{client}}=N_{\text{visible}}\times b_{\text{player}}$$

Bei spieltypischen Tick-Raten (20–30 Hz) erzeugt jeder Spieler Positionsdaten im Umfang von $b_{\text{player}}\approx 800$ Byte pro Sekunde. 200 sichtbare Spieler verursachen somit Kosten von $200\times 800=160$ KB/s pro Client. Die naive Serverlast einer vollständigen Verteilung an alle ist noch höher und wächst mit $N^2$. Genau deshalb begrenzt die Relevanzfilterung (räumliches Interest Management) $N_{\text{visible}}$, bevor die Aktualisierungen innerhalb des Tick-Budgets an jede Verbindung gesendet werden. Unser Netzwerkleitfaden behandelt die Abwägungen bei Delta-Komprimierung und Aktualisierungsfrequenz.

Einschränkungen beim mobilen Rendering. Mobile GPUs erreichen nur 1/5 bis 1/10 des Durchsatzes von Desktop-GPUs, haben ein Speicherlimit von etwa 1 GB (gegenüber 2–4 GB auf Desktop-Systemen) und drosseln bei anhaltender Last aufgrund der Wärmeentwicklung. Ein mobiles Qualitätsprofil reduziert die Segmentdichte, die Objektanzahl, die Renderauflösung, die Sichtweite und die Schattenqualität. Das Ziel ist nicht die Gleichwertigkeit mit der Desktop-Version, sondern die Erhaltung von Lesbarkeit und Reaktionsschnelligkeit. Reale GPU-Benchmarks findest du unter Leistungskennzahlen für 3D im Browser.

---

Teil 3 von 12.
Zurück: Teil 2 – Worker-Physik und die Angst vor Eingabeverzögerungen
Weiter: Teil 4 – Streaming vor aufwendigem Terrain
Serienleitfaden: /de/blog/2026-02-25-open-world-browser-series-guide