ब्राउज़र-नेटिव गेम अब गंभीर हो रहे हैं: ओपन-सोर्स कॉम्बैट प्रोजेक्ट्स क्या दिखाते हैं

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

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

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

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

मुझे मिले सबसे मजबूत प्रोजेक्ट

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

नतीजों ने मुझे क्यों चौंकाया

चौंकाने वाली बात केवल यह नहीं थी कि ग्राफिक्स अच्छे दिखते थे। एक पॉलिश्ड सीन को रेंडर करना गेम डेवलपमेंट का केवल एक हिस्सा है। जो प्रोजेक्ट अलग दिखे, वे ऐसे सिस्टम लागू कर रहे थे जिन्हें विश्वसनीय तरीके से नकली बनाना कठिन है: इनपुट बफरिंग, कॉम्बैट स्टेट ट्रांजिशन, टार्गेट चयन, अटैक मूवमेंट, एनीमेशन टाइमिंग, हिट डिटेक्शन, दुश्मन की प्रतिक्रिया, डिफेंसिव विंडो, कैमरा व्यवहार और इम्पैक्ट फीडबैक।

इससे एक उपयोगी अंतर स्पष्ट होता है:

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

ये अंतर सबसे मजबूत प्रोजेक्ट्स में बार-बार दिखाई दिए, और README में लगे रेंडरर लोगो से अधिक महत्वपूर्ण हैं।

Voxel Musou: ब्राउज़र कॉम्बैट की वास्तविक मूव-ग्रामर हो सकती है

Voxel Musou उन सबसे स्पष्ट उदाहरणों में से एक था जो दिखाता है कि ब्राउज़र कॉम्बैट का मतलब अब केवल एक बटन से बंधी एक अटैक एनीमेशन होना जरूरी नहीं है। इसका सोर्स mike007jd/voxel-musou पर उपलब्ध है।

प्रोजेक्ट पूरी तरह लीनियर कॉम्बो की जगह लंबी सामान्य अटैक चेन और चार्ज ब्रांच का उपयोग करता है। आर्किटेक्चर के स्तर पर यह महत्वपूर्ण है, क्योंकि सिस्टम को इस तरह मॉडल किया जा सकता है:

current move + buffered input + combat state -> next move

यह लगातार बढ़ते विशेष मामलों वाली शर्तों के संग्रह की तुलना में कैरेक्टर-एक्शन गेम के लिए कहीं बेहतर आधार है। यह एरियल अटैक, विशेष सीक्वेंस, कई कैरेक्टर किट, बॉस व्यवहार, हिट-स्टॉप और दुश्मनों के बड़े समूहों से कॉम्बैट भी दिखाता है।

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

Long Wind: आधुनिक ब्राउज़र एक्शन गेम के सबसे करीब

Long Wind सबसे मजबूत ऑल-इन-वन रेफरेंस में से एक था, क्योंकि यह थर्ड-पर्सन मूवमेंट को लाइट और हेवी अटैक, लॉक-ऑन, गार्ड, परफेक्ट पैरी, डॉज इन्वल्नरेबिलिटी, पोश्चर प्रेशर, एक्जीक्यूशन, लॉन्च और नॉकडाउन रिएक्शन, प्रोजेक्टाइल, बॉस और कई दुश्मन आर्केटाइप के साथ जोड़ता है। इसका सोर्स jbang2004/long-wind पर उपलब्ध है।

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

मोशन वॉर्पिंग उस समस्या को हल करती है जिसे वेब डेमो अक्सर अनदेखा करते हैं

Samurai Third-Person Template ThreeJS खास तौर पर दिलचस्प है, क्योंकि यह थर्ड-पर्सन मेली की एक क्लासिक समस्या को संबोधित करता है। इसका सोर्स achrefelouafi/SamuraiThirdPersonTemplateThreeJS पर उपलब्ध है।

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

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

महत्वपूर्ण अंतर यह है:

animation intent != movement authority

कैरेक्टर पहले से बनाई गई एनीमेशन के दृश्य इरादे को बनाए रख सकता है, जबकि वास्तव में कैरेक्टर कहाँ जाएगा इस पर गेमप्ले कंट्रोलर की अथॉरिटी बनी रहती है।

कोलिजन डिटेक्शन और हिट वैलिडेशन अलग समस्याएँ हैं

Stick & Steel एक बहुत अलग कॉम्बैट मॉडल की पड़ताल करता है। इसका सोर्स Rabneba/stick-steel पर उपलब्ध है।

तलवार को मुख्य रूप से डैमेज वॉल्यूम वाली एनीमेशन मानने के बजाय यह प्रोजेक्ट हथियारों को वास्तविक भौतिक मौजूदगी देता है। संपर्क की गति, हथियार की दिशा, शरीर का क्षेत्र, गार्ड, टक्कर, नॉकडाउन और हथियार छूटना—सब मायने रखते हैं।

सबसे आसानी से दूसरे प्रोजेक्ट्स में लागू होने वाला सबक यह नहीं है कि हर एक्शन गेम में पूरी तरह भौतिक हथियार होने चाहिए। सबक यह है:

कोलिजन आपको बताता है कि दो चीजें छुईं। यह नहीं बताता कि कोई अर्थपूर्ण हिट हुई या नहीं।

एक विश्वसनीय कॉम्बैट सिस्टम को अक्सर दूसरी परत की जरूरत होती है, जो यह तय करे कि संपर्क में पर्याप्त गति थी या नहीं, दिशा सही थी या नहीं, हथियार का सही हिस्सा लगा या नहीं, समय सही था या नहीं और लक्ष्य की अवस्था वैध थी या नहीं, ताकि उसे डैमेज माना जा सके।

केंद्रीकृत कॉम्बैट रिजॉल्यूशन जटिल डिफेंस को समझना आसान बनाता है

Hollowmere, जिसका सोर्स euuuuuuan/hollowmere-public पर है, दृश्य चमक-दमक की तुलना में सॉफ्टवेयर आर्किटेक्चर के कारण अधिक अलग दिखा।

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

एक अधिक साफ मानसिक मॉडल यह है:

incoming attack -> evade | parry | hit

रेंडरर को नतीजा दिखाना चाहिए, कॉम्बैट की सच्चाई का दूसरा संस्करण गढ़ना नहीं चाहिए।

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

गेम फील सजावट नहीं, एक इंजीनियरिंग सिस्टम है

Fabled Revolutions, जिसका सोर्स ericrius1/FabledRevolutions पर है, ठीक इसलिए उपयोगी है क्योंकि यह उन प्रभावों को अलग करके दिखाता है जो हिट को वजनदार महसूस कराते हैं।

तार्किक रूप से सही कॉम्बैट सिस्टम भी कमजोर महसूस हो सकता है। कोलिजन सटीक हो सकता है, डैमेज सही फ्रेम पर लागू हो सकता है, और फिर भी नतीजा ऐसा लग सकता है जैसे दो मॉडल एक-दूसरे के आर-पार निकल गए।

महसूस होने वाला इम्पैक्ट अक्सर थोड़े समय रहने वाले कई प्रभावों की परत से बनता है:

• हिट-स्टॉप;
• कैमरा शेक या किक;
• हथियार के ट्रेल;
• इम्पैक्ट पार्टिकल;
• हर्ट फ्लैश;
• नॉकबैक;
• एनीमेशन रिएक्शन;
• सही समय पर आने वाली ध्वनि।

यह एक और उपयोगी अंतर सुझाता है: कॉम्बैट की शुद्धता, कॉम्बैट का फील नहीं है। ब्राउज़र गेम को दोनों चाहिए।

कॉम्बैट क्वालिटी का मुख्य संकेतक रेंडरर नहीं था

रिसर्च में दिखे अधिक दिलचस्प पैटर्न में से एक यह था कि सबसे अच्छा कॉम्बैट इस बात से तय नहीं हुआ कि कोई प्रोजेक्ट सबसे नया रेंडरिंग API उपयोग करता था या नहीं।

Three.js बार-बार सामने आया। कुछ प्रोजेक्ट WebGPU-संबंधित रेंडरिंग टेक्नोलॉजी इस्तेमाल करते थे, जबकि दूसरे पारंपरिक WebGL-आधारित स्टैक पर थे। फिजिक्स इंजन, TypeScript, JavaScript, Vite, WebAssembly और अलग-अलग रेंडरिंग तरीके पूरे रिसर्च में दिखाई दिए।

लेकिन उन्नत कॉम्बैट अधिक लगातार आर्किटेक्चर पर निर्भर था: फिक्स्ड-स्टेप सिमुलेशन, स्पष्ट स्टेट, भरोसेमंद टार्गेटिंग, एनीमेशन ओनरशिप की समझदार व्यवस्था, डेटा-ड्रिवन मूव्स, केंद्रीकृत डैमेज रिजॉल्यूशन और अच्छा इम्पैक्ट फीडबैक।

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

ब्राउज़र वितरण समीकरण क्यों बदल देता है

ब्राउज़र का एक ऐसा फायदा है जिसका ग्राफिक्स से बहुत कम लेना-देना है: वितरण में बेहद कम घर्षण।

पारंपरिक गेम अक्सर खोज और इंटरैक्शन के बीच कई चरण रखते हैं: स्टोर पेज ढूँढिए, बड़ा पैकेज डाउनलोड कीजिए, इंस्टॉल कीजिए, लॉन्च कीजिए, अपडेट का इंतजार कीजिए और कभी-कभी अर्थपूर्ण गेमप्ले तक पहुँचने से पहले अकाउंट भी बनाइए।

ब्राउज़र गेम इस रास्ते को एक लिंक तक घटा सकता है।

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

यह फायदा खास तौर पर प्रयोगात्मक गेम्स और स्वतंत्र डेवलपमेंट में महत्वपूर्ण हो जाता है। ब्राउज़र केवल रनटाइम नहीं है; यह एक वितरण प्रणाली भी है।

ब्राउज़र अभी कहाँ हारता है

इस रिसर्च ने मुझे यह नहीं मनवाया कि ब्राउज़र ने नेटिव गेम प्लेटफॉर्म की जगह ले ली है। ऐसा नहीं हुआ है।

कई सीमाएँ अभी भी महत्वपूर्ण हैं:

• बड़े एसेट पेलोड। अगर गेम को शुरुआत में बहुत बड़ा डाउनलोड चाहिए, तो तुरंत पहुँच अब तुरंत महसूस नहीं होती।
• मेमोरी दबाव। ब्राउज़र को दूसरे टैब और ऑपरेटिंग सिस्टम के साथ रहना पड़ता है, और मेमोरी का व्यवहार समर्पित नेटिव प्रोसेस की तुलना में कम अनुमानित होता है।
• मोबाइल थर्मल सीमाएँ। तकनीकी रूप से काम करने वाला 3D गेम भी लंबे सेशन में बुरी तरह थ्रॉटल हो सकता है।
• ब्राउज़र के अंतर। ग्राफिक्स, ऑडियो, pointer lock, फुलस्क्रीन व्यवहार, कंट्रोलर और परफॉर्मेंस गुण पूरी तरह एक जैसे नहीं होते।
• शेडर और एसेट तैयारी। अगर पाइपलाइन सावधानी से डिजाइन न की गई हो, तो कम्पाइलेशन या अपलोड काम अब भी दिखाई देने वाले स्टॉल पैदा कर सकते हैं।
• ऑफलाइन और लोकल पर्सिस्टेंस की सीमाएँ। नेटिव एप्लिकेशन बड़े लोकल इंस्टॉलेशन और फाइलों पर अधिक सीधा नियंत्रण बनाए रखते हैं।
• प्रतिस्पर्धी सुरक्षा। जब क्लाइंट एक वेब एप्लिकेशन हो, तब गंभीर एंटी-चीट और hostile-client मान्यताएँ काफी कठिन हो जाती हैं।

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

AI प्रोटोटाइप से URL तक की लूप को बहुत छोटा कर देती है

यहाँ AI प्रासंगिक है, लेकिन इसलिए नहीं कि वह जादुई तरीके से एक वाक्य को तैयार, उच्च-गुणवत्ता वाले गेम में बदल देती है। अधिक यथार्थवादी फायदा इटरेशन की गति है।

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

AI इनमें से कई लूप छोटे कर सकती है। वेब वितरण के साथ मिलकर वर्कफ्लो असामान्य रूप से सीधा हो जाता है:

idea -> prototype -> deploy -> open URL -> test -> iterate

ब्राउज़र पहले ही डिप्लॉयमेंट तेज करता है। AI उसी लूप के इम्प्लीमेंटेशन पक्ष को भी तेज कर सकती है।

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

वेब डेवलपर्स के लिए इसका क्या मतलब है

वेब डेवलपमेंट और गेम डेवलपमेंट के बीच की सीमा कम कठोर होती जा रही है।

एक गंभीर ब्राउज़र गेम अब परिचित वेब टूलिंग का उपयोग करते हुए क्लासिक गेम-इंजीनियरिंग अवधारणाओं की जरूरत भी रख सकता है:

• फिक्स्ड सिमुलेशन स्टेप;
• स्टेट मशीन;
• इनपुट बफरिंग;
• एनीमेशन ग्राफ;
• स्पेशल क्वेरी;
• फिजिक्स;
• फ्रेम बजट;
• GPU रिसोर्स मैनेजमेंट;
• ऑडियो टाइमिंग;
• डिटरमिनिस्टिक सिस्टम।

साथ ही, ब्राउज़र को टार्गेट करने वाले गेम डेवलपर्स को वे चीजें मिलती हैं जिनमें वेब पहले से असाधारण रूप से अच्छा है: URL, तुरंत डिप्लॉयमेंट, CDN डिलीवरी, तेज अपडेट, टेलीमेट्री, अकाउंट सिस्टम, रेस्पॉन्सिव इंटरफेस और बिना घर्षण के शेयरिंग।

इस रिसर्च ने मेरा अपना मानसिक मॉडल बदल दिया। अब मैं ब्राउज़र गेम्स को मुख्य रूप से नेटिव गेम्स के सरल संस्करण के रूप में नहीं देखता। मैं ब्राउज़र को एक ऐसे तेजी से सक्षम होते गेम प्लेटफॉर्म के रूप में देखता हूँ जिसकी ताकतों का सेट अलग है: तुरंत वितरण, तेज इटरेशन, तेजी से गंभीर होती 3D क्षमताएँ और एक विशाल मौजूदा डेवलपमेंट इकोसिस्टम।

वेब केवल कहीं और बनाए गए गेम्स को दिखाने में बेहतर नहीं हो रहा है। यह तेजी से ऐसी जगह बन रहा है जहाँ गंभीर गेम सिस्टम सीधे डिजाइन, इम्प्लीमेंट, टेस्ट, वितरित और खेले जा सकते हैं।