ब्राउज़र में open world बनाने में असल में क्या लगता है

लेखक Mariana Muntean, Cinevva की CEO

Cinevva की टीम ने हाल के game-dev इतिहास की सबसे पारदर्शी engineering डायरियों में से एक प्रकाशित की है: एक 12-भाग वाली सीरीज़ जो एक ऐसा multiplayer open world बनाने की हमारी कोशिश को दर्ज करती है जो पूरी तरह ब्राउज़र में चलता है। कोई download नहीं। कोई app store नहीं। बस एक URL।

यह प्रोजेक्ट 24 तकनीकी प्रयोगों तक फैला था जिन्हें हम "spikes" कहते हैं, यानी छोटे और केंद्रित prototypes जो हर एक किसी एक जोखिम भरे सवाल का जवाब देने के लिए बनाए गए। हर spike के साथ live सोर्स कोड आता है जिसे आप अभी अपने ब्राउज़र में खोलकर चला सकते हैं। सीरीज़ को Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक, ने लिखा है, और यह marketing से कम और 2026 में ब्राउज़र असल में क्या कर सकते हैं इसके मोर्चे से लिखी एक फील्ड डायरी जैसी ज़्यादा पढ़ने में आती है।

सीरीज़ को पढ़ने लायक बनाने वाली बात, चाहे आप कभी terrain systems बनाने की योजना न भी रखते हों, इसके नीचे छिपा तरीका है। यह इस बात का केस स्टडी है कि किसी महत्वाकांक्षी प्रोजेक्ट को महंगी किसी चीज़ पर प्रतिबद्ध होने से पहले कैसे de-risk किया जाए।

सबसे मुश्किल सवाल से शुरुआत

ज़्यादातर open-world प्रोजेक्ट एक तय क्रम में नाकाम होते हैं। पहले आपको एक खूबसूरत concept मिलता है। फिर एक सुंदर scene। फिर आपको पता चलता है कि gameplay के अस्तित्व में आने से पहले ही आपका frame budget खर्च हो चुका था।

हमारी टीम ने क्रम को उलट दिया। पहला spike जानबूझकर भद्दा था: एक 512 मीटर का terrain mesh, 500 instanced objects, procedural height noise, एक water plane और fog। न shadows, न beauty pass। इकलौता सवाल यह था कि क्या ब्राउज़र camera के उसमें घूमते वक्त एक स्थिर frame rate बनाए रख सकता है।

रख सकता था। और उस "हां" ने एक ऐसी चीज़ स्थापित की जिसे Oleg "baseline contract" कहते हैं, यानी एक न्यूनतम scene के लिए एक मापा गया reference cost जिसके सामने हर अगले feature को खुद को सही ठहराना होता था। अगर कोई नया effect शानदार दिखता था पर frame budget को उड़ा देता था, तो वह ship नहीं होता था। कम से कम अभी नहीं।

इस तरह का अनुशासन साफ नज़र आने वाली बात लगती है। हकीकत में, तेज़ी से बदलते prototype माहौल में यह दुर्लभ है, जहां हर कोई अगली visual जीत को लेकर उत्साहित रहता है।

physics वाला दांव

दूसरे प्रयोग ने एक architectural बहस को सुलझाया जो ब्राउज़र game developers को बांटती है: क्या physics को main thread पर चलना चाहिए, जहां यह आसान है, या एक Web Worker में, जहां यह rendering को block नहीं कर सकती?

Worker-आधारित physics कागज़ पर ज़्यादा साफ-सुथरी है। हकीकत में, डर latency का है। हर input event को एक message boundary दो बार पार करनी पड़ती है: एक बार worker तक पहुंचने के लिए, एक बार result वापस लाने के लिए। अगर यह आना-जाना बहुत धीमा हो, तो कोई key दबाने और अपने character को हिलते देखने के बीच चीज़ें सुस्त महसूस होंगी।

टीम ने Rapier physics engine (Rust से WebAssembly में compile किया गया) को एक dedicated worker में जोड़ा, message pipeline तैयार किया, और मापा। overhead नगण्य था। controls अब भी तुरंत महसूस होते थे। लेकिन हमने सावधानी से यह नोट किया कि हमने एक खास scenario को verify किया था, कोई सार्वभौमिक नियम नहीं। जब बाद में GPU दबाव और streaming की जटिलता बदली, तो धारणाओं को फिर से जांचना ज़रूरी होगा।

वे उबाऊ spikes जिन्होंने प्रोजेक्ट को बचाया

सीरीज़ के तीसरे भाग में कोई screenshots नहीं हैं। इसमें तीन ऐसे प्रयोग शामिल हैं जो दिखने में साधारण लगते थे पर जिनके product स्तर के नतीजे थे।

पहले ने यह जांचा कि क्या Cloudflare Durable Objects game जैसे tick rates पर real-time position broadcasts संभाल सकते हैं, यानी multiplayer की रीढ़। अगर यह नाकाम होता, तो पूरे network architecture को single-island ownership के बजाय शुरुआती sharding की ज़रूरत पड़ती।

दूसरे ने एक mobile quality profile को verify किया: कोई desktop preset का नाम बदलकर नहीं, बल्कि उसी terrain baseline से एक स्पष्ट कम-लागत वाला rendering path। सवाल यह था कि क्या renderer को दोबारा लिखे बिना world mobile GPU की पाबंदियों के तहत पठनीय और responsive बना रह सकता है।

तीसरे ने यह आंका कि क्या creator workflows के लिए AI-generated behavior scripts production इस्तेमाल के लिए भरोसेमंद हो पाएंगे।

इनमें से किसी ने demo reels नहीं बनाई। तीनों ने ऐसी सख्त सीमाएं तय कीं जिन्होंने उसके बाद के हर architectural फैसले को आकार दिया। Oleg लिखते हैं कि इन "साधारण दिखने वाले spikes ने visual spikes के मुकाबले architecture को ज़्यादा तेज़ी से बदला।"

streaming: जहां सुंदर प्रोजेक्ट बिखर जाते हैं

आप एक स्थिर frame में बहुत कुछ छिपा सकते हैं। दौड़ते वक्त किसी chunk boundary को पार करते समय की 40-millisecond की stutter आप नहीं छिपा सकते।

टीम ने advanced terrain बनाने से पहले streaming की जांच की, जानबूझकर चिंताओं को अलग रखते हुए। Spike 6 ने सरल content के साथ neighborhood chunk loading को verify किया। उस साफ signal के बाद ही Spike 11 ने progressive refinement के साथ compressed heightmap streaming पेश किया, यानी terrain को पहले 17-sample resolution पर load करना, फिर 33, फिर पूरा 65-sample grid।

यह क्रम हमारी उम्मीद से ज़्यादा मायने रखता था। अगर हमने सीधे compressed height chunks से शुरुआत की होती, तो हर hitch अस्पष्ट होती। क्या यह कोई decode समस्या थी, कोई texture upload stall, या कोई geometry update दिक्कत? पहले सरल streaming की जांच ने अनिश्चितता की एक पूरी श्रेणी को खत्म कर दिया।

एक व्यावहारिक सबक उभरा: upload stalls को सीधे मापें, average FPS के ज़रिए नहीं। averages frame spikes को छिपा देते हैं, और frame spikes ही वह चीज़ हैं जो players को असल में महसूस होती हैं।

visual budget की लड़ाइयां

तीन अलग-अलग प्रयोगों ने rendering costs पर एक साथ बंडल करने के बजाय अलग-अलग हमला किया। Vegetation घनत्व और wind animation। cliff faces के लिए triplanar mapping के साथ multi-layer terrain materials। वास्तविक terrain load के तहत cascaded shadow maps।

vegetation spike ने दिखाया कि instances को कम meshes में batch करना प्रति-blade polygon count घटाने से ज़्यादा मायने रखता था। material spike ने पाया कि vertical surfaces पर triplanar projection GPU cost के लायक थी, पर पांचवीं texture splat layer जोड़ना नहीं। shadow spike ने तय किया कि 1024 resolution पर तीन cascades 2 milliseconds से ज़्यादा GPU time लिए बिना स्वीकार्य contact shadows देते थे।

टीम ने एक सीधा नियम अपनाया: कोई feature तभी आगे बढ़ता है जब वह मापे गए frame-time data के साथ अपनी लागत समझा सके। शुरू में तय की गई इस पाबंदी ने volumetric terrain और clipmaps के इर्द-गिर्द बाद के architectural फैसलों को काफी साफ-सुथरा बना दिया।

वह मोड़ जिसने प्रोजेक्ट की दिशा बदल दी

Spike 10 से पहले, हमारा मानसिक मॉडल था "बड़ा world यानी ज़्यादा geometry।" Spike 10 के बाद, यह बन गया "स्थिर geometry budget, camera-केंद्रित ring updates।"

Geometry clipmaps, यानी camera पर केंद्रित terrain के संकेंद्रित rings जिनमें हर ring उत्तरोत्तर मोटा होता जाता है, का मतलब था कि draw distance चाहे जो हो, triangle count लगभग स्थिर रहता था। व्यावहारिक तरकीब ring boundaries पर geomorphing की थी: shader में vertex heights को सहजता से blend करना ताकि resolution levels के बीच का बदलाव गति में अदृश्य रहे।

एक सूक्ष्म सबक testing methodology से आया। Clipmaps screenshots में ठीक लगते हैं। वे अपने artifacts केवल ring boundaries से होकर लगातार camera गति के तहत ही दिखाते हैं। टीम ने स्थिर गति से traversals चलाने और temporal noise पर नज़र रखने में समय लगाया। "Screenshots ने झूठ बोला," Oleg लिखते हैं। "गति ने सच बताया।"

ज़मीन के नीचे जाना

Heightmaps गुफाओं को नहीं दर्शा सकते। वे एक grid पर हर बिंदु के लिए एक elevation मान संग्रहित करते हैं। जिस पल आपको tunnels, overhangs, या तराशी हुई चट्टानें चाहिए, उसी पल आपको volumetric terrain चाहिए।

Spike 12 ने WebGPU compute shaders का इस्तेमाल करके GPU पर marching cubes लागू किया, एक 3D signed distance field से triangle meshes निकालते हुए। चार 64-cubed chunks animated SDF edits से प्रति-frame mesh updates के साथ एक साथ चले। compute shader ने सब कुछ संभाला, यानी field का मूल्यांकन, cells का वर्गीकरण, vertices का उत्सर्जन, बिना किसी CPU readback के।

चुनौती इसे काम करवाना नहीं थी। चुनौती इसे बाकी सब चीज़ों के साथ काम करवाना थी। Three.js के scene graph के साथ एकीकरण, buffer lifecycle management (WebGPU buffers का आकार नहीं बदला जा सकता), अब भी in flight GPU resources को नष्ट होने से बचाने के लिए fence handling, इस सबके लिए सीरीज़ दो पूरे भाग समर्पित करती है, जिसे हम "incremental hardening" कहते हैं, यानी एक बार में एक क्षमता जोड़ने और हर जोड़ के बाद यह जांचने की साधारण प्रक्रिया कि पिछली layer अब भी काम करती है।

seam का दुःस्वप्न

सीरीज़ का तकनीकी रूप से सबसे डरावना हिस्सा भाग 9 से 11 तक फैला है, जो उस बात को कवर करता है जो तब होती है जब अलग-अलग resolutions वाले terrain chunks मिलते हैं।

जब एक high-detail chunk एक low-detail chunk के बगल में होता है, तो उनके स्वतंत्र रूप से बनाए गए meshes boundary पर मेल नहीं खाते। नतीजा होते हैं दिखने वाले cracks, झिलमिलाते edges, और T-junctions जहां से light रिसती है। Transvoxel algorithm इसे खास transition cells से हल करता है जो resolution अंतर को पाटते हैं, पर इसे सभी chunk configurations में सही ढंग से लागू करना, सही winding order, उचित buffer management और सटीक draw ranges के साथ, छह अलग-अलग प्रयोगों में खर्च हुआ।

टीम की सबसे यादगार debugging कहानी: एक seam artifact का दो दिन पीछा करना जिसका दोष हमने transition logic पर मढ़ा। असली अपराधी stale data था। GPU compute shader ने एक buffer में N vertices लिखे, पर draw call अब भी पिछले frame के N+M vertices को render करने के लिए configured था। उन अतिरिक्त vertices में कचरा था जो झिलमिलाते, उस्तरे जैसे पतले triangles पैदा करता था। एक line का fix: draw range को atomic counter की active vertex count तक clip करना।

"Rendering bugs अक्सर meshing bugs का भेस धारण कर लेते हैं," Oleg कहते हैं। "Geometry पूरे समय सही थी।"

अराजकता से शासन तक

seam की लड़ाई के बाद, टीम ने तदर्थ chunk व्यवहार को एक स्पष्ट policy system से बदला। अब एक central function ने हर chunk का LOD स्तर, rendering mode (heightmap या marching cubes), और किन faces को transition cells की ज़रूरत थी, यह तय किया। Distance rings ने base LOD तय किया। एक adjacency constraint ने यह सुनिश्चित किया कि कोई भी दो पड़ोसी chunks एक से ज़्यादा resolution स्तर से अलग न हों। एक edit bitmap ने volumetric chunks को distance चाहे जो हो, marching-cubes mode में रखा अगर उनमें creator संशोधन हों।

रंग-कोडित debug overlays, यानी heightmap chunks के लिए हरा, marching cubes के लिए नीला, transition faces के लिए नारंगी, ने "मैंने उस ridge के पास कहीं एक bug देखा" को "bug position (142, 12, -67) पर उत्तर-पश्चिम की ओर दिखता है" में बदल दिया।

"Policy ने जटिलता घटाई नहीं," Oleg लिखते हैं। "इसने जटिलता को व्यवस्थित किया।"

इन सबका कुल जोड़

आखिरी spike ने clipmap rings, प्रति-fragment sky fog (हर terrain fragment की दिशा में असल skybox रंग को sample करते हुए), और Three.js module wiring को एक एकीकृत प्रदर्शन में मिलाया। नतीजा एक ऐसा terrain system है जो near-field volumetric editing, mid-field heightmap chunks, और far-field clipmap rings को एक policy layer के तहत परत-दर-परत रखता है जो mode, LOD और transitions को नियंत्रित करती है।

सीरीज़ उन सबकों के साथ समाप्त होती है जिन्हें Oleg कहते हैं कि वे किसी भी भविष्य के प्रोजेक्ट पर दोहराएंगे:

• feature काम से पहले risk spikes से शुरुआत करें। content pipelines में निवेश करने से पहले "क्या हम यह कर भी सकते हैं?" वाले सवालों को खत्म करें।
• integration छलांगों से पहले known-good baselines को freeze करें। एक साफ checkpoint स्थापित करने में बिताया गया दिन बाद में regressions को bisect करने के कई दिन बचाता है।
• optimization marathons से पहले policy और observability को अनिवार्य करें। trigger rules वाली नामित परिस्थितियां हर बार रहस्यमय bugs को मात देती हैं।
• गति के तहत जांचें, screenshots से नहीं। Pops, flicker, और streaming hitches सब स्थिर frames में छिप जाते हैं।
• प्रति-feature frame time मापें, average FPS नहीं। averages उन spikes को छिपा देते हैं जो users को असल में महसूस होती हैं।
• गड़बड़ हिस्सों को प्रकाशित करें। गलत मोड़, भूत का पीछा, गलत system को दोष देने के दो दिन। ये वही हिस्से हैं जिनसे लोग असल में सीख सकते हैं।

Cinevva से परे यह क्यों मायने रखता है

सीरीज़ तीन वजहों से महत्वपूर्ण है जो एक कंपनी की terrain pipeline से आगे जाती हैं।

पहली, यह दिखाती है कि WebGPU compute shaders, WebAssembly physics, और edge पर deploy किए गए Durable Objects एक दहलीज़ पार कर चुके हैं। volumetric terrain, real-time editing, और streaming LOD वाला एक multiplayer open world 2026 में एक ब्राउज़र tab में architecturally व्यावहारिक है। दो साल पहले यह सच नहीं था।

दूसरी, spike methodology, यानी छोटे और केंद्रित प्रयोग जिनमें हर एक live, मापने योग्य नतीजों के साथ किसी एक जोखिम भरे सवाल का जवाब देता है, किसी भी ऐसी टीम के लिए एक template देती है जो ऐसा कुछ करने की कोशिश कर रही है जो शायद काम न करे। प्रतिबद्ध होने से पहले मापने का, एकीकृत करने से पहले baselines स्थापित करने का, optimize करने से पहले edge cases को नाम देने का अनुशासन terrain systems से कहीं आगे लागू होता है।

तीसरी, आमूल पारदर्शिता ही असल बात है। सभी 24 प्रयोगों के लिए सोर्स कोड प्रकाशित करना, dead ends और दो-दिन वाले debugging चक्करों समेत, इसे एक तकनीकी blog से कहीं ज़्यादा बना देता है। यह एक सार्वजनिक engineering नोटबुक है जो पाठक को ग्राहक के बजाय एक सहकर्मी की तरह मानती है।

पूरी सीरीज़ हमारी सीरीज़ गाइड में उपलब्ध है, जिसमें हर spike ब्राउज़र में live चल रहा है।

---

यह लेख मूल रूप से Medium पर प्रकाशित हुआ था।