इस कैज़ुअल ड्राइविंग गेम के अनगिनत और सिलसिलेवार तरीके से बनाए गए नज़ारों की मदद से, WebGL की क्षमता के बारे में जानें.
Slow Roads एक कैज़ुअल ड्राइविंग गेम है. इसमें प्रोसेस के हिसाब से लगातार तैयार नज़ारों पर ज़ोर दिया जाता है. इन सभी को ब्राउज़र में WebGL ऐप्लिकेशन के तौर पर होस्ट किया जाता है. बहुत से लोगों के लिए, ब्राउज़र के सीमित संदर्भ में ऐसा लग सकता है कि इस तरह का गहन अनुभव गलत लग सकता है—और इस प्रोजेक्ट में इस नज़रिए को दूर करना मेरा एक लक्ष्य रहा है. इस लेख में, मैं उन तकनीकों के बारे में बताऊँगी जिनका इस्तेमाल करके मैंने वेब में 3D की बहुत बड़ी क्षमता को हाइलाइट करने के अपने मिशन में परफ़ॉर्मेंस में आने वाली बाधाओं का सामना किया.
ब्राउज़र में 3D डेवलपमेंट
Slow Roads रिलीज़ करने के बाद, मुझे सुझाव में बार-बार एक टिप्पणी मिली: "मुझे नहीं पता था कि ऐसा ब्राउज़र में मुमकिन है". अगर आप यह राय शेयर करते हैं, तो इसका मतलब है कि आप बहुत कम हैं. साल 2022 की जेएस की स्थिति सर्वे के मुताबिक, करीब 80% डेवलपर ने अभी तक WebGL के साथ प्रयोग नहीं किया है. मेरे लिए, यह दुख की बात है कि ब्राउज़र-आधारित गेमिंग में बहुत सारी संभावनाएं छूट सकती हैं. Slow Roads के साथ, मुझे WebGL को आगे सुलझने का मौका देना है, और शायद उन डेवलपर की संख्या कम करनी है जो "हाई-परफ़ॉर्मेंस JavaScript गेम इंजन" वाक्यांश का इस्तेमाल करने से बचते हैं.
WebGL बहुत सारे लोगों को रहस्यमयी और जटिल लग सकता है, लेकिन हाल ही के सालों में इसके डेवलपमेंट इकोसिस्टम काफ़ी बड़े हो गए हैं. इसमें काफ़ी बदलाव करके ऐसे टूल और लाइब्रेरी बनाई गई हैं जो काफ़ी अच्छी तरह से काम करती हैं. अब फ़्रंट-एंड डेवलपर अपने काम में 3D UX को शामिल करना पहले से ज़्यादा आसान हो गया है. वह भी कंप्यूटर ग्राफ़िक का पहले से अनुभव न होने पर भी. WebGL की मुख्य लाइब्रेरी Three.js, कई एक्सपैंशन के लिए काम करता है. इसमें, react- तीन-फ़ाइबर भी शामिल है, जो 3D कॉम्पोनेंट को रीऐक्ट फ़्रेमवर्क में शामिल करता है. अब Babylon.js या PlayCanvas जैसे व्यापक वेब-आधारित गेम एडिटर भी उपलब्ध हैं जो जाना-पहचाना इंटरफ़ेस और इंटिग्रेट किए गए टूलचेन उपलब्ध कराते हैं.
इन लाइब्रेरी की सुविधाओं की अहमियत के बावजूद, महत्वाकांक्षी प्रोजेक्ट पर तकनीकी सीमाएं लागू होती हैं. ब्राउज़र-आधारित गेमिंग के बारे में शकील से यह पता चल सकता है कि JavaScript सिंगल-थ्रेड और सीमित संसाधनों वाला है. हालांकि, इन सीमाओं पर नेविगेट करने से छिपी वैल्यू अनलॉक हो जाती है: किसी भी दूसरे प्लैटफ़ॉर्म पर, ब्राउज़र से मिलने वाली तुरंत सुलभता और बड़े पैमाने पर काम करने की सुविधा मिलती है. ब्राउज़र-आधारित किसी भी सिस्टम पर मौजूद उपयोगकर्ता एक क्लिक में गेम खेलना शुरू कर सकते हैं. इसके लिए, उन्हें ऐप्लिकेशन इंस्टॉल करने और सेवाओं में साइन इन करने की ज़रूरत नहीं पड़ती. यह बताने की ज़रूरत नहीं है कि डेवलपर को यूज़र इंटरफ़ेस (यूआई) बनाने या मल्टीप्लेयर मोड के लिए नेटवर्किंग मैनेज करने के लिए, उपलब्ध मज़बूत फ़्रंट-एंड फ़्रेमवर्क की सुविधा चाहिए. मेरे हिसाब से, ये वैल्यू, ब्राउज़र को खिलाड़ियों और डेवलपर, दोनों के लिए एक बेहतरीन प्लैटफ़ॉर्म बनाती हैं. इनकी वजह से, Slow Roads चैनल पर भी, तकनीकी सीमाओं की वजह से डिज़ाइन में समस्या आ सकती है.
धीमी सड़कों पर बेहतरीन परफ़ॉर्मेंस देना
'धीमी सड़कों' की मुख्य विशेषताओं में तेज़ रफ़्तार और महंगे नज़ारों का इस्तेमाल किया जाता है. इसलिए, बेहतरीन परफ़ॉर्मेंस की ज़रूरत मेरे डिज़ाइन के फ़ैसले को अहमियत देती है. मेरी मुख्य रणनीति थी कि गेमप्ले का आसान वर्शन डिज़ाइन किया जाए, ताकि काम के शॉर्ट-कट को इंजन के आर्किटेक्चर के हिसाब से इस्तेमाल किया जा सके. हालांकि, इसका मतलब यह है कि कम से कम इस्तेमाल के लिए, कुछ अच्छी सुविधाएं ऑफ़र की जाती हैं. हालांकि, इसके नतीजे में आपको पसंद के मुताबिक, ज़्यादा ऑप्टिमाइज़ किया गया ऐसा सिस्टम मिलता है जो अलग-अलग ब्राउज़र और डिवाइसों के साथ आसानी से काम करता है.
यहां उन अहम कॉम्पोनेंट के बारे में बताया गया है जो धीमी सड़कों को कम करने में मदद करते हैं.
गेमप्ले के आस-पास का एनवायरमेंट तैयार करना
गेम का मुख्य हिस्सा एनवायरमेंट जनरेट करने वाला इंजन है, जो काफ़ी महंगा है. इसकी वजह यह है कि इसकी वजह से, मेमोरी और कंप्यूटिंग के लिए बजट का सबसे अच्छा हिस्सा लिया जा सकता है. यहां इस्तेमाल की गई ट्रिक कुछ समय के दौरान हेवी कंप्यूटेशन को शेड्यूल और डिस्ट्रिब्यूट करने में इस्तेमाल की गई है, ताकि परफ़ॉर्मेंस में बढ़ोतरी की वजह से फ़्रेमरेट में कोई रुकावट न आए.
आस-पास की ज्यामिति की टाइलें कई तरह से बनी होती हैं. इनका साइज़ और रिज़ॉल्यूशन अलग-अलग होता है. इन्हें "जानकारी के लेवल" या LoDs की कैटगरी में रखा जाता है. यह इस बात पर निर्भर करता है कि ये टाइल, कैमरे में कितनी पास दिखेंगी. बिना रुके घूमने वाले कैमरे के साथ आम गेम में, अलग-अलग LoD लगातार लोड और अनलोड होने चाहिए, ताकि खिलाड़ी जहां भी जाना चाहें, अपने आस-पास की चीज़ों की बारीकियां दिखा सकें. यह काम का खर्च महंगा और बेकार हो सकता है, खास तौर पर तब, जब वातावरण में डाइनैमिक रूप से बदलाव हो. अच्छी बात यह है कि इस आम प्रोसेस को धीमी सड़कों पर पूरी तरह से बदला जा सकता है. इसके लिए, लोगों को सड़क पर रुकने की ज़रूरत होती है. इसके बजाय, ज़्यादा जानकारी वाली ज्यामिति को उस संकरे गलियारे के लिए रिज़र्व किया जा सकता है जो मार्ग को सीधे दिखाता है.
खिलाड़ी के आने से पहले ही सड़क के बीच की लाइन जनरेट हो जाती है. इससे यह अनुमान लगाया जा सकता है कि असल में कब और कहां पर्यावरण की जानकारी की ज़रूरत होगी. इसका नतीजा एक पतला सिस्टम है, जो महंगे कामों को शेड्यूल कर सकता है. इससे हर समय, ज़रूरत के मुताबिक कम से कम काम लिया जा सकता है. साथ ही, ऐसी जानकारी पर कोई खर्च नहीं किया जाता है जिसे कहीं देखा न जा सके. यह तकनीक सिर्फ़ इसलिए मुमकिन है, क्योंकि सड़क सिर्फ़ एक ही पाथ है, जो बिना ब्रांच वाला रास्ता है. यह रास्ते के शॉर्टकट को ध्यान में रखकर गेमप्ले करने का अच्छा उदाहरण है.
भौतिकी के नियमों से झिझकना
दूसरा चरण है, फ़िज़िक्स का सिम्युलेशन, जिसे एनवायरमेंट इंजन की कंप्यूटेशनल डिमांड कहा जाता है. स्लो रोड्स में फ़िज़िक्स पर आधारित कम से कम इंजन का इस्तेमाल किया जाता है. यह इंजन, हर शॉर्ट-कट उपलब्ध पर लगता है.
इसकी मुख्य वजह यह है कि एक ही जगह पर बहुत ज़्यादा ऑब्जेक्ट को प्रोसेस न किया जाए. इससे, अचानक होने वाले टकराव और नुकसान पहुंचाने वाली चीज़ों जैसी चीज़ों को छूट देकर, कम से कम और ज़ेन कॉन्टेक्स्ट को बेहतर बनाया जा सकता है. यह मान लेने पर कि वाहन सड़क पर रहेगा, इसका मतलब है कि ऑफ़-रोड ऑब्जेक्ट से होने वाले टकरावों को उचित रूप से अनदेखा किया जा सकता है. इसके अलावा, सड़क को स्पैर्स मिडलाइन के रूप में कोड में बदलने से, सड़क की सतह और गार्ड रेल की मदद से तेज़ टक्कर का पता लगाने के लिए शानदार ट्रिक उपलब्ध कराई जाती हैं. ये रास्ते, सड़क के बीच की दूरी की जांच पर आधारित होते हैं. इसके बाद ऑफ़-रोड ड्राइविंग और महंगी हो जाती है. हालांकि, गेमप्ले के संदर्भ को बेहतर तरीके से समझने के लिए यह एक और उदाहरण है.
मेमोरी फ़ुटप्रिंट को मैनेज करना
ब्राउज़र पर पाबंदी लगाने वाले एक अन्य संसाधन के रूप में, मेमोरी को सावधानी से मैनेज करना ज़रूरी है—भले ही, JavaScript कूड़ा-कचरा इकट्ठा करता हो. इसे आसानी से नज़रअंदाज़ किया जा सकता है, लेकिन गेम लूप में नई मेमोरी का थोड़ी-बहुत एलान करने पर भी 60 हर्ट्ज़ पर दौड़ते समय गंभीर समस्याएं हो सकती हैं. कचरे के बड़े संग्रह को पूरा करने में कई फ़्रेम लग सकते हैं, जिससे व्यक्ति का शरीर एक-दूसरे के साथ काम करना बंद कर देता है. इससे बचने के लिए, लूप मेमोरी को शुरू करते समय क्लास वैरिएबल में पहले से तय किया जा सकता है और हर फ़्रेम में रीसाइकल किया जा सकता है.
यह भी बेहद ज़रूरी है कि बहुत ज़्यादा डेटा स्ट्रक्चर, जैसे कि ज्यामिति और उनसे जुड़े डेटा बफ़र, आर्थिक रूप से मैनेज किए जाते हों. Slow Roads जैसे गेम में, ज़्यादातर ज्यामिति एक तरह के ट्रेडमिल पर होती है - जब कोई पुराना टुकड़ा दूर से आ जाता है, तो इसके डेटा स्ट्रक्चर को स्टोर किया जा सकता है और फिर से रीसाइकल किया जा सकता है. इसे ऑब्जेक्ट पूलिंग का डिज़ाइन पैटर्न कहते हैं.
इन तरीकों की मदद से, डेटा को आसानी से लागू किया जा सकता है. साथ ही, आसानी से इसका इस्तेमाल किया जा सकता है. उच्च-परफ़ॉर्मेंस वाले कॉन्टेक्स्ट में, इस बात का ध्यान रखना
ज़रूरी है कि किस तरह सुविधा की सुविधाएं कभी-कभी डेवलपर को फ़ायदा पहुंचाने के लिए क्लाइंट से पैसे लेती हैं. उदाहरण के लिए, Object.keys() या Array.map() जैसे तरीके बेहद आसान हैं. हालांकि, यह नज़रअंदाज़ करना आसान है कि हर तरीका अपनी रिटर्न वैल्यू के लिए एक नया अरे बनाता है. इस तरह के ब्लैक-बॉक्स की अंदरूनी परफ़ॉर्मेंस को समझकर, आप कोड को बेहतर बना सकते हैं. साथ ही, परफ़ॉर्मेंस को लेकर होने वाले स्नीकी वाले हिट से भी बचा जा सकता है.
प्रक्रिया के हिसाब से जनरेट की गई ऐसेट की मदद से, कॉन्टेंट लोड होने में लगने वाले समय को कम करना
हालांकि, गेम डेवलपर के लिए रनटाइम की परफ़ॉर्मेंस सबसे बड़ी चिंता होनी चाहिए, लेकिन वेब पेज के लोड होने में लगने वाले शुरुआती समय से जुड़े सामान्य नियम अब भी सही रहते हैं. जान-बूझकर ज़्यादा कॉन्टेंट ऐक्सेस करते समय उपयोगकर्ता ज़्यादा माफ़ करें. हालांकि, उपयोगकर्ता को अपने साथ जोड़े रखने की स्थिति में, साइट को लोड होने में ज़्यादा समय लगने से, इसका अनुभव खराब हो सकता है. गेम के दौरान अक्सर टेक्सचर, आवाज़, और 3D मॉडल के रूप में बड़ी ऐसेट की ज़रूरत होती है. साथ ही, जहां भी बारीकी को छोड़ा जा सकता है, वहां कम से कम इन्हें सावधानी से कंप्रेस किया जाना चाहिए.
इसके अलावा, प्रोसेस के आधार पर क्लाइंट पर ऐसेट जनरेट करने से, पहली बार में ज़्यादा समय तक ट्रांसफ़र होने से बचा जा सकता है. धीमे कनेक्शन वाले उपयोगकर्ताओं के लिए यह बहुत बड़ा फ़ायदा है. साथ ही, इससे डेवलपर को गेम बनाने के तरीके पर ज़्यादा सीधा कंट्रोल मिलता है. न सिर्फ़ शुरुआती लोडिंग चरण में, बल्कि अलग-अलग क्वालिटी सेटिंग के लिए जानकारी के लेवल में बदलाव करने पर भी, डेवलपर को ज़्यादा कंट्रोल मिलता है.
स्लो रोड्स की ज़्यादातर ज्यामिति, क्रम से और सामान्य तरीके से बनाई गई है. इसमें शेड की अलग-अलग बनावट के कॉम्बिनेशन बनाए गए हैं, ताकि बारीकियां साफ़ तौर पर दिख सकें. इसकी कमी यह है कि ये टेक्सचर भारी एसेट हो सकते हैं. हालांकि, यहां बचत करने के ज़्यादा मौके हैं. स्टोकेस्टिक टेक्सचरिंग जैसे तरीकों से, छोटे स्रोत वाले टेक्सचर की मदद से ज़्यादा बारीकियां हासिल की जा सकती हैं. साथ ही, सबसे बड़े लेवल पर, texgen.js जैसे टूल की मदद से पूरी तरह से क्लाइंट पर टेक्सचर जनरेट करना भी मुमकिन है. यही बात ऑडियो के लिए भी लागू होती है, क्योंकि Web Audio API के साथ ऑडियो नोड के साथ साउंड जनरेट करने की सुविधा मिलती है.
प्रोसेसल ऐसेट की मदद से, शुरुआती एनवायरमेंट को जनरेट करने में औसतन 3.2 सेकंड लगते हैं. छोटे अप-फ़्रंट डाउनलोड साइज़ का ज़्यादा से ज़्यादा फ़ायदा पाने के लिए, एक सिंपल स्प्लैश स्क्रीन पर नए लोगों का स्वागत किया जाता है. साथ ही, एक बटन दबाने के बाद महंगे सीन को शुरू करने की प्रक्रिया को टाल दिया जाता है. यह डाइनैमिक तौर पर लोड होने वाली ऐसेट का फ़ालतू ट्रांसफ़र कम करते हुए, बाउंस होने वाले सेशन के लिए आसान बफ़र के तौर पर भी काम करता है.
देर से ऑप्टिमाइज़ेशन के लिए तेज़ी से काम करना
मैंने हमेशा माना है कि Slow Roads के कोडबेस को प्रयोग के तौर पर इस्तेमाल किया जा रहा है. इसलिए, मैंने इसे बनाने की दिशा में तेज़ी से कदम उठाया है. जटिल और तेज़ी से बदलते सिस्टम आर्किटेक्चर के साथ काम करते समय, यह अनुमान लगाना मुश्किल हो सकता है कि अहम दिक्कतें कहां आ सकती हैं. सही सुविधाओं को तेज़ी से लागू करने के बजाय, इन सुविधाओं को तेज़ी से लागू करने पर फ़ोकस किया जाना चाहिए. इसके बाद, सिस्टम को ऑप्टिमाइज़ करने के लिए पीछे की ओर काम किया जाना चाहिए जहां इसकी असल में ज़रूरत होती है. इस चरण के लिए, Chrome DevTools में परफ़ॉर्मेंस प्रोफ़ाइलर बहुत बहुत काम का है. इससे, गेम के पुराने वर्शन में आ रही कुछ बड़ी समस्याओं का पता लगाने में मुझे मदद मिली है. डेवलपर के रूप में आपका समय बहुत अहमियत रखता है. इसलिए, पक्का करें कि आप उन समस्याओं पर सोच-विचार करने में अपना समय न बर्बाद करें जो अहम या ग़ैर-ज़रूरी साबित हो सकती हैं.
उपयोगकर्ता अनुभव पर नज़र रखना
इन सभी तरकीबों को लागू करते समय, यह पक्का करना ज़रूरी है कि गेम उम्मीद के मुताबिक परफ़ॉर्म कर रहा हो. किसी भी गेम डेवलपमेंट का अहम पहलू होता है कि वेब गेम में कई तरह के हार्डवेयर मौजूद हों. हालांकि, वेब गेम का दायरा काफ़ी बड़ा हो सकता है. इसमें टॉप-एंड डेस्कटॉप और दशकों पुराने मोबाइल डिवाइस, दोनों एक साथ शामिल हैं. इसका सबसे आसान तरीका है कि आप अपने कोड बेस में सबसे संभावित रुकावटों से निपटने के लिए सेटिंग ऑफ़र करें, जो कि जीपीयू और सीपीयू से जुड़े टास्क के लिए है, जैसा कि आपके प्रोफ़ाइलर ने बताया है.
हालांकि, खुद की मशीन पर प्रोफ़ाइल बनाने से सिर्फ़ इतना ही कवर किया जा सकता है. इसलिए, बेहतर होगा कि आप अपने उपयोगकर्ताओं के साथ फ़ीडबैक लूप को खत्म कर लें. 'धीमी सड़कों' के लिए मैं आसान आंकड़े चलाता/चलाती हूं, जो स्क्रीन रिज़ॉल्यूशन जैसे प्रासंगिक कारकों के साथ परफ़ॉर्मेंस की रिपोर्ट देता है. ये आंकड़े analytics.io का इस्तेमाल करके, बेसिक नोड बैकएंड को भेजे जाते हैं. साथ ही, इन-गेम फ़ॉर्म के ज़रिए सबमिट किए गए लोगों की ओर से मिले लिखित सुझाव के साथ-साथ इन्हें भी भेजा जाता है. शुरुआती दिनों में, इन आंकड़ों में कई अहम समस्याएं मिली हैं, जिन्हें UX में आसान बदलावों से कम किया जा सकता है. जैसे, लगातार कम FPS (फ़्रेम प्रति सेकंड) का पता चलने पर सेटिंग मेन्यू को हाइलाइट करना या चेतावनी देना कि अगर परफ़ॉर्मेंस बहुत खराब है, तो उपयोगकर्ता को हार्डवेयर से तेज़ी लाने की सुविधा चालू करनी पड़ सकती है.
आगे धीमी सड़कें
इन सभी तरीकों को अपनाने के बाद भी, खिलाड़ियों की काफ़ी संख्या कम होती है, लेकिन उन्हें कम सेटिंग पर खेलना ज़रूरी होता है. मुख्य रूप से, ऐसे लाइटवेट डिवाइस होते हैं जिनमें जीपीयू नहीं होता. उपलब्ध क्वालिटी सेटिंग की वजह से परफ़ॉर्मेंस का बंटवारा समान रूप से होता है, लेकिन सिर्फ़ 52% प्लेयर 55 FPS (फ़्रेम प्रति सेकंड) से ज़्यादा फ़्रेम रेट हासिल कर पाते हैं.
अच्छी बात यह है कि आपके पास अब भी ऐसी कई सुविधाएं हैं जिनकी मदद से, गेम की परफ़ॉर्मेंस बेहतर की जा सकती है. जीपीयू की मांग को कम करने के लिए रेंडरिंग की कुछ और तरकीबें जोड़ने के साथ-साथ, मुझे उम्मीद है कि आने वाले समय में, एनवायरमेंट जनरेट करने के साथ-साथ वेब वर्कर के साथ प्रयोग करने की कोशिश की जाएगी. ऐसा हो सकता है कि कोड बेस में WASM या WebGPU को शामिल करने की ज़रूरत पड़े. अगर मेरे पास कोई बड़ा कमरा है, तो उससे बेहतर और ज़्यादा विविधता वाली जगह बन पाएगी. यह प्रोजेक्ट के बाकी बचे कामों का लक्ष्य होगा.
शौक के तौर पर शुरू होने वाले प्रोजेक्ट की वजह से, Slow Roads चैनल पर, यह दिखाना एक शानदार तरीका साबित हुआ है कि हैरतअंगेज़ तरीके से विस्तार से काम करने वाले, बेहतर परफ़ॉर्म करने वाले, और लोकप्रिय ब्राउज़र गेम कितने काम के हो सकते हैं. अगर मैंने WebGL में आपकी रुचि बढ़ाने में कामयाब रहा है, तो जान लें कि तकनीकी रूप से धीमी सड़कें, इसकी सभी क्षमताओं का काफ़ी अच्छा उदाहरण है. मैं पाठकों को Three.js शोकेस को एक्सप्लोर करने के लिए प्रेरित करता हूं. खास तौर पर, जिन लोगों को वेब गेम डेवलप करने में दिलचस्पी है उनका webgamedev.com पर मौजूद समुदाय में आपका स्वागत है.