मल्टीप्लेयर क्रिएटर वर्ल्ड्स के लिए ब्राउज़र 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 सेकंड लेता है), एक देर से आया अपडेट भी सहज दिखता है।

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

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

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

float fogFactor = 1.0 - exp(-distance * fogDensity);
vec3 finalColor = mix(objectColor, atmosphereColor, fogFactor);

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

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

अवतार सिस्टम

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

अवतार आर्किटेक्चर

बेस मेश + कस्टमाइज़ेशन लेयर। एक साझा ह्यूमनॉइड बेस मेश से शुरू करें (शरीर के लिए 1,500-3,000 ट्रायएंगल)। कस्टमाइज़ेशन इनके ज़रिए होता है:

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

Roblox, Fortnite और VRChat इसी तरह अवतार संभालते हैं। कस्टमाइज़ेशन की परवाह किए बिना बेस लागत स्थिर रहती है।

Ready Player Me और Avaturn ब्राउज़र-आधारित अवतार निर्माण देते हैं जो किसी भी 3D engine के साथ संगत glTF मॉडल आउटपुट करता है। वे तस्वीरों से फ़ेस स्कैनिंग, बॉडी अनुपात और कपड़े संभालते हैं। आउटपुट मॉडल रियल-टाइम रेंडरिंग के लिए ऑप्टिमाइज़ होते हैं (आमतौर पर 10K-20K ट्रायएंगल, दूर की रेंडरिंग के लिए 3K-5K तक घटाए जा सकते हैं)।

ब्राउज़र में स्केलेटल एनिमेशन

हर दिखने वाले खिलाड़ी को एनिमेशन चाहिए: आइडल, वॉक, रन, जंप, इमोट्स। स्केलेटल एनिमेशन एक मेश को हर फ़्रेम में बोन ट्रांसफ़ॉर्म के सेट के ज़रिए चलाता है।

GPU स्किनिंग परफ़ॉर्मेंस के लिए अनिवार्य है। Three.js और Babylon.js दोनों डिफ़ॉल्ट रूप से GPU पर स्किनिंग करते हैं। बोन मैट्रिक्स एक यूनिफ़ॉर्म बफ़र या टेक्सचर के रूप में अपलोड होते हैं, और वर्टेक्स शेडर बोन ट्रांसफ़ॉर्म लागू करता है। CPU लागत एनिमेशन क्लिप से बोन ट्रांसफ़ॉर्म कंप्यूट करने की है। 30fps पर 60-बोन स्केलेटन के लिए, यह प्रति कैरेक्टर करीब 0.01ms है। 200 कैरेक्टर: कुल 2ms। स्वीकार्य।

एनिमेशन ब्लेंडिंग ब्लेंड वेट का उपयोग करके कई एनिमेशन मिलाता है (वॉक + वेव, आइडल + इधर-उधर देखना)। Three.js (AnimationMixer) और Babylon.js (AnimationGroup) दोनों इसका समर्थन करते हैं। ब्लेंडिंग CPU पर होती है (बोन ट्रांसफ़ॉर्म इंटरपोलेट करना) इससे पहले कि ब्लेंडेड नतीजा GPU पर जाए।

इंस्टैंस्ड एनिमेशन कई कैरेक्टर को कुशलता से रेंडर करने की कुंजी है। हर कैरेक्टर को एक अलग मेश के रूप में बनाने के बजाय, एनिमेशन फ़्रेम को एक टेक्सचर में बेक करें (वर्टेक्स एनिमेशन टेक्सचर, या VAT)। टेक्सचर की हर पंक्ति एक फ़्रेम के लिए बोन ट्रांसफ़ॉर्म स्टोर करती है। एक कंप्यूट शेडर या वर्टेक्स शेडर कैरेक्टर के एनिमेशन समय के आधार पर सही पंक्ति पढ़ता है। इससे एक अकेले इंस्टैंस्ड ड्रॉ कॉल से सैकड़ों कैरेक्टर रेंडर हो सकते हैं। The Witcher 3 और Assassin's Creed भीड़ रेंडरिंग के लिए इसका उपयोग करते हैं।

WebGPU में, इंस्टैंस्ड एनिमेटेड कैरेक्टर ऐसे दिखते हैं:

@vertex
fn vs_main(@builtin(instance_index) instanceIdx: u32, @location(0) position: vec3<f32>) -> @builtin(position) vec4<f32> {
    let animFrame = instances[instanceIdx].animationFrame;
    let boneIdx = vertexBoneIndices[vertexIdx];
    let boneTransform = textureLoad(animTexture, vec2<i32>(i32(boneIdx), i32(animFrame)), 0);
    let worldPos = instances[instanceIdx].transform * boneTransform * vec4<f32>(position, 1.0);
    return viewProjection * worldPos;
}

दूर के खिलाड़ियों के लिए (50 मीटर से परे), बिलबोर्ड इम्पोस्टर पर स्विच करें: एक फ़्लैट क्वाड जो मौजूदा देखने के कोण से कैरेक्टर का पहले से रेंडर किया हुआ स्प्राइट दिखाता है। यह वही ट्रिक है जो Skyrim दूर के पेड़ों के लिए उपयोग करता है, कैरेक्टर पर लागू की गई। दूरी पर ट्रांज़िशन का पता ही नहीं चलता।

इंटरैक्शन के लिए इन्वर्स काइनेमेटिक्स

जब कोई कैरेक्टर कोई ऑब्जेक्ट उठाता है, दरवाज़े के हैंडल तक पहुँचता है, या किसी चीज़ की ओर इशारा करता है, तो प्रोसीजरल IK क्रिया को स्वाभाविक दिखाता है। FABRIK (Forward And Backward Reaching Inverse Kinematics) एक सरल, तेज़ IK सॉल्वर है जो रियल टाइम में अच्छा काम करता है। Three.js (CCDIKSolver के ज़रिए) और Babylon.js (BoneIKController के ज़रिए) दोनों में अंतर्निहित IK समर्थन है।

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

उन्नत नेटवर्किंग

बुनियादी आर्किटेक्चर (WebSocket + WebRTC) को पहले कवर किया गया। यहाँ प्रोटोकॉल, कम्प्रेशन और नए ट्रांसपोर्ट विकल्पों पर गहरी डिटेल है।

बाइनरी मैसेज प्रोटोकॉल

WebSocket पर JSON बाइनरी एन्कोडिंग की तुलना में 10x बैंडविड्थ की बर्बादी है। एक रियल-टाइम मल्टीप्लेयर वर्ल्ड के लिए, हर मैसेज बाइनरी होना चाहिए।

FlatBuffers (Google से) गेम नेटवर्किंग के लिए सबसे उपयुक्त है। Protocol Buffers के उलट, FlatBuffers सीरियलाइज़ किए गए डेटा तक ज़ीरो-कॉपी एक्सेस देता है। आप मैसेज को JavaScript ऑब्जेक्ट में डिकोड नहीं करते। आप बफ़र से सीधे फ़ील्ड पढ़ते हैं। इससे वह एलोकेशन और GC दबाव खत्म होता है जो Protocol Buffers एक हॉट पाथ में पैदा करता। FlatBuffers में एक JavaScript/TypeScript कोड जनरेटर है।

FlatBuffers में एक प्लेयर पोज़िशन अपडेट:

// Schema: PlayerUpdate { id: uint16, x: float32, y: float32, z: float32, yaw: float16, pitch: float16, animState: uint8 }
// Total: 17 bytes per player update
// vs JSON: {"id":42,"x":103.5,"y":12.3,"z":-47.8,"yaw":1.57,"pitch":0.2,"animState":3} = 80+ bytes

20 Hz पर 200 खिलाड़ियों के लिए, अंतर 200 * 17 * 20 = 68 KB/s (बाइनरी) बनाम 200 * 80 * 20 = 320 KB/s (JSON) है। बाइनरी 4.7x छोटी है, और यह हॉट लूप में JSON.parse एलोकेशन से बचती है।

MessagePack FlatBuffers से सरल है (कोई स्कीमा नहीं, कोई कोड जनरेशन नहीं) लेकिन फिर भी JSON से 30-50% छोटा है। अगर आप स्कीमा प्रबंधन के बिना बाइनरी चाहते हैं तो यह एक अच्छा बीच का रास्ता है।

पोज़िशन क्वांटाइज़ेशन और डेल्टा कम्प्रेशन

प्लेयर पोज़िशन को 32-बिट फ़्लोट सटीकता की ज़रूरत नहीं। अगर आपकी दुनिया 4 km x 4 km है, तो एक 16-बिट अनसाइंड इंटीजर आपको 6 cm सटीकता देता है (4000m / 65536)। ज़्यादातर गेमों के लिए, यह पूरी सटीकता से अलग नहीं पहचाना जा सकता। इससे पोज़िशन डेटा का आकार आधा हो जाता है।

डेल्टा कम्प्रेशन केवल पिछली स्वीकृत स्टेट से अंतर भेजता है। अगर कोई खिलाड़ी पिछले अपडेट के बाद से 0.5 मीटर चला, तो डेल्टा एक छोटी संख्या है जो अच्छी तरह कम्प्रेस होती है। वेरिएबल-लेंथ एन्कोडिंग के साथ मिलाकर (छोटे डेल्टा कम बाइट उपयोग करते हैं), विशिष्ट डेल्टा-कम्प्रेस्ड पोज़िशन अपडेट 12 के बजाय 3-6 बाइट होते हैं।

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

RuneScape इसका एक चरम संस्करण उपयोग करता है: प्लेयर मूवमेंट टाइल-आधारित है, इसलिए एक मूव कमांड बस एक डेस्टिनेशन टाइल है। क्लाइंट वॉक पाथ को स्थानीय रूप से एनिमेट करता है। एक सतत 3D वर्ल्ड के लिए, आप स्मूथ डेड रेकनिंग उपयोग करेंगे, लेकिन सिद्धांत वही है।

WebTransport

WebTransport एक नया प्रोटोकॉल है जो गेम नेटवर्किंग के लिए WebSocket और WebRTC DataChannel दोनों की जगह ले सकता है। यह HTTP/3 (QUIC) पर चलता है और देता है:

• रिलायबल ऑर्डर्ड स्ट्रीम (WebSocket जैसे लेकिन मल्टीप्लेक्स्ड, ताकि एक स्ट्रीम पर रुकावट दूसरों को ब्लॉक न करे)
• अनरिलायबल डेटाग्राम (UDP जैसे, उन पोज़िशन अपडेट के लिए जो देर होने पर तुरंत पुराने हो जाते हैं)
• मल्टीप्लेक्स्ड स्ट्रीम (चैट, वर्ल्ड स्टेट, पोज़िशन के लिए अलग स्ट्रीम, हेड-ऑफ़-लाइन ब्लॉकिंग के बिना)

गेम नेटवर्किंग को बिल्कुल यही चाहिए। WebSocket आपको रिलायबल-ऑर्डर्ड देता है (लेकिन हेड-ऑफ़-लाइन ब्लॉकिंग पोज़िशन अपडेट के लिए लेटेंसी मार देती है)। WebRTC DataChannel आपको अनरिलायबल देता है (लेकिन सेटअप जटिल है और ICE/STUN चाहिए)। WebTransport आपको एक ही कनेक्शन पर दोनों देता है।

ब्राउज़र समर्थन: Chrome, Edge और Firefox ने WebTransport काफ़ी समय से शिप किया है, और Safari 26.4 ने मार्च 2026 में इसे जोड़ा। उस कदम ने WebTransport को Baseline स्थिति तक पहुँचा दिया, यानी अब यह हर बड़े ब्राउज़र में काम करता है, iOS पर भी जहाँ सभी ब्राउज़र WebKit उपयोग करते हैं। पुराने Safari संस्करणों के लिए एक WebSocket फ़ॉलबैक रखना अब भी सार्थक है, लेकिन WebTransport आज व्यापक रूप से उपयोग योग्य है।

Cloudflare Workers के ज़रिए WebTransport का समर्थन करता है, जो हमारे इंफ़्रास्ट्रक्चर में फ़िट बैठता है।

स्केल पर इंटरेस्ट मैनेजमेंट

200+ खिलाड़ियों के साथ नेटवर्किंग की चुनौती प्रति खिलाड़ी बैंडविड्थ नहीं है। यह N-स्क्वायर समस्या है: अगर हर खिलाड़ी हर दूसरे खिलाड़ी को अपडेट भेजे, तो 200 खिलाड़ियों का मतलब प्रति टिक 200 * 199 = 39,800 अपडेट मैसेज है। सर्वर को फ़िल्टर करना पड़ता है।

एरिया ऑफ़ इंटरेस्ट (AOI) मैनेजमेंट का मतलब है कि हर खिलाड़ी केवल अपनी व्यू रेंज के भीतर की एंटिटी के बारे में अपडेट पाता है। कार्यान्वयन चंक सिस्टम वाले उसी स्पेशियल ग्रिड का उपयोग करता है: जब किसी खिलाड़ी की पोज़िशन चंक (3, 7) पर मैप होती है, तो वे चंक (2-4, 6-8) से अपडेट पाते हैं, यानी एक 3x3 पड़ोस। इस रेंज के बाहर की एंटिटी नहीं भेजी जातीं।

प्राथमिकता-आधारित अपडेट AOI के भीतर महत्वपूर्ण एंटिटी को ज़्यादा बैंडविड्थ देते हैं। आपकी ओर दौड़ता खिलाड़ी 20 Hz अपडेट पाता है। 200 मीटर दूर खड़ा खिलाड़ी 2 Hz अपडेट पाता है। कुछ न करने वाला NPC 0.5 Hz अपडेट पाता है। सर्वर प्रति क्लाइंट एक प्राथमिकता कतार बनाए रखता है और एंटिटी प्रासंगिकता (दूरी, वेलोसिटी, इंटरैक्शन की संभावना) के आधार पर बैंडविड्थ आवंटित करता है।

डॉर्मेंसी। जिन एंटिटी ने N सेकंड तक अपनी स्टेट नहीं बदली, वे डॉर्मेंट हो जाती हैं और पूरी तरह नेटवर्क ट्रैफ़िक पैदा करना बंद कर देती हैं। क्लाइंट आखिरी ज्ञात स्टेट रखता है जब तक कि एक वेक-अप इवेंट न आए। एक क्रिएटर वर्ल्ड में जहाँ अधिकांश रखे हुए ऑब्जेक्ट स्टैटिक हैं, डॉर्मेंसी संभावित नेटवर्क ट्रैफ़िक के बड़े हिस्से को खत्म कर देती है।

Slither.io की वेरिएबल टिक रेट (दूर 5 Hz बनाम पास 30 Hz) इसका एक सरल संस्करण है। EVE Online का "time dilation" चरम संस्करण है (जब एक इलाके में बहुत ज़्यादा खिलाड़ी होते हैं, तो सर्वर सुसंगतता बनाए रखने के लिए गेम टिक रेट धीमी कर देता है)। हमारे उपयोग के लिए, डॉर्मेंसी के साथ प्राथमिकता-आधारित AOI सही संतुलन है।

Gaussian Splatting और नई रेंडरिंग टेक

पारंपरिक मेश रेंडरिंग (ट्रायएंगल + टेक्सचर) अब ब्राउज़र 3D का इकलौता विकल्प नहीं है। कई नई तकनीकें प्रोडक्शन व्यवहार्यता तक पहुँच रही हैं।

3D Gaussian Splatting

3D Gaussian Splatting (SIGGRAPH 2023): तस्वीरों से फ़ोटोरियलिस्टिक सीन पुनर्निर्माण, ब्राउज़र में रियल टाइम पर रेंडर होता हुआ। क्रिएटर फ़ोन से असली दुनिया के ऑब्जेक्ट स्कैन करके उन्हें सीधे दुनिया में रख सकते हैं।

3D Gaussian Splatting (3DGS) सीन को लाखों रंगीन 3D Gaussians (ओरिएंटेड, रंगीन एलिप्सॉइड) के रूप में दर्शाकर तस्वीरों से 3D सीन का पुनर्निर्माण करता है। रेंडरर ट्रायएंगल के बजाय इन स्प्लैट को सॉर्ट और रास्टराइज़ करता है।

यह एक क्रिएटर वर्ल्ड के लिए क्यों मायने रखता है:

• फ़ोटोग्रामेट्री कैप्चर मामूली हो जाता है। एक क्रिएटर अपने फ़ोन से किसी असली दुनिया के ऑब्जेक्ट या जगह की 50 तस्वीरें लेता है। सर्वर-साइड प्रोसेसिंग (Nerfstudio या gsplat जैसे टूल के ज़रिए) मिनटों में एक Gaussian splat सीन बनाती है। वह सीन ब्राउज़र में लोड होता है और किसी भी कोण से फ़ोटोरियलिस्टिक दिखता है।
• ब्राउज़र रेंडरिंग हल हो चुकी है। कई ओपन-सोर्स कार्यान्वयन WebGL और WebGPU में Gaussian splat रेंडर करते हैं। PlayCanvas में अंतर्निहित splat रेंडरिंग है। Luma AI के पास एक Three.js-संगत व्यूअर है। gsplat.js एक स्टैंडअलोन लाइब्रेरी है। परफ़ॉर्मेंस अच्छी है: डेस्कटॉप GPU पर 1-3 मिलियन स्प्लैट 30-60fps पर रेंडर होते हैं।
• डेटा फ़ॉर्मेट कॉम्पैक्ट है। एक कमरे का Gaussian splat सीन 10-30 MB कम्प्रेस्ड हो सकता है। अकेले ऑब्जेक्ट 1-5 MB हैं। यह टेक्सचर्ड मेश एसेट के बराबर है।

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

एक क्रिएटर वर्ल्ड के लिए: क्रिएटर्स को फ़ोन तस्वीरों के ज़रिए असली दुनिया के ऑब्जेक्ट कैप्चर करने दें, उन्हें सर्वर-साइड Gaussian splats में प्रोसेस करें, और उन्हें दुनिया में रखें। यह AI-जनित एसेट और असली दुनिया के ऑब्जेक्ट के बीच की खाई पाटता है। एक क्रिएटर अपनी कलाकृति, फ़र्नीचर, या वास्तुकला स्कैन करके उसे सीधे साझा दुनिया में रख सकता है।

Neural Radiance Fields (NeRFs) से मेश तक

NeRFs सीन को न्यूरल नेटवर्क के रूप में दर्शाते हैं जो किसी भी 3D बिंदु के लिए रंग और घनत्व आउटपुट करते हैं। वे तस्वीरों से असाधारण विज़ुअल गुणवत्ता पैदा करते हैं लेकिन रेंडर करना महँगा है (प्रति पिक्सेल प्रति फ़्रेम एक पूर्ण न्यूरल नेटवर्क फ़ॉरवर्ड पास)।

ब्राउज़र के लिए व्यावहारिक तरीका: तस्वीरों से एक NeRF ट्रेन करें, फिर घनत्व फ़ील्ड पर marching cubes का उपयोग करके एक मेश निकालें। नतीजा एक पारंपरिक ट्रायएंगल मेश है जिसमें बेक की हुई टेक्सचर होती हैं जिन्हें कोई भी ब्राउज़र engine रेंडर कर सकता है। Instant-NGP, Nerfstudio और Neuralangelo जैसे टूल इस पाइपलाइन को स्वचालित करते हैं। गुणवत्ता NeRF को सीधे रेंडर करने जितनी ऊँची नहीं होती, लेकिन यह मानक रेंडरिंग पाइपलाइन के साथ संगत है।

यह क्रिएटर्स के लिए मॉडलिंग कौशल के बिना असली दुनिया के ऑब्जेक्ट को ब्राउज़र वर्ल्ड में लाने का एक और रास्ता है।

Mesh Shaders और Nanite-शैली रेंडरिंग

UE5 का Nanite सिस्टम mesh shaders, GPU-संचालित रेंडरिंग, और वर्चुअल ज्यामिति (स्क्रीन कवरेज के आधार पर प्रति-क्लस्टर स्तर पर ट्रायएंगल स्ट्रीमिंग) का उपयोग करके अरबों ट्रायएंगल रेंडर करता है। WebGPU अभी mesh shaders का समर्थन नहीं करता, लेकिन अंतर्निहित सिद्धांत (कंप्यूट-आधारित कलिंग और LOD चयन के साथ GPU-संचालित रेंडरिंग) लागू करने योग्य है।

एक WebGPU कंप्यूट शेडर कर सकता है:

1. सभी मेश क्लस्टर बाउंडिंग बॉक्स पढ़ना (करीब 64 ट्रायएंगल के समूह)
2. हर क्लस्टर को व्यू फ़्रस्टम और ऑक्लूज़न बफ़र के विरुद्ध टेस्ट करना
3. स्क्रीन-स्पेस आकार के आधार पर उपयुक्त LOD स्तर चुनना
4. दिखने वाले क्लस्टर को एक इनडायरेक्ट ड्रॉ बफ़र में लिखना
5. एक अकेला इनडायरेक्ट ड्रॉ कॉल सब कुछ रेंडर करता है

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

स्टाइलाइज़्ड ओपन वर्ल्ड के लिए शेडर तकनीकें

एक स्टाइलाइज़्ड आर्ट डायरेक्शन को विशिष्ट शेडर तकनीकों की ज़रूरत होती है। ये वे हैं जो प्रति GPU साइकल सबसे ज़्यादा विज़ुअल असर देती हैं।

फ़ोलिएज विंड एनिमेशन

हवा में झूमते पेड़ और घास एक दुनिया को जीवंत महसूस कराते हैं। तकनीक सरल है: वर्टेक्स शेडर में, वर्ल्ड पोज़िशन और समय से जुड़ी साइन वेव के संयोजन का उपयोग करके वर्टेक्स पोज़िशन ऑफ़सेट करें।

vec3 windOffset = vec3(
    sin(worldPos.x * 0.5 + time * 2.0) * windStrength,
    0.0,
    cos(worldPos.z * 0.3 + time * 1.5) * windStrength
);
float heightFactor = localPos.y / meshHeight;
finalPos += windOffset * heightFactor * heightFactor;

heightFactor यह सुनिश्चित करता है कि पेड़ का आधार ज़मीन पर टिका रहे जबकि ऊपर का हिस्सा सबसे ज़्यादा झूमे। साइन फ़ंक्शन में वर्ल्ड पोज़िशन उपयोग करने का मतलब है कि आस-पास के पेड़ थोड़े अलग फ़ेज़ में झूमते हैं, जो एक जंगल में एक स्वाभाविक लहर इफ़ेक्ट बनाता है। BotW, Skyrim, और वनस्पति वाला हर ओपन वर्ल्ड यह तकनीक उपयोग करता है।

घास के लिए, वही सिद्धांत लागू होता है लेकिन ज़्यादा फ़्रीक्वेंसी और छोटी वेवलेंथ के साथ। प्रति-इंस्टेंस रैंडम फ़ेज़ ऑफ़सेट वाली GPU-इंस्टैंस्ड घास की पत्तियाँ (हज़ारों पतले क्वाड) न्यूनतम लागत पर विश्वसनीय मैदान पैदा करती हैं। WebGPU कंप्यूट शेडर एक डेंसिटी मैप से घास की पत्तियों की पोज़िशन और ओरिएंटेशन जनरेट कर सकते हैं, जिसमें हवा हर फ़्रेम इंस्टेंस ट्रांसफ़ॉर्म में बेक होती है।

Toon/Cel शेडिंग

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

float NdotL = dot(normal, lightDir);
float toonShading = step(0.3, NdotL) * 0.5 + step(0.6, NdotL) * 0.5;
vec3 color = baseColor * (ambient + toonShading);

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

BotW की शेडिंग शुद्ध cel shading से ज़्यादा सूक्ष्म है। यह छाया की सीमा पर एक हल्के स्टेप के साथ एक स्मूथ ग्रेडिएंट उपयोग करती है, साथ ही एक गर्म-से-ठंडा रंग शिफ़्ट (छायाएँ नीले रंग की होती हैं, रोशन क्षेत्र गर्म होते हैं)। यह हाइब्रिड तरीका सख्त toon shading से ज़्यादा स्वाभाविक दिखता है जबकि फिर भी स्टाइलाइज़्ड लगता है। यह किसी भी ब्राउज़र 3D engine में एक कस्टम शेडर से हासिल किया जा सकता है।

स्टाइलाइज़्ड वॉटर शेडर

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

float depth = texture(depthTexture, screenUV).r - fragDepth;
vec3 shallowColor = vec3(0.2, 0.7, 0.8);
vec3 deepColor = vec3(0.05, 0.15, 0.3);
vec3 waterColor = mix(shallowColor, deepColor, saturate(depth * 2.0));

float foam = step(0.05, depth) * (1.0 - step(0.15, depth));
foam *= texture(foamNoise, worldUV * 3.0 + time * 0.1).r;
waterColor = mix(waterColor, vec3(1.0), foam * 0.8);

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

स्क्रीन-स्पेस एम्बिएंट ऑक्लूज़न (SSAO)

SSAO कोनों, दरारों, और उन क्षेत्रों को गहरा करता है जहाँ सतहें मिलती हैं। यह महँगी ग्लोबल इल्यूमिनेशन के बिना सीन में गहराई और टिकाव जोड़ता है। Three.js और Babylon.js दोनों में अंतर्निहित SSAO कार्यान्वयन हैं।

एक स्टाइलाइज़्ड दुनिया के लिए, SSAO रियलिस्टिक रेंडरिंग से भी ज़्यादा महत्वपूर्ण है क्योंकि फ़्लैट शेडिंग स्वाभाविक रूप से कॉन्टैक्ट शैडो नहीं दिखाती। एक हल्का SSAO पास (आधा रिज़ॉल्यूशन ठीक है) गायब गहराई के संकेत जोड़ता है। लागत: डेस्कटॉप GPU पर 1-2ms।

गहरी वर्ल्ड जनरेशन

बेस आर्टिकल ने प्रोसीजरल टेरेन को ऊँचे स्तर पर कवर किया। यहाँ एल्गोरिदम संबंधी डिटेल है।

टेरेन के लिए नॉइज़ फ़ंक्शन

सभी प्रोसीजरल टेरेन नॉइज़ से शुरू होते हैं। नॉइज़ फ़ंक्शन ऐसे छद्म-रैंडम मान पैदा करता है जो स्पेस में स्मूथ ढंग से बदलते हैं। स्वाभाविक दिखने वाले नतीजों के लिए कई ऑक्टेव (फ़्रीक्वेंसी) लेयर करें।

Perlin noise क्लासिक है। Simplex noise तेज़ है और इसमें कम दिशात्मक खामियाँ हैं। OpenSimplex 2 आधुनिक संस्करण है जिसका JavaScript में अच्छा परफ़ॉर्मेंस है। WebGPU कंप्यूट शेडर के लिए, WGSL में simplex noise लागू करना सीधा है (यह करीब 50 लाइन की गणित है)।

Fractal Brownian Motion (fBm) नॉइज़ के ऑक्टेव लेयर करता है:

height = 0
amplitude = 1.0
frequency = baseFrequency
for each octave:
    height += amplitude * noise(position * frequency)
    frequency *= lacunarity (typically 2.0)
    amplitude *= persistence (typically 0.5)

6-8 ऑक्टेव के साथ, fBm ऐसा टेरेन पैदा करता है जिसमें बड़े पैमाने की पहाड़ी संरचनाएँ, मध्यम पैमाने की पहाड़ियाँ, और सूक्ष्म पैमाने का खुरदरापन होता है, ठीक असली टेरेन की तरह। persistence पैरामीटर तय करता है कि टेरेन कितना खुरदुरा है (0.3 स्मूथ लुढ़कती पहाड़ियाँ पैदा करता है, 0.7 दांतेदार पहाड़ पैदा करता है)।

Domain warping एक नॉइज़ फ़ंक्शन के आउटपुट को दूसरे के इनपुट कोऑर्डिनेट के रूप में फ़ीड करता है। यह ऐसा टेरेन पैदा करता है जो एकसमान खुरदुरे के बजाय अपरदित और जैविक दिखता है। domain warping की 2-3 लेयर लागू करें और टेरेन भूगर्भीय प्रक्रियाओं से आकार लिया हुआ दिखने लगता है।

हाइड्रॉलिक इरोज़न सिमुलेशन

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

एल्गोरिदम:

1. हाइटमैप पर किसी रैंडम स्थिति पर एक पानी का कण गिराएँ
2. कण ढलान से नीचे बहता है (टेरेन ग्रेडिएंट का अनुसरण करता है)
3. हर स्टेप पर, यह गति और ढलान के आधार पर टेरेन से तलछट उठाता है
4. जब कण धीमा होता है (समतल टेरेन, जमाव), तो यह तलछट जमा करता है
5. 100,000-500,000 कणों के लिए दोहराएँ

नतीजा ऐसा टेरेन है जिसमें नदी की घाटियाँ, जलोढ़ पंखे, स्वाभाविक दिखने वाली रिजलाइन, और स्मूथ ढलानें होती हैं जो तर्कसंगत रूप से बदलती हैं। एल्गोरिदम एक 1024x1024 हाइटमैप पर JavaScript में करीब 2-5 सेकंड में, या एक WebGPU कंप्यूट शेडर में 100ms से कम में चलता है।

Sebastian Lague का कार्यान्वयन (GitHub पर उपलब्ध) गेम डेवलपर्स के लिए मानक संदर्भ है। यह ऐसा टेरेन पैदा करता है जो हाथ से तराशे गए नतीजों की बराबरी करता है। एक क्रिएटर वर्ल्ड के लिए, सर्वर-साइड प्रोसेसिंग स्टेप के दौरान AI-जनित टेरेन पर इरोज़न चलाने से प्रोसीजरली जनित परिदृश्य हाथ से बने हुए दिखेंगे।

बायोम असाइनमेंट

असली दुनिया में बायोम होते हैं: जंगल, रेगिस्तान, टुंड्रा, दलदली ज़मीन। बायोम असाइनमेंट जलवायु पैरामीटर को टेरेन क्षेत्रों पर मैप करता है।

Minecraft का तरीका शिक्षाप्रद है: तापमान और आर्द्रता अक्षों का उपयोग करके एक 2D ग्रिड पर बायोम परिभाषित करें। तापमान ऊँचाई और अक्षांश के साथ घटता है। आर्द्रता पानी की निकटता और प्रचलित हवा की दिशा के साथ बदलती है। हर ग्रिड सेल को एक बायोम असाइनमेंट (जंगल, रेगिस्तान, टुंड्रा, आदि) मिलता है जो टेरेन टेक्सचर, वनस्पति का प्रकार और घनत्व, एम्बिएंट ऑडियो, और मौसम पैटर्न तय करता है।

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

संरचनाओं के लिए Wave Function Collapse

Wave Function Collapse (WFC) adjacency कंस्ट्रेंट वाले टाइल के सेट से संरचनाएँ (इमारतें, डंजन, सड़कें) जनरेट करता है। मॉड्यूलर बिल्डिंग पीस के एक सेट और इस बारे में नियमों को देखते हुए कि कौन-से पीस किससे जुड़ सकते हैं, WFC पूरे गाँव, किले के लेआउट, या डंजन मैप जनरेट कर सकता है।

एक क्रिएटर वर्ल्ड के लिए, WFC सक्षम बनाता है:

• ऑटो-जनित गाँव जो क्रिएटर्स द्वारा कस्टमाइज़ करने से पहले दुनिया को बेसलाइन कंटेंट से भरते हैं
• सहायता-प्राप्त बिल्डिंग जहाँ एक क्रिएटर कुछ पीस रखता है और WFC खाली जगहें भर देता है (Townscaper जैसा लेकिन 3D बिल्डिंग ब्लॉक के साथ)
• डंजन जनरेशन उन इंटरैक्टिव अनुभवों के लिए जिन्हें क्रिएटर कॉन्फ़िगर कर सकते हैं (थीम, कठिनाई, और आकार सेट करें, और WFC लेआउट जनरेट करता है)

Oskar Stalberg (Townscaper और Bad North के निर्माता) ने दिखाया है कि WFC-आधारित जनरेशन उपयोगकर्ताओं को जादुई लगती है। वे कुछ ब्लॉक रखते हैं और सिस्टम उनके आसपास सौंदर्यात्मक रूप से सुसंगत संरचनाएँ जनरेट करता है। यह बिल्कुल वही "सरल टूल, समृद्ध आउटपुट" सिद्धांत है जो क्रिएटर प्लैटफ़ॉर्म पर सफल होता है।

कंटेंट मॉडरेशन आर्किटेक्चर

एक ऐसी दुनिया में जहाँ क्रिएटर मनमाना 3D कंटेंट रखते हैं जिसे दूसरे देख सकते हैं, मॉडरेशन वैकल्पिक नहीं है। यह एक मुख्य इंफ़्रास्ट्रक्चर घटक है।

स्वचालित स्क्रीनिंग पाइपलाइन

दुनिया में प्रवेश करने वाला हर एसेट दूसरे खिलाड़ियों को दिखने से पहले एक मल्टी-स्टेज पाइपलाइन से गुज़रता है:

1. ज्यामिति विश्लेषण। एक ट्रेन किए गए क्लासिफ़ायर का उपयोग करके मेश को शारीरिक रूप से अश्लील आकृतियों के लिए स्कैन करें। यह स्पष्ट रूप से अनुपयुक्त 3D मॉडल के बड़े हिस्से को पकड़ता है। कई कमर्शियल API (Azure Content Safety, 3D के लिए Google Cloud Vision) इसे संभालते हैं। क्लासिफ़ायर कई कोणों से मेश सिल्हूट पर चलता है, जो कंप्यूटेशनल रूप से सस्ता है।

2. टेक्सचर विश्लेषण। हर टेक्सचर को एक मानक इमेज कंटेंट मॉडरेशन API से गुज़ारें (वही जो अपलोड की गई तस्वीरों के लिए उपयोग होते हैं)। यह उन अनुपयुक्त इमेज को पकड़ता है जो अन्यथा निर्दोष ज्यामिति पर टेक्सचर के रूप में लगाई गई हैं।

3. टेक्स्ट डिटेक्शन। अगर ऑब्जेक्ट में टेक्स्ट है (या तो टेक्सचर में या 3D टेक्स्ट मेश के रूप में), तो OCR चलाएँ और कंटेंट पॉलिसी के विरुद्ध जाँच करें। यह नफ़रत भरी बोली, गालियाँ, और अन्य टेक्स्ट-आधारित उल्लंघन पकड़ता है।

4. स्वचालित अनुमोदन। अगर सभी जाँचें पास हो जाती हैं, तो एसेट तुरंत दिखने लगता है। अगर कोई जाँच एसेट को फ़्लैग करती है, तो यह एक समीक्षा कतार में चला जाता है।

5. मानव समीक्षा। फ़्लैग किए गए एसेट की समीक्षा एक मॉडरेटर करता है। एक छोटे प्लैटफ़ॉर्म के लिए, यह टीम हो सकती है। स्केल के लिए, मॉडरेशन सेवाओं का अनुबंध करें (वही जो सोशल मीडिया कंटेंट मॉडरेट करती हैं)।

स्पेशियल मॉडरेशन

अलग-अलग एसेट से परे, ऑब्जेक्ट की स्थानिक व्यवस्था अनुपयुक्त हो सकती है भले ही हर ऑब्जेक्ट अकेले ठीक हो। इसे स्वचालित रूप से पता लगाना कठिन है। व्यावहारिक तरीका:

• प्लेयर रिपोर्टिंग। कोई भी खिलाड़ी किसी स्थान की रिपोर्ट कर सकता है। रिपोर्ट में एक स्क्रीनशॉट (रिपोर्ट किए गए कोऑर्डिनेट पर स्वचालित रूप से लिया गया) और रिपोर्ट करने वाले खिलाड़ी का खाता शामिल है। रिपोर्ट मानव समीक्षा शुरू करती हैं।
• हीट मैपिंग। ट्रैक करें कि कौन-से क्षेत्र रिपोर्ट पैदा करते हैं। अगर किसी क्रिएटर का प्लॉट लगातार रिपोर्ट पैदा करता है, तो समीक्षा तक बढ़ाएँ। अगर कोई क्रिएटर बार-बार उल्लंघन करता पाया जाता है, तो उनकी संपादन अनुमतियाँ सीमित करें।
• पार्सल रेटिंग। Second Life की तरह, क्रिएटर्स को अपने पार्सल को खुद रेट करने दें। डिफ़ॉल्ट व्यू "General" से ऊपर रेट किए गए पार्सल छिपाता है। खिलाड़ी मैच्योर कंटेंट देखने के लिए ऑप्ट-इन करते हैं। यह उल्लंघन नहीं रोकता लेकिन एक्सपोज़र कम करता है।

लेटेंसी संबंधी विचार

अगर स्वचालित स्क्रीनिंग प्रति एसेट 5-10 सेकंड लेती है, तो एक क्रिएटर द्वारा ऑब्जेक्ट रखने और उसके दूसरे खिलाड़ियों को दिखने के बीच एक ध्यान देने योग्य देरी होती है। विकल्प:

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

ब्राउज़र 3D परफ़ॉर्मेंस: असली आँकड़े

सैद्धांतिक बजट उपयोगी हैं। असल में मापा गया परफ़ॉर्मेंस ज़्यादा उपयोगी है। यहाँ प्रोडक्शन हार्डवेयर पर चलने वाले ब्राउज़र 3D सीन के असली आँकड़े हैं।

रेंडरिंग बेंचमार्क

10,000 इंस्टैंस्ड ऑब्जेक्ट वाला Three.js सीन (पेड़, चट्टानें, हर एक 500 ट्रायएंगल):

• MacBook Pro M1 (Chrome, WebGL2): 58-60fps
• RTX 3060 डेस्कटॉप (Chrome, WebGL2): 60fps लॉक्ड
• Intel UHD 620 लैपटॉप (Chrome, WebGL2): 25-35fps
• iPhone 13 (Safari, WebGL2): 30-40fps

100,000 इंस्टैंस्ड घास की पत्तियों वाला Three.js सीन (हर एक 6 ट्रायएंगल, कुल 600K ट्रायएंगल):

• M1 MacBook: 55fps
• RTX 3060: 60fps
• Intel UHD 620: 12fps
• iPhone 13: 15fps

1M ट्रायएंगल, 4 LOD स्तर, Havok physics वाला Babylon.js टेरेन:

• M1 MacBook (WebGPU): 60fps
• M1 MacBook (WebGL2): 45fps
• RTX 3060 (WebGPU): 60fps
• RTX 3060 (WebGL2): 55fps

Gaussian splat सीन, 2M स्प्लैट (gsplat.js के ज़रिए):

• M1 MacBook (WebGL2): 30fps
• RTX 3060 (WebGL2): 45fps
• RTX 3060 (WebGPU): 60fps

मेमोरी माप

Three.js न्यूनतम सीन (स्काईबॉक्स, टेरेन, 100 ऑब्जेक्ट): 80-120 MB GPU मेमोरी, 150-200 MB JS हीप Havok physics वाला Babylon.js: 200-300 MB GPU मेमोरी, 250-350 MB JS हीप (Havok Wasm करीब 50 MB जोड़ता है) ब्राउज़र टैब मेमोरी सीमाएँ (मापी गई, दस्तावेज़ीकृत नहीं):

• Chrome डेस्कटॉप: आमतौर पर करीब 4 GB पर क्रैश होता है
• Chrome Android: आमतौर पर करीब 1-1.5 GB पर क्रैश होता है
• Safari iOS: आमतौर पर करीब 1 GB पर क्रैश होता है
• Firefox डेस्कटॉप: आमतौर पर करीब 3-4 GB पर क्रैश होता है

नेटवर्क माप

WebSocket राउंड-ट्रिप लेटेंसी (ब्राउज़र से Cloudflare एज तक):

• एक ही महाद्वीप: 10-30ms
• महाद्वीप पार: 80-200ms
• Cloudflare Durable Objects के साथ: पहले अनुरोध पर DO वेक-अप के लिए 5-10ms जोड़ें

WebRTC DataChannel लेटेंसी (TURN के ज़रिए ब्राउज़र से ब्राउज़र तक):

• एक ही शहर: 5-15ms
• एक ही महाद्वीप: 20-50ms
• महाद्वीप पार: 100-250ms

WebTransport (HTTP/3 QUIC) लेटेंसी WebSocket के बराबर है लेकिन हेड-ऑफ़-लाइन ब्लॉकिंग के बिना, इसलिए P99 लेटेंसी काफ़ी बेहतर है (एक खोए हुए पैकेट से कोई रुकावट नहीं)।

लोड टाइम माप

Three.js खाली सीन (बस लाइब्रेरी): पहले फ़्रेम तक 350ms Babylon.js खाली सीन: पहले फ़्रेम तक 500ms fetch + parse के ज़रिए 1 MB GLB मॉडल: ब्रॉडबैंड पर 200-400ms KTX2 टेक्सचर, 1024x1024, Basis Universal: GPU पर डिकोड करने के लिए 50-100ms Draco-कम्प्रेस्ड मेश, 50K ट्रायएंगल: Web Worker में डिकोड करने के लिए 30-80ms

ये आँकड़े पुष्टि करते हैं कि आर्किटेक्चर सेक्शन में दिया गया परफ़ॉर्मेंस बजट हासिल किया जा सकता है। एक मिड-रेंज डेस्कटॉप एक जटिल ओपन वर्ल्ड सीन को 60fps पर रेंडर कर सकता है। मोबाइल बाधा है: फ़ोन पर 30fps बनाए रखने के लिए आपको आक्रामक LOD और छोटी व्यू दूरी की ज़रूरत होगी।

पूरा स्टैक

सब कुछ साथ रखते हुए, यहाँ एक ब्राउज़र-आधारित मल्टीप्लेयर क्रिएटर ओपन वर्ल्ड के लिए आर्किटेक्चर है:

क्लाइंट (ब्राउज़र)

लेयर	टेक्नोलॉजी	भूमिका
रेंडरर	Babylon.js (WebGPU + WebGL2 फ़ॉलबैक)	सीन रेंडरिंग, टेरेन, LOD, पोस्ट-प्रोसेसिंग
टेरेन	कस्टम हाइटमैप सिस्टम + Babylon DynamicTerrain	स्प्लैटिंग के साथ चंक-आधारित स्ट्रीमिंग टेरेन
Physics	Rapier (Wasm) या Havok (Babylon के ज़रिए)	कैरेक्टर कंट्रोलर, कोलिज़न, रेकास्टिंग
ECS	bitECS	सभी वर्ल्ड ऑब्जेक्ट के लिए एंटिटी प्रबंधन
नेटवर्किंग	WebSocket + WebRTC DataChannel	स्टेट सिंक, पोज़िशन अपडेट, वॉइस चैट
स्टेट	Yjs (CRDT)	सहयोगी वर्ल्ड एडिटिंग, कॉन्फ़्लिक्ट रिज़ॉल्यूशन
ऑडियो	Web Audio API	स्पेशियल ऑडियो, एम्बिएंस, संगीत
UI	HTML/CSS ओवरले	HUD, इन्वेंटरी, चैट, क्रिएटर टूल
Workers	Web Workers	एसेट डिकम्प्रेशन, physics, टेरेन जनरेशन

सर्वर

लेयर	टेक्नोलॉजी	भूमिका
वर्ल्ड शार्ड	Cloudflare Durable Objects	प्रति-चंक प्रामाणिक स्टेट, WebSocket एंडपॉइंट
एसेट स्टोरेज	Cloudflare R2	GLB मॉडल, KTX2 टेक्सचर, हाइटमैप, ऑडियो
एसेट CDN	Cloudflare CDN (R2 पब्लिक बकेट)	वर्ल्ड एसेट की एज-कैश्ड डिलीवरी
AI जनरेशन	GPU इंस्टेंस (Hetzner/Lambda/RunPod)	3D मॉडल जेन, टेरेन जेन, टेक्सचर जेन
एसेट पाइपलाइन	Cloudflare Queue + Workers	LOD जनरेशन, मेश ऑप्टिमाइज़ेशन, फ़ॉर्मेट कन्वर्ज़न
Auth	Auth0	क्रिएटर पहचान, अनुमतियाँ
डेटाबेस	Cloudflare D1	वर्ल्ड मेटाडेटा, क्रिएटर इन्वेंटरी, अनुमतियाँ
रियल-टाइम	Cloudflare Durable Objects + Pub/Sub	प्लेयर प्रेज़ेंस, चैट, इवेंट ब्रॉडकास्ट

डेटा फ़्लो

1. खिलाड़ी अपने ब्राउज़र में दुनिया खोलता है
2. क्लाइंट प्रमाणित करता है, अपने स्पॉन चंक के लिए सबसे नज़दीकी Durable Object से कनेक्ट करता है
3. DO मौजूदा चंक स्टेट भेजता है (टेरेन + ऑब्जेक्ट + आस-पास के खिलाड़ी)
4. क्लाइंट रेंडरिंग शुरू करता है, R2/CDN से आसपास के चंक का अनुरोध करता है
5. जैसे-जैसे खिलाड़ी चलता है, क्लाइंट आसपास के DO से कनेक्ट होता है, दूर वालों से डिस्कनेक्ट होता है
6. क्रिएटर एक ऑब्जेक्ट रखता है: क्लाइंट एडिट DO को भेजता है, DO सत्यापित करता है और CRDT डेल्टा के ज़रिए सभी कनेक्टेड क्लाइंट को प्रसारित करता है
7. DO हर एडिट पर चंक स्टेट को स्टोरेज में सहेजता है (डीबाउंस्ड)
8. दूसरे खिलाड़ी नए ऑब्जेक्ट को 100-200ms के भीतर प्रकट होते देखते हैं

परफ़ॉर्मेंस बजट

एक मिड-रेंज डेस्कटॉप (RTX 3060 / M1 Mac / 16GB RAM) पर 60fps अनुभव के लिए:

संसाधन	बजट	नोट्स
ड्रॉ कॉल	प्रति फ़्रेम < 500	बैचिंग, इंस्टैंसिंग, LOD
ट्रायएंगल	प्रति फ़्रेम < 2M	LOD इसे नियंत्रण में रखता है
टेक्सचर मेमोरी	< 512 MB	KTX2 कम्प्रेशन, स्ट्रीमिंग, एटलस पूलिंग
ज्यामिति मेमोरी	< 256 MB	साझा बफ़र, पूलिंग, आक्रामक अनलोड
JavaScript हीप	< 512 MB	ECS ऑब्जेक्ट नहीं, टाइप्ड एरे उपयोग करता है
नेटवर्क	निरंतर < 500 KB/s	डेल्टा कम्प्रेशन, स्पेशियल प्रासंगिकता फ़िल्टरिंग
शुरुआती लोड	< 10 MB, < 5 सेकंड	प्रोग्रेसिव लोडिंग, टेरेन-पहले
चंक लोड	< 200 KB, < 200ms	आसपास के चंक प्री-फ़ेच करें

सफल ब्राउज़र गेम और वे क्या साबित करते हैं

ब्राउज़र गेम कोई निच नहीं हैं। ये सबसे बड़े गेमिंग बाज़ारों में से एक हैं। Poki हर महीने 100 मिलियन से ज़्यादा खिलाड़ियों को सेवा देता है। CrazyGames, Newgrounds, और itch.io लाखों और को सेवा देते हैं। ब्राउज़र में सफल होने वाले गेमों में विशिष्ट आर्किटेक्चरल पैटर्न होते हैं जिन पर अध्ययन सार्थक है।

आज शिप होने वाले ब्राउज़र 3D गेम

Hordes.io: एक सतत 3D ब्राउज़र MMO में 200+ खिलाड़ी। कस्टम WebGL, लो-पॉली शैली, 5 सेकंड से कम में लोड होता है। एक डेवलपर ने बनाया।

Hordes.io सबसे प्रासंगिक ब्राउज़र MMO है। कस्टम WebGL रेंडरिंग का उपयोग करके एक अकेले डेवलपर द्वारा बनाया गया, यह एक सतत 3D वर्ल्ड में 200+ खिलाड़ियों को रियल-टाइम कॉम्बैट, गिल्ड, क्लास, और PvP के साथ रखता है। पूरा गेम 5 सेकंड से कम में लोड होता है। दुनिया आक्रामक कलिंग वाले ज़ोन में बँटी है। प्लेयर मॉडल सरल हैं (फ़्लैट शेडिंग के साथ लो-पॉली) लेकिन पार्टिकल इफ़ेक्ट और एनिमेशन कॉम्बैट को रिस्पॉन्सिव महसूस कराते हैं। Hordes.io तीन चीज़ें साबित करता है: ब्राउज़र MMO एक सीन में सैकड़ों समवर्ती खिलाड़ी संभाल सकते हैं, एक अकेला डेवलपर एक बना सकता है, और ब्राउज़र में स्टाइलाइज़्ड ग्राफ़िक्स रियलिस्टिक से बेहतर परफ़ॉर्म करते हैं।

Krunker.io: 10M मासिक खिलाड़ी, Three.js पर बना, एक पूर्ण इन-ब्राउज़र मैप एडिटर और उपयोगकर्ता-जनित कंटेंट मार्केटप्लेस के साथ।

Krunker.io 10 मिलियन से ज़्यादा मासिक खिलाड़ियों के शिखर पर पहुँचा और FRVR द्वारा अधिग्रहित किया गया। यह एक पूर्ण मैप एडिटर, कस्टम गेम मोड, उपयोगकर्ता-जनित कंटेंट, और एक मार्केटप्लेस वाला ब्राउज़र-आधारित FPS है। Three.js पर बना, यह अपनी ब्लॉकी आर्ट शैली और आक्रामक ऑप्टिमाइज़ेशन के कारण लो-एंड हार्डवेयर पर भी 60fps+ पर चलता है। लेवल एडिटर विशेष रूप से प्रासंगिक है। खिलाड़ी एक वॉक्सेल जैसी ब्लॉक सिस्टम का उपयोग करके मैप बनाते हैं, उन्हें मार्केटप्लेस पर साझा करते हैं, और दूसरे उन पर खेलते हैं। यह क्रिएटर-वर्ल्ड लूप का छोटा रूप है: कुछ बनाओ, उसे साझा करो, दूसरे उसे अनुभव करें। Krunker ने साबित किया कि उपयोगकर्ता-जनित 3D कंटेंट ब्राउज़र में काम कर सकता है अगर निर्माण टूल काफ़ी सरल हों।

ev.io Babylon.js पर बना एक ब्राउज़र FPS है। यह अधिकांश हार्डवेयर पर अच्छा चलता है, कस्टम मैप का समर्थन करता है, और दिखाता है कि Babylon का WebGL रेंडरर एक ब्राउज़र टैब में तेज़-गति वाला 3D एक्शन संभाल सकता है। गेम परफ़ॉर्मेंस बजट के भीतर रहने के लिए आक्रामक टेक्सचर कम्प्रेशन और लो-पॉली पर्यावरण उपयोग करता है।

Shell Shockers (5 मिलियन से ज़्यादा मासिक खिलाड़ी) एक 3D मल्टीप्लेयर शूटर है जहाँ आप अंडों के रूप में खेलते हैं। Three.js पर बना, यह ब्राउज़र में रिस्पॉन्सिव हिट डिटेक्शन के साथ रियल-टाइम मल्टीप्लेयर संभालता है। कार्टूनी आर्ट शैली एसेट की ज़रूरतें न्यूनतम रखती है जबकि फिर भी पॉलिश्ड दिखती है।

Townscaper: इमारतें रखने के लिए क्लिक करें, सिस्टम सड़कें, मेहराब, और सीढ़ियाँ स्वचालित रूप से जनरेट करता है। कोई मेन्यू नहीं, कोई उद्देश्य नहीं। शुद्ध रचनात्मक आनंद पर 1 मिलियन से ज़्यादा कॉपी बिकीं।

Townscaper एक ब्राउज़र गेम नहीं है, लेकिन वर्ल्ड बिल्डिंग के प्रति इसका तरीका बेहद प्रासंगिक है। खिलाड़ी एक पानी की सतह पर इमारतें रखने के लिए क्लिक करते हैं। गेम प्लेसमेंट पैटर्न के आधार पर स्वचालित रूप से वास्तुशिल्प डिटेल, सड़कें, मेहराब, और सीढ़ियाँ जनरेट करता है। कोई मेन्यू नहीं, कोई सेटिंग नहीं, कोई उद्देश्य नहीं। बस क्लिक करो और बनाओ। इसकी 1 मिलियन से ज़्यादा कॉपी बिकीं। सीख: कभी-कभी सबसे सरल रचनात्मक टूल सबसे आकर्षक अनुभव पैदा करते हैं। अगर हम दुनिया में ऑब्जेक्ट रखना Townscaper जितना तत्काल महसूस करा सकें, तो क्रिएटर घंटों बनाने में बिताएँगे।

A-Frame / 8th Wall अनुभव। A-Frame (Three.js पर बना) हज़ारों वेब-आधारित 3D अनुभवों को चलाता है। 8th Wall, वह लंबे समय से चलने वाला WebAR प्लैटफ़ॉर्म जिसे Niantic ने अधिग्रहित किया, ने दिखाया कि जटिल कैमरा-आधारित AR मोबाइल ब्राउज़र में बिना प्लगइन चलता है, हालाँकि Niantic ने 2025 के अंत में घोषणा की कि वह सेवा बंद कर रहा है (होस्ट किए गए अनुभव 2027 तक चालू रहेंगे)। ये गेम नहीं हैं, लेकिन वे दिखाते हैं कि physics और इंटरैक्शन के साथ जटिल 3D रेंडरिंग एक ब्राउज़र टैब में बिना प्लगइन काम करती है। इनमें से कई अनुभव 2-3 सेकंड में लोड होते हैं और मिड-रेंज फ़ोन पर चलते हैं।

Vuntra City: एक लाइव प्रोसीजरल सिटी लैब

Vuntra City एक नेटिव UE5 प्रोजेक्ट है, ब्राउज़र गेम नहीं, इसलिए यह हमारे स्टैक के लिए सीधा परफ़ॉर्मेंस बेंचमार्क नहीं है। फिर भी यह हमारे ओपन-वर्ल्ड आर्किटेक्चर के लिए सबसे उपयोगी पब्लिक केस स्टडीज में से एक है क्योंकि devlogs असली प्रोडक्शन दबाव में सिस्टम डिज़ाइन ट्रेड-ऑफ़ के बारे में असामान्य रूप से विशिष्ट हैं।

एक मज़बूत सीख स्पीड-अवेयर डिटेल पॉलिसी है। ट्रांसपोर्ट और ऑप्टिमाइज़ेशन वीडियो में, हाई-स्पीड ट्रैवर्सल को छतों के ऊपर ले जाया जाता है, जबकि स्पीड बढ़ने पर वर्ल्ड डिटेल घट जाती है ताकि स्ट्रीम मैनेजर इंटीरियर churn से न दब जाए (rapid transport, optimization techniques)। यह हमारी ब्राउज़र योजना से साफ़ मैप होता है जहाँ वेलोसिटी को सीधे प्रीफ़ेच रेडियस, इंटीरियर एक्टिवेशन रेंज, और प्रति-फ़्रेम स्पॉन बजट नियंत्रित करना चाहिए।

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

NPC का काम भी बेहद प्रासंगिक है। मिलियन-NPC सिस्टम मोटे शेड्यूल स्टेट को ग्लोबली कंप्यूट करता है, फिर केवल प्लेयर-आसन्न स्पेस में महँगे व्यवहार का सिमुलेशन करता है (million persistent NPCs, behind the scenes)। हमारे लिए, यह एक दो-स्तरीय सिमुलेशन मॉडल को मज़बूत करता है: सस्ती डिटरमिनिस्टिक फ़ार-फ़ील्ड स्टेट, AOI के अंदर समृद्ध नियर-फ़ील्ड व्यवहार।

आखिर में, Vuntra City का पर्यावरण डिज़ाइन उस चीज़ को मज़बूत करता है जिसे तकनीकी योजना में भूलना आसान है: वितरण डिज़ाइन कंटेंट डिज़ाइन है। प्रोजेक्ट एकसमान रैंडम प्लेसमेंट से बचता है, आश्चर्य के लिए वेटेड आउटलायर उपयोग करता है, और सर्वव्यापी मिनिमैप मार्कर के बजाय डायजेटिक maps और addresses के ज़रिए खोज चलाता है (procedural environments don't have to be boring, where we're going we won't need a minimap)।

बड़े पैमाने पर पहुँचे ब्राउज़र गेम

Agar.io (2015) ने साबित किया कि ब्राउज़र मल्टीप्लेयर लाखों तक पहुँच सकता है। अपने शिखर पर, इसके सर्वर भर में 100,000 से ज़्यादा समवर्ती खिलाड़ी थे। गेम 2D और यांत्रिक रूप से सरल है (छोटी सेल्स को सोखकर बढ़ें), लेकिन नेटवर्किंग आर्किटेक्चर स्पेशियल पार्टिशनिंग के ज़रिए विशाल समवर्तीता संभालता है। हर सर्वर गेम वर्ल्ड का एक क्षेत्र चलाता है। खिलाड़ी केवल अपने व्यू में मौजूद एंटिटी के बारे में अपडेट पाते हैं। यह वही इंटरेस्ट मैनेजमेंट पैटर्न है जो एक 3D ओपन वर्ल्ड के लिए चाहिए, बस 2D में।

Slither.io ने Agar.io की सफलता पर निर्माण किया और साबित किया कि मॉडल स्केल करता है। शिखर पर 67 मिलियन मासिक सक्रिय उपयोगकर्ता। गेम रियल-टाइम पोज़िशन सिंक के लिए WebSocket और नेटवर्क ट्रैफ़िक सीमित करने के लिए स्पेशियल पार्टिशनिंग उपयोग करता है। एक डिटेल ध्यान देने योग्य है: Slither.io की सर्वर-साइड कोलिज़न डिटेक्शन दूर के खिलाड़ियों के लिए नज़दीकी (30 Hz) की तुलना में कम टिक रेट (5 Hz) पर चलती है। दूरी के अनुसार यह वेरिएबल टिक रेट एक 3D ओपन वर्ल्ड पर लागू होती है।

Surviv.io एक ब्राउज़र-आधारित बैटल रॉयल था जो Kongregate द्वारा अधिग्रहित होने से पहले 50 मिलियन मासिक खिलाड़ियों तक पहुँचा। इसने पूरी तरह ब्राउज़र में रियल-टाइम नेटवर्क्ड physics, विध्वंसक पर्यावरण, और आइटम पिकअप के साथ एक पूर्ण 80-खिलाड़ी बैटल रॉयल मैच चलाया। मैप पहले से डिज़ाइन किए गए बिल्डिंग टेम्पलेट से प्रोसीजरली व्यवस्थित था, जो एक पैटर्न है जिसे हम क्रिएटर-रखी संरचनाओं के लिए उपयोग कर सकते हैं।

Zombs Royale ने ब्राउज़र में तेज़ लोड टाइम और रिस्पॉन्सिव नेटवर्किंग के साथ एक 100-खिलाड़ी बैटल रॉयल चलाया। Surviv.io की तरह, इसने साबित किया कि रियल-टाइम ब्राउज़र गेमों में बड़ी खिलाड़ी संख्याएँ व्यावसायिक रूप से व्यवहार्य हैं, सिर्फ़ तकनीकी रूप से संभव नहीं।

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

RuneScape: एक MMO जो ब्राउज़र में चला गया

RuneScape: एक ब्राउज़र टैब में चलने वाली 20+ साल के कंटेंट वाली पूरी MMO। कस्टम बाइनरी प्रोटोकॉल, टाइल-आधारित स्ट्रीमिंग, प्रति सर्वर 2,000 समवर्ती खिलाड़ी। प्रमाण कि ब्राउज़र MMO स्केल पर काम करते हैं।

RuneScape एक ब्राउज़र-आधारित ओपन वर्ल्ड के लिए सबसे महत्वपूर्ण केस स्टडी है क्योंकि यह असल में हुआ। Jagex ने 20 साल के कंटेंट वाली एक पूरी MMO को ब्राउज़र में पहुँचाया।

RuneScape मूल रूप से एक Java applet के रूप में चलता था। जब ब्राउज़र ने Java समर्थन हटाया, तो Jagex ने क्लाइंट को C++ में फिर से बनाया और एक पूरी तरह कार्यात्मक HTML5/WebGL क्लाइंट भी शिप किया। Old School RuneScape (रेट्रो संस्करण) अब Emscripten के ज़रिए WebAssembly में कम्पाइल किए गए एक क्लाइंट के माध्यम से पूरी तरह ब्राउज़र में चलता है। गेम बड़ी सतत दुनिया, प्रति सर्वर सैकड़ों खिलाड़ियों के साथ रियल-टाइम मल्टीप्लेयर, एक कार्यात्मक grand exchange (नीलामी घर) वाली अर्थव्यवस्था, और गहरी प्रगति प्रणालियों वाले 23 कौशल संभालता है।

मायने रखने वाली तकनीकी डिटेल:

• दुनिया मैप स्क्वायर (64x64 टाइल क्षेत्र) में बँटी है। क्लाइंट खिलाड़ी के आसपास क्षेत्रों का एक 13x13 ग्रिड लोड करता है (104x104 टाइल दिखाई देते हैं)। इस ग्रिड के बाहर के क्षेत्र पूरी तरह कल हो जाते हैं।
• टेरेन प्रति टाइल कोने में हाइट मानों के साथ टाइल-आधारित है। टेरेन ओवरले (रास्ते, पानी के किनारे, बीच ट्रांज़िशन) प्रति आकार 12 रोटेशन वेरिएंट वाला एक शेप सिस्टम उपयोग करते हैं। यह एक हाइटमैप से ज़्यादा सीमित है लेकिन बेहद कॉम्पैक्ट और स्ट्रीम करने में तेज़ है।
• नेटवर्क प्रोटोकॉल WebSocket पर कस्टम बाइनरी है। हर पैकेट प्रकार की एक परिभाषित संरचना होती है। प्लेयर पोज़िशन अपडेट मैप स्क्वायर कोऑर्डिनेट के लिए 2 बाइट और मूवमेंट प्रकार के लिए वेरिएबल-लेंथ एन्कोडिंग उपयोग करते हैं। चैट, ट्रेड, और कॉम्बैट इवेंट के अपने कॉम्पैक्ट बाइनरी फ़ॉर्मेट हैं। पूरा प्रोटोकॉल न्यूनतम बैंडविड्थ के लिए भारी रूप से ऑप्टिमाइज़ है।
• ऑब्जेक्ट रेंडरिंग एक मॉडल सिस्टम उपयोग करती है जहाँ सर्वर एक मॉडल ID भेजता है और क्लाइंट कैश्ड मॉडल रेंडर करता है। अधिकांश मॉडल एक बार लोड होते हैं और फिर से उपयोग होते हैं। इसका मतलब है कि दुनिया ज्यामिति स्ट्रीम करने के बजाय मेटाडेटा (कौन-सा मॉडल कहाँ जाता है) के रूप में स्ट्रीम होती है।
• हर सर्वर इंस्टेंस पूरे गेम वर्ल्ड भर में 2,000 समवर्ती खिलाड़ी संभालता है। दुनिया स्पेशियली शार्ड नहीं की गई है। एक अकेली सर्वर प्रोसेस 600ms गेम टिक पर सभी खिलाड़ियों, सभी NPC, और सभी गेम लॉजिक का प्रबंधन करती है। यह काम करता है क्योंकि गेम लॉजिक प्रति-टिक सरल है: प्लेयर एक्शन प्रोसेस करना, NPC AI अपडेट करना, कॉम्बैट हल करना, स्टेट बदलाव प्रसारित करना।

RuneScape हमारे केस के लिए क्या साबित करता है: सतत वर्ल्ड स्टेट, हज़ारों खिलाड़ियों, जटिल गेम सिस्टम, और एक असली अर्थव्यवस्था वाली एक पूरी MMO एक ब्राउज़र टैब में चल सकती है। क्लाइंट 50 MB से कम डाउनलोड होता है, कुछ सेकंड में लोड होता है, और लैपटॉप पर चलता है। अगर एक 20 साल पुरानी Java MMO यह बदलाव कर सकती है, तो एक उद्देश्य-निर्मित ब्राउज़र वर्ल्ड पर और भी कम पाबंदियाँ हैं।

जहाँ RuneScape का तरीका फ़िट नहीं बैठता: RuneScape की रेंडरिंग आइसोमेट्रिक/फ़िक्स्ड-कैमरा है, फ़र्स्ट/थर्ड-पर्सन 3D नहीं। आधुनिक मानकों से विज़ुअल गुणवत्ता कम है। और दुनिया क्रिएटर-एडिटेबल नहीं है। लेकिन नेटवर्किंग आर्किटेक्चर, टाइल-आधारित स्ट्रीमिंग, और यह प्रमाण कि ब्राउज़र MMO दशकों तक खिलाड़ियों को बनाए रखती हैं, सब सीधे प्रासंगिक हैं।

Habbo Hotel: सोशल स्पेस जो 25 साल चले

Habbo Hotel 2000 में लॉन्च हुआ और अब भी चल रहा है। यह एक 2D आइसोमेट्रिक सोशल वर्ल्ड है जहाँ उपयोगकर्ता कमरे बनाते और सजाते हैं, दूसरे लोगों के कमरों में जाते हैं, और मेलजोल करते हैं। शिखर पर, इसके 9 मिलियन मासिक उपयोगकर्ता थे। पूरा अनुभव Flash में चलता था (Flash के बंद होने के बाद अब HTML5 में)।

Habbo इसलिए मायने रखता है कि इसने कितने लंबे समय तक एक क्रिएटर समुदाय को बनाए रखा। रूम सिस्टम असल में उसी का 2D संस्करण है जो हम बना रहे हैं: उपयोगकर्ता एक ग्रिड में फ़र्नीचर ऑब्जेक्ट रखते हैं, लेआउट कस्टमाइज़ करते हैं, और दूसरों को आने के लिए आमंत्रित करते हैं। आर्थिक मॉडल (उपयोगकर्ता असली पैसे से वर्चुअल फ़र्नीचर खरीदते हैं) ने जीवनकाल में 1 बिलियन डॉलर से ज़्यादा राजस्व पैदा किया है।

Habbo क्या सिखाता है:

• उपयोगकर्ता-निर्मित इंटीरियर वाले रूम-आधारित स्पेस दशकों तक एक सोशल प्लैटफ़ॉर्म के रूप में काम करते हैं अगर निर्माण टूल सरल हों और सोशल फ़ीचर मज़बूत हों।
• वर्चुअल फ़र्नीचर अर्थव्यवस्था दीर्घकालिक जुड़ाव बनाए रखती है। उपयोगकर्ता आइटम खरीदते, ट्रेड करते, और जमा करते हैं। आइटम की कोई गेमप्ले उपयोगिता नहीं। वे शुद्ध आत्म-अभिव्यक्ति और हैसियत हैं।
• सोशल स्पेस में मॉडरेशन के लिए लगातार निवेश चाहिए। Habbo कई मॉडरेशन संकटों से गुज़रा है। स्वचालित कंटेंट फ़िल्टरिंग साथ ही मानव मॉडरेटर साथ ही सामुदायिक रिपोर्टिंग न्यूनतम व्यवहार्य तरीका है।
• Flash से HTML5 (करीब 2020-2021 में पूरा) में बदलाव ने साबित किया कि एक बड़ी सोशल वर्ल्ड अपने समुदाय को खोए बिना रेंडरिंग तकनीक माइग्रेट कर सकती है। उपयोगकर्ता अपने कमरों और दोस्तों की परवाह करते हैं, अंतर्निहित तकनीक की नहीं।

Among Us और स्पेशियल सोशल गेम

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

एक क्रिएटर वर्ल्ड को बेहतर बनाने वाले स्पेशियल सोशल फ़ीचर:

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

Poki और CrazyGames पर स्केल हुए ब्राउज़र गेम

Poki और CrazyGames मिलकर हर महीने 150 मिलियन से ज़्यादा खिलाड़ियों को सेवा देते हैं। इन प्लैटफ़ॉर्म पर सबसे अच्छा परफ़ॉर्म करने वाले गेम विशेष रूप से ब्राउज़र में क्या काम करता है इस बारे में अंतर्दृष्टि देते हैं।

ब्राउज़र गेम पोर्टल पर सबसे अच्छा परफ़ॉर्म करने वाले पैटर्न:

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

इन पोर्टल पर सबसे सफल 3D गेम (जैसे Shell Shockers, 1v1.LOL, Smash Karts) पॉली काउंट कम, टेक्सचर सरल, और फ़्रेमरेट ऊँचा रखते हैं। वे साबित करते हैं कि खिलाड़ी सरल ग्राफ़िक्स स्वीकार करते हैं अगर अनुभव स्मूथ और रिस्पॉन्सिव हो।

ब्राउज़र-आधारित क्रिएटर प्लेटफ़ॉर्म

Hubs by Mozilla (अब समुदाय द्वारा संभाला जाता है)। ब्राउज़र में मल्टी-यूज़र 3D स्पेस, Three.js और A-Frame पर बने। वॉइस चैट, अवतार, और साझा ऑब्जेक्ट सपोर्ट करता है। यह कोई ओपन वर्ल्ड नहीं है (यह रूम-आधारित है), लेकिन नेटवर्किंग और रेंडरिंग आर्किटेक्चर प्रासंगिक हैं। Mozilla ने होस्टेड सेवा बंद करने से पहले इसे ओपन-सोर्स कर दिया, इसलिए पूरा कोडबेस अध्ययन के लिए उपलब्ध है। GitHub।

Hyperfy. पूरी तरह ब्राउज़र में चलने वाला एक वेब-आधारित मेटावर्स प्लेटफ़ॉर्म। Three.js रेंडरिंग, मल्टीप्लेयर, अवतार कस्टमाइज़ेशन, और वर्ल्ड बिल्डिंग। यह Hubs से हमारे लक्ष्य के ज़्यादा क़रीब है क्योंकि यह क्रिएटर टूल्स पर ज़ोर देता है। वर्ल्ड्स बिना डाउनलोड के एक ब्राउज़र टैब में लोड होते हैं। hyperfy.io।

Ethereal Engine (पहले XREngine)। मल्टी-यूज़र वर्ल्ड्स के लिए ओपन-सोर्स इंजन, Three.js और bitECS पर बना। WebXR, स्पेशियल ऑडियो, और वर्ल्ड एडिटिंग सपोर्ट करता है। इसमें बिल्ट-इन ECS आर्किटेक्चर, नेटवर्किंग लेयर, और एडिटर टूल्स हैं। यह उसके सबसे क़रीब मौजूद ओपन-सोर्स प्रोजेक्ट है जिसका हम वर्णन कर रहे हैं। यह अध्ययन करने लायक है कि वे entity management के लिए bitECS को Three.js के साथ कैसे जोड़ते हैं और उनकी नेटवर्किंग spatial स्टेट को कैसे संभालती है। GitHub।

Dusk (पहले Rune)। वेब गेम्स के लिए मल्टीप्लेयर गेम SDK। यह नेटवर्किंग लेयर संभालता है ताकि डेवलपर गेमप्ले पर ध्यान दें। उनका स्टेट सिंक तरीका सर्वर reconciliation के साथ predicted स्टेट इस्तेमाल करता है, जो रिस्पॉन्सिव मल्टीप्लेयर का मानक मॉडल है। SDK rollback netcode की जटिलता को छिपा देता है। उनके डेवलपर अनुभव के लिए अध्ययन करने लायक है।

Niantic Studio. एक ब्राउज़र-आधारित विज़ुअल एडिटर और वेब गेम इंजन (8th Wall के टूलिंग का उत्तराधिकारी) जो 3D और XR अनुभव बनाने के लिए है जिन्हें दूसरे एक ब्राउज़र में देख सकें। यह दर्शाता है कि अगर टूल्स पहुँच योग्य हों तो ग़ैर-तकनीकी क्रिएटर भी एक ब्राउज़र में 3D दृश्य बना सकते हैं। (Niantic ने अपने geospatial काम को Niantic Spatial में अलग किया और अपना गेम्स कारोबार, जिसमें Pokemon GO भी शामिल है, 2025 में Scopely को बेच दिया।)

PlayCanvas Editor. यह ख़ुद कोई गेम नहीं है, लेकिन PlayCanvas का क्लाउड-आधारित 3D एडिटर दिखाता है कि सहयोगी वर्ल्ड-बिल्डिंग टूल्स ब्राउज़र में चल सकते हैं। टीम के कई सदस्य एक साथ वही दृश्य एडिट करते हैं। एडिटर बदलावों को एक रियल-टाइम सिंक लेयर के ज़रिए संप्रेषित करता है। यह वही सहयोगी निर्माण मॉडल है जिसकी हमें ज़रूरत होगी, बस एक गेम एडिटर के बजाय हमारी दुनिया canvas के रूप में।

नेटिव क्रिएटर प्लेटफ़ॉर्म (ब्राउज़र के लिए सबक)

ये प्लेटफ़ॉर्म नेटिव ऐप के रूप में चलते हैं, लेकिन क्रिएटर टूल्स, वर्ल्ड persistence, और सोशल डायनामिक्स को लेकर उनके डिज़ाइन फ़ैसले सीधे लागू होते हैं।

Roblox: 8 करोड़+ डेली यूज़र, 2023 में क्रिएटर्स को $740M का भुगतान। निर्माण इन-इंजन होता है। खोज सोशल है। वह बिज़नेस मॉडल जो साबित करता है कि क्रिएटर प्लेटफ़ॉर्म ख़ुद को टिका सकते हैं।

Roblox एक क्रिएटर वर्ल्ड के लिए अकेला सबसे ज़रूरी संदर्भ है। 8 करोड़+ डेली एक्टिव यूज़र। क्रिएटर्स पूरे 3D अनुभव (गेम, सोशल स्पेस, स्टोर) बनाते हैं जिन्हें दूसरे प्लेयर्स देखने जाते हैं। प्लेटफ़ॉर्म होस्टिंग, नेटवर्किंग, खोज, और monetization संभालता है।

Roblox जो सही करता है:

• निर्माण इन-इंजन है। Roblox Studio वही माहौल है जिसे प्लेयर्स अनुभव करते हैं। क्रिएटर्स अपना काम तुरंत टेस्ट करते हैं। कोई export/upload/wait चक्र नहीं है। एक ब्राउज़र वर्ल्ड के लिए, एडिटर ख़ुद दुनिया होनी चाहिए।
• स्क्रिप्टिंग पहुँच योग्य है। Lua (Roblox की स्क्रिप्टिंग भाषा) इतनी सरल है कि बच्चे इसे सीख लेते हैं। जटिल व्यवहार संभव है लेकिन वैकल्पिक। फ़र्श नीचा है और छत ऊँची है।
• खोज सोशल है। आप अनुभव इसलिए पाते हैं क्योंकि दोस्त उन्हें खेल रहे हैं। होमपेज trending अनुभव दिखाता है। एक ब्राउज़र वर्ल्ड के लिए, दुनिया ख़ुद खोज की सतह है। आप घूमकर चीज़ें खोजते हैं।
• Monetization काम करती है। क्रिएटर्स असली पैसा कमाते हैं (Roblox ने 2023 में क्रिएटर्स को $740 मिलियन का भुगतान किया)। यह गंभीर रचनात्मक प्रयास को आकर्षित करता है। आर्थिक प्रोत्साहन के बिना, क्रिएटर प्लेटफ़ॉर्म शौक़िया प्रोजेक्ट बनकर फीके पड़ जाते हैं।
• Roblox का रेंडरिंग इंजन कस्टम है और एक नेटिव ऐप में चलता है, ब्राउज़र में नहीं। लेकिन प्रति-अनुभव asset बजट आधुनिक मानकों से मामूली हैं (अधिकतम 100 MB अनुशंसित)। ज़्यादातर सफल Roblox अनुभव low-poly स्टाइलाइज़्ड आर्ट इस्तेमाल करते हैं, जो ब्राउज़र रेंडरिंग सीमाओं के साथ मेल खाता है।

Fortnite Creative / UEFN (Unreal Editor for Fortnite)। Epic ने Unreal Engine का पूरा एडिटर Fortnite क्रिएटर्स तक पहुँचाया। नतीजा एक ऐसा प्लेटफ़ॉर्म है जहाँ लोग पेशेवर-स्तर के टूल्स से द्वीप (स्वयं-निहित दुनियाएँ) बनाते हैं। Fortnite होस्टिंग, मल्टीप्लेयर, और वितरण संभालता है।

प्रासंगिक अंतर्दृष्टि:

• पेशेवर टूल्स पेशेवर कंटेंट आकर्षित करते हैं। UEFN दृश्य रूप से शानदार अनुभव पैदा करता है क्योंकि क्रिएटर्स के पास UE5 की पूरी क्षमताओं तक पहुँच है। समझौता है जटिलता। UEFN की सीखने की राह कठिन है।
• द्वीप-आधारित instancing (हर रचना एक अलग दुनिया है) एक अकेली साझा दुनिया की moderation और conflict समस्याओं से बचाता है। लेकिन इसका यह भी मतलब है कि क्रिएटर्स घूमते हुए स्वाभाविक रूप से एक-दूसरे का काम नहीं खोजते। आप द्वीपों पर मेन्यू के ज़रिए जाते हैं, चलकर नहीं।
• बिज़नेस मॉडल काम करता है। Fortnite का क्रिएटर प्रोग्राम जुड़ाव के आधार पर भुगतान करता है। शीर्ष क्रिएटर्स साल में लाखों कमाते हैं। फिर से, आर्थिक प्रोत्साहन गुणवत्ता को आगे बढ़ाता है।

Dreams (Media Molecule / PlayStation)। Dreams ने कंसोल प्लेयर्स को एक पूरा 3D निर्माण सुइट (मॉडलिंग, एनिमेशन, संगीत, लॉजिक, लेवल डिज़ाइन) और रचनाएँ साझा करने का एक प्लेटफ़ॉर्म दिया। टूल की गहराई के मामले में यह अब तक बना सबसे महत्वाकांक्षी क्रिएटर-प्लेटफ़ॉर्म है।

प्रासंगिक अंतर्दृष्टि:

• पॉलीगन एडिटिंग के बजाय मूर्ति-आधारित मॉडलिंग। क्रिएटर्स move/grab/smooth टूल्स से नरम आयतन आकार देते हैं, ZBrush जैसा लेकिन ज़्यादा सहज। सीखने की राह कोमल है। यह तरीका इन-ब्राउज़र निर्माण के लिए अच्छी तरह बैठता है क्योंकि इसमें vertices और UV maps समझने की ज़रूरत नहीं।
• हर चीज़ एक साझा asset है। अगर कोई पेड़ का मॉडल बनाता है, तो कोई भी इसे अपनी रचना में इस्तेमाल कर सकता है (श्रेय के साथ)। यह एक चक्रवृद्धि रचनात्मक ecosystem बनाता है जहाँ हर रचना प्लेटफ़ॉर्म को और मूल्यवान बनाती है।
• Dreams व्यावसायिक रूप से संघर्ष करता रहा आलोचनात्मक प्रशंसा के बावजूद। समस्या वितरण थी: यह PlayStation तक सीमित था, और निर्माण टूल्स इतने गहरे थे कि ज़्यादातर प्लेयर कभी कंटेंट उपभोग से आगे नहीं बढ़े। सबक: निर्माण टूल्स इतने सरल होने चाहिए कि अधिकांश यूज़र उन्हें आज़माएँ, भले ही केवल अल्पसंख्यक गंभीर बिल्डर बनें।

Core (Manticore Games)। मल्टीप्लेयर गेम बनाने और खेलने का एक मुफ़्त प्लेटफ़ॉर्म, Unreal Engine पर एक सरल किए गए एडिटर के साथ बना। Core का एडिटर एक नेटिव ऐप के रूप में चलता है, लेकिन इसका दर्शन प्रासंगिक है। टेम्पलेट और समुदाय-साझा स्क्रिप्ट शुरुआती लोगों को पहले से बने घटकों से गेम जोड़ने देते हैं। उन्नत क्रिएटर्स कस्टम व्यवहार के लिए Lua स्क्रिप्ट लिख सकते हैं। Core एक बड़े दर्शक तक पहुँचने में संघर्ष करता रहा, आंशिक रूप से इसलिए कि गेम Core लॉन्चर के ज़रिए खेलने पड़ते थे। एक ब्राउज़र-आधारित संस्करण में यह घर्षण नहीं होता।

VRChat और Rec Room सोशल प्लेटफ़ॉर्म हैं जहाँ क्रिएटर्स ऐसे स्पेस बनाते हैं जिन्हें दूसरे देखने जाते हैं। VRChat Unity इस्तेमाल करता है और PC/VR पर चलता है। Rec Room मोबाइल समेत हर चीज़ पर चलता है। दोनों साबित करते हैं कि यूज़र-जेनरेटेड 3D वर्ल्ड्स बड़े समुदायों को टिका सकते हैं। VRChat तकनीकी रूप से ज़्यादा प्रभावशाली है (कस्टम शेडर, जटिल अवतार)। Rec Room ज़्यादा पहुँच योग्य है (इन-ऐप निर्माण टूल्स, सरल ग्राफ़िक्स, व्यापक प्लेटफ़ॉर्म सपोर्ट)। एक ब्राउज़र वर्ल्ड के लिए, Rec Room का सरल इन-ऐप निर्माण टूल्स वाला तरीका VRChat के external-tool वर्कफ़्लो से ज़्यादा लागू होता है।

Second Life: 2003 में लॉन्च हुआ, 2 लाख+ डेली यूज़र के साथ अब भी चल रहा है। पूरी तरह यूज़र-निर्मित। पार्सल-आधारित स्वामित्व, ~$500M/साल मूल्य की वर्चुअल अर्थव्यवस्था। persistence और moderation में 20 साल के सबक।

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

Second Life 20+ साल बाद क्या सिखाता है:

• persistence ग्राफ़िक्स से ज़्यादा मायने रखती है। Second Life के विज़ुअल पुराने हैं, लेकिन दुनिया बनी रहती है। रचनाएँ वहीं रहती हैं जहाँ आप उन्हें रखते हैं। रिश्ते और इतिहास जमा होते हैं। यही persistence लोगों को वापस आते रहने पर मजबूर करती है।
• अर्थव्यवस्था निर्माण को आगे बढ़ाती है। Second Life का GDP सालाना $500 मिलियन अनुमानित है। क्रिएटर्स बनाते हैं क्योंकि वे बेच सकते हैं। आर्थिक प्रोत्साहन के बिना, क्रिएटर कंटेंट की मात्रा और गुणवत्ता गिर जाती है।
• यूज़र-जेनरेटेड कंटेंट को moderation इंफ़्रास्ट्रक्चर चाहिए। Second Life ने 20 साल की moderation चुनौतियाँ झेली हैं। कोई भी प्लेटफ़ॉर्म जहाँ यूज़र एक साझा स्पेस में मनमाना कंटेंट रख सकते हैं, उसे स्वचालित स्कैनिंग, रिपोर्टिंग टूल्स, और मानव समीक्षा चाहिए।
• ज़मीन-आधारित spatial संगठन काम करता है। Second Life अपनी दुनिया को पार्सल में बाँटता है जो यूज़र के पास होते हैं। हर पार्सल की एक prim (ऑब्जेक्ट) सीमा होती है। यह स्वाभाविक रूप से किसी एक क्रिएटर को सारे संसाधन खाने से रोकता है। एक ब्राउज़र वर्ल्ड के लिए, प्रति-चंक ऑब्जेक्ट बजट के साथ चंक-आधारित स्वामित्व समकक्ष पैटर्न है।

तुलनात्मक विश्लेषण: हर गेम हमें क्या सिखाता है

गेम	मुख्य सबक	लागू होने वाली टेक	अनदेखा करने पर जोखिम
Skyrim	सेल ग्रिड के साथ चंक-आधारित स्ट्रीमिंग	हाइटमैप टेरेन, LOD टियर, इंटीरियर/एक्सटीरियर अलगाव	दुनिया ब्राउज़र मेमोरी में नहीं समाती
The Witcher 3	अलग-अलग टीमों द्वारा परतदार वर्ल्ड संरचना	कंटेंट-अवेयर स्ट्रीमिंग, इम्पोस्टर रेंडरिंग	क्रिएटर स्वतंत्र रूप से काम नहीं कर सकते
Breath of the Wild	सिस्टमिक नियम स्क्रिप्टेड कंटेंट को मात देते हैं	मटेरियल इंटरैक्शन सिस्टम, फ़िज़िक्स-संचालित गेमप्ले	दुनिया स्टैटिक और बेजान महसूस होती है
GTA V	ambient जीवन दुनिया को असली महसूस कराता है	NPC व्यवहार सिस्टम, ट्रैफ़िक, दिन का समय	क्रिएटर वर्ल्ड एक ख़ाली म्यूज़ियम जैसी महसूस होती है
Elden Ring	घनत्व में बदलाव और asset पुनः उपयोग	मॉड्यूलर asset लाइब्रेरी, विरल + घने ज़ोन	या तो बहुत ख़ाली या भरने में बहुत महँगी
No Man's Sky	canvas के लिए प्रोसीजरल जेनरेशन, आत्मा के लिए क्रिएटर कंटेंट	seed-आधारित टेरेन, छोटा बेस डेटा मॉडल	अनंत लेकिन उबाऊ टेरेन
Minecraft	पूरी तरह संपादन योग्य दुनिया, सरल टूल्स, अनंत गहराई	चंक स्ट्रीमिंग, palette कम्प्रेशन, block-edit प्रोटोकॉल	क्रिएटर दुनिया को ख़ुद दोबारा आकार नहीं दे सकते
Roblox	निर्माण इन-इंजन है, अर्थव्यवस्था गुणवत्ता को आगे बढ़ाती है	इन-वर्ल्ड एडिटर, क्रिएटर monetization	कोई नहीं बनाता क्योंकि कोई कारण नहीं है
Krunker.io	सरल टूल्स के साथ ब्राउज़र UGC बड़े पैमाने पर काम करता है	Three.js रेंडरिंग, voxel-आधारित एडिटर, marketplace	निर्माण टूल्स आम क्रिएटर्स के लिए बहुत जटिल
Hordes.io	ब्राउज़र 3D में 200+ प्लेयर, solo-dev संभव	कस्टम WebGL, spatial culling, स्टाइलाइज़्ड आर्ट	मल्टीप्लेयर लेयर को ज़रूरत से ज़्यादा इंजीनियर करना
Vuntra City (नेटिव संदर्भ)	स्पीड-अवेयर स्ट्रीमिंग और दो-स्तरीय वर्ल्ड सिमुलेशन एक विशाल प्रोसीजरल शहर को सुसंगत रखते हैं	वेग-युग्मित LOD नीति, टोपोलॉजी query लेयर, far-field schedule सिमुलेशन + near-field व्यवहार	तेज़ ट्रैवर्सल pop-in और सिमुलेशन spikes पैदा करता है
Agar.io / Slither.io	spatial partitioning विशाल concurrency संभव बनाती है	दूरी के हिसाब से variable tick rate, interest management	बड़े पैमाने पर नेटवर्क ढह जाता है
Second Life	persistence और अर्थव्यवस्था 20-साल के समुदाय टिकाती हैं	पार्सल-आधारित स्वामित्व, ऑब्जेक्ट बजट, marketplace	कोई दीर्घकालिक retention नहीं
Dreams	मूर्ति-आधारित निर्माण पॉलीगन एडिटिंग से ज़्यादा सहज है	आयतन-आधारित मॉडलिंग, साझा asset लाइब्रेरी	निर्माण टूल्स CAD प्रोग्राम जैसे लगते हैं
Fortnite Creative	प्रो टूल्स प्रो कंटेंट आकर्षित करते हैं	प्लेटफ़ॉर्म में पूरी एडिटर क्षमताएँ	कंटेंट गुणवत्ता की छत बहुत नीची है
RuneScape	पूरा MMO Wasm, बाइनरी प्रोटोकॉल के ज़रिए ब्राउज़र में काम करता है	Emscripten, कस्टम बाइनरी WebSocket प्रोटोकॉल, टाइल स्ट्रीमिंग	ब्राउज़र क्या संभाल सकते हैं इसे कम आँकना
Habbo Hotel	सरल रूम निर्माण 25-साल का समुदाय टिकाता है	ग्रिड-आधारित प्लेसमेंट, वर्चुअल फ़र्नीचर अर्थव्यवस्था	निर्माण टूल्स को ज़रूरत से ज़्यादा जटिल बनाना

हमारे ख़ास मामले (ब्राउज़र-आधारित, क्रिएटर-केंद्रित, मल्टीप्लेयर) के लिए सबसे ज़्यादा मायने रखने वाले गेम हैं Minecraft (संपादन योग्य दुनिया, छोटा डेटा), Roblox (इन-इंजन निर्माण, अर्थव्यवस्था), Krunker (बड़े पैमाने पर ब्राउज़र UGC), और Hordes.io (ब्राउज़र MMO आर्किटेक्चर)। AAA टाइटल (Skyrim, BotW, Witcher 3) रेंडरिंग और स्ट्रीमिंग सिखाते हैं। ब्राउज़र हिट (Agar.io, Slither.io, Surviv.io) बड़े पैमाने पर नेटवर्किंग सिखाते हैं। क्रिएटर प्लेटफ़ॉर्म (Roblox, Dreams, Second Life) समुदाय की डायनामिक्स सिखाते हैं। Vuntra City एक आधुनिक प्रोसीजरल शहर में स्पीड-अवेयर स्ट्रीमिंग, diegetic नेविगेशन, और मिलियन-एजेंट सिमुलेशन पैटर्न के लिए एक वर्तमान, implementation-स्तर का संदर्भ जोड़ता है।

Skyrim और The Witcher एक ब्राउज़र में कैसे दिखेंगे

चलिए ठोस बात करते हैं। अगर आपने Skyrim के Whiterun को लेकर उसे ब्राउज़र डिलीवरी के लिए दोबारा बनाया:

टेरेन: Whiterun के आस-पास का इलाका लगभग 2km x 2km है। हमारे चंक साइज़ (64m) पर, यह लगभग 32x32 = 1024 चंक्स है। प्रति चंक हाइटमैप पर 2-4 KB के हिसाब से, यह 2-4 MB टेरेन डेटा है। टेरेन टेक्सचर (घास, मिट्टी, चट्टान, बर्फ़) KTX2 atlas टाइलों के रूप में शायद और 5 MB जोड़ें। कुल टेरेन: पूरे क्षेत्र के लिए 10 MB से कम।

संरचनाएँ: Whiterun में ख़ुद शायद 40-50 इमारतें हैं। हर इमारत एक ऑप्टिमाइज़्ड GLB (3 LOD स्तर) के रूप में उच्चतम डिटेल पर शायद 200-500 KB। लेकिन आपको पूरा डिटेल सिर्फ़ 5-10 सबसे क़रीबी इमारतों के लिए चाहिए। बाकी मध्यम या निम्न LOD (प्रत्येक 50-100 KB) हैं। किसी भी समय कुल दिखने वाली संरचनाएँ: 2-5 MB।

फ़ोलिएज: Whiterun के आस-पास Skyrim के पेड़ और घास सभी instanced हैं। आपको शायद 10 अनूठे पेड़ मॉडल चाहिए (पूर्ण LOD पर प्रत्येक 200 KB, billboard इम्पोस्टर के रूप में 20 KB) और एक घास सिस्टम जो GPU पर density map से ब्लेड जेनरेट करता है। कुल फ़ोलिएज assets: 2-3 MB। 5x5 चंक क्षेत्र के लिए instancing डेटा (स्थिति, घुमाव, स्केल): 500 KB से कम।

NPCs: Whiterun में गार्ड के अलावा लगभग 70 नामित NPCs हैं। मध्यम क्वालिटी पर हर अवतार: 100-200 KB। लेकिन किसी भी समय सिर्फ़ 10-20 दिखते हैं। कुल NPC रेंडरिंग डेटा: 2-4 MB।

किसी भी समय दिखने वाले Whiterun-स्केल क्षेत्र के लिए कुल योग: 15-25 MB। यह एक ब्राउज़र में पूरी तरह संभव है। इनिशियल लोड ब्रॉडबैंड पर 3-5 सेकंड के भीतर टेरेन और बड़ी संरचनाएँ दिखा देगा, और डिटेल अगले कुछ सेकंड में भर जाएगा।

The Witcher 3 का Novigrad बड़ा और घना है लेकिन वही सिद्धांत लागू होते हैं। आपको ज़्यादा आक्रामक LOD और स्ट्रीमिंग चाहिए होगी, लेकिन किसी भी पल में कुल दिखने वाला डेटा ब्राउज़र मेमोरी सीमाओं के भीतर रहता है।

हम सबसे पहले क्या बनाएँगे

एक पूरा ओपन वर्ल्ड एक बहु-वर्षीय प्रोजेक्ट है। कुछ असली चीज़ क्रिएटर्स के हाथों में जल्दी पहुँचाने की राह यह है:

फ़ेज़ 1: साझा द्वीप (3 महीने)। हाइटमैप टेरेन, पानी, बुनियादी फ़ोलिएज, दिन/रात चक्र वाला एक अकेला टेरेन चंक (512x512m द्वीप)। Durable Objects के ज़रिए मल्टीप्लेयर (50 तक concurrent यूज़र)। क्रिएटर अपनी मौजूदा Cinevva लाइब्रेरी से AI-जेनरेटेड 3D assets रख सकते हैं। इसे एक साझा diorama की तरह सोचें।

फ़ेज़ 2: विस्तार योग्य दुनिया (3 महीने)। एक 4x4 km दुनिया के लिए चंक स्ट्रीमिंग। क्रिएटर-स्वामित्व वाले प्लॉट जहाँ उनके पास एडिट अनुमतियाँ हैं। टेरेन और ऑब्जेक्ट के लिए LOD सिस्टम। persistent वर्ल्ड स्टेट। पूरी दुनिया में 200 तक concurrent यूज़र।

फ़ेज़ 3: जीवंत दुनिया (6 महीने)। AI-सहायता वाली टेरेन sculpting। प्रोसीजरल फ़ोलिएज और वातावरण। Quest/event सिस्टम ताकि क्रिएटर इंटरैक्टिव अनुभव बना सकें, सिर्फ़ स्टैटिक दृश्य नहीं। वॉइस चैट। अवतार कस्टमाइज़ेशन। दुनिया एक गंतव्य बन जाती है, एक डेमो नहीं।

खुले सवाल

आर्ट स्टाइल। स्टाइलाइज़्ड (low-poly, cel-shaded) रेंडर करना सस्ता है और AI-जेनरेटेड assets के लिए ज़्यादा माफ़ करने वाला। यथार्थवादी के लिए उच्च-गुणवत्ता वाले assets और ज़्यादा रेंडरिंग बजट चाहिए। Skyrim पुराने ग्राफ़िक्स के बावजूद काम कर गया क्योंकि आर्ट डायरेक्शन सुसंगत था। BotW टैबलेट-क्लास हार्डवेयर पर ख़ूबसूरत है क्योंकि cel-shaded स्टाइल कम पॉलीगन गिनती छिपा देती है। Minecraft 16x16 टेक्सचर इस्तेमाल करता है और अब तक के सबसे पहचाने जाने वाले गेम्स में से एक है। Krunker.io और Hordes.io दोनों ब्राउज़र में सरल स्टाइलाइज़्ड ग्राफ़िक्स के साथ सफल होते हैं। सबूत भारी रूप से एक ब्राउज़र वर्ल्ड के लिए स्टाइलाइज़्ड दिशा के पक्ष में हैं। हमें जल्दी एक ख़ास विज़ुअल पहचान चुननी होगी और AI-जेनरेटेड assets में निरंतरता लागू करनी होगी।

वर्ल्ड persistence बनाम instancing। क्या हर कोई एक दुनिया साझा करता है (एक MMO या Second Life की तरह) या हर क्रिएटर को अपना instance मिलता है जिसे दूसरे देख सकें (Minecraft सर्वर या Fortnite Islands की तरह)? टेक दोनों को सपोर्ट करती है, लेकिन सोशल डायनामिक्स पूरी तरह अलग हैं। Second Life की persistent साझा दुनिया अनायास खोज पैदा करती है (आप घूमते हुए दूसरे लोगों के काम पर पहुँच जाते हैं)। Fortnite के instanced द्वीपों को खोज के लिए एक मेन्यू या पोर्टल सिस्टम चाहिए। Roblox एक hub-आधारित तरीका इस्तेमाल करता है: गेम अलग हैं लेकिन आप एक साझा इंटरफ़ेस के ज़रिए ब्राउज़ और खोज करते हैं। एक हाइब्रिड काम कर सकता है: एक persistent साझा overworld जहाँ क्रिएटर प्लॉट के मालिक हों (Second Life पार्सल की तरह), पोर्टल के ज़रिए standalone अनुभव में घुसने के विकल्प के साथ।

निर्माण टूल की गहराई। Dreams ने साबित किया कि गहरे निर्माण टूल्स आलोचकों को प्रभावित करते हैं लेकिन यूज़र्स को डराते हैं। Townscaper ने साबित किया कि न्यूनतम टूल्स एक मिलियन कॉपियाँ बेच सकते हैं। Roblox Studio बीच में बैठता है: बच्चों के लिए काफ़ी सरल, पेशेवरों के लिए काफ़ी गहरा। Krunker का voxel एडिटर इससे भी सरल है। एक ब्राउज़र वर्ल्ड के लिए, हमें Townscaper-स्तर की सरलता से शुरू करना चाहिए (वस्तुएँ रखें, वे snap और जुड़ जाती हैं) और समय के साथ गहराई जोड़ें। दुनिया में अपनी पहली वस्तु रखने का इनिशियल अनुभव 30 सेकंड से कम लेना चाहिए।

अर्थव्यवस्था। Roblox, Second Life, और Fortnite Creative सभी साबित करते हैं कि आर्थिक प्रोत्साहन ही एक खिलौने को एक प्लेटफ़ॉर्म में बदलता है। क्रिएटर्स के लिए अपने काम से कमाने का कोई रास्ता न होने पर, सबसे प्रतिभाशाली क्रिएटर्स कहीं और बनाएँगे। इसे पहले दिन लॉन्च होने की ज़रूरत नहीं, लेकिन आर्किटेक्चर को इसका समर्थन करना चाहिए (ऑब्जेक्ट स्वामित्व, visit ट्रैकिंग, क्रिएटर श्रेय)।

मोबाइल। मोबाइल पर WebGPU भरोसेमंद होने से सालों दूर है। एक मोबाइल अनुभव को एक कम किया हुआ संस्करण होना होगा: सरल टेरेन, कम वस्तुएँ, छोटी view distance। Rec Room का अनुकूली क्वालिटी के साथ हर चीज़ पर चलने का तरीका अध्ययन करने लायक है। या हम मोबाइल के लिए एक नेटिव ऐप भेजें और पूरा अनुभव ब्राउज़र में रखें।

Moderation। एक ओपन वर्ल्ड जहाँ कोई भी कुछ भी रख सकता है, एक moderation दुःस्वप्न है। Second Life 20 साल से इससे निपट रहा है। हर रखे गए asset को दूसरों को दिखने से पहले स्वचालित कंटेंट समीक्षा चाहिए। यह रचनात्मक प्रक्रिया में latency जोड़ता है लेकिन यह बिना समझौता वाली बात है। हमें पार्सल-आधारित कंटेंट रेटिंग (Second Life के General/Moderate/Adult सिस्टम की तरह) पर भी विचार करना चाहिए ताकि क्रिएटर अपनी कंटेंट सीमाएँ चुन सकें।

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

मुख्य सीख

ब्राउज़र 3D ओपन वर्ल्ड आज संभव हैं। Hordes.io एक ब्राउज़र में 3D में 200+ प्लेयर चलाता है। Krunker.io के पास एक पूरे 3D मैप एडिटर के साथ 10 मिलियन मासिक प्लेयर थे। .io गेम्स ने साबित किया कि ब्राउज़र मल्टीप्लेयर लाखों तक स्केल होता है। टेक काल्पनिक नहीं है।

रेंडरिंग तैयार है। Three.js और Babylon.js 2010 के शुरुआती AAA गेम्स के बराबर 3D दृश्य संभालते हैं। WebGPU टेरेन और फ़ोलिएज के लिए compute शेडर खोलता है। Wasm फ़िज़िक्स इंजन नेटिव के 2-3x के भीतर चलते हैं। एक Whiterun-स्केल क्षेत्र 15-25 MB दिखने वाले डेटा में समाता है।

नेटवर्किंग तैयार है। Cloudflare Durable Objects आपको edge पर प्रति-चंक authoritative सर्वर देते हैं। CRDTs बिना conflict के सहयोगी एडिटिंग संभालते हैं। spatial partitioning (Agar.io से Skyrim तक हर गेम द्वारा साबित) सैकड़ों concurrent प्लेयर्स पर नेटवर्क ट्रैफ़िक को संभालने योग्य रखती है।

AAA ओपन वर्ल्ड (Skyrim, Witcher 3, BotW, Elden Ring, Minecraft, No Man's Sky) सिर्फ़ ग्राफ़िकल बेंचमार्क नहीं हैं। वे चंक स्ट्रीमिंग, LOD management, प्रोसीजरल जेनरेशन, सिस्टमिक डिज़ाइन, और वर्ल्ड संरचना पर पाठ्यपुस्तकें हैं। वे जो भी तकनीक इस्तेमाल करते हैं, उसका एक ब्राउज़र-संगत समकक्ष है।

क्रिएटर प्लेटफ़ॉर्म (Roblox, Second Life, Fortnite Creative, Dreams) सोशल और आर्थिक सबक सिखाते हैं। निर्माण इन-वर्ल्ड होना चाहिए, एक external टूल में नहीं। आर्थिक प्रोत्साहन गुणवत्ता को आगे बढ़ाता है। persistence लगाव पैदा करती है। सरल टूल्स शक्तिशाली टूल्स से ज़्यादा क्रिएटर्स तक पहुँचते हैं।

रचनात्मक पाइपलाइन वह जगह है जहाँ Cinevva के पास बढ़त है। हम पहले से 3D assets, टेक्सचर, और ऑडियो जेनरेट करते हैं। उस पाइपलाइन को एक वर्ल्ड प्लेसमेंट सिस्टम से जोड़ना ही गायब टुकड़ा है। AI-जेनरेटेड कंटेंट दुनिया को भरता है। क्रिएटर की curation और व्यवस्था उसे आत्मा देती है।

हमारे पास जो आख़िरकार होगा वह एक ब्राउज़र में Skyrim नहीं है। यह Minecraft (संपादन योग्य दुनिया), Roblox (क्रिएटर अर्थव्यवस्था), और BotW (सिस्टमिक इंटरैक्शन) के चौराहे के ज़्यादा क़रीब है, जो AI-संचालित निर्माण टूल्स के साथ एक ब्राउज़र टैब में चलता है। इसे बनाने की टेक्नोलॉजी मौजूद है। सवाल execution का है।

रिसर्च पेपर और शैक्षणिक संदर्भ

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

टेरेन जेनरेशन और रेंडरिंग

"An Image Synthesizer" -- Ken Perlin (SIGGRAPH 1985)। DOI। वह पेपर जिसने Perlin noise पेश किया। 1985 के बाद हर गेम में हर प्रोसीजरल टेरेन जेनरेटर इसी तक जाता है। noise फ़ंक्शन वह स्मूथ यादृच्छिकता पैदा करता है जो octaves में परतों में रखे जाने पर (fractional Brownian motion) प्राकृतिक दिखने वाले हाइटमैप जेनरेट करता है। Simplex noise (Perlin, 2001) तेज़ उत्तराधिकारी है। हमारी टेरेन पाइपलाइन के लिए, यह नींव है: noise-आधारित हाइटमैप जेनरेशन एक WebGPU compute शेडर में इंटरैक्टिव गति पर चलता है।

"Texturing and Modeling: A Procedural Approach" -- Ebert, Musgrave, Peachey, Perlin, Worley (1994, तीसरा संस्करण 2003)। प्रोसीजरल जेनरेशन पर पाठ्यपुस्तक। टेरेन मॉडलिंग पर Musgrave के अध्याय, जिनमें erosion-जैसी विशेषताओं वाला multifractal टेरेन शामिल है, आधुनिक गेम टेरेन जेनरेटर का सीधा आधार हैं। यहाँ वर्णित fBm पैरामीटर (lacunarity, persistence, octave count) वही हैं जिन्हें हम टेरेन कस्टमाइज़ेशन के लिए क्रिएटर्स को दिखाएँगे।

"Geometry Clipmaps: Terrain Rendering Using Nested Regular Grids" -- Losasso और Hoppe (SIGGRAPH 2004)। DOI। इस पेपर ने हल किया कि concentric LOD rings (clipmaps) का इस्तेमाल करके इंटरैक्टिव दरों पर विशाल टेरेन कैसे रेंडर करें। टेरेन मेश कैमरे पर केंद्रित nested grids का एक निश्चित सेट है। कैमरे के हिलने पर, grids shift और अपडेट होते हैं। यह वह तकनीक है जिसकी हमारे टेरेन सेक्शन में WebGL 2 के लिए सिफ़ारिश की गई है, और यह काम करती है क्योंकि GPU workload दुनिया के आकार की परवाह किए बिना स्थिर रहता है। मूल implementation WebGL से पहले की है लेकिन सीधे इस पर मैप होती है।

"Fast Hydraulic Erosion Simulation and Visualization on GPU" -- Mei, Decaudin, Hu (2007)। PDF। hydraulic erosion को एक CPU-bound ऑफ़लाइन प्रक्रिया से एक रियल-टाइम GPU गणना में बदला। पेपर का shallow-water सिमुलेशन मॉडल (पानी को एक height field के रूप में मानना, grid cells के बीच flow की गणना) एक compute शेडर में चलता है। हमारी पाइपलाइन के लिए, सर्वर-साइड GPU erosion noise-जेनरेटेड टेरेन को एक सेकंड से कम में भूवैज्ञानिक रूप से विश्वसनीय लैंडस्केप में बदल सकती है, जिससे AI-जेनरेटेड टेरेन हाथ से तराशा हुआ दिखता है।

"Real-Time Rendering of Procedurally Generated Planets" -- No Man's Sky की GDC टॉक और Sean Murray के विवरणों से हाइब्रिड तरीके। हालाँकि यह एक अकेला पेपर नहीं है, Innes McKendrick (Hello Games) की GDC 2017 टॉक "Building Worlds Using Maths" विस्तार से बताती है कि No Man's Sky stacked noise फ़ंक्शंस, marching cubes के साथ voxel प्रतिनिधित्व, और GPU-साइड जेनरेशन का इस्तेमाल करके ग्रह-स्तर का टेरेन कैसे जेनरेट करता है। हमारे प्रोसीजरल टेरेन तरीके के लिए सीधे प्रासंगिक, ख़ासकर ऐसी टेरेन विशेषताएँ जेनरेट करने के लिए जिन्हें हाइटमैप दर्शा नहीं सकते (गुफाएँ, arches)।

"C-DBLOD: Hybrid LOD for Terrain Rendering" -- Filip Strugar (2014)। Paper। geometry clipmaps पर एक सुधार जो कैमरा स्थिति के आस-पास बेहतर अनुकूलन के लिए quadtree-आधारित चयन जोड़ता है। मुख्य समझ: निश्चित concentric rings के बजाय, अलग-अलग रिज़ॉल्यूशन पर टेरेन पैचेस चुनने के लिए एक quadtree इस्तेमाल करें। यह अनियमित टेरेन (जहाँ कुछ इलाकों को दूसरों से ज़्यादा डिटेल चाहिए) को शुद्ध clipmaps से बेहतर संभालता है। एक छोटे CPU-साइड quadtree traversal के साथ WebGL 2 में implement करने योग्य।

3D Gaussian Splatting और न्यूरल रेंडरिंग

"3D Gaussian Splatting for Real-Time Radiance Field Rendering" -- Kerbl, Kopanas, Leimkühler, Drettakis (SIGGRAPH 2023)। Project page। वह पेपर जिसने Gaussian splatting क्रांति शुरू की। एक दृश्य को लाखों 3D Gaussians के रूप में दर्शाया जाता है, हर एक में स्थिति, covariance (आकार), opacity, और spherical harmonic रंग गुणांक। रेंडरिंग splats को depth के हिसाब से sort करती है और उन्हें 2D Gaussians के रूप में rasterize करती है। यह तरीका NeRFs की तुलना में train करने में 100-1000x तेज़ है और रियल-टाइम दरों पर रेंडर होता है। कई WebGL/WebGPU implementations मौजूद हैं। हमारे प्लेटफ़ॉर्म के लिए, यह क्रिएटर्स को फ़ोन तस्वीरों से असली दुनिया की वस्तुएँ कैप्चर करने और उन्हें ब्राउज़र वर्ल्ड में रखने देता है।

"NeRF: Representing Scenes as Neural Radiance Fields for View Synthesis" -- Mildenhall et al. (ECCV 2020)। Project page। नींव वाला न्यूरल दृश्य प्रतिनिधित्व पेपर। एक न्यूरल नेटवर्क 3D coordinates को रंग और density पर मैप करता है, जो इनपुट तस्वीरों के एक सेट से फ़ोटोरियलिस्टिक नए view synthesis को संभव बनाता है। हालाँकि NeRFs एक ब्राउज़र में सीधे रेंडर करने के लिए बहुत महँगे हैं (उन्हें प्रति-पिक्सल नेटवर्क मूल्यांकन चाहिए), NeRF-to-mesh extraction पाइपलाइन (एक NeRF train करना, फिर density field पर marching cubes चलाना) तस्वीरों से उच्च-गुणवत्ता वाले textured mesh पैदा करती है।

"Instant Neural Graphics Primitives with a Multiresolution Hash Encoding" -- Müller, Evans, Schied, Keller (SIGGRAPH 2022)। Project page। spatial encoding के लिए एक multi-resolution hash table का इस्तेमाल करके NeRF training को घंटों से सेकंड तक घटाया। इसने NeRF को production इस्तेमाल के लिए व्यावहारिक बनाया। hash encoding तकनीक एक ब्राउज़र वर्ल्ड में दूसरे spatial डेटा पर भी लागू होती है (बड़े 3D datasets में तेज़ lookups)।

"Neuralangelo: High-Fidelity Neural Surface Reconstruction" -- Li et al. (CVPR 2023)। Project page। multi-resolution hash encoding और SDF (signed distance function) अनुमान के लिए numerical gradients का इस्तेमाल करके न्यूरल प्रतिनिधित्वों से उच्च-गुणवत्ता वाले triangle mesh निकालता है। आउटपुट mesh ब्राउज़र 3D इंजन में सीधे इस्तेमाल योग्य हैं। हमारी asset पाइपलाइन के लिए, Neuralangelo (या NeuS2 जैसे समान टूल्स) NeRF कैप्चर को साफ़ ज्यामिति और बेक किए हुए टेक्सचर के साथ वेब-तैयार GLB फ़ाइलों में बदल सकता है।

मल्टीप्लेयर नेटवर्किंग और स्टेट सिंक्रोनाइज़ेशन

"Interest Management in Massively Multiplayer Online Games" -- Boulanger, Kienzle, Verbrugge (2006)। DOI। MMOs के लिए area-of-interest (AOI) management तकनीकों का एक व्यापक सर्वे। spatial प्रासंगिकता के आधार पर नेटवर्क अपडेट फ़िल्टर करने के लिए grid-आधारित, aura-आधारित, और हाइब्रिड तरीकों को कवर करता है। grid-आधारित तरीका (जो हमारे चंक सिस्टम पर मैप होता है) समान-घनत्व वाली दुनियाओं के लिए सबसे कुशल है। aura-आधारित तरीका (प्रति-entity प्रभाव त्रिज्या) variable घनत्व के लिए बेहतर काम करता है। AOI के भीतर priority-आधारित अपडेट दरों के साथ चंक-आधारित AOI की हमारी सिफ़ारिश इस रिसर्च से ली गई है।

"Dead Reckoning: Latency Hiding for Networked Games" -- Pantel और Wolf (2002)। DOI। networked गेम्स के लिए dead reckoning (अंतिम ज्ञात वेग के आधार पर entity स्थिति का अनुमान) को औपचारिक रूप देता है। पेपर समझौते को मापता है: ऊँचे prediction thresholds bandwidth घटाते हैं लेकिन corrections के दौरान दिखने वाली स्थिति त्रुटि बढ़ाते हैं। 50-200ms latency वाले ब्राउज़र गेम्स के लिए, 0.5-1.0 मीटर का एक prediction threshold corrections को अदृश्य रखता है जबकि स्थिति अपडेट bandwidth को 60-80% तक काटता है।

"Conflict-free Replicated Data Types" -- Shapiro, Preguiça, Baquero, Zawirski (2011)। DOI। नींव वाला CRDT पेपर। state-आधारित और operation-आधारित CRDTs परिभाषित करता है जो coordination के बिना converge होते हैं। हमारे वर्ल्ड एडिटिंग सिस्टम के लिए, प्रासंगिक CRDTs हैं: LWW-Register (Last-Writer-Wins Register) उन ऑब्जेक्ट प्रॉपर्टीज़ के लिए जिनका एक अकेला मान होता है (स्थिति, घुमाव, रंग), और OR-Set (Observed-Remove Set) एक चंक में ऑब्जेक्ट के संग्रह के लिए (बिना conflict के concurrent add/remove संभालता है)। Yjs इन्हें JavaScript में कुशलता से implement करता है।

"Time Warp: A Mechanism for Distributed Simulation" -- Jefferson (1985)। DOI। मूल optimistic distributed simulation पेपर। हालाँकि Time Warp ख़ुद एक ब्राउज़र गेम के लिए बहुत जटिल है, मुख्य समझ (events को optimistically process करें और किसी दूसरे node से conflict आने पर roll back करें) सर्वर reconciliation के साथ आधुनिक client-side prediction का आधार है। हर रिस्पॉन्सिव मल्टीप्लेयर गेम ऐसे ही काम करता है: client locally अनुमान लगाता है, actions सर्वर को भेजता है, और सर्वर के असहमत होने पर correct करता है।

"The TRIBES Engine Networking Model" -- Frohnmayer और Gift (GDC 1999)। interest management, prioritized state अपडेट, और bandwidth budgeting के साथ client-server गेम नेटवर्किंग के पहले व्यावहारिक विवरणों में से एक। "ghost manager" अवधारणा (सर्वर प्रति-client यह view रखता है कि client क्या जानता है, और सिर्फ़ उस view से deltas भेजता है) बिल्कुल वही है जो हमारा चंक-आधारित Durable Object आर्किटेक्चर implement करता है। यह GDC टॉक ज़्यादातर आधुनिक गेम नेटवर्किंग का बौद्धिक पूर्वज है।

"Source Multiplayer Networking" -- Valve (2009)। Developer documentation। Source इंजन नेटवर्किंग मॉडल (Half-Life 2, CS:GO, Team Fortress 2 में इस्तेमाल) का Valve का दस्तावेज़ीकरण। client-side prediction, entity interpolation, lag compensation, और "snapshot" सिस्टम को कवर करता है जहाँ सर्वर नियमित अंतराल पर पूरा वर्ल्ड स्टेट भेजता है जबकि client snapshots के बीच interpolate करता है। यह authoritative सर्वर नेटवर्किंग का स्वर्ण मानक है और हमारे आर्किटेक्चर पर सीधे लागू होता है।

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

"Model Synthesis: A General Procedural Modeling Algorithm" -- Merrell (2007)। DOI। Wave Function Collapse के पूर्ववर्तियों में से एक। स्थानीय constraints को propagate करके example मॉडल से 3D संरचनाएँ जेनरेट करता है। algorithm सबसे कम संभावनाओं वाली cells को iteratively collapse करके (न्यूनतम entropy heuristic) वैश्विक निरंतरता सुनिश्चित करता है। यही तरीका Townscaper और समान जेनरेटर सरल यूज़र इनपुट से सुसंगत संरचनाएँ पैदा करने के लिए इस्तेमाल करते हैं।

"WaveFunctionCollapse" -- Maxim Gumin (2016)। GitHub। एक पारंपरिक पेपर नहीं बल्कि व्यापक दस्तावेज़ीकरण वाला एक मूलभूत ओपन-सोर्स प्रोजेक्ट। algorithm एक छोटी example image या tileset लेता है और बड़े आउटपुट जेनरेट करता है जो स्थानीय रूप से इनपुट जैसे होते हैं। एक क्रिएटर वर्ल्ड के लिए, WFC क्रिएटर-परिभाषित नियमों के एक छोटे सेट से इमारत लेआउट, road नेटवर्क, डंजन मैप, और टेरेन डिटेल जेनरेट कर सकता है। कई JavaScript implementations मौजूद हैं।

"Wave Function Collapse is Constraint Solving in the Wild" -- Karth और Smith (FDG 2017)। DOI। WFC का एक शैक्षणिक विश्लेषण जो constraint satisfaction से इसके संबंध को स्पष्ट करता है और दिखाता है कि इसका विश्लेषण और विस्तार कैसे करें। WFC की सीमाओं (यह अटक सकता है और backtracking की ज़रूरत पड़ सकती है) और इन समस्याओं से बचने वाले tilesets कैसे डिज़ाइन करें, यह समझने के लिए प्रासंगिक।

"Superposition Theorem and Its Implications for the Procedural Generation of Game Content" -- Sandhu et al. (2022)। प्रोसीजरल कंटेंट जेनरेशन के लिए quantum-प्रेरित superposition अवधारणाओं के इस्तेमाल को खोजता है। हालाँकि अनुमानात्मक है, एक अंतिम configuration पर "collapse" होने से पहले कई संभव states बनाए रखने का गणितीय ढाँचा बिल्कुल वैसा है जैसे WFC काम करता है और ज़्यादा परिष्कृत जेनरेशन सिस्टम को सूचित कर सकता है।

रियल-टाइम रेंडरिंग तकनीकें

"Real-Time Rendering" -- Akenine-Möller, Haines, Hoffman (चौथा संस्करण, 2018)। मानक पाठ्यपुस्तक। अध्याय 19 (Acceleration Structures), अध्याय 20 (Efficient Shading), और अध्याय 21 (Virtual and Augmented Reality) ख़ास तौर पर प्रासंगिक हैं। यहाँ वर्णित frustum culling, occlusion culling, और LOD algorithms वही हैं जिन्हें Three.js, Babylon.js, और हर गेम इंजन implement करते हैं। एक पेपर नहीं, लेकिन निश्चित संदर्भ।

"A Survey on Baking Neural Radiance Fields for Real-Time View Synthesis" -- Reiser et al. (2023)। DOI। NeRFs को ऐसे फ़ॉर्मैट में बदलने के तरीकों का सर्वे करता है जो रियल टाइम में रेंडर होते हैं (mesh, टेक्सचर, sparse voxel grids)। हमारी asset पाइपलाइन पर सीधे प्रासंगिक जहाँ सर्वर-साइड न्यूरल कैप्चर को ब्राउज़र-रेंडर करने योग्य आउटपुट पैदा करना होता है।

"Scalable and Accurate Online Feature Matching Using 3D Gaussian Splatting" -- विभिन्न समूह (2024-2025)। कई हालिया पेपर Gaussian splats के साथ एडिटिंग, compositing, और dynamic दृश्यों को खोजते हैं। प्रासंगिक क्योंकि क्रिएटर वर्ल्ड्स को कई splat दृश्यों (हर क्रिएटर की कैप्चर की हुई वस्तुएँ) को एक अकेले सुसंगत दृश्य में composite करना होता है। splat एडिटिंग के तरीके (recoloring, deformation, compositing) सक्रिय रिसर्च क्षेत्र हैं।

"Efficient GPU Screen-Space Ray Tracing" -- McGuire और Mara (JCGT 2014)। DOI। हमारे water रेंडरिंग सेक्शन में इस्तेमाल किए गए screen-space reflections के पीछे का पेपर। पूरी ray tracing की लागत के बिना अनुमानित reflections के लिए depth buffer के ज़रिए rays trace करता है। "hierarchical tracing" variant (एक min-max depth mipmap का इस्तेमाल) WebGL 2 पर कुशलता से चलता है।

"Simulating Ocean Water" -- Jerry Tessendorf (2001)। PDF। FFT-आधारित ocean सिमुलेशन पर नींव वाला पेपर। Phillips spectrum (ocean लहरों का सांख्यिकीय मॉडल) और inverse FFT के ज़रिए इसे एक spatial displacement map में बदलने का तरीका बताता है। यथार्थवादी ocean वाले हर बड़े गेम (Sea of Thieves, Assassin's Creed, Uncharted) द्वारा इस्तेमाल किया जाता है। FFT गणना WebGPU compute शेडर पर साफ़-साफ़ मैप होती है।

"Precomputed Atmospheric Scattering" -- Bruneton और Neyret (EGSR 2008)। DOI। भौतिक रूप से सटीक sky रेंडरिंग के पीछे का पेपर। atmospheric scattering को lookup tables में precompute करता है जिन्हें एक फ़्रैगमेंट शेडर रियल टाइम में sample करता है। पहले सिद्धांतों से सही sky रंग, aerial perspective (दूर की वस्तुएँ नीली/धुंधली दिखती हैं), और सूर्यास्त/सूर्योदय के रंग पैदा करता है। precomputed tables छोटी हैं (कुछ सौ KB) और रनटाइम शेडर सस्ता है। Three.js का Sky शेडर और Babylon.js का procedural sky दोनों इस तरीके के सरल किए हुए संस्करण हैं।

"Ambient Occlusion Volumes" -- McGuire (HPG 2010) और "Scalable Ambient Obscurance" -- McGuire, Mara, Luebke (HPG 2012)। PDF। आधुनिक SSAO implementations के पीछे के पेपर। SAO ब्राउज़र 3D इंजन में सबसे आम तौर पर implement किया जाने वाला variant है क्योंकि यह कुशल है (प्रति पिक्सल एक depth buffer sample) और विश्वसनीय contact shadows पैदा करता है। algorithm हर पिक्सल के आस-पास depth buffer को sample करके अनुमान लगाता है कि यह पास की ज्यामिति से कितना "occluded" है। Three.js और Babylon.js दोनों SAO-व्युत्पन्न SSAO implement करते हैं।

Crowd रेंडरिंग और एनिमेशन

"GPU Crowd Rendering" -- Dudash (2007) और instanced crowd रेंडरिंग पर बाद की GDC/SIGGRAPH प्रस्तुतियाँ। मुख्य तकनीक: skeletal एनिमेशन फ़्रेम्स को टेक्सचर में बेक करें (Vertex Animation Textures), फिर crowds को instanced mesh के रूप में रेंडर करें जहाँ हर instance अपने current फ़्रेम के आधार पर एनिमेशन टेक्सचर से अपने bone transforms पढ़ता है। यह एनिमेशन मूल्यांकन को draw calls से अलग करता है, जिससे एक अकेला instanced draw call सैकड़ों अनूठे रूप से एनिमेटेड characters रेंडर कर सकता है।

"Position Based Dynamics" -- Müller et al. (2007)। DOI। PBD पर नींव वाला पेपर, जो आधुनिक गेम इंजन कपड़ा, बाल, और soft bodies सिमुलेट करने का तरीका है। Rapier (हमारा अनुशंसित Wasm फ़िज़िक्स इंजन) PBD-व्युत्पन्न solvers इस्तेमाल करता है। अवतार कस्टमाइज़ेशन (capes, बहते बाल, ढीले कपड़े) के लिए, PBD गेम फ़्रेम दरों पर रिस्पॉन्सिव सिमुलेशन देता है। Wasm implementation इसे मुख्य JavaScript thread से दूर रखता है।

"FABRIK: A Fast, Iterative Solver for the Inverse Kinematics Problem" -- Aristidou और Lasenby (2011)। DOI। हमारे अवतार सेक्शन में अनुशंसित IK solver के पीछे का पेपर। FABRIK बारी-बारी से end effector से root तक और root से end effector तक पहुँचकर काम करता है, 3-5 iterations में converge होता है। यह Jacobian-आधारित IK से तेज़ है, joint constraints को स्वाभाविक रूप से संभालता है, और implement करना सरल है (बुनियादी solver के लिए लगभग 50 लाइन कोड)। Three.js और Babylon.js दोनों के IK implementations FABRIK से व्युत्पन्न हैं।

वर्चुअल वर्ल्ड्स और सहयोगी वातावरण

"Massive Multiplayer Online Games: A Survey of the State-of-the-Art" -- Yahyavi और Kemme (2013)। DOI। client-server मॉडल, peer-to-peer तरीके, interest management, consistency मॉडल, scalability तकनीकें, और धोखाधड़ी रोकथाम को कवर करते हुए MMO आर्किटेक्चर का व्यापक सर्वे। consistency मॉडल (strict, eventual, causal) का वर्गीकरण हमारे CRDT-आधारित तरीके पर मैप होता है (vector clocks के ज़रिए causal ordering के साथ eventual consistency)।

"A Distributed Architecture for Multiplayer Interactive Applications on the Internet" -- Diot और Gautier (1999)। DOI। distributed virtual environments पर शुरुआती रिसर्च जिसने मुख्य तनाव पहचाना: strict consistency को coordination चाहिए (latency जोड़ता है), जबकि weak consistency जवाबदेही देती है लेकिन दिखने वाली असंगति का जोखिम उठाती है। पेपर एक बीच के रास्ते के रूप में "local lag" (स्थानीय display को थोड़ी देर रोकना ताकि remote अपडेट आने का समय मिले) के पक्ष में तर्क देता है। वर्ल्ड एडिट्स (वस्तुएँ रखना) के लिए, 100-200ms का local lag अदृश्य है और सर्वर को validate करने का समय देता है।

"The Second Life Grid: The Architecture of a Near-Contemporary Open Source Virtual World" -- Linden Lab तकनीकी दस्तावेज़ीकरण और समुदाय reverse-engineering। हालाँकि एक अकेला पेपर नहीं, Second Life के आर्किटेक्चर का तकनीकी विश्लेषण व्यापक रूप से दस्तावेज़ित है। मुख्य समझ: हर 256x256m region एक डेडिकेटेड सर्वर instance पर चलता है। ऑब्जेक्ट "primitives" (transforms, टेक्सचर, और स्क्रिप्ट वाले बुनियादी आकार) के एक tree के रूप में स्टोर होते हैं। viewer ऑब्जेक्ट विवरण और टेक्सचर माँग पर स्ट्रीम करता है। प्रति-ऑब्जेक्ट persistence वाला यह पार्सल-आधारित मॉडल उसके सबसे क़रीब मौजूद आर्किटेक्चर है जो हम बना रहे हैं, और Second Life का 20+ साल का संचालन साबित करता है कि यह स्केल होता है।

वेब ग्राफ़िक्स और ब्राउज़र परफ़ॉर्मेंस

"WebGPU: A High-Performance Graphics API for the Web" -- W3C GPU for the Web Working Group (2023-जारी)। Specification। WebGPU की औपचारिक specification। एक रिसर्च पेपर नहीं, लेकिन ब्राउज़र GPU प्रोग्रामिंग के लिए निश्चित तकनीकी दस्तावेज़। compute शेडर specification (सेक्शन 23) इस गाइड में वर्णित टेरेन जेनरेशन, फ़ोलिएज scattering, और particle सिस्टम के लिए ख़ास तौर पर प्रासंगिक है।

"WebAssembly: A Framework for Running Compiled Code in the Browser" -- Haas et al. (PLDI 2017)। DOI। ब्राउज़र vendors का मूल WebAssembly पेपर। दिखाता है कि Wasm compute-intensive workloads के लिए नेटिव परफ़ॉर्मेंस के 2x के भीतर हासिल करता है। यह ब्राउज़र ओपन वर्ल्ड्स के लिए Wasm-compiled फ़िज़िक्स इंजन (Rapier, Havok) की हमारी सिफ़ारिश को मान्य करता है। पेपर का परफ़ॉर्मेंस विश्लेषण दिखाता है कि ओवरहेड मुख्य रूप से bounds checking और indirect function calls से आता है, compilation मॉडल से नहीं।

"Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code" -- Jangda et al. (USENIX ATC 2019)। PDF। Wasm बनाम नेटिव परफ़ॉर्मेंस का एक कठोर benchmark। पाता है कि SPEC CPU benchmark suite में Wasm औसतन नेटिव C से 1.45x-1.55x धीमा चलता है। ख़ासकर गेम फ़िज़िक्स के लिए (floating-point heavy, कम system calls), ओवरहेड निचले सिरे पर है (~1.3x)। यह पुष्टि करता है कि एक ब्राउज़र में Wasm फ़िज़िक्स रियल-टाइम गेम workloads के लिए संभव है।

"Bringing the Web up to Speed with WebAssembly" -- Rossberg et al. (2018)। DOI। WebAssembly के डिज़ाइन तर्क और औपचारिक semantics का वर्णन करता है। ख़ास तौर पर प्रासंगिक: memory safety guarantees की चर्चा (सेक्शन 3) बताती है कि Wasm modules नेटिव plugins के सुरक्षा जोखिमों के बिना एक ब्राउज़र टैब को JavaScript के साथ सुरक्षित रूप से क्यों साझा कर सकते हैं। यही फ़िज़िक्स इंजन (जो पारंपरिक रूप से C++ लाइब्रेरी थे) को एक ब्राउज़र में चलाना सुरक्षित बनाता है।

AI-संचालित कंटेंट जेनरेशन

"Text-to-3D Generation with Bidirectional Diffusion Using Both 2D and 3D Priors" -- विभिन्न समूह (2023-2025)। कई हालिया पेपर (DreamFusion, Magic3D, ProlificDreamer, MVDream, Zero-1-to-3++) 3D optimization के लिए 2D diffusion मॉडल को priors के रूप में इस्तेमाल करके text prompts से 3D assets जेनरेट करना खोजते हैं। 2023 की शुरुआत से 2025 तक गुणवत्ता नाटकीय रूप से सुधरी है, blobby आकारों से विस्तृत, textured mesh तक पहुँची है। हमारे प्लेटफ़ॉर्म के लिए, ये मॉडल (सर्वर-साइड GPUs पर चलते हुए) क्रिएटर asset पाइपलाइन में "AI जेनरेशन" चरण हैं।

"DreamFusion: Text-to-3D using 2D Diffusion" -- Poole et al. (ICLR 2023)। Project page। Score Distillation Sampling (SDS) पर नींव वाला पेपर, जो 3D optimization को मार्गदर्शन देने के लिए एक pre-trained 2D diffusion मॉडल इस्तेमाल करता है। मुख्य समझ: अगर आप किसी मौजूदा 2D मॉडल का इस्तेमाल करके यह आँक सकें कि किसी 3D ऑब्जेक्ट के रेंडर किए हुए views एक text prompt से मेल खाते हैं या नहीं, तो आपको 3D training डेटा की ज़रूरत नहीं। इसने text-to-3D जेनरेशन का दरवाज़ा खोला और बाद के काम (Magic3D, ProlificDreamer) का आधार है जिसने गुणवत्ता और गति सुधारी।

"LRM: Large Reconstruction Model for Single Image to 3D" -- Hong et al. (ICLR 2024)। Project page। एक अकेले GPU पर 5 सेकंड में एक अकेली image से एक 3D मॉडल reconstruct करता है। मॉडल एक NeRF-जैसा प्रतिनिधित्व निकालता है जिसे एक mesh में बदला जा सकता है। एक क्रिएटर वर्ल्ड के लिए, इसका मतलब है कि एक क्रिएटर किसी भी असली दुनिया की वस्तु की तस्वीर ले सकता है और सेकंडों में एक 3D मॉडल पा सकता है। यह गति इसे एक batch प्रक्रिया के बजाय एक इंटरैक्टिव टूल के रूप में संभव बनाती है।

"Procedural Content Generation via Machine Learning (PCGML)" -- Summerville et al. (2018)। DOI। गेम्स में प्रोसीजरल कंटेंट जेनरेशन के लिए मशीन लर्निंग के इस्तेमाल का एक सर्वे। लेवल जेनरेशन, आइटम जेनरेशन, narrative जेनरेशन, और वर्ल्ड जेनरेशन को कवर करता है। ख़ास तौर पर प्रासंगिक: "controllable generation" की चर्चा जहाँ डिज़ाइनर उच्च-स्तरीय पैरामीटर सेट करते हैं और ML मॉडल विवरण भरता है। यह AI-सहायता वाली वर्ल्ड बिल्डिंग का paradigm है: क्रिएटर इरादा सेट करते हैं ("इस इलाके को एक डरावना जंगल बनाओ"), AI ज्यामिति, टेक्सचर, और आबादी भरता है।

ये पेपर हमारे आर्किटेक्चर से कैसे जुड़ते हैं

रिसर्च हमारे आर्किटेक्चर पर परतों में मैप होती है:

टेरेन पाइपलाइन: Perlin/simplex noise (Perlin 1985, 2001) बेस हाइटमैप जेनरेट करता है। Hydraulic erosion (Mei et al. 2007) भूवैज्ञानिक यथार्थवाद जोड़ता है। Geometry clipmaps (Losasso और Hoppe 2004) या CDLOD (Strugar 2014) टेरेन को ब्राउज़र में कुशलता से रेंडर करते हैं। Atmospheric scattering (Bruneton और Neyret 2008) दूर के टेरेन को सही दिखाता है।

Asset पाइपलाइन: Text-to-3D (DreamFusion et al.) और image-to-3D (LRM) सर्वर-साइड assets जेनरेट करते हैं। Gaussian splatting (Kerbl et al. 2023) photogrammetry कैप्चर संभव बनाता है। Neuralangelo (Li et al. 2023) न्यूरल कैप्चर से साफ़ mesh निकालता है। सभी आउटपुट ब्राउज़र-तैयार GLB/KTX2 में process होते हैं।

रेंडरिंग: SSAO (McGuire 2012) गहराई जोड़ता है। Screen-space reflections (McGuire और Mara 2014) water को शक्ति देते हैं। FFT ocean (Tessendorf 2001) water सिमुलेट करता है। Vertex animation textures (Dudash 2007) crowds रेंडर करते हैं। FABRIK (Aristidou और Lasenby 2011) character IK चलाता है।

नेटवर्किंग: Interest management (Boulanger et al. 2006) spatial प्रासंगिकता के हिसाब से अपडेट फ़िल्टर करता है। Dead reckoning (Pantel और Wolf 2002) bandwidth घटाता है। CRDTs (Shapiro et al. 2011) सहयोगी एडिटिंग संभालते हैं। सर्वर reconciliation के साथ client prediction (Jefferson 1985, Valve Source Networking) जवाबदेही देता है।

वर्ल्ड जेनरेशन: WFC (Gumin 2016, Karth और Smith 2017) संरचनाएँ और लेआउट जेनरेट करता है। PCGML (Summerville et al. 2018) AI-सहायता वाली जेनरेशन का ढाँचा देता है जहाँ क्रिएटर इरादा सेट करते हैं और मॉडल विवरण भरते हैं।

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

आगे पढ़ें

• 2026 में वेब गेम्स टेक स्टैक WebGL, WebGPU, और WebAssembly की बुनियादी बातें कवर करता है
• वेब गेम इंजन तुलना ब्राउज़र डिलीवरी के लिए इंजनों की तुलना करता है
• Three.js + USDC टेक रिपोर्ट ब्राउज़र में 3D assets लोड करने पर
• फ़्रंटियर ओपन-सोर्स जेन AI मॉडल AI जेनरेशन पाइपलाइन के लिए
• को-ऑप गेम डिज़ाइन मल्टीप्लेयर डिज़ाइन पैटर्न पर जो प्लेयर्स को जोड़े रखते हैं
• ब्राउज़र ओपन वर्ल्ड्स के लिए लैंडस्केप जेनरेशन — टेरेन, erosion, और vegetation रेंडरिंग
• WebSocket मल्टीप्लेयर बेसिक्स — ब्राउज़र मल्टीप्लेयर नेटवर्किंग शुरू करना
• WebGPU शुरुआत — अगली पीढ़ी के ब्राउज़र 3D के लिए रेंडरिंग API
• स्ट्रीमिंग asset loading — बड़े 3D वर्ल्ड्स के लिए progressive loading पैटर्न