ब्राउज़र में open world बनाना, भाग 1: हमने इसे तोड़ने की कोशिश से शुरुआत की
लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक
यहां नए हैं? सीरीज़ गाइड का इस्तेमाल करें। इसमें बताया गया है कि spike क्या होता है और सभी भागों के लिंक दिए गए हैं।
हम एक multiplayer open world बना रहे हैं जो पूरी तरह ब्राउज़र में चलता है। कोई install नहीं, कोई app store नहीं, बस एक URL। सबसे बड़ा risk शुरू से ही साफ था: क्या एक ब्राउज़र खेलने लायक frame rates पर एक persistent 3D world को render कर सकता है और साथ ही gameplay, physics और networking के लिए भी जगह छोड़ सकता है?
ज़्यादातर open world प्रोजेक्ट एक तय क्रम में नाकाम होते हैं। पहले आपको एक अच्छा concept मिलता है। फिर आपको एक खूबसूरत scene मिलता है। फिर आपको एहसास होता है कि gameplay के अस्तित्व में आने से पहले ही आपका frame budget खत्म हो चुका है।
हम बाकी किसी भी चीज़ में निवेश करने से पहले render budget वाले सवाल का जवाब चाहते थे। इसलिए Spike 1 ने खूबसूरत trailer को छोड़कर सीधे मापने का काम किया।
Spike 1 को नए tab में खोलें ↗ · सोर्स देखें
सेटअप जानबूझकर सरल था। एक 512 मीटर का terrain mesh, island falloff के साथ layered sine noise से बनी procedural height, एक water plane, atmospheric fog, और 500 instanced objects। हमने plain WebGL का इस्तेमाल Three.js के साथ किया, ACES tone mapping, और कोई shadows नहीं।
हमें इस बात की परवाह नहीं थी कि यह कैसा दिखता है। हमें इस बात की परवाह थी कि camera को इसमें घुमाते वक्त scene स्थिर रहता है या नहीं।
इस spike से दो चीज़ें निकलीं जिन्होंने पूरे प्रोजेक्ट को आकार दिया।
पहली, हमने पुष्टि की कि अगर हम पहले pass को अनुशासित रखें तो desktop पर हमारे पास सचमुच जगह बची हुई थी। इससे हमें बाद में मुश्किल terrain architecture आज़माने का भरोसा मिला।
दूसरी, हमने एक baseline contract बनाया। आने वाले हर spike को इस scene के मुकाबले अपनी लागत समझानी थी। अगर कोई नया feature अच्छा दिखता था लेकिन उसकी लागत बहुत ज़्यादा थी, तो उसे आगे नहीं बढ़ाया जाता था।
वह baseline अनुशासन बाद में बहुत अहम बन गया जब हम seam artifacts, mixed LOD transitions, और compute driven meshing से टकराए। एक स्थिर reference के बिना, हर bug असल से बड़ा दिखता है।
भाग 2 में हम rendering से आगे बढ़कर input feel पर जाते हैं। Worker physics architecture docs में बढ़िया लगती है। यह सिर्फ़ तभी मायने रखती है जब आप कोई key दबाएं और character अब भी तुरंत प्रतिक्रिया देता महसूस हो।
इस अध्याय में बताई गई technology
Heightmap terrain. एक 2D grid जहां हर cell एक अकेला elevation value रखता है। GPU vertex shader में एक flat mesh को विस्थापित करके terrain की सतह बनाता है। Heightmaps compact होते हैं (16-bit पर एक 65x65 chunk ~8 KB का होता है), GPU-friendly होते हैं, और render करने में तेज़ होते हैं। इसकी सीमा यह है कि ये गुफाओं, overhangs, या किसी भी ऐसी सतह को नहीं दिखा सकते जो खुद पर वापस मुड़ जाती है। heightmap की सीमाओं और उनके बाद क्या आता है, इसकी पृष्ठभूमि के लिए, हमारी landscape generation गाइड देखें।
Three.js. वह rendering library जो हमने इस पूरे प्रोजेक्ट में इस्तेमाल की। Three.js, WebGL 2 (और बाद में WebGPU) को cameras, lights, materials, और geometry objects वाले एक scene graph में बदल देती है। यह एक ही draw call में एक ही geometry की कई copies render करने के लिए InstancedMesh देती है, साथ ही frustum culling, PBR materials, और post-processing भी। GitHub पर Three.js देखें। Three.js एक ब्राउज़र open world stack में कैसे फिट होती है, इसके लिए हमारी browser 3D tech गाइड देखें।
InstancedMesh. Three.js का एक feature जो एक ही geometry की N copies को एक ही draw call से render करता है, हर एक अलग position/rotation/scale पर। प्रति-instance transforms एक matrix attribute buffer में रखे जाते हैं। इसी तरह हमने Spike 1 में 500 objects को 500 अलग draw calls के बिना render किया। बड़े पैमाने पर vegetation के लिए, GPU-driven instanced culling इसे और आगे ले जाती है। हमारी GPU vegetation culling पर landscape गाइड देखें।
Frame budget. 60 fps पर, हर frame के पास हर चीज़ के लिए
12 में से भाग 1।
आगे: भाग 2 - Worker physics और input lag का डर
सीरीज़ गाइड: /hi/blog/2026-02-25-open-world-browser-series-guide