मल्टीप्लेयर क्रिएटर वर्ल्ड्स के लिए ब्राउज़र 3D ओपन वर्ल्ड टेक

हम अपने क्रिएटर्स को एक साझा ओपन वर्ल्ड में रखना चाहते हैं। कोई लॉबी नहीं। कोई गैलरी नहीं। एक जीवंत 3D स्पेस जहाँ लोग घूम सकें, बना सकें और एक-दूसरे के काम से अचानक टकरा सकें। ऐसा कुछ जो ब्राउज़र टैब में लोड हो और एक ऐसी जगह जैसा लगे जहाँ रहना सार्थक हो।

यह एक मुश्किल समस्या है। Skyrim और The Witcher 3 ने अपनी दुनिया बनाने में सैकड़ों मिलियन डॉलर खर्च किए, और फिर भी वे डेडिकेटेड हार्डवेयर पर डिस्क पर दसियों गीगाबाइट के साथ शिप होते हैं। हम एक ब्राउज़र टैब, सैकड़ों खिलाड़ियों में साझा स्टेट, और एक ऐसी दुनिया का लक्ष्य रख रहे हैं जिसे क्रिएटर्स असल में फिर से आकार दे सकें।

यह गाइड दर्ज करती है कि टेक पर रिसर्च करते हुए हमें क्या मिला। आज क्या संभव है, क्या आने वाला है, और कौन-सा आर्किटेक्चर हमें वहाँ पहुँचाएगा।

Skyrim और The Witcher से हम क्या सीख सकते हैं

टेक्नोलॉजी चुनने से पहले, यह समझना मददगार है कि दो सबसे सफल ओपन वर्ल्ड असल में कैसे काम करते हैं। उनकी तकनीकें ब्राउज़र की पाबंदियों पर हैरान कर देने वाले ढंग से अच्छी तरह बैठती हैं।

Skyrim का सेल सिस्टम

Skyrim का ओपन वर्ल्ड खिलाड़ी के चारों ओर सेल्स का 5x5 ग्रिड स्ट्रीम करता है। दूर के पहाड़ कम-रिज़ॉल्यूशन वाले इम्पोस्टर हैं। आपको कभी पता नहीं चलता।

Skyrim अपनी दुनिया को 57x37 बाहरी सेल्स के एक ग्रिड में बाँटता है, हर एक 4096x4096 गेम यूनिट (करीब 59 मीटर) का। इंजन किसी भी समय खिलाड़ी के चारों ओर सेल्स का 5x5 ग्रिड लोड करता है। जैसे-जैसे आप चलते हैं, पीछे के किनारे की सेल्स अनलोड होती हैं जबकि आगे के किनारे की सेल्स स्ट्रीम होकर आती हैं। आंतरिक स्पेस (डंजन, इमारतें) अलग वर्ल्डस्पेस होते हैं जो दरवाज़े के ट्रिगर के ज़रिए लोड होते हैं।

यह सीधे एक ब्राउज़र वर्ल्ड पर लागू होता है। आप पूरा मैप लोड नहीं करते। आप खिलाड़ी के चारों ओर का एक मोहल्ला लोड करते हैं और जैसे-जैसे वे चलते हैं चंक्स बदलते रहते हैं। मुख्य बात: Skyrim कभी आपको दूर के टेरेन की पूरी डिटेल नहीं देखने देता। यह एक मल्टी-रिज़ॉल्यूशन तरीका अपनाता है।

Skyrim में LOD (Level of Detail) टियर:

• 1-2 सेल्स के भीतर पूरी डिटेल (खिलाड़ी का तुरंत आसपास का इलाका)
• मध्यम दूरी पर सरल मेश (ऑब्जेक्ट छोटी ज्यामिति खो देते हैं)
• मध्यम दूरी से आगे पेड़ों और चट्टानों के लिए बिलबोर्ड इम्पोस्टर
• टेरेन LOD दूर के परिदृश्य के लिए पहले से बेक की गई कम-रिज़ॉल्यूशन मेश का उपयोग करता है
• ऑब्जेक्ट फेड दूरियाँ हर ऑब्जेक्ट के हिसाब से ट्यून की गई हैं (घास पहले फेड होती है, इमारतें आखिर में)

Skyrim का परिदृश्य प्रति सेल 32x32 वर्टेक्स पैच के साथ एक हाइटमैप-आधारित टेरेन का उपयोग करता है। हर पैच पर अलग टेक्सचर हो सकते हैं जो अल्फा मैप के साथ ब्लेंड होते हैं। इसे स्टोर और रेंडर करना सस्ता है। एक सेल का टेरेन डेटा किलोबाइट में नापा जाता है, मेगाबाइट में नहीं।

हम क्या लागू कर सकते हैं: चंक-आधारित स्ट्रीमिंग, हाइटमैप टेरेन, आक्रामक LOD, आंतरिक/बाहरी अलगाव, और यह विचार कि दूर का टेरेन ज्यामितीय रूप से सटीक होने की ज़रूरत नहीं रखता, बस देखने में विश्वसनीय होना चाहिए।

The Witcher 3 का स्ट्रीमिंग आर्किटेक्चर

The Witcher 3 की 136 km2 दुनिया कंटेंट-अवेयर स्ट्रीमिंग का उपयोग करती है। 200m से आगे के पेड़ सपाट इम्पोस्टर हैं। इमारतें टेरेन से अलग स्ट्रीम होती हैं।

The Witcher 3 की दुनिया Skyrim से बड़ी है (सभी क्षेत्रों में करीब 136 km2) और एक ज़्यादा परिष्कृत स्ट्रीमिंग सिस्टम का उपयोग करती है। CD Projekt RED ने एक कस्टम इंजन (REDengine 3) बनाया जहाँ दुनिया को स्ट्रीमिंग सेक्टर में बाँटा गया है, किसी सख्त ग्रिड में नहीं।

हर सेक्टर में कंटेंट लेयर्स का एक पदानुक्रम होता है:

• टेरेन 4 LOD लेवल के साथ पैच के रूप में स्ट्रीम होता है
• फोलिएज दूरी-आधारित कलिंग के साथ GPU इंस्टैंसिंग का उपयोग करता है
• स्टैटिक ज्यामिति (इमारतें, चट्टानें) टेरेन से अलग स्ट्रीम होती है
• गेमप्ले ऑब्जेक्ट (NPC, आइटम, ट्रिगर) क्वेस्ट स्टेट और निकटता के आधार पर लोड होते हैं

रेंडरर भौतिकी-आधारित मटेरियल के साथ डिफर्ड शेडिंग का उपयोग करता है। एक ट्रिक जो खास तौर पर प्रासंगिक है: The Witcher 3 आक्रामक रूप से इम्पोस्टर का उपयोग करता है। 200 मीटर दूर का पेड़ शाखाओं और पत्तियों वाला 3D मॉडल नहीं है। यह एक सपाट टेक्सचर्ड क्वाड है जो हमेशा कैमरे की ओर मुँह करता है। इंजन इन इम्पोस्टर को कई कोणों से पहले से रेंडर करता है और कैमरा हिलने पर उन्हें बदलता है। आपको कभी पता नहीं चलता क्योंकि वे काफ़ी दूर होते हैं।

वर्ल्ड कंपोज़िशन: The Witcher 3 का ओपन वर्ल्ड अलग-अलग टीमों ने एक साथ काम करते हुए परतों में बनाया था। टेरेन टीम ने परिदृश्य गढ़ा। एनवायरनमेंट आर्ट टीम ने संरचनाएँ रखीं। क्वेस्ट टीम ने ट्रिगर और NPC पाथ जोड़े। इस परतदार कंपोज़िशन सिस्टम ने एक बड़ी टीम को एक-दूसरे के काम में दखल दिए बिना काम करने दिया।

हम क्या लागू कर सकते हैं: परतदार वर्ल्ड कंपोज़िशन (क्रिएटर प्लेटफ़ॉर्म के लिए बेहद ज़रूरी), दूर के ऑब्जेक्ट के लिए इम्पोस्टर रेंडरिंग, कई लाइट स्रोतों के लिए डिफर्ड रेंडरिंग, और यह समझ कि स्ट्रीमिंग कंटेंट-अवेयर होनी चाहिए (जो आंतरिक भाग आप देख नहीं सकते उन्हें लोड न करें, जिन NPC के पास आप नहीं हैं उन्हें स्पॉन न करें)।

Breath of the Wild का केमिस्ट्री इंजन

BotW टैबलेट-श्रेणी के हार्डवेयर पर चलता है और शानदार दिखता है। सेल-शेडेड स्टाइल, वॉटरकलर डिस्टेंस फॉग, और स्क्रिप्टेड कंटेंट के बजाय सिस्टमिक इंटरैक्शन। स्टाइलाइज़्ड ओपन वर्ल्ड का गोल्ड स्टैंडर्ड।

ओपन वर्ल्ड डिज़ाइन के लिए Nintendo का तरीका सामान्य फ़ॉर्मूले को उलट देता है। दुनिया को स्क्रिप्टेड कंटेंट से भरने के बजाय, उन्होंने सिस्टमिक नियम बनाए और खिलाड़ियों को उभरते व्यवहार की खोज करने दी। आग घास में फैलती है। आँधी-तूफ़ान में धातु बिजली का संचालन करती है। हवा ऑब्जेक्ट को बहा ले जाती है। एक सुसंगत भौतिकी/रसायन परत के ज़रिए हर चीज़ हर चीज़ के साथ इंटरैक्ट करती है।

यह एक क्रिएटर वर्ल्ड के लिए मायने रखता है क्योंकि यह सुझाता है कि दुनिया खुद किसी भी अलग रखे गए ऑब्जेक्ट से ज़्यादा दिलचस्प हो सकती है। अगर क्रिएटर्स मटेरियल गुण और इंटरैक्शन नियम परिभाषित कर सकें (सिर्फ़ स्टैटिक मेश रखने के बजाय), तो दुनिया को उभरता व्यवहार मिलता है जो उन इलाकों में भी एक्सप्लोरेशन को सार्थक बनाता है जिन्हें किसी ने जानबूझकर डिज़ाइन नहीं किया।

BotW से तकनीकी सीख:

• अपेक्षाकृत कम पॉलीगॉन संख्या और रिज़ॉल्यूशन (Switch पर डॉक्ड 900p)। स्टाइलाइज़्ड सेल-शेडेड लुक कम फ़िडेलिटी को छिपा देता है। एक ब्राउज़र वर्ल्ड आज समान विज़ुअल क्वालिटी हासिल कर सकता है।
• डिस्टेंस रेंडरिंग एक टून-शेडेड फॉग का उपयोग करता है जो वॉटरकलर-स्टाइल स्काईबॉक्स में फेड हो जाता है। रेंडर करने में सस्ता, व्यवहार में सुंदर। इस तरह का वायुमंडलीय परिप्रेक्ष्य एक फ्रैगमेंट शेडर में लगभग मुफ़्त है।
• दुनिया करीब 84 km2 की है लेकिन विरल है। मैप का ज़्यादातर हिस्सा घूमने योग्य टेरेन है जिस पर रुचि के बिंदु बिखरे हुए हैं। घना कंटेंट कस्बों और श्राइन के लिए आरक्षित है। यह "विरल लेकिन दिलचस्प" तरीका The Witcher 3 के घनी आबादी वाले Novigrad की तुलना में एसेट की ज़रूरतों को नाटकीय रूप से कम कर देता है।
• भौतिकी ऑब्जेक्ट में मटेरियल टैग (लकड़ी, धातु, खाना, विस्फोटक) होते हैं जो इंटरैक्शन तय करते हैं। असली नियमों की संख्या कम है (शायद 20-30 इंटरैक्शन प्रकार) लेकिन वे ऐसे तरीकों से मिलते हैं जो अनंत महसूस होते हैं।

GTA V की वर्ल्ड लेयरिंग

GTA V का Los Santos परतदार एम्बिएंट सिस्टम के कारण जीवंत महसूस होता है: ट्रैफ़िक, पैदल यात्री, दिन का समय, मौसम। दूर की इमारतें कंपोज़िट की गई फ़ोटो हैं, 3D मॉडल नहीं।

Los Santos के लिए Rockstar का तरीका एक अलग सबक सिखाता है। GTA V की दुनिया जीवंत महसूस होती है परतदार एम्बिएंट सिस्टम के कारण, इसलिए नहीं कि हर NPC के पास एक क्वेस्ट है।

शहर में ट्रैफ़िक सिस्टम हैं जो एक सड़क नेटवर्क पर सैकड़ों वाहनों का सिमुलेशन करते हैं। पैदल यात्री रूट पर चलते हैं, खिलाड़ी पर प्रतिक्रिया देते हैं, और आपस में इंटरैक्ट करते हैं। दिन का समय आबादी के घनत्व, मौजूद NPC के प्रकार और एम्बिएंट गतिविधि को बदल देता है। मौसम ड्राइविंग भौतिकी और NPC व्यवहार को प्रभावित करता है।

एक क्रिएटर वर्ल्ड के लिए, सीख यह है कि एम्बिएंट लाइफ़ ही उस दुनिया में फ़र्क़ पैदा करती है जो म्यूज़ियम जैसी महसूस होती है और जो एक जगह जैसी महसूस होती है। साधारण व्यवहार भी (सिर के ऊपर उड़ते पक्षी, किनारे से टकराती लहरें, इमारतों के बीच चलते NPC) एक जीवंत दुनिया का भ्रम पैदा करते हैं।

GTA V से तकनीकी सीख:

• मैप 75 km2 का है और आक्रामक LOD के साथ एक स्ट्रीमिंग सिस्टम का उपयोग करता है जो वेग के आधार पर लोड करता है (तेज़ ड्राइविंग चलने से आगे तक लोड करती है)।
• GTA Online इस दुनिया में एक साथ 30 खिलाड़ियों को रखता है। 30 पर भी, Rockstar ने पाया कि उन्हें स्थानिक इंटरेस्ट मैनेजमेंट की ज़रूरत है: आपको पास के खिलाड़ियों के बारे में विस्तृत अपडेट मिलते हैं और दूर वालों के बारे में कम बार। हमारे 200-खिलाड़ी लक्ष्य पर भी वही सिद्धांत लागू होता है।
• GTA V की एसेट पाइपलाइन अब तक की सबसे कुशल में से एक है। पूरा गेम करीब 80 GB में आ जाता है, अत्यधिक टेक्सचर कम्प्रेशन, मेश शेयरिंग, और प्रोसीजरल डिटेल के कारण। इसके बिल्डिंग इंटीरियर मॉड्यूलर टुकड़ों का खूब दोबारा उपयोग करते हैं।
• गेम एक परिष्कृत इम्पोस्टर सिस्टम का उपयोग करता है जहाँ दूर की इमारतें असल में एक साथ कंपोज़िट की गई सपाट फ़ोटो हैं। खिलाड़ी को कभी पता नहीं चलता क्योंकि ट्रांज़िशन दूरियाँ विशिष्ट देखने के कोणों के हिसाब से ट्यून की गई हैं।

Elden Ring का सीमलेस ओपन वर्ल्ड

Elden Ring का 79 km2 मैप विरल खुले टेरेन को घने हाथ से बनाए गए डंजन के साथ मिलाता है। वही एनवायरनमेंट एसेट हर जगह अलग-अलग व्यवस्थाओं में दिखते हैं। जब कंपोज़िशन और लाइटिंग बदलती है तो दोहराव गायब हो जाता है।

FromSoftware ने Elden Ring को Dark Souls के उसी इंजन पर बनाया लेकिन उसे एक ओपन वर्ल्ड तक बढ़ाया। नतीजा दिलचस्प है क्योंकि यह दिखाता है कि एक अपेक्षाकृत छोटी टीम (Rockstar या CD Projekt की तुलना में) कैसे एक बड़ा ओपन वर्ल्ड बना सकती है।

ट्रिक है घनत्व में भिन्नता। Elden Ring का मैप विशाल है (करीब 79 km2) लेकिन बड़े हिस्से खुले टेरेन हैं जिनमें बिखरे हुए दुश्मन और रुचि के बिंदु हैं। घना, हाथ से बनाया गया कंटेंट (Stormveil Castle जैसे Legacy Dungeons) ओपन वर्ल्ड में जड़ा हुआ है और वही आंतरिक/बाहरी अलगाव उपयोग करता है जो Skyrim करता है।

Elden Ring से तकनीकी सीख:

• दुनिया बड़ी टाइल्स में स्ट्रीम होती है। घोड़े पर आप बहुत दूर तक देख सकते हैं, लेकिन दूर का टेरेन बेहद सरल है। पास में, डिटेल Dark Souls 3 के बराबर है।
• लोडिंग स्क्रीन केवल फ़ास्ट-ट्रैवल करते या कुछ खास डंजन में घुसते वक़्त दिखती हैं। ओपन वर्ल्ड खुद बिना रुकावट के स्ट्रीम होता है।
• गेम एनवायरनमेंट एसेट का खूब दोबारा उपयोग करता है। वही पेड़ के मॉडल, चट्टान की संरचनाएँ, और खंडहर के टुकड़े मैप भर में अलग-अलग व्यवस्थाओं में दिखते हैं। व्यवस्था और लाइटिंग में पर्याप्त विविधता के साथ, दोहराव नज़र नहीं आता। यह सीधे एक क्रिएटर वर्ल्ड पर लागू होता है जहाँ मॉड्यूलर टुकड़ों की एक लाइब्रेरी अनंत विविधता पैदा कर सकती है।
• मल्टीप्लेयर सेशन-आधारित है (दूसरे खिलाड़ियों को अपनी दुनिया में बुलाना), स्थायी नहीं। लेकिन असिंक्रोनस फ़ीचर (संदेश, ब्लडस्टेन, दूसरे खिलाड़ियों के घोस्ट) एक स्थायी सर्वर के नेटवर्किंग ओवरहेड के बिना साझा अस्तित्व का अहसास पैदा करते हैं। ये एम्बिएंट मल्टीप्लेयर फ़ीचर एक ब्राउज़र वर्ल्ड में जोड़ना सस्ता होगा।

No Man's Sky: प्रोसीजरल हर चीज़

साझा सीड से जनरेट किए गए 18 क्विंटिलियन ग्रह। हर खिलाड़ी वही ब्रह्मांड देखता है बिना उसे सर्वर पर स्टोर किए। बेस बिल्डिंग डेटा कॉम्पैक्ट है: पार्ट ID प्लस ट्रांसफ़ॉर्म।

No Man's Sky प्रोसीजरल जनरेशन का चरम उदाहरण है। एक साझा सीड से जनरेट किए गए 18 क्विंटिलियन ग्रह, ताकि हर खिलाड़ी वही ब्रह्मांड देखे बिना उसमें से कुछ भी सर्वर पर स्टोर किए।

जनरेशन पाइपलाइन चरणों में काम करती है: गैलेक्सी-स्तर के सीड तारों की स्थिति तय करते हैं, तारा सीड ग्रहों की संख्या और प्रकार तय करते हैं, ग्रह सीड टेरेन जनरेशन (मल्टी-ऑक्टेव नॉइज़), बायोम असाइनमेंट, फ़्लोरा/फ़ौना प्रजातियाँ, कलर पैलेट, और संसाधन वितरण चलाते हैं। हर चीज़ सीड से नियतात्मक रूप से कंप्यूट होती है, इसलिए वही निर्देशांक देखने वाले दो खिलाड़ी कोई ग्रह डेटा आपस में बदले बिना वही ग्रह देखते हैं।

No Man's Sky से तकनीकी सीख:

• टेरेन जनरेशन नॉइज़ फ़ंक्शन की एक श्रृंखला के साथ वॉक्सेल-आधारित मार्चिंग क्यूब्स का उपयोग करता है। इससे गुफाएँ, ओवरहैंग, और तैरते द्वीप संभव होते हैं जिन्हें हाइटमैप टेरेन दिखा नहीं सकता। बदले में प्रति चंक ज़्यादा कंप्यूट लागत आती है, लेकिन नतीजा देखने में ज़्यादा दिलचस्प टेरेन होता है।
• बेस-बिल्डिंग सिस्टम सबसे क़रीब है उस चीज़ के जिसकी हम कल्पना कर रहे हैं। खिलाड़ी ऐसी संरचनाएँ रखते हैं जो सर्वर पर बनी रहती हैं और दूसरे खिलाड़ियों को दिखती हैं। बेस डेटा कॉम्पैक्ट है (स्थिति और घुमाव वाले पार्ट की एक सूची) और तब स्ट्रीम होता है जब कोई ग्रह पर जाता है।
• गेम की शुरुआत में अनंत विविधता के बावजूद दोहराव वाले कंटेंट के लिए आलोचना हुई थी। सीड-आधारित जनरेशन अनंत टेरेन पैदा कर सकती है लेकिन सीमित आश्चर्य। सीख: प्रोसीजरल जनरेशन कैनवस के लिए काम करती है, लेकिन क्रिएटर द्वारा रखा गया कंटेंट ही किसी जगह को डिज़ाइन किया हुआ और इरादतन महसूस कराता है।
• Hello Games ने लॉन्च के सालों बाद मल्टीप्लेयर जोड़ा। 32 तक खिलाड़ी पूरी बिल्डिंग और एक्सप्लोरेशन के साथ एक सेशन साझा करते हैं। नेटवर्क मॉडल सरल है: एक खिलाड़ी होस्ट करता है, बाक़ी कनेक्ट होते हैं। स्थायी स्टेट वाले एक ब्राउज़र वर्ल्ड के लिए, एक सर्वर-अथॉरिटेटिव मॉडल बेहतर काम करता है, लेकिन No Man's Sky साबित करता है कि साझा प्रोसीजरल वर्ल्ड संभव हैं।

Minecraft: क्रिएटर वर्ल्ड्स के लिए ब्लूप्रिंट

30 करोड़ कॉपी बिकीं। 16x16 पिक्सेल टेक्सचर। पूरी तरह एडिट करने योग्य टेरेन। अनंत रूप से जनरेट। मल्टीप्लेयर। एक क्रिएटर वर्ल्ड के लिए सबसे अहम संदर्भ। ब्राउज़र क्लोन साबित करते हैं कि यह अवधारणा WebGL में काम करती है।

जो हम बना रहे हैं उसके लिए Minecraft सबसे अहम संदर्भ बिंदु है, किसी भी ग्राफ़िकल AAA टाइटल से ज़्यादा। 30 करोड़ कॉपी बिकीं। दुनिया अनंत रूप से जनरेट होती है, पूरी तरह विनाशकारी है, और मल्टीप्लेयर है। Minecraft में क्रिएटर्स सिर्फ़ ऑब्जेक्ट नहीं रखते। वे खुद टेरेन को फिर से आकार देते हैं।

Minecraft से तकनीकी सीख:

• दुनिया 16x16x384 ब्लॉक चंक्स में बँटी है। केवल खिलाड़ी के पास के चंक्स लोड होते हैं (रेंडर डिस्टेंस कॉन्फ़िगर करने योग्य है)। यह Skyrim जैसा ही चंक स्ट्रीमिंग पैटर्न है लेकिन पूरी तरह एडिट करने योग्य टेरेन के साथ।
• हर चंक एक पैलेट-कम्प्रेस्ड ब्लॉक ID की ऐरे के रूप में स्टोर होता है। केवल 5 अलग ब्लॉक प्रकार वाला एक चंक प्रति ब्लॉक पूरे ब्लॉक ID के बजाय एक 4-बिट पैलेट इंडेक्स स्टोर करता है। इससे चंक डेटा बहुत कॉम्पैक्ट हो जाता है (कम्प्रेशन के बाद आम तौर पर प्रति चंक 10-50 KB)।
• Minecraft का मल्टीप्लेयर प्रोटोकॉल अच्छी तरह दर्ज है और अपेक्षाकृत सरल है। जैसे-जैसे खिलाड़ी चलता है सर्वर चंक डेटा भेजता है। ब्लॉक बदलाव छोटे डेल्टा अपडेट के रूप में प्रसारित होते हैं (स्थिति + नया ब्लॉक प्रकार)। यह बिल्कुल वही मॉडल है जो हम क्रिएटर एडिट के लिए उपयोग करेंगे।
• गेम Java में चलता है और अब इसका C++ में एक Bedrock Edition है। ब्राउज़र-आधारित Minecraft क्लोन (ClassiCube, eaglercraft) हैं जो साबित करते हैं कि मूल अवधारणा WebGL में काम करती है। वे आम तौर पर 60fps पर 8-12 चंक रेंडर डिस्टेंस संभालते हैं, जो करीब 200-400 मीटर का दृश्य देता है।
• Minecraft का मॉडिंग इकोसिस्टम इसकी असली खाई है। मॉड नए ब्लॉक, एंटिटी, बायोम, और गेमप्ले सिस्टम जोड़ते हैं। एक क्रिएटर वर्ल्ड के लिए, यह सुझाता है कि विस्तार-योग्यता उतनी ही मायने रखती है जितना मूल अनुभव। अगर क्रिएटर्स नए इंटरैक्शन प्रकार परिभाषित कर सकें (सिर्फ़ ऑब्जेक्ट रखने के बजाय), तो दुनिया समय के साथ समृद्ध होती है।
• Redstone (Minecraft का इन-गेम वायरिंग सिस्टम) दिखाता है कि अगर आप क्रिएटर्स को सरल, संयोजन-योग्य प्रिमिटिव दें तो वे जटिल सिस्टम बनाएँगे। लॉजिक गेट, ऑटोमैटिक फ़ार्म, कैलकुलेटर। सरल नियम-सेट असाधारण जटिलता पैदा करता है। यह BotW के केमिस्ट्री इंजन जैसा ही सबक है।

AAA ओपन वर्ल्ड्स में सामान्य पैटर्न

इन सभी टाइटलों को देखते हुए, वही पैटर्न बार-बार दिखते हैं:

स्थानिक विभाजन सार्वभौमिक है। चाहे वह सेल्स हों (Bethesda), सेक्टर (CD Projekt), चंक्स (Mojang/Rockstar), या टाइल्स (FromSoftware), हर ओपन वर्ल्ड स्पेस को लोड करने योग्य इकाइयों में बाँटता है। कोई इंजन पूरी दुनिया को मेमोरी में रखने की कोशिश नहीं करता।

मल्टी-रिज़ॉल्यूशन हर चीज़। टेरेन, मेश, टेक्सचर, और यहाँ तक कि ऑडियो सभी के कई क्वालिटी लेवल होते हैं। आपको जो रिज़ॉल्यूशन मिलता है वह इस पर निर्भर करता है कि आप कितने क़रीब हैं और ऑब्जेक्ट कितना अहम है।

ऑक्लूज़न कलिंग कच्चे ट्रायएंगल थ्रूपुट से ज़्यादा मायने रखती है। जो आप देख नहीं सकते उसे रेंडर न करना, जो आप देख सकते हैं उसे ऑप्टिमाइज़ करने से ज़्यादा परफ़ॉर्मेंस बचाता है। Skyrim एक सरल दूरी-आधारित सिस्टम उपयोग करता है। The Witcher 3 बड़े ऑक्लूडर (इमारतें, चट्टानें) के साथ सॉफ़्टवेयर ऑक्लूज़न उपयोग करता है। UE5 के Nanite जैसे आधुनिक इंजन इसे हार्डवेयर ऑक्लूज़न क्वेरी के साथ और आगे ले जाते हैं।

असिंक्रोनस लोडिंग ट्रांज़िशन छिपा देती है। ये गेम ओपन वर्ल्ड के लिए लोडिंग स्क्रीन नहीं दिखाते (केवल फ़ास्ट-ट्रैवल या आंतरिक ट्रांज़िशन के लिए)। वे बैकग्राउंड थ्रेड पर कंटेंट लोड करते हैं, समानांतर में डीकम्प्रेस करते हैं, और धीरे-धीरे नया कंटेंट स्वैप करते हैं।

पॉलीगॉन संख्या के ऊपर आर्ट डायरेक्शन। Skyrim 2011 में ऐसे ग्राफ़िक्स के साथ शिप हुआ जो तब भी मामूली थे। BotW टैबलेट-श्रेणी की चिप पर चलता है और सुंदर दिखता है। Minecraft 16x16 पिक्सेल टेक्सचर उपयोग करता है और अब तक के सबसे विज़ुअली पहचाने जाने वाले गेमों में से एक है। एक ब्राउज़र वर्ल्ड के लिए, यह बहुत मायने रखता है। कम फ़िडेलिटी पर अच्छी तरह डायरेक्ट की गई आर्ट स्टाइल हमेशा एक तकनीकी रूप से उन्नत लेकिन कलात्मक रूप से सपाट दुनिया को मात देगी।

सिस्टमिक डिज़ाइन स्क्रिप्टेड कंटेंट को मात देता है। BotW का केमिस्ट्री इंजन, Minecraft के ब्लॉक इंटरैक्शन, और GTA V के ट्रैफ़िक सिस्टम सभी सरल नियमों से उभरता व्यवहार पैदा करते हैं। यह बनाने में सस्ता है, चलाने में सस्ता है, और हाथ से बनाए गए स्क्रिप्टेड अनुक्रमों से ज़्यादा खिलाड़ी कहानियाँ पैदा करता है। एक क्रिएटर वर्ल्ड के लिए, सिस्टमिक डिज़ाइन का मतलब है कि दुनिया उन इलाकों में भी दिलचस्प बनी रहती है जिन्हें किसी ने जानबूझकर डिज़ाइन नहीं किया।

क्रिएटर द्वारा रखे गए कंटेंट को स्थायित्व और दृश्यता चाहिए। Minecraft बेस, No Man's Sky बेस, और GTA Online प्रॉपर्टी सभी सेशन भर बनी रहती हैं और दूसरे खिलाड़ियों को दिखती हैं। क्रिएटर कंटेंट के लिए डेटा मॉडल हमेशा कॉम्पैक्ट होता है (पार्ट ID + ट्रांसफ़ॉर्म) जबकि विज़ुअल प्रतिनिधित्व समृद्ध होता है (क्लाइंट डेटा को पूरे 3D सीन में फैलाता है)।

रेंडरिंग: एक ब्राउज़र असल में क्या कर सकता है?

Three.js

Three.js नींव है। इसकी सबसे बड़ी कम्युनिटी है (100K से ज़्यादा GitHub स्टार), सबसे ज़्यादा उदाहरण, और सबसे व्यापक संगतता। यह WebGL 2 को अमूर्त करता है और WebGPURenderer के ज़रिए प्रयोगात्मक WebGPU सपोर्ट रखता है।

एक ओपन वर्ल्ड के लिए, Three.js आपको देता है:

• फोलिएज, चट्टानों, और दोहराई जाने वाली ज्यामिति के लिए इंस्टैंस्ड रेंडरिंग (InstancedMesh)
• अंतर्निहित LOD सिस्टम (THREE.LOD दूरी के हिसाब से मेश स्वैप करता है)
• प्रति ऑब्जेक्ट स्वचालित फ़्रस्टम कलिंग
• कस्टम BufferGeometry या हाइटमैप-आधारित PlaneGeometry के ज़रिए टेरेन
• MeshStandardMaterial और MeshPhysicalMaterial के ज़रिए PBR मटेरियल
• EffectComposer के ज़रिए पोस्ट-प्रोसेसिंग (bloom, SSAO, tone mapping)
• कस्टम कोड के ज़रिए कैस्केडेड शैडो मैपिंग संभव के साथ शैडो मैप
• प्राथमिक एसेट फ़ॉर्मेट के रूप में glTF/GLB (कॉम्पैक्ट, GPU-तैयार)

Three.js के पास टूल्स का एक सक्रिय इकोसिस्टम भी है जो ओपन वर्ल्ड के लिए मायने रखता है। three-mesh-bvh जटिल मेश पर रेकास्टिंग और स्थानिक क्वेरी को तेज़ करता है। postprocessing (vanruesc द्वारा) Three के अंतर्निहित स्टैक से ज़्यादा परफ़ॉर्मेंट पोस्ट-प्रोसेसिंग स्टैक देता है। three-gpu-pathtracing संदर्भ-गुणवत्ता वाली रेंडरिंग सक्षम करता है।

ओपन वर्ल्ड्स के लिए सीमाएँ: Three.js के पास कोई अंतर्निहित सीन ग्राफ़ नहीं है जो बड़े पैमाने पर स्ट्रीमिंग, LOD मैनेजमेंट, या स्थानिक विभाजन संभाले। आप वे ख़ुद बनाते हैं। कोई अंतर्निहित एंटिटी कंपोनेंट सिस्टम (ECS), कोई भौतिकी, और कोई टेरेन सिस्टम नहीं है। यह एक रेंडरर है, इंजन नहीं। यह असल में एक कस्टम ओपन वर्ल्ड के लिए फ़ायदा है क्योंकि आप मेमोरी लेआउट और लोडिंग रणनीति को नियंत्रित करते हैं, लेकिन इसका मतलब है शुरुआत में ज़्यादा काम।

const lod = new THREE.LOD();
lod.addLevel(highDetailMesh, 0);
lod.addLevel(mediumDetailMesh, 50);
lod.addLevel(lowDetailMesh, 200);
lod.addLevel(impostorSprite, 500);
scene.add(lod);

Babylon.js

Babylon.js दूसरा बड़ा दावेदार है। Microsoft-समर्थित, इसमें ओपन वर्ल्ड्स की विशिष्ट समस्या के लिए Three.js से ज़्यादा गहरे अंतर्निहित फ़ीचर हैं।

प्रासंगिक अंतर्निहित फ़ीचर:

• बड़े सीन की कुशल कलिंग के लिए ऑक्ट्री-आधारित सीन विभाजन
• बड़े पैमाने पर इंस्टैंस्ड रेंडरिंग के लिए Solid Particle System
• अंतर्निहित LOD और मल्टी-टेक्सचर स्प्लैटिंग के साथ हाइटमैप से टेरेन
• विज़ुअल शेडर निर्माण के लिए Node Material Editor
• WebGPU सपोर्ट (Three.js से ज़्यादा परिपक्व, क्योंकि Babylon ने पहले निवेश किया)
• Havok physics इंटीग्रेशन (Wasm-कम्पाइल्ड, प्रोडक्शन-क्वालिटी)
• प्रोग्रेसिव लोडिंग के साथ glTF स्ट्रीमिंग

Babylon का DynamicTerrain एक्सटेंशन हाइटमैप डेटा से चलते-चलते टेरेन चंक्स जनरेट करता है, LOD अपने आप संभालता है, और टेक्सचर स्प्लैटिंग सपोर्ट करता है। यह उस चीज़ के बहुत क़रीब है जो Skyrim करता है, बनिस्बत उसके जो Three.js बॉक्स से बाहर देता है।

const terrain = new BABYLON.DynamicTerrain("terrain", {
  terrainSub: 100,
  mapData: heightmapData,
  mapSubX: 1000,
  mapSubZ: 1000,
}, scene);
terrain.LODLimits = [4, 3, 2, 1];

बदलाव की क़ीमत: Babylon.js एक बड़ी लाइब्रेरी है (पूरा बिल्ड ~1-2MB मिनिफ़ाइड बनाम Three.js ~600KB पर)। लेकिन एक ओपन वर्ल्ड के लिए, आप शायद Three.js में इतना कस्टम कोड जोड़ेंगे कि आकार का फ़र्क़ नगण्य हो जाए। Babylon के पास अपना Node Material सिस्टम, इंस्पेक्टर, और डेव टूल्स भी हैं, जो इटरेशन को तेज़ करते हैं।

Babylon.js 8.0 (मार्च 2025 में रिलीज़) ने इसे यहाँ इंजन कोर के रूप में और मज़बूत किया। सभी कोर इंजन शेडर अब GLSL और WGSL दोनों में शिप होते हैं, इसलिए WebGPU बिना किसी कन्वर्ज़न लेयर के काम करता है और WebGPU बंडल पहले से करीब आधे आकार का है। उसी रिलीज़ ने Havok का पूरा कैरेक्टर कंट्रोलर इंजन में लाया, एरिया लाइट्स, एक दोबारा बनाया गया ऑडियो इंजन, और Gaussian splatting सुधार (SPZ और कम्प्रेस्ड PLY फ़ॉर्मेट, स्फेरिकल हार्मोनिक्स, और कम मेमोरी/CPU फ़ुटप्रिंट)।

PlayCanvas

PlayCanvas का ज़िक्र करना ज़रूरी है क्योंकि यह सबसे प्रोडक्शन-प्रमाणित वेब-फ़र्स्ट 3D इंजन है। Snap, Facebook, और कई विज्ञापन क्लाइंट ने इसके साथ जटिल 3D अनुभव शिप किए हैं। इंजन करीब 1MB का है, तेज़ी से लोड होता है, और क्लाउड एडिटर सहयोगी वर्ल्ड बिल्डिंग सक्षम करता है।

खासकर एक ओपन वर्ल्ड के लिए, PlayCanvas ड्रॉ कॉल ऑप्टिमाइज़ेशन के लिए बैच ग्रुप, एक अंतर्निहित लाइटमैपर, और Gaussian splatting सपोर्ट देता है (फ़ोटोग्रामेट्री-कैप्चर किए गए असली दुनिया के एनवायरनमेंट के लिए प्रासंगिक)। रनटाइम टाइट है और मोबाइल ब्राउज़र के लिए अच्छी तरह ऑप्टिमाइज़ किया हुआ है।

WebGPU: परफ़ॉर्मेंस की चाबी

WebGPU ब्राउज़र ओपन वर्ल्ड्स के लिए समीकरण बदल देता है। दो फ़ीचर जो सबसे ज़्यादा मायने रखते हैं:

कंप्यूट शेडर GPU-साइड टेरेन जनरेशन, फोलिएज प्लेसमेंट, पार्टिकल सिमुलेशन, और यहाँ तक कि सरल भौतिकी सक्षम करते हैं। एक WebGL वर्ल्ड में, यह सब JavaScript में CPU पर चलता है। WebGPU के साथ, आप टेरेन पैच पूरी तरह GPU पर जनरेट कर सकते हैं, LOD ट्रांज़िशन GPU पर कंप्यूट कर सकते हैं, और कलिंग पास GPU पर चला सकते हैं। यह CPU को नेटवर्किंग, गेम लॉजिक, और कंटेंट स्ट्रीमिंग के लिए मुक्त कर देता है।

इनडायरेक्ट रेंडरिंग GPU को कंप्यूट शेडर आउटपुट के आधार पर तय करने देती है कि क्या ड्रॉ करना है। आप एक ड्रॉ कॉल सबमिट करते हैं, और GPU दूरी के आधार पर तय करता है कि हर LOD लेवल के लिए कितने इंस्टैंस रेंडर करने हैं। आधुनिक इंजन इसी तरह घास के लाखों तिनके या पेड़ संभालते हैं। इनडायरेक्ट रेंडरिंग के बिना (जो WebGL सपोर्ट नहीं करता), CPU को सब कुछ सॉर्ट और बैच करना पड़ता है, जो घने सीन में बॉटलनेक बन जाता है।

WebGPU अब हर बड़े ब्राउज़र में शिप होता है। Chrome और Edge के पास यह वर्शन 113 से है, Firefox ने इसे Windows (141) और Apple Silicon macOS (145) पर जोड़ा, और Safari 26 ने इसे 2025 के आख़िर में macOS, iOS, iPadOS, और visionOS पर लाया। इससे वैश्विक सपोर्ट करीब 82% हो जाता है, मोबाइल समेत (Chrome for Android और Samsung Internet भी इसे शिप करते हैं)। आप फिर भी पुराने ब्राउज़र और उन डिवाइस के लिए एक WebGL 2 फ़ॉलबैक रखेंगे जहाँ WebGPU सक्षम नहीं है, लेकिन यह खाई तेज़ी से बंद हुई है।

@compute @workgroup_size(64)
fn generateTerrain(@builtin(global_invocation_id) id: vec3<u32>) {
    let worldPos = vec2<f32>(f32(id.x), f32(id.y)) * cellSize + worldOffset;
    let height = fbmNoise(worldPos, octaves, persistence);
    heightmap[id.x + id.y * width] = height;
}

अनुशंसित रेंडरिंग स्टैक

डेस्कटॉप पर क्रिएटर्स को लक्ष्य करने वाले एक ब्राउज़र ओपन वर्ल्ड के लिए:

प्राथमिक: Three.js या Babylon.js, जहाँ उपलब्ध हो वहाँ WebGPU रेंडरर के साथ, WebGL 2 फ़ॉलबैक। Babylon के पास मज़बूत अंतर्निहित ओपन-वर्ल्ड प्रिमिटिव हैं। Three.js के पास बड़ी कम्युनिटी और ज़्यादा लचीलापन है।

हमारी पसंद: इंजन कोर के लिए Babylon.js, अंतर्निहित टेरेन LOD, ऑक्ट्री कलिंग, Havok physics (Wasm), और परिपक्व WebGPU सपोर्ट के कारण। जहाँ Babylon में कमी हो वहाँ Three.js इकोसिस्टम टूल्स उपयोग करें (जैसे, स्थानिक क्वेरी के लिए mesh BVH)। सब कुछ एक कस्टम वर्ल्ड-स्ट्रीमिंग लेयर में लपेटें।

वर्ल्ड स्ट्रीमिंग आर्किटेक्चर

यह मुश्किल हिस्सा है। एक ब्राउज़र टैब को डेस्कटॉप पर करीब 2-4 GB मेमोरी मिलती है (ब्राउज़र द्वारा थोपी गई सीमाएँ), मोबाइल पर करीब 1 GB, और कोई सीधा डिस्क एक्सेस नहीं। हर चीज़ नेटवर्क के ज़रिए आती है। आपको एक ऐसा आर्किटेक्चर चाहिए जो दिखने वाली दुनिया को मेमोरी में रखे जबकि खिलाड़ी जिस दिशा में बढ़ रहा है उससे ठीक आगे का कंटेंट स्ट्रीम करे।

चंक-आधारित वर्ल्ड ग्रिड

Skyrim के सेल सिस्टम की तरह, दुनिया को चंक्स के एक नियमित ग्रिड में बाँटें। हर चंक एक स्वतंत्र इकाई है जिसे अलग से लोड, रेंडर, और अनलोड किया जा सकता है।

चंक का आकार मायने रखता है। बहुत छोटा हो तो आप लगातार ऊँचे ओवरहेड के साथ लोड/अनलोड करते रहते हैं। बहुत बड़ा हो तो हर चंक डाउनलोड होने में बहुत समय लेता है। आम ब्रॉडबैंड कनेक्शन वाले एक ब्राउज़र वर्ल्ड के लिए:

• ज़मीनी स्तर पर 64x64 मीटर चंक्स
• हर चंक में होता है: हाइटमैप पैच (2-4 KB), टेक्सचर स्प्लैट मैप (16-32 KB कम्प्रेस्ड), इंस्टैंस्ड रेफ़ के रूप में स्टैटिक मेश (1-50 KB इंस्टैंस डेटा), क्रिएटर द्वारा रखे गए ऑब्जेक्ट एक मेनिफ़ेस्ट के रूप में (1-10 KB)
• लोड रेडियस: पूरी डिटेल पर 5x5 चंक्स (320m दृश्य), मध्यम LOD पर 9x9, केवल-टेरेन पर 17x17
• लक्ष्य: हर चंक का पूरी-डिटेल डेटा 200 KB से कम, ताकि एक 5x5 मोहल्ला 5 MB से कम हो

प्रोग्रेसिव लोडिंग पाइपलाइन

एक चंक के बारे में सब कुछ एक साथ लोड न करें। एक प्रायोरिटी क्यू उपयोग करें:

1. पहले टेरेन ज्यामिति (केवल हाइटमैप, प्रति चंक 2-4 KB)। खिलाड़ी 100ms के भीतर ज़मीन देखता है।
2. टेरेन टेक्सचर (स्प्लैट मैप, पहले कम-रिज़ॉल्यूशन फिर अपग्रेड)। ज़मीन में 200ms के भीतर रंग आता है।
3. बड़ी संरचनाएँ (इमारतें, बड़ी चट्टानें)। सिल्हूट 500ms के भीतर दिखते हैं।
4. डिटेल ऑब्जेक्ट (फोलिएज, छोटे प्रॉप, क्रिएटर आइटम)। दुनिया 1-2 सेकंड में भरती है।
5. हाई-रेज़ टेक्सचर आख़िर में अपग्रेड होते हैं। अगर किसी दूर की इमारत के टेक्सचर को एक अतिरिक्त सेकंड लगे तो किसी को पता नहीं चलता।

यह इस बात से मेल खाता है कि मानव आँख कैसे काम करती है। हम लापता ज़मीन और लापता बड़ी संरचनाएँ नोटिस करते हैं। हम लापता घास नोटिस नहीं करते।

मेमोरी मैनेजमेंट

ब्राउज़र मेमोरी सीमित है और गार्बेज कलेक्टर आपका दुश्मन है। एक अकेला GC पॉज़ एक फ़्रेम के लिए आपको 60fps से 10fps तक गिरा सकता है।

ऑब्जेक्ट पूलिंग अनिवार्य है। आम ऑब्जेक्ट (पेड़, चट्टान, घास के पैच) के लिए पूल पहले से आवंटित करें और चंक्स के लोड/अनलोड होने पर उन्हें रीसायकल करें। हॉट पाथ में कभी नए THREE.Mesh या BABYLON.Mesh इंस्टैंस न बनाएँ। इसके बजाय पूल किए गए ऑब्जेक्ट पर ज्यामिति और मटेरियल रेफ़रेंस स्वैप करें।

टेक्सचर एटलस ड्रॉ कॉल और मेमोरी फ़्रैगमेंटेशन दोनों कम करते हैं। सभी टेरेन टेक्सचर को कुछ बड़े एटलस में पैक करें। क्रिएटर-अपलोडेड टेक्सचर को सर्वर पर प्रति-चंक एटलस में पैक करें और उन्हें एकल छवियों के रूप में स्ट्रीम करें।

ज्यामिति कम्प्रेशन Draco या Meshopt के साथ डाउनलोड आकार को 5-10x कम करता है और डीकम्प्रेशन एक Web Worker पर चलता है ताकि यह मेन थ्रेड को ब्लॉक न करे। खासकर टेरेन के लिए, क्वांटाइज़ किए गए हाइटमैप (सरल डेल्टा एन्कोडिंग के साथ कम्प्रेस्ड 16-बिट मान) किसी भी सामान्य-उद्देश्य मेश फ़ॉर्मेट से छोटे होते हैं।

ArrayBuffer ओनरशिप ट्रांसफ़र वर्कर और मेन थ्रेड के बीच कॉपी करने से बचाता है। जब एक वर्कर एक मेश डीकम्प्रेस करता है, तो ट्रांसफ़रेबल ऑब्जेक्ट के साथ postMessage का उपयोग करके बफ़र को बिना किसी कॉपी के मेन थ्रेड पर ट्रांसफ़र करें।

एसेट डिलीवरी

स्टैटिक वर्ल्ड डेटा के लिए एज कैशिंग के साथ CDN। टेरेन चंक्स, बेस मेश, और टेक्सचर एटलस जो अक्सर नहीं बदलते उन्हें आक्रामक रूप से कैश किया जाना चाहिए (Cache-Control: max-age=31536000, immutable)।

कंटेंट-एड्रेस्ड स्टोरेज का मतलब है हर एसेट वर्शन को उसके URL में एक अनोखा हैश मिलता है। जब कोई क्रिएटर एक चंक संशोधित करता है, तो नए वर्शन को नया हैश मिलता है और पुराना अब भी उसे देख रहे किसी के लिए कैश में रहता है। किसी कैश इनवैलिडेशन की ज़रूरत नहीं।

Basis Universal कम्प्रेशन के साथ KTX2 टेक्सचर। ये उस GPU फ़ॉर्मेट में डीकम्प्रेस होते हैं जो डिवाइस सपोर्ट करता है (BC7, ASTC, ETC2, या RGBA फ़ॉलबैक)। एक 1024x1024 टेरेन टेक्सचर अनकम्प्रेस्ड 4 MB से KTX2 में करीब 150 KB हो जाता है। हज़ारों अनोखे टेक्सचर वाली दुनिया के लिए, यह कम्प्रेशन ही व्यवहार्य और अव्यवहार्य के बीच का फ़र्क़ है।

सभी 3D एसेट के लिए glTF Binary (GLB)। यह 3D का JPEG है। हर ब्राउज़र इंजन इसे लोड करता है, यह कॉम्पैक्ट है, और यह एक ही फ़ाइल में टेक्सचर, मटेरियल, और एनिमेशन एम्बेड कर सकता है। मेश कम्प्रेशन के लिए Draco या Meshopt एक्सटेंशन उपयोग करें। क्रिएटर-अपलोडेड एसेट दुनिया में आने से पहले सर्वर-साइड पर ऑप्टिमाइज़्ड GLB में प्रोसेस होते हैं।

मल्टीप्लेयर नेटवर्किंग

सैकड़ों क्रिएटर्स को एक ही दुनिया में रखने के लिए एक ऐसा नेटवर्किंग आर्किटेक्चर चाहिए जो रियल-टाइम मूवमेंट, स्थायी वर्ल्ड स्टेट, और क्रिएटर एडिट को बिना पिघले संभाले।

सर्वर आर्किटेक्चर

वर्ल्ड स्टेट के लिए अथॉरिटेटिव सर्वर। ब्राउज़र अविश्वसनीय है। सभी सार्थक क्रियाएँ (ऑब्जेक्ट रखना, टेरेन संशोधित करना, चंक्स के बीच चलना) सर्वर-साइड पर सत्यापित होती हैं। क्लाइंट स्थानीय रूप से भविष्यवाणी करता है और सर्वर स्टेट के साथ मेल बैठाता है।

स्थानिक शार्डिंग दुनिया को सर्वर इंस्टैंस में बाँटती है। हर शार्ड वर्ल्ड ग्रिड के एक आयताकार क्षेत्र का मालिक होता है। जैसे-जैसे खिलाड़ी का घनत्व बदलता है, शार्ड बँट या मिल सकते हैं। EVE Online एक ही ब्रह्मांड में हज़ारों खिलाड़ियों को इसी तरह संभालता है, और छोटे पैमाने पर यही सिद्धांत है।

एक क्रिएटर वर्ल्ड के लिए जहाँ ज़्यादातर इंटरैक्शन स्थानीय होते हैं (आप अपने इलाके में बना रहे हैं, आपके पड़ोसी इसे देख सकते हैं), स्थानिक शार्डिंग स्वाभाविक रूप से काम करती है। एक शार्ड सीमा पर खड़ा खिलाड़ी दोनों शार्ड का कंटेंट देखता है, जिसके लिए क्रॉस-शार्ड विज़िबिलिटी क्वेरी चाहिए, लेकिन यह एक हल हो चुकी समस्या है।

सर्वर के लिए टेक्नोलॉजी विकल्प:

टेक्नोलॉजी	खूबियाँ	उपयोग का मामला
Cloudflare Durable Objects	एज-डिप्लॉयड, ऑटो-स्केलिंग, अंतर्निहित स्थायित्व, WebSocket सपोर्ट	वर्ल्ड शार्ड स्टेट, प्रति-चंक अथॉरिटी
Hathora / Rivet	मैनेज्ड गेम सर्वर होस्टिंग, DDoS सुरक्षा, वैश्विक डिप्लॉयमेंट	डेडिकेटेड गेम सर्वर इंस्टैंस
Colyseus	Node.js के लिए ओपन-सोर्स गेम सर्वर फ़्रेमवर्क, स्कीमा-आधारित स्टेट सिंक	स्टेट डिफ़िंग के साथ रूम-आधारित मल्टीप्लेयर
PartyKit	एज-डिप्लॉयड, WebSocket + WebRTC, Cloudflare Workers आधारित	रियल-टाइम सहयोग, हल्का मल्टीप्लेयर
कस्टम Rust/Go	अधिकतम नियंत्रण, प्रति इंस्टैंस सबसे अच्छी परफ़ॉर्मेंस	कम-लेटेंसी भौतिकी चाहने वाले उच्च-घनत्व शार्ड

हमारा संदर्भ (Cloudflare इन्फ़्रास्ट्रक्चर): Durable Objects स्वाभाविक रूप से फ़िट होते हैं। हर वर्ल्ड चंक एक Durable Object बन जाता है जो उस चंक के कंटेंट के लिए अथॉरिटेटिव स्टेट रखता है। खिलाड़ी अपने मौजूदा चंक के लिए ज़िम्मेदार Durable Object से WebSocket के ज़रिए कनेक्ट होते हैं। जब वे किसी सटे हुए चंक में जाते हैं, तो वे उस चंक के DO से कनेक्ट होते हैं। Durable Objects स्टेट को अपने आप डिस्क पर स्थायी बनाते हैं, इसलिए वर्ल्ड डेटा रीस्टार्ट से बच जाता है।

क्लाइंट-सर्वर संचार

विश्वसनीय क्रमबद्ध संदेशों (चैट, वर्ल्ड एडिट, इन्वेंट्री, गेम स्टेट) के लिए WebSocket। खिलाड़ी जिस सक्रिय शार्ड को देख सकता है उसके प्रति एक कनेक्शन (आम तौर पर 1-4 कनेक्शन)।

अविश्वसनीय अक्रमबद्ध संदेशों (खिलाड़ी की स्थिति, एनिमेशन, क्षणिक प्रभाव) के लिए WebRTC DataChannel। WebRTC पीयर-टू-पीयर सक्षम है, लेकिन कई खिलाड़ियों वाली दुनिया के लिए, आप N2 कनेक्शन से बचने के लिए इसे एक SFU (Selective Forwarding Unit) के ज़रिए चलाएँगे। Cloudflare Calls या LiveKit SFU के रूप में काम कर सकते हैं।

स्टेट सिंक्रोनाइज़ेशन डेल्टा कम्प्रेशन उपयोग करता है। सर्वर ट्रैक करता है कि हर क्लाइंट ने क्या देखा है और केवल बदलाव भेजता है। एक क्रिएटर वर्ल्ड के लिए, यह खास तौर पर अहम है क्योंकि वर्ल्ड स्टेट (कौन से ऑब्जेक्ट मौजूद हैं, वे कहाँ हैं, उनके क्या गुण हैं) खिलाड़ी की स्थितियों से बहुत कम बार बदलता है। आप वर्ल्ड स्टेट अपडेट 2-5 Hz पर भेज सकते हैं जबकि खिलाड़ी की स्थितियाँ 20-30 Hz पर अपडेट होती हैं।

interface WorldChunkState {
  version: number;
  terrain: TerrainPatch;
  objects: PlacedObject[];
  creators: CreatorPresence[];
}

interface DeltaUpdate {
  chunkId: string;
  fromVersion: number;
  toVersion: number;
  addedObjects: PlacedObject[];
  removedObjectIds: string[];
  modifiedObjects: Partial<PlacedObject>[];
  creatorMoves: CreatorPosition[];
}

क्रिएटर एडिट के लिए कॉन्फ़्लिक्ट रिज़ॉल्यूशन

जब दो क्रिएटर एक साथ एक ही इलाके को संशोधित करते हैं, तो आपको एक कॉन्फ़्लिक्ट रिज़ॉल्यूशन रणनीति चाहिए। यहीं रियल-टाइम सहयोग मॉडलों के बीच का चुनाव मायने रखता है।

Last-write-wins सबसे सरल है। किसी भी समय हर ऑब्जेक्ट का एक मालिक होता है। अगर आप एक इमारत एडिट कर रहे हैं, तो जब तक आप उसे रिलीज़ न करें तब तक कोई और उसे एडिट नहीं कर सकता। सरल, कोई कॉन्फ़्लिक्ट नहीं, लेकिन सहयोग को सीमित करता है।

Operational Transform (OT) वह है जो Google Docs उपयोग करता है। ऑपरेशन समवर्ती ऑपरेशन के विरुद्ध रूपांतरित होते हैं ताकि एक सुसंगत नतीजा निकले। यह टेक्स्ट के लिए काम करता है लेकिन 3D स्थानिक ऑपरेशन के लिए जटिल हो जाता है। Figma अपने 2D कैनवस के लिए इसका एक रूप उपयोग करता है।

CRDTs (Conflict-free Replicated Data Types) समवर्ती एडिट की अनुमति देते हैं जो बिना समन्वय के हमेशा एक ही स्टेट पर मिलते हैं। अलग ऑब्जेक्ट वाली दुनिया के लिए (हर एक ID और गुणों के साथ), प्रति गुण एक Last-Writer-Wins Register ऑब्जेक्ट संग्रह के लिए एक Add-Wins Set के साथ मिलकर आपको स्वचालित अभिसरण देता है। Yjs और Automerge JavaScript के लिए प्रोडक्शन-क्वालिटी CRDT लाइब्रेरी हैं।

हमारी सिफ़ारिश: वर्ल्ड ऑब्जेक्ट स्टेट (क्या मौजूद है, कहाँ है, क्या गुण हैं) के लिए CRDTs उपयोग करें और स्थानिक सत्यापन (एक ही जगह दो ऑब्जेक्ट नहीं, ऑब्जेक्ट वर्ल्ड सीमा के भीतर रहें) के लिए अथॉरिटेटिव सर्वर। CRDT सहयोग संभालता है। सर्वर भौतिकी संभालता है।

स्केल संभालना: कितने खिलाड़ी?

ब्राउज़र MMO आज मौजूद हैं। Hordes.io एक ब्राउज़र में एक सीन में 200+ खिलाड़ी चलाता है। BrowserQuest (Mozilla का प्रयोग) एक सरल टाइल-आधारित दुनिया के साथ सैकड़ों संभालता था। सवाल यह नहीं है कि क्या ब्राउज़र मल्टीप्लेयर संभाल सकते हैं, बल्कि यह है कि खिलाड़ियों की संख्या बढ़ने पर आप कितनी विज़ुअल फ़िडेलिटी बनाए रख सकते हैं।

खिलाड़ी रेंडरिंग बजट: हर दिखने वाले खिलाड़ी को एक मेश, एनिमेशन, और संभवतः क्रिएटर-कस्टमाइज़्ड रूप चाहिए। 60fps पर, आपके पास प्रति फ़्रेम 16ms है। एक उचित बजट:

• पास की दूरी पर 50 पूरी तरह एनिमेटेड खिलाड़ी: ~2ms एनिमेशन + स्किनिंग
• मध्यम दूरी पर 200 खिलाड़ी (सरल एनिमेशन, इंस्टैंस्ड): ~1ms
• मिनीमैप पर डॉट/आइकन के रूप में 500+ खिलाड़ी: नगण्य

यह आपको एक दृश्य में ~250 खिलाड़ियों की दिखने वाली आबादी देता है, जो एक क्रिएटर वर्ल्ड के लिए पर्याप्त से ज़्यादा है। World of Warcraft की राजधानियाँ शायद ही कभी एक दृश्य में 200 से ज़्यादा कैरेक्टर रेंडर करती हैं।

नेटवर्क बजट: हर खिलाड़ी 20 Hz पर स्थिति भेजते हुए करीब 40 बाइट * 20 = 800 बाइट/सेकंड है। दृश्य में 200 खिलाड़ी: 160 KB/s स्थिति डेटा। वर्ल्ड स्टेट, चैट, और क्रिएटर क्रियाएँ जोड़ें, और आप प्रति क्लाइंट 200-500 KB/s देख रहे हैं। ब्रॉडबैंड क्षमताओं के भीतर अच्छी तरह है लेकिन कम्प्रेस करना सार्थक है।

टेरेन सिस्टम

टेरेन किसी भी ओपन वर्ल्ड की नींव है। यह वह जगह भी है जहाँ ब्राउज़र की पाबंदियाँ सबसे ज़ोर से लगती हैं क्योंकि टेरेन को हर जगह और हमेशा दिखाई देना चाहिए।

हाइटमैप-आधारित टेरेन

Skyrim की तरह, एक हाइटमैप उपयोग करें। ऊँचाई मानों का एक 2D ग्रिड एक वर्टेक्स शेडर के ज़रिए 3D टेरेन जनरेट करता है। यह मनमाने मेश टेरेन से नाटकीय रूप से ज़्यादा कॉम्पैक्ट है।

16-बिट परिशुद्धता पर एक 4096x4096 हाइटमैप अनकम्प्रेस्ड 32 MB है। लेकिन आप इसे कभी एक साथ लोड नहीं करते। हर 64m चंक हाइटमैप का एक 65x65 सेक्शन उपयोग करता है (16-बिट पर करीब 8.4 KB)। उसे डेल्टा एन्कोडिंग और zlib से कम्प्रेस करें और आप प्रति चंक 2 KB से कम हैं।

टेक्सचर स्प्लैटिंग एक ब्लेंड मैप का उपयोग करके कई टेरेन मटेरियल (घास, चट्टान, मिट्टी, रेत) पेंट करता है। हर चंक के पास एक 4-चैनल RGBA स्प्लैट मैप होता है जहाँ हर चैनल एक मटेरियल का ब्लेंड वज़न नियंत्रित करता है। प्रति स्प्लैट मैप 4 टेक्सचर और प्रति चंक स्प्लैट मैप बदलने की क्षमता के साथ, आपको पूरी दुनिया में विज़ुअल विविधता मिलती है।

आधुनिक टेरेन रेंडरर वर्चुअल टेक्सचरिंग (जिसे मेगाटेक्सचर भी कहते हैं, Rage में id Software की टेक से) उपयोग करते हैं। रनटाइम पर स्प्लैटिंग के बजाय, आप ब्लेंडेड टेरेन टेक्सचर को उच्च रिज़ॉल्यूशन पर पहले से रेंडर करते हैं और कैमरा हिलने पर उसकी टाइल्स स्ट्रीम करते हैं। यह रनटाइम परफ़ॉर्मेंस के लिए स्टोरेज का व्यापार करता है। WebGPU के कंप्यूट शेडर वह फ़ीडबैक और पेज-टेबल मैनेजमेंट संभाल सकते हैं जो वर्चुअल टेक्सचरिंग को चाहिए।

क्लिपमैप या जियोक्लिपमैपिंग

एक ब्राउज़र में बड़े टेरेन को रेंडर करने के लिए, CDLOD (C. Dick's LOD) या जियोक्लिपमैपिंग तरीका अच्छी तरह काम करता है। टेरेन को कैमरे के चारों ओर संकेंद्रित वलयों के एक सेट के रूप में रेंडर किया जाता है, हर वलय पिछले से आधे रिज़ॉल्यूशन पर। कैमरे के पास आप पूरी-रिज़ॉल्यूशन टेरेन देखते हैं। दूर आप एक मोटा वर्शन देखते हैं। ट्रांज़िशन सहज होते हैं क्योंकि ज्यामिति स्तरों के बीच मॉर्फ़ होती है।

यह तकनीक GPU-अनुकूल है (प्रति वलय एक ड्रॉ कॉल), स्थिर मेमोरी के साथ अनंत टेरेन संभालती है, और WebGL 2 में काम करती है। Flight Simulator और ज़्यादातर आधुनिक ओपन-वर्ल्ड गेम इसी का किसी स्तर पर उपयोग करते हैं।

क्रिएटर-संशोधित टेरेन

अगर क्रिएटर्स टेरेन गढ़ सकें, तो आपको बेस हाइटमैप के ऊपर संशोधन स्टोर और स्ट्रीम करने का एक तरीका चाहिए। दो तरीके:

डेल्टा हाइटमैप बेस टेरेन और संशोधित टेरेन के बीच के अंतर को स्टोर करते हैं। दुनिया का ज़्यादातर हिस्सा असंशोधित है (डेल्टा शून्य हैं), इसलिए यह बेहद अच्छी तरह कम्प्रेस होता है। एक चंक लोड करते समय, बेस के ऊपर डेल्टा लागू करें।

ज़्यादा नाटकीय संशोधनों (गुफाएँ, ओवरहैंग, मेहराब) के लिए वॉक्सेल ओवरले। एक हाइटमैप ऐसे टेरेन का प्रतिनिधित्व नहीं कर सकता जहाँ एक बिंदु पर दो ऊँचाइयाँ हों। केवल संशोधित चंक्स में स्टोर किया गया एक विरल वॉक्सेल ग्रिड यह संभालता है। मार्चिंग क्यूब्स या ड्यूल कंटूरिंग मेश जनरेट करता है। यह ज़्यादा महँगा है लेकिन Minecraft-स्टाइल टेरेन एडिटिंग सक्षम करता है।

AI-संचालित वर्ल्ड जनरेशन

यहीं Cinevva की मौजूदा जनरेटिव AI क्षमताएँ एक फ़ोर्स मल्टीप्लायर बन जाती हैं। हर चट्टान और पेड़ को हाथ से बनाने के बजाय, क्रिएटर्स AI को दुनिया भरने के लिए निर्देशित कर सकते हैं।

न्यूरल फ़ील्ड के साथ टेरेन जनरेशन

न्यूरल टेरेन जनरेशन पर हालिया रिसर्च (NVIDIA का GET3D, Terragen का न्यूरल नेटवर्क मोड, और "Terrain Generation Using Procedural Models" जैसे पेपर) दिखाती है कि प्रशिक्षित मॉडल टेक्स्ट प्रॉम्प्ट या स्केच इनपुट से विश्वसनीय टेरेन जनरेट कर सकते हैं। एक क्रिएटर एक मोटा तटरेखा बना सकता है और कह सकता है "जंगली पहाड़ियाँ एक चट्टानी किनारे से मिलती हुई" और उसे उपयुक्त अपरदन, वनस्पति मास्क, और मटेरियल असाइनमेंट के साथ एक हाइटमैप मिल सकता है।

ब्राउज़र डिलीवरी के लिए, आप जनरेशन सर्वर-साइड चलाएँगे और नतीजा स्ट्रीम करेंगे। जनरेशन मॉडल को ब्राउज़र में चलने की ज़रूरत नहीं। यह हाइटमैप और स्प्लैट मैप पैदा करता है जिन्हें ब्राउज़र मानक टेरेन पाइपलाइन के साथ रेंडर कर सकता है।

3D एसेट जनरेशन

Hunyuan3D, Meshy, Tripo, और Rodin जैसे मॉडल टेक्स्ट या छवियों से 3D मेश जनरेट कर सकते हैं। एक क्रिएटर वर्ल्ड के लिए वर्कफ़्लो:

1. क्रिएटर बताता या स्केच करता है कि वह क्या चाहता है ("एक काई से ढका पत्थर का मेहराब" या "एक फ़्यूचरिस्टिक लैंप पोस्ट")
2. सर्वर जनरेशन मॉडल चलाता है, एक हाई-पॉली मेश पैदा करता है
3. सर्वर ऑटो-प्रोसेस करता है: वेब-अनुकूल पॉली संख्या तक घटाना, LOD जनरेट करना, टेक्सचर को एटलस में बेक करना, Draco कम्प्रेशन के साथ GLB के रूप में एक्सपोर्ट करना
4. एसेट क्रिएटर की इन्वेंट्री में दिखता है, दुनिया में रखने के लिए तैयार

यह पाइपलाइन Cinevva पर पहले से टुकड़ों में मौजूद है। कमी वाला हिस्सा LOD/ऑप्टिमाइज़ेशन चरण और वर्ल्ड प्लेसमेंट सिस्टम है।

प्रोसीजरल पॉपुलेशन

AI-जनरेटेड एसेट के साथ भी, एक जंगल में हर पेड़ को मैन्युअल रूप से रखना थका देने वाला है। प्रोसीजरल स्कैटरिंग नियम क्रिएटर्स को ज़ोन परिभाषित करने देते हैं ("यह इलाका घना जंगल है", "यह ढलान चट्टानी मलबा है") और सिस्टम उन्हें अपने आप भर देता है।

GPU कंप्यूट शेडर ब्राउज़र में स्कैटरिंग चला सकते हैं। एक डेंसिटी मैप और नियमों के एक सेट (न्यूनतम दूरी, ढलान बाधाएँ, ऊँचाई रेंज) को देखते हुए, एक कंप्यूट पास एक पूरे चंक के लिए इंस्टैंस स्थितियाँ 1ms से कम में जनरेट करता है। डेंसिटी मैप संशोधित करें, और फोलिएज तुरंत फिर से जनरेट हो जाता है।

एंटिटी कंपोनेंट सिस्टम (ECS)

हज़ारों ऑब्जेक्ट वाली एक ओपन वर्ल्ड को एक कुशल एंटिटी मैनेजमेंट सिस्टम चाहिए। ECS पैटर्न (Unity के DOTS और Bevy के बाद से गेम इंजन में लोकप्रिय) JavaScript पर अच्छी तरह बैठता है।

bitECS JavaScript के लिए एक उच्च-परफ़ॉर्मेंस ECS है जो टाइप्ड ऐरे और बिटवाइज़ ऑपरेशन उपयोग करता है। एंटिटी सादे पूर्णांक हैं। कंपोनेंट सतत टाइप्ड ऐरे हैं (प्रति कंपोनेंट प्रकार एक)। सिस्टम ऐरे पर क्रमिक रूप से इटरेट करते हैं, जो JavaScript में भी कैश-अनुकूल है।

import { createWorld, defineComponent, Types, defineQuery, addEntity, addComponent } from 'bitecs';

const Position = defineComponent({ x: Types.f32, y: Types.f32, z: Types.f32 });
const Velocity = defineComponent({ x: Types.f32, y: Types.f32, z: Types.f32 });
const ChunkRef = defineComponent({ chunkX: Types.i16, chunkZ: Types.i16 });

const world = createWorld();
const movingQuery = defineQuery([Position, Velocity]);

function movementSystem(world) {
  const entities = movingQuery(world);
  for (let i = 0; i < entities.length; i++) {
    const eid = entities[i];
    Position.x[eid] += Velocity.x[eid] * dt;
    Position.y[eid] += Velocity.y[eid] * dt;
    Position.z[eid] += Velocity.z[eid] * dt;
  }
  return world;
}

एक ओपन वर्ल्ड के लिए, ECS सब कुछ संभालता है: खिलाड़ी कैरेक्टर, रखे गए ऑब्जेक्ट, NPC, पार्टिकल, ट्रिगर, और वर्ल्ड प्रॉप। जब एक चंक अनलोड होता है, तो उसकी एंटिटी ECS से हटा दी जाती हैं। जब एक चंक लोड होता है, तो एंटिटी जोड़ी जाती हैं। ECS को स्थानिक संगठन की परवाह नहीं। यह बस कंपोनेंट प्रोसेस करता है।

भौतिकी

WebAssembly की बदौलत ब्राउज़र भौतिकी हैरान कर देने वाले ढंग से अच्छी हो गई है।

Rapier (Rust -> Wasm)

Rapier Rust में लिखा गया एक भौतिकी इंजन है जो WebAssembly में कम्पाइल होता है। यह रिजिड बॉडी, कोलाइडर, जॉइंट, कैरेक्टर कंट्रोलर, और रेकास्टिंग संभालता है। आम गेम वर्कलोड के लिए परफ़ॉर्मेंस नेटिव Bullet/PhysX के 2-3x के भीतर है।

एक ओपन वर्ल्ड के लिए, Rapier संभालता है:

• खिलाड़ी कैरेक्टर कंट्रोलर (टेरेन पर चलना, सीढ़ियाँ चढ़ना, ढलानों पर फिसलना)
• ऑब्जेक्ट-से-ऑब्जेक्ट टकराव (रखे गए ऑब्जेक्ट, प्रोजेक्टाइल)
• खिलाड़ी इंटरैक्शन के लिए रेकास्टिंग (चुनने के लिए किसी ऑब्जेक्ट पर क्लिक करना)
• ट्रिगर वॉल्यूम (किसी इलाके में घुसना, एक इवेंट ट्रिगर करना)

Rapier एक Web Worker में चलता है, इसलिए भौतिकी सिमुलेशन रेंडरिंग को ब्लॉक नहीं करता। आप हर फ़्रेम रेंडरर को स्थितियाँ भेजते हैं और बदले में इनपुट इवेंट प्राप्त करते हैं।

Havok for Web (Babylon.js के ज़रिए)

अगर आप Babylon.js के साथ जाते हैं, तो Havok physics एक Wasm मॉड्यूल के रूप में अंतर्निहित आता है। Havok ज़्यादातर AAA गेम (Half-Life 2, Skyrim, Breath of the Wild) के पीछे का भौतिकी इंजन है। Wasm बिल्ड प्रोडक्शन-क्वालिटी का है और Babylon के सीन ग्राफ़ के लिए ऑप्टिमाइज़्ड है।

टेरेन टकराव

भौतिकी इंजन को टेरेन के लिए टकराव ज्यामिति चाहिए। पूरे दिखने वाले टेरेन के लिए एक पूरी-रिज़ॉल्यूशन ट्रायमेश जनरेट करना महँगा होगा। इसके बजाय, केवल खिलाड़ी के पास के चंक्स (3x3 या 5x5 निकटतम चंक्स) के लिए टकराव हाइटफ़ील्ड जनरेट करें और बाक़ी सब के लिए सरल टकराव उपयोग करें। Rapier का हाइटफ़ील्ड कोलाइडर बिल्कुल इसी उपयोग के मामले के लिए डिज़ाइन किया गया है।

ऑडियो

ध्वनि एक 3D स्पेस को एक विज़ुअल डेमो से एक जगह में बदल देती है। Web Audio API एक ब्राउज़र में स्थानिक ऑडियो के लिए ज़रूरी सब कुछ देता है।

HRTF के साथ स्थानिक ऑडियो (Head-Related Transfer Function) ध्वनियों को 3D स्पेस में रखता है। आपकी बाईं ओर का एक झरना ऐसा लगता है जैसे वह आपकी बाईं ओर है। पास जाएँ और वह ज़्यादा तेज़ हो जाता है। किसी इमारत के पीछे जाएँ और वह दबा हुआ हो जाता है (अतिरिक्त प्रोसेसिंग के साथ)।

एम्बिएंस ज़ोन ऑडियो के लिए टेक्सचर स्प्लैटिंग जैसे काम करते हैं। क्षेत्र परिभाषित करें (जंगल, गुफा, किनारा, शहर) और जैसे-जैसे खिलाड़ी उनके बीच चलता है एम्बिएंट साउंडस्केप क्रॉसफ़ेड करें। Skyrim जंगलों को जीवंत ध्वनि इसी तरह देता है। हवा, पक्षी, सरसराते पत्ते, और दूर के जानवरों की परत लगाएँ। इसमें से कुछ भी जटिल नहीं है। यह सब स्थानिक है।

Web Audio परफ़ॉर्मेंस दर्जनों एक साथ चलने वाले स्थानिक स्रोतों के लिए काफ़ी अच्छी है। बॉटलनेक आम तौर पर एसेट आकार होता है, प्रोसेसिंग नहीं। कम्प्रेस्ड ऑडियो के लिए Opus या AAC उपयोग करें, लंबे एम्बिएंट ट्रैक स्ट्रीम करें, और छोटे साउंड इफ़ेक्ट (कदमों की आवाज़, इंटरैक्शन) पहले से लोड करें।

पानी, मौसम, और वातावरण

हर यादगार ओपन वर्ल्ड में पानी और मौसम होता है। ये सिस्टम मूड परिभाषित करते हैं और दुनिया को जीवंत महसूस कराते हैं। ये एक ब्राउज़र में हैरान कर देने वाले ढंग से हासिल करने योग्य भी हैं।

पानी की रेंडरिंग

ब्राउज़र 3D में पानी की जटिलता के तीन स्तर हैं, और आप पहले सबसे सरल वाला शिप कर सकते हैं और बाद में अपग्रेड कर सकते हैं।

स्तर 1: रिफ़्लेक्टिव प्लेन। एक रिफ़्लेक्टिव/रिफ़्रैक्टिव मटेरियल के साथ पानी के स्तर पर एक सपाट मेश। सीन को उल्टा एक टेक्सचर में रेंडर करें (प्लेनर रिफ़्लेक्शन), इसे एक नीली टिंट के साथ ब्लेंड करें, और लहर की गति के लिए स्क्रॉलिंग नॉर्मल मैप जोड़ें। यही Skyrim का बेस वॉटर शेडर करता है। Three.js में, आधिकारिक रेपो में Water उदाहरण यह लागू करता है। Babylon.js में, WaterMaterial इसे बॉक्स से बाहर करता है। लागत: रिफ़्लेक्शन के लिए एक अतिरिक्त रेंडर पास (आधा रिज़ॉल्यूशन ठीक है), साथ ही पानी की सतह ड्रॉ। एक मध्य-श्रेणी GPU पर, यह प्रति फ़्रेम 2-3ms जोड़ता है।

स्तर 2: स्क्रीन-स्पेस रिफ़्लेक्शन + डेप्थ-आधारित प्रभाव। एक अलग रिफ़्लेक्शन रेंडर पास के बजाय, रिफ़्लेक्शन के लिए मौजूदा फ़्रेम बफ़र सैंपल करें (SSR)। डेप्थ-आधारित कलर अब्ज़ॉर्प्शन जोड़ें (पानी जहाँ गहरा है वहाँ ज़्यादा गहरा है), डेप्थ तुलना का उपयोग करके किनारों पर फ़ोम, और पानी के नीचे के टेरेन पर प्रोजेक्ट किए गए कॉस्टिक। यही The Witcher 3 उपयोग करता है। SSR Three.js के postprocessing स्टैक और Babylon.js की रेंडरिंग पाइपलाइन दोनों में उपलब्ध है। लागत: SSR के लिए 1-2ms, डेप्थ प्रभावों के लिए नगण्य।

स्तर 3: FFT महासागर सिमुलेशन। खुले महासागर के लिए, GPU पर वेव स्पेक्ट्रा का सिमुलेशन करने के लिए एक Fast Fourier Transform उपयोग करें। Jerry Tessendorf का पेपर "Simulating Ocean Water" (2001) वह नींव है जिसका हर बड़ा गेम इंजन उपयोग करता है। FFT WebGPU में एक कंप्यूट शेडर के रूप में चलता है, हर फ़्रेम एक डिस्प्लेसमेंट मैप और एक नॉर्मल मैप जनरेट करता है। नतीजतन महासागर बेहद विश्वसनीय दिखता है। यही Sea of Thieves, Assassin's Creed Black Flag, और Uncharted 4 उपयोग करते हैं। WebGPU में, एक 256x256 FFT महासागर डेस्कटॉप GPU पर 1ms से कम में चलता है।

@compute @workgroup_size(16, 16)
fn fftOceanDisplacement(@builtin(global_invocation_id) id: vec3<u32>) {
    let k = vec2<f32>(f32(id.x) - N/2.0, f32(id.y) - N/2.0);
    let omega = sqrt(length(k) * gravity);
    let phase = omega * time;
    let h = spectrum[id.xy] * vec2<f32>(cos(phase), sin(phase));
    displacement[id.xy] = h;
}

एक क्रिएटर वर्ल्ड के लिए, स्तर 1 (रिफ़्लेक्टिव प्लेन) से शुरू करें और जब रेंडरर परिपक्व हो तब स्तर 2 तक अपग्रेड करें। स्तर 3 केवल तभी चाहिए जब दुनिया में खुला महासागर हो।

मौसम सिस्टम

Skyrim और BotW में मौसम ट्रांज़िशन वाली एक स्टेट मशीन से संचालित होता है। साफ़ > बादल > बारिश > तूफ़ान > साफ़। हर स्टेट एक साथ कई सिस्टम बदलती है: स्काईबॉक्स, फॉग घनत्व, एम्बिएंट लाइट रंग, पार्टिकल इफ़ेक्ट (बारिश/बर्फ़), ऑडियो (हवा, बारिश), और गेमप्ले गुण (BotW में गीली सतहें फिसलन भरी होती हैं)।

एक ब्राउज़र वर्ल्ड के लिए, मौसम सिस्टम की तीन परतें होती हैं:

आकाश रेंडरिंग। एक प्रोसीजरल आकाश शेडर स्काईबॉक्स टेक्सचर से सस्ता और ज़्यादा लचीला है। Preetham या Hosek-Wilkie आकाश मॉडल केवल सूरज की स्थिति से भौतिक रूप से विश्वसनीय आकाश रंग कंप्यूट करते हैं। एक प्लेन के ज़रिए स्क्रॉल किए गए 3D नॉइज़ का उपयोग करके एक क्लाउड लेयर जोड़ें। Babylon.js में एक अंतर्निहित प्रोसीजरल आकाश मटेरियल है। Three.js में Sky उदाहरण है। दोनों नगण्य GPU लागत पर विश्वसनीय नतीजे पैदा करते हैं (यह एक अकेला फ़ुलस्क्रीन क्वाड है)।

पार्टिकल इफ़ेक्ट। बारिश हज़ारों पतले क्वाड का एक पार्टिकल सिस्टम है जो ऊपर से गिरते हैं। बर्फ़ समान है लेकिन धीमे, बहते रास्तों के साथ। फॉग एक पोस्ट-प्रोसेसिंग पास है जो डेप्थ के आधार पर सीन को एक फॉग रंग की ओर ब्लेंड करता है। ये सभी मानक WebGL इफ़ेक्ट हैं। लागत पार्टिकल संख्या पर निर्भर करती है: 10,000 बारिश के पार्टिकल प्रति फ़्रेम करीब 0.5ms जोड़ते हैं।

पर्यावरणीय प्रतिक्रिया। गीली सतहें स्पेकुलर रिफ़्लेक्शन बढ़ाती हैं। बर्फ़ का जमाव ऊपर की ओर मुँह करने वाली सतहों पर सफ़ेदी जोड़ता है। अवतल टेरेन में पोखर दिखते हैं। ये शेडर ट्रिक हैं, ज्यामिति बदलाव नहीं। एक "wetness" यूनिफ़ॉर्म मटेरियल रफ़नेस बदलता है। एक "snow cover" यूनिफ़ॉर्म उन सतहों पर सफ़ेद ब्लेंड करता है जिनके नॉर्मल ऊपर की ओर इशारा करते हैं। GTA V और The Witcher 3 बिल्कुल यही तरीका उपयोग करते हैं।

सिंक्रोनाइज़्ड मौसम। एक मल्टीप्लेयर वर्ल्ड में, मौसम क्लाइंट भर में सुसंगत होना चाहिए। सबसे सरल तरीका: सर्वर 1 Hz पर एक मौसम स्टेट (ट्रांज़िशन प्रगति समेत) प्रसारित करता है। क्लाइंट स्थानीय रूप से इंटरपोलेट करते हैं। चूँकि मौसम धीरे-धीरे बदलता है (साफ़ से बारिश का ट्रांज़िशन 30-60 सेकंड लेता है), एक देर से आया अपडेट भी सहज दिखता है।

वायुमंडलीय परिप्रेक्ष्य

यह एक दुनिया को बड़ा महसूस कराने के लिए अकेला सबसे प्रभावी विज़ुअल तरीका है, और यह लगभग मुफ़्त है। वायुमंडल में प्रकाश के बिखराव के कारण दूर के ऑब्जेक्ट ज़्यादा धुँधले, ज़्यादा नीले, और कम कंट्रास्ट वाले दिखते हैं। हर ओपन वर्ल्ड इसका उपयोग करता है।

एक फ़्रैगमेंट शेडर में, डेप्थ के आधार पर दूर के पिक्सेल को वायुमंडल रंग की ओर ब्लेंड करें: