ब्राउज़र में open world बनाना, भाग 2: Worker physics और input lag का डर
लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक
यहां नए हैं? सीरीज़ गाइड का इस्तेमाल करें। इसमें बताया गया है कि spike क्या होता है और सभी भागों के लिंक दिए गए हैं।
अगर आप काफी समय तक ब्राउज़र multiplayer बनाते रहें, तो आखिरकार आपको यह बहस सुनने को मिलती है।
"Worker में physics साफ-सुथरा architecture है। Main thread पर physics ज़्यादा सुरक्षित महसूस होता है।"
दोनों सच हो सकते हैं। जो मायने रखता है वह है control का एहसास और असली input के तहत latency।
Spike 2 इसी का जवाब देने के लिए बनाया गया था, राय से नहीं बल्कि माप से।
Spike 2 को नए tab में खोलें ↗ · सोर्स देखें
हमने Spike 1 का terrain दोबारा इस्तेमाल किया और Rapier को एक समर्पित module worker में जोड़ा। Input state हर frame पर worker को भेजा जाता था, simulation वहीं step होती थी, और authoritative position वापस renderer के पास आती थी।
मुख्य metrics थे input से दिखने वाले movement तक की latency और physics step की timing। हमने सामान्य movement, sprint bursts, और jump cadence के दौरान jitter पर भी नज़र रखी।
नतीजा उम्मीद से बेहतर रहा। हमारे message shape और cadence के साथ, worker boundary latency पर हावी नहीं हुई। Controls अब भी तुरंत महसूस होते थे, और players को बस यही चीज़ मायने रखती है।
इस चरण की एक चुनौती थी interpretation का risk। एक सफल नतीजे के बाद, teams अक्सर बहुत ज़्यादा सामान्यीकरण कर लेती हैं और मान लेती हैं कि architecture का सवाल हमेशा के लिए बंद हो गया। ऐसा नहीं है। हमने सिर्फ एक ठोस scenario और hardware profile को validate किया था। बाद के spikes को भी अपनी धारणाओं की दोबारा जांच करनी पड़ी जब GPU और streaming का दबाव बदला।
इस spike ने हमें एक process upgrade भी दिया। हमने interactive spikes के लिए HUD में timing telemetry को by default दिखाना शुरू किया। इससे team की बातचीत "यह कुछ गड़बड़ महसूस होता है" से बदलकर "इस path ने 1.2 ms जोड़े" हो गई।
भाग 3 में हम उन कम चमक-दमक वाले experiments को देखेंगे जिन्होंने बाद में महंगे झटकों से बचाया। Broadcast load, mobile की पाबंदियां, और behavior generation की भरोसेमंदी।
इस अध्याय में संदर्भित technology
Rapier. Rust में लिखा गया एक physics engine जो ब्राउज़र में इस्तेमाल के लिए WebAssembly में compile होता है। यह rigid bodies, colliders, joints, character controllers, और raycasting को native से 2-3x performance पर संभालता है। Open worlds के लिए, Rapier player character controllers (terrain पर चलना, steps चढ़ना, slopes पर फिसलना), object collision, interactions के लिए raycasting, और trigger volumes देता है। देखें Rapier documentation और हमारी physics पर browser 3D tech guide।
Web Workers. ब्राउज़र threads जो JavaScript (या Wasm) को main thread से अलग चलाते हैं। Worker में physics simulation का मतलब है कि एक भारी world.step() call rendering को block नहीं करती। Main thread हर frame पर postMessage के ज़रिए worker को input state भेजता है और बदले में authoritative positions पाता है। Latency की कीमत है दो message hops (desktop पर हर एक ~0.1-0.5 ms)। फायदा यह है कि render thread कभी collision detection पर अटकता नहीं। Transferable objects (ArrayBuffer transfer) बड़े position arrays के लिए copy overhead को खत्म कर देते हैं।
WebAssembly (Wasm). एक binary instruction format जो ब्राउज़र में near-native speed पर चलता है। Rapier, Havok, और Recast सभी Wasm में compile होते हैं। Rapier-Wasm में physics step कुछ सौ bodies के लिए आमतौर पर 0.5-2 ms होता है, जबकि बराबर के JavaScript के लिए 5-15 ms। Wasm modules .wasm files के रूप में JavaScript glue code के साथ load होते हैं। देखें WebAssembly specification।
Input-to-visual latency. एक keypress और स्क्रीन पर उसके फलस्वरूप होने वाले visual बदलाव के बीच का समय। Movement को "तुरंत" महसूस होने के लिए, यह ~80 ms से नीचे रहना चाहिए। Worker physics setup में यह chain जुड़ती जाती है:
keydown event (main thread), worker को postMessage और वापस (
12 में से भाग 2।
पिछला: भाग 1 - हमने इसे तोड़ने की कोशिश से शुरुआत की
अगला: भाग 3 - वे बेरंग spikes जिन्होंने हमें बचाया
सीरीज़ गाइड: /hi/blog/2026-02-25-open-world-browser-series-guide