Eine offene Welt im Browser entwickeln, Teil 2: Physik im Worker und die Angst vor Eingabeverzögerungen
Von Oleg Sidorkin, CTO und Mitgründer von Cinevva
Neu hier? Nutze den Serienleitfaden. Dort erklären wir, was ein Spike ist, und verlinken alle Teile.
Wer lange genug Browser-Multiplayer-Spiele entwickelt, stößt irgendwann auf diese Diskussion.
„Physik in einem Worker ist saubere Architektur. Physik im Hauptthread fühlt sich sicherer an.“
Beides kann stimmen. Entscheidend sind das Steuerungsgefühl und die Latenz bei echten Eingaben.
Spike 2 sollte diese Frage mit Messungen beantworten, nicht mit Meinungen.
Spike 2 in einem neuen Tab öffnen ↗ · Quellcode ansehen
Wir verwendeten das Terrain aus Spike 1 erneut und integrierten Rapier in einen dedizierten Modul-Worker. Der Eingabestatus wurde in jedem Frame an den Worker gesendet, dort wurde die Simulation ausgeführt und die maßgebliche Position anschließend an den Renderer zurückgegeben.
Die wichtigsten Messwerte waren die Latenz zwischen Eingabe und sichtbarer Bewegung sowie die Dauer der Physikschritte. Außerdem achteten wir bei normalen Bewegungen, kurzen Sprints und regelmäßigen Sprüngen auf Ruckler.
Das Ergebnis war besser als erwartet. Mit unserer Nachrichtenstruktur und Übertragungsfrequenz hatte die Worker-Grenze keinen maßgeblichen Einfluss auf die Latenz. Die Steuerung fühlte sich weiterhin unmittelbar an – und nur das würde die Spielenden interessieren.
Eine Herausforderung dieser Phase war das Risiko von Fehlinterpretationen. Nach einem erfolgreichen Ergebnis verallgemeinern Teams häufig zu stark und gehen davon aus, dass die Architekturfrage für immer geklärt sei. Das ist sie nicht. Wir hatten lediglich ein konkretes Szenario und ein bestimmtes Hardwareprofil validiert. In späteren Spikes mussten wir unsere Annahmen erneut prüfen, als die Belastung durch GPU und Streaming zunahm.
Dieser Spike verbesserte auch unseren Prozess. Bei interaktiven Spikes begannen wir, Zeitmessdaten standardmäßig im HUD anzuzeigen. Dadurch änderten sich die Gespräche im Team von „Irgendetwas fühlt sich falsch an“ zu „Dieser Pfad hat 1,2 ms hinzugefügt“.
In Teil 3 behandeln wir die weniger glamourösen Experimente, die später kostspielige Überraschungen verhinderten: Broadcast-Last, Einschränkungen auf Mobilgeräten und die Zuverlässigkeit der Verhaltensgenerierung.
In diesem Kapitel erwähnte Technologien
Rapier. Eine in Rust geschriebene Physik-Engine, die für die Verwendung im Browser zu WebAssembly kompiliert wird. Sie verarbeitet Starrkörper, Collider, Gelenke, Charakter-Controller und Raycasting mit dem Zwei- bis Dreifachen nativer Leistung. Für offene Welten bietet Rapier Charakter-Controller für Spielfiguren (Laufen auf Terrain, Überwinden von Stufen, Rutschen an Hängen), Objektkollisionen, Raycasting für Interaktionen und Trigger-Volumes. Siehe die Rapier-Dokumentation und unseren Technologieleitfaden zur Physik für 3D im Browser.
Web Workers. Browser-Threads, die JavaScript (oder Wasm) außerhalb des Hauptthreads ausführen. Eine Physiksimulation in einem Worker bedeutet, dass ein aufwendiger world.step()-Aufruf das Rendering nicht blockiert. Der Hauptthread sendet den Eingabestatus in jedem Frame über postMessage an den Worker und erhält die maßgeblichen Positionen zurück. Der Latenzaufschlag entsteht durch die beiden Nachrichtenwege (jeweils etwa 0,1–0,5 ms auf Desktop-Systemen). Der Vorteil besteht darin, dass der Rendering-Thread nie durch die Kollisionserkennung ins Stocken gerät. Übertragbare Objekte (ArrayBuffer-Transfer) vermeiden bei großen Positions-Arrays den Kopieraufwand.
WebAssembly (Wasm). Ein binäres Befehlsformat, das in Browsern mit nahezu nativer Geschwindigkeit ausgeführt wird. Rapier, Havok und Recast werden alle zu Wasm kompiliert. Ein Physikschritt in Rapier-Wasm dauert bei einigen Hundert Körpern typischerweise 0,5–2 ms, verglichen mit 5–15 ms für eine entsprechende JavaScript-Implementierung. Wasm-Module werden als .wasm-Dateien geladen, die zusammen mit dem JavaScript-Verbindungscode abgerufen werden. Siehe die WebAssembly-Spezifikation.
Latenz zwischen Eingabe und Bildausgabe. Die Zeit zwischen einem Tastendruck und der daraus resultierenden sichtbaren Änderung auf dem Bildschirm. Damit sich eine Bewegung „unmittelbar“ anfühlt, muss sie unter etwa 80 ms bleiben. Bei einer Physikberechnung im Worker addieren sich die einzelnen Glieder der Kette:
Tastendruckereignis (Hauptthread), postMessage zum Worker und zurück (
Teil 2 von 12.
Zurück: Teil 1 – Zuerst haben wir versucht, alles zum Scheitern zu bringen
Weiter: Teil 3 – Die unspektakulären Spikes, die uns gerettet haben
Serienleitfaden: /de/blog/2026-02-25-open-world-browser-series-guide